[Nut-upsuser] Return on experience with an Emerson/Liebert GXT3
clepple at gmail.com
Mon Oct 6 13:04:45 UTC 2014
On Oct 6, 2014, at 3:31 AM, paul.chavent at fnac.net wrote:
> On 10/03/2014 03:42 PM, Charles Lepple wrote:> On Oct 3, 2014, at 7:50 AM, paul.chavent at fnac.net wrote:
>> This is what I was referring to (from the belkin-hid log):
>> 1.325782 Report[buf]: (5 bytes) => 05 53 00 48 00
>> 1.325799 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x05, Offset: 16, Size: 16, Value: 0
>> 1.325814 ConfigVoltage = 0 -> assuming correction factor = 1e+08
>> You may need to bump the debug level to 5 to see the full exponent processing (cf get_unit_expo() in libhid.c). Please gzip the log - it will be big.
> See attachment
I think I see what is going on.
0.368670 Report[buf]: (5 bytes) => 05 4e 00 48 00
0.368698 PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
0.368723 Unit = 00000000, UnitExp = 0
0.368747 Exponent = 0
0.368776 Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x05, Offset: 0, Size: 16, Value: 0
0.368805 Input/OutputVoltage = 0 -> assuming correction factor = 1e+07
offset 0, size 16 in Report[buf] is '4e 00' (0x004e == 78) but LogMax is 1 (and it should be 0xffff to match the size).
This is annoying, because it means that we can't simply scale the values. I don't know of an easy way to fix this, short of adding a way to override the HID Report Descriptor.
While we're here, does a battery voltage of 72V nominal sound reasonable for your unit?
>> I would prefer not to move things around too much, unless we can get people to test the other models. I realize it is annoying that the subdriver names do not match the brands, but the idea is that the matching happens automatically.
>> Right, in usbhid-ups.c, the liebert_subdriver entry is after the belkin_subdriver.
> OK, i suppose that this issue will be solved when all the liebert devices will be moved in the liebert-hid driver, in the future.
I'm not sure I understand why we would want do this. We really have two different "Liebert" cases: the rebranded Phoenixtec hardware (which basically complies with the HID PDC spec, although does not provide much information), and the buggy Liebert/Belkin hardware. Call it inertia or laziness, but combining the two means lots of extra testing to make sure we do not break existing device support.
>>> (3) in the hid report, we have several items with the same name (see attached lsusb dump).
>>> How it is handled by the lookup table ? Is there any indexing possible ?
>> I will have more time to look at this later, but at a quick glance, I did not see what you were referring to (the lsusb dump, while comprehensive, is hard to parse). Bear in mind that many vendors duplicate Input and Feature HID elements.
> Please find in attachment the hid report descriptor : there are several Charging/Discharging fields.
> I'm wondering if it gives the status of the different (additional) battery composing the system ?
If so, they are not reporting the presence of such a battery:
0.428188 Report[buf]: (2 bytes) => 0c 05
0.428215 PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
0.428240 Unit = 00000000, UnitExp = 0
0.428264 Exponent = 0
0.428290 hid_lookup_path: 00840004 -> UPS
0.428316 hid_lookup_path: 00840024 -> PowerSummary
0.428344 hid_lookup_path: 008500d1 -> BatteryPresent
0.428373 Path: UPS.PowerSummary.BatteryPresent, Type: Input, ReportID: 0x0c, Offset: 4, Size: 1, Value: 0
>>> (4) would it be useful to add missing items to the driver's hid to nu lookup table (even in the the unmapped part) ?
>> Sure, although the unmapped entries are just for debugging - we will want to eventually rename them to official NUT names, or comment them out again before checking the driver in to version control.
> Is there a list of all official NUT names (i haven't searched yet) ?
- Charles Lepple
More information about the Nut-upsuser