Nut upsuser - Oct 2014 - Return on experience with an Emerson/Liebert GXT3

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>

On Oct 10, 2014, at 6:44 AM, paul.chavent at fnac.net wrote:
> Please find attached the patches i have applied to the current master.
Merged to master, as of commit f5462ebb. Thanks again!

-- 
Charles Lepple
clepple at gmail