2014-11-09 9:59 GMT-03:00 Charles Lepple <clepple at gmail.com>:> On Nov 9, 2014, at 6:58 AM, Marcelo Fernandez <marcelo.fidel.fernandez at gmail.com> wrote: > >> I'm attaching a new debug log with this modification, just in case, >> but I'm still seeing the lines you've pointed at: >> >> 0.062308 Path: UPS.PowerSummary.Voltage, Type: Feature, >> ReportID: 0x05, Offset: 0, Size: 16, Value: 1 >> 0.062336 Report[buf]: (5 bytes) => 05 51 00 48 00 >> 0.062352 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, >> ReportID: 0x05, Offset: 16, Size: 16, Value: 0 >> 0.062379 ConfigVoltage = 0 -> assuming correction factor = 1e+08 > > Strange, I would have thought that the "Value: 0" would show the actual number. Does it look like drivers/libhid.o got rebuilt?Yes, at first I thought the same (that I did something wrong), but everything seems ok: root at nut:/home/marcelo/nut-2.7.2.5/drivers# ls libhid* -lh -rw-r--r-- 1 marcelo marcelo 28K nov 9 08:52 libhid.c -rw-r--r-- 1 marcelo marcelo 5,1K nov 6 11:08 libhid.h -rw-rw-r-- 1 marcelo marcelo 65K nov 9 08:52 libhid.o I edited the source file, did a "make" and "sudo make install". Then, I executed "/usr/local/ups/sbin/upsdrvctl start", "/usr/local/ups/sbin/upsd", and "/usr/local/ups/bin/upsc liebert" to get that output. I also have plugged and configured another UPS in that system, an APC via serial port, but it uses another driver and it doesn't seem to interfere with this one.> Can you retry with debug level 5 (-DDDDD) just once?Yes, no problem! I'd like this UPS to be well supported under Nut. :-) Thank you -- Marcelo F. Fern?ndez Buenos Aires, Argentina Lic. en Sistemas de Informaci?n E-Mail: marcelo.fidel.fernandez at gmail.com Blog: http://blog.marcelofernandez.info Twitter: http://twitter.com/fidelfernandez -------------- next part -------------- A non-text attachment was scrubbed... Name: liebert-3.log.gz Type: application/x-gzip Size: 18428 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141109/6f12b070/attachment-0001.bin>
On Nov 9, 2014, at 8:13 AM, Marcelo Fernandez <marcelo.fidel.fernandez at gmail.com> wrote:> 2014-11-09 9:59 GMT-03:00 Charles Lepple <clepple at gmail.com>: >> >> Strange, I would have thought that the "Value: 0" would show the actual number. Does it look like drivers/libhid.o got rebuilt? > > Yes, at first I thought the same (that I did something wrong), but > everything seems ok:My apologies, you did say the numbers looked different. Here's how the numbers get interpreted: In hidparser.c:GetValue(), the bits get extracted from the report (example: "Report[buf]: (5 bytes) => 05 51 00 48 00"). For ConfigVoltage, the offset is 16 bits, and we skip the first 8 (the report ID; 05 in this case). The size is 16 bits, so that is "48 00" -> "0048", which should be 72. However, this UPS still has a logical Min/Max of 0/1 in effect when the parser reads this. Can you add the attached patch to your tree? I guess leave the other line commented out; I think there is some other scaling that needs to be addressed. The proper way to fix this is to override the HID descriptor, and that will take a little more coding. -- Charles Lepple clepple at gmail -------------- next part -------------- A non-text attachment was scrubbed... Name: hidparser_fix_logical_max.patch Type: application/octet-stream Size: 747 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141109/b29c662e/attachment.obj>
2014-11-09 11:39 GMT-03:00 Charles Lepple <clepple at gmail.com>:> On Nov 9, 2014, at 8:13 AM, Marcelo Fernandez <marcelo.fidel.fernandez at gmail.com> wrote: > >> 2014-11-09 9:59 GMT-03:00 Charles Lepple <clepple at gmail.com>: >>> >>> Strange, I would have thought that the "Value: 0" would show the actual number. Does it look like drivers/libhid.o got rebuilt? >> >> Yes, at first I thought the same (that I did something wrong), but >> everything seems ok: > > My apologies, you did say the numbers looked different. > > Here's how the numbers get interpreted: > > In hidparser.c:GetValue(), the bits get extracted from the report (example: "Report[buf]: (5 bytes) => 05 51 00 48 00"). For ConfigVoltage, the offset is 16 bits, and we skip the first 8 (the report ID; 05 in this case). The size is 16 bits, so that is "48 00" -> "0048", which should be 72. > > However, this UPS still has a logical Min/Max of 0/1 in effect when the parser reads this. > > Can you add the attached patch to your tree? I guess leave the other line commented out; I think there is some other scaling that needs to be addressed. The proper way to fix this is to override the HID descriptor, and that will take a little more coding.Sure, let's do it: marcelo at nut:~/nut-2.7.2.5$ patch -p1 < hidparser_fix_logical_max.patch (Stripping trailing CRs from patch; use --binary to disable.) patching file drivers/hidparser.c plus make and make install. Now seems the values are well obtained, take a look: root at nut:/usr/local/ups/bin# ./upsc liebert battery.charge: 100 battery.charge.low: 20 battery.charge.warning: 20 battery.type: PbAc battery.voltage: 81.0 battery.voltage.nominal: 72.0 device.mfr: Emerson Network Power device.model: Liebert GXT3 device.serial: 1226603098AF453 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.7.2.5 driver.version.data: Belkin/Liebert HID 0.17 driver.version.internal: 0.38 ups.mfr: Emerson Network Power ups.model: Liebert GXT3 ups.productid: 0008 ups.serial: 1226603098AF453 ups.status: OL CHRG ups.vendorid: 10af Regards -- Marcelo F. Fern?ndez Buenos Aires, Argentina Lic. en Sistemas de Informaci?n E-Mail: marcelo.fidel.fernandez at gmail.com Blog: http://blog.marcelofernandez.info Twitter: http://twitter.com/fidelfernandez