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

paul.chavent at fnac.net paul.chavent at fnac.net
Fri Oct 10 10:44:16 UTC 2014


Hi

On 10/06/2014 03:04 PM, Charles Lepple wrote:> 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?
> 

Yes, that's it.

>> 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.
> 

Ok, i didn't understand the purpose of the liebert-hid driver. 
Moreover, I don't see any problem with the actual code organization, I'd just need to understand.

>> 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
> 

Yes the presence of the battery isn't reported as i expected.

> 
>>>> (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.

Please find attached the patches i have applied to the current master.

>>
>> Is there a list of all official NUT names (i haven't searched yet) ?
>>
> http://www.networkupstools.org/docs/developer-guide.chunked/apas01.html
> 

Thank you.

Paul.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drivers-fix-possible-memory-leak.patch
Type: text/x-patch
Size: 637 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141010/97f15d8c/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-drivers-add-Liebert-GXT3-device.patch
Type: text/x-patch
Size: 2475 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141010/97f15d8c/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-drivers-Liebert-GXT3-workaround.patch
Type: text/x-patch
Size: 652 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141010/97f15d8c/attachment-0005.bin>


More information about the Nut-upsuser mailing list