paul.chavent at fnac.net
2014-Oct-06 07:31 UTC
[Nut-upsuser] Return on experience with an Emerson/Liebert GXT3
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 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.>> (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 ?>> (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) ? Cheers. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hid-report-descriptor-fields.txt URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141006/c2aee3db/attachment-0001.txt> -------------- next part -------------- A non-text attachment was scrubbed... Name: usbhid-ups.log.gz Type: application/x-gzip Size: 19758 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141006/c2aee3db/attachment-0001.bin>
Charles Lepple
2014-Oct-06 13:04 UTC
[Nut-upsuser] Return on experience with an Emerson/Liebert GXT3
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 attachmentI 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/