[Nut-upsuser] Return on experience with an Emerson/Liebert GXT3

[Charles Lepple]

On Oct 6, 2014, at 3:31 AM, paul.chavent at fnac.net wrote:

> Hi
> 
> 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) ?
> 
http://www.networkupstools.org/docs/developer-guide.chunked/apas01.html

-- 
- Charles Lepple
http://ghz.cc/charles/