[Nut-upsuser] There is no voltage information
Jim Klimov
jimklimov+nut at gmail.com
Mon Mar 25 10:19:56 GMT 2024
Hello all,
I think I've found the "regression" in Belkin/Liebert USB HID support
which worked for NUT v2.7.4 and reports zero voltages in 2.8.0 -- it was
actually caused by a bug fix: practically the only functional difference
per `git diff v2.7.4..v2.8.0 drivers/belkin-hid.c` is a change from `abs()`
to `fabs()` in order-of-magnitude comparisons like `if( abs(value - 1e-7) <
1e-9 ) {...}` which feel odd on their own, discussed in
https://github.com/networkupstools/nut/issues/2370
The old code worked because `abs()` is for `int` numbers, and the
miniscule argument became an always-zero after casting (which is less than
`10^-9`), and for existing devices it just happened to be the correct
codepath to pick an exponent for USB readings. The new code made the
comparisons mathematically correct, to work on `double` precision numbers
using `fabs()` (to not confuse with `fabsf()` for `float` types, go
figure). And boom! Something no longer clicks for `1.39e-06 => 13.9V` and
`2.206e-05 => 220V` (with correction factor `1e7`).
Obligatory inspiring motivator : https://xkcd.com/1172/
Thanks to Mr. Fischer for the right logs (and version-dissection
findings) at the right time :)
Jim Klimov
On Mon, Mar 25, 2024 at 7:41 AM Juan Carlos Fischer <
juancarlos.fischer at gmail.com> wrote:
> Hello Jim!
> First of all, allow me to thank you for your time and invaluable help.
> Exactly arm v7l are 32 bit. I will conduct several tests and keep you
> informed.
>
> On the other hand this is what I got
> pi at raspberrypi:~ $ sudo /lib/nut/usbhid-ups -DDDDDD -a Liebert
> 0.000000 [D3] do_global_args: var='maxretry' val='3'
> 0.001309 [D3] do_global_args: var='user' val='nut'
> 0.001604 [D1] Overriding previously specified user 'nut' with 'nut'
> specified in global section
> 0.002196 [D3] main_arg: var='driver' val='usbhid-ups'
> 0.002280 [D3] main_arg: var='port' val='auto'
> 0.002360 [D5] send_to_all: SETINFO driver.parameter.port "auto"
> 0.006042 [D3] main_arg: var='vendorid' val='10AF'
> 0.006172 [D5] send_to_all: SETINFO driver.parameter.vendorid "10AF"
> 0.006402 [D3] main_arg: var='productid' val='0001'
> 0.006490 [D5] send_to_all: SETINFO driver.parameter.productid "0001"
> 0.006563 [D3] main_arg: var='bus' val='001'
> 0.006646 [D5] send_to_all: SETINFO driver.parameter.bus "001"
> 0.006720 [D3] main_arg: var='desc' val='PSA UPS'
> 0.006792 [D3] main_arg: var='pollinterval' val='15'
> 0.006980 [D1] debug level is '6'
> 0.009706 [D5] send_to_all: SETINFO device.type "ups"
> 0.009873 [D2] Initializing an USB-connected UPS with library
> libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication
> driver (libusb 1.0)' ver='0.43')
> 0.009942 [D1] upsdrv_initups (non-SHUT)...
> 0.064656 [D2] Checking device 1 of 12 (2109/0813)
> 0.064792 [D1] Failed to open device (2109/0813), skipping: Access
> denied (insufficient permissions)
> 0.064851 [D2] Checking device 2 of 12 (1058/2620)
> 0.064956 [D1] Failed to open device (1058/2620), skipping: Access
> denied (insufficient permissions)
> 0.065018 [D2] Checking device 3 of 12 (2109/0813)
> 0.065074 [D1] Failed to open device (2109/0813), skipping: Access
> denied (insufficient permissions)
> 0.065122 [D2] Checking device 4 of 12 (1D6B/0003)
> 0.065171 [D1] Failed to open device (1D6B/0003), skipping: Access
> denied (insufficient permissions)
> 0.065240 [D2] Checking device 5 of 12 (045E/00F5)
> 0.065275 [D1] Failed to open device (045E/00F5), skipping: Access
> denied (insufficient permissions)
> 0.065308 [D2] Checking device 6 of 12 (10AF/0001)
> 0.077166 [D2] - VendorID: 10af
> 0.077216 [D2] - ProductID: 0001
> 0.077277 [D2] - Manufacturer: Emerson Network Power
> 0.077332 [D2] - Product: LiebertPSA
> 0.077372 [D2] - Serial Number:
> 0.077391 [D2] - Bus: 001
> 0.077427 [D2] - Device: unknown
> 0.077481 [D2] - Device release number: 0014
> 0.077560 [D2] Trying to match device
> 0.077600 [D2] match_function_subdriver (non-SHUT mode): matching a
> device...
> 0.077664 [D3] match_function_regex: matching a device...
> 0.077905 [D2] Device matches
> 0.077972 [D2] Reading first configuration descriptor
> 0.078055 [D3] libusb_kernel_driver_active() returned 0
> 0.078099 [D2] failed to claim USB device: Resource busy
> 0.078159 [D2] Kernel driver already detached
> 0.078199 [D2] failed to claim USB device: Resource busy
> 0.078260 [D2] Kernel driver already detached
> 0.078317 [D2] failed to claim USB device: Resource busy
> 0.078379 [D2] Kernel driver already detached
> 0.078439 [D2] failed to claim USB device: Resource busy
> 0.078496 [D2] Kernel driver already detached
> 0.078534 Can't claim USB device [10af:0001]@0/0: Entity not found
>
> The same for 2.74. has an endless output.
> I rescue the following
> 0.278176 Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x20,
> Offset: 0, Size: 16, Value: 2.201e-05
> 0.278274 Input/OutputVoltage = 2.201e-05 -> assuming correction factor
> = 1e+07
> 0.278384 send_to_all: SETINFO input.voltage "220.1"
> 0.278517 hid_lookup_usage: UPS -> 00840004
> 0.278621 hid_lookup_usage: Output -> 0084001c
> 0.278769 hid_lookup_usage: Voltage -> 00840030
> 0.278913 string_to_path: depth = 3
> 0.279025 Report[buf]: (3 bytes) => 2b 9e 08
> 0.279133 PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0
> 0.279240 Unit = 00f0d121, UnitExp = -1
> 0.279304 Exponent = -8
> 0.279412 Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x2b,
> Offset: 0, Size: 16, Value: 2.206e-05
> 0.279523 Input/OutputVoltage = 2.206e-05 -> assuming correction factor
> = 1e+07
> 0.279655 send_to_all: SETINFO output.voltage "220.6"
> 0.279793 hid_lookup_usage: UPS -> 00840004
> 0.279893 hid_lookup_usage: PowerSummary -> 00840024
> 0.279999 hid_lookup_usage: Voltage -> 00840030
> 0.280100 string_to_path: depth = 3
> 0.280209 Report[buf]: (3 bytes) => 1d 8b 00
> 0.280313 PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0
> 0.280426 Unit = 00f0d121, UnitExp = -1
> 0.280488 Exponent = -8
> 0.280596 Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x1d,
> Offset: 0, Size: 16, Value: 1.39e-06
> 0.280707 Input/OutputVoltage = 1.39e-06 -> assuming correction factor =
> 1e+07
> 0.280822 send_to_all: SETINFO battery.voltage "13.9"
> 0.280929 hid_lookup_usage: UPS -> 00840004
> 0.281029 hid_lookup_usage: PowerSummary -> 00840024
> 0.281136 hid_lookup_usage: ConfigVoltage -> 00840040
> 0.281249 string_to_path: depth = 3
> 0.281361 Report[buf]: (3 bytes) => 1f 0c 00
> 0.281440 PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0
> 0.281539 Unit = 00f0d121, UnitExp = -1
> Sorry if it's not useful.
>
> Best regards
>
> Juan Carlos
>
> On Thu, Mar 21, 2024 at 4:57 AM Jim Klimov <jimklimov+nut at gmail.com>
> wrote:
>
>> Thanks again.
>>
>> So one more bit (other than indeed different libusb versions) that
>> could potentially come into play is bitness - armv7l builds are 32-bit,
>> right?
>>
>> One idea from here is to have you run the driver programs directly with
>> high debug verbosity, e.g. `usbhid-ups -DDDDDD -s Liebert` to compare the
>> two walls of text (at some debug level it spews byte data seen from
>> libusb); this might be more convenient to proceed with as a github issue.
>>
>> Another idea, if you would be comfortable building NUT from source,
>> would be to check if NUT v2.8.0 (and/or current git master) mis-behaves
>> similarly if built in the Debian 11 32-bit environment against libusb-0.1.
>> So to dissect if the issue is between NUT 2.7.4 and 2.8.0 or in the OS
>> environment/dependencies somehow. This can get you started:
>> https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
>> (take care to `configure --with-usb=libusb-0.1 ...`) - notably, you won't
>> have to *install* this build over what have you in the OS to just test the
>> newly built driver.
>>
>> Jim
>>
>>
>>
>> On Thu, Mar 21, 2024 at 7:18 AM Juan Carlos Fischer <
>> juancarlos.fischer at gmail.com> wrote:
>>
>>> Hello!
>>>
>>> NUT 2.7.4
>>> Raspberry Pi 4 Model B Rev 1.5 8 GB "Raspbian GNU/Linux 11
>>> (bullseye)" Linux raspberrypi 5.15.32-v7l+ #1538 SMP Thu Mar 31
>>> 19:39:41 BST 2022 armv7l GNU/Linux
>>>
>>> pi at raspberrypi:~ $ sudo ldd /lib/nut/usbhid-ups
>>>
>>> linux-vdso.so.1 (0xbec53000)
>>> /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so =>
>>> /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6f83000)
>>> libusb-0.1.so.4 => /lib/arm-linux-gnueabihf/libusb-0.1.so.4 (0xb6f4e000)
>>> libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6f22000)
>>> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6dce000)
>>> /lib/ld-linux-armhf.so.3 (0xb6f98000)
>>>
>>> NUT 2.8.0
>>> Raspberry Pi 4 Model B Rev 1.5 8 GB "Debian GNU/Linux 12 (bookworm)" Linux
>>> raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023
>>> aarch64 GNU/Linux
>>>
>>> pi at raspberrypi:~ $ sudo ldd /lib/nut/usbhid-ups
>>>
>>> linux-vdso.so.1 (0x0000007f9051c000)
>>> libusb-1.0.so.0 => /lib/aarch64-linux-gnu/libusb-1.0.so.0
>>> (0x0000007f90410000)
>>> libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f90260000)
>>> /lib/ld-linux-aarch64.so.1 (0x0000007f904df000)
>>> libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000007f90210000)
>>> libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0
>>> (0x0000007f901e0000)
>>>
>>> Best regards,
>>> -jcf
>>>
>>>
>>> On Wed, Mar 20, 2024 at 5:10 PM Jim Klimov <jimklimov+nut at gmail.com>
>>> wrote:
>>>
>>>> Thanks.
>>>>
>>>> Can you please also check (e.g. with ldd `which usbhid-ups`) which
>>>> `libusb` variant (1.0 or 0.1) was the 2.7.4 version of the driver running
>>>> with?
>>>> I wonder if the two generations of that library got something
>>>> differently?..
>>>>
>>>> The commit I mentioned -
>>>> https://github.com/networkupstools/nut/commit/207fed2282 - which added
>>>> the exponent checks, was from 2012 and should be in 2.7.4 as well :-\
>>>>
>>>> Checked: it is -
>>>> https://github.com/networkupstools/nut/blob/v2.7.4/drivers/belkin-hid.c#L157-L194
>>>>
>>>> Are the two tests running on otherwise the same HW/OS setup?
>>>>
>>>> Jim
>>>>
>>>>
>>>> On Wed, Mar 20, 2024 at 9:01 PM Juan Carlos Fischer <
>>>> juancarlos.fischer at gmail.com> wrote:
>>>>
>>>>> Hello!
>>>>> Thanks for answering.
>>>>> This is the result using version 2.7.4:
>>>>>
>>>>> Network UPS Tools - UPS driver controller 2.7.4
>>>>> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
>>>>> USB communication driver 0.33
>>>>> Using subdriver: Belkin/Liebert HID 0.17
>>>>>
>>>>> battery.charge: 100
>>>>> battery.charge.low: 38
>>>>> battery.charge.warning: 38
>>>>> battery.type: PbAc
>>>>> battery.voltage: 13.9
>>>>> battery.voltage.nominal: 12.0
>>>>> device.mfr: Emerson Network Power
>>>>> device.model: LiebertPSA
>>>>> device.serial:
>>>>> device.type: ups
>>>>> driver.name: usbhid-ups
>>>>> driver.parameter.bus: 001
>>>>> driver.parameter.pollfreq: 30
>>>>> driver.parameter.pollinterval: 2
>>>>> driver.parameter.port: auto
>>>>> driver.parameter.productid: 0001
>>>>> driver.parameter.synchronous: no
>>>>> driver.parameter.vendorid: 10AF
>>>>> driver.version: 2.7.4
>>>>> driver.version.data: Belkin/Liebert HID 0.17
>>>>> driver.version.internal: 0.41
>>>>> input.frequency: 50.0
>>>>> input.voltage: 221.8
>>>>> output.voltage: 222.6
>>>>> ups.load: 8
>>>>> ups.mfr: Emerson Network Power
>>>>> ups.model: LiebertPSA
>>>>> ups.productid: 0001
>>>>> ups.serial:
>>>>> ups.status: OL CHRG
>>>>> ups.vendorid: 10af
>>>>>
>>>>> Regards,
>>>>>
>>>>> Juan Carlos
>>>>>
>>>>> On Wed, Mar 20, 2024 at 4:22 PM Jim Klimov <jimklimov+nut at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> For clarity: what changed with the move from NUT v2.7.4 to 2.8.0 -
>>>>>> the warnings "became reported", or the highlighted values became zeroes
>>>>>> (and were valid non-zero numbers with older NUT - so a regression)?
>>>>>>
>>>>>> It seems the message is specific to the subdriver and comes from
>>>>>> commit 207fed2282 and a change to the method involved was just recently
>>>>>> experimentally proposed in
>>>>>> https://github.com/networkupstools/nut/issues/2271 discussion
>>>>>> comments (refinement to consider merging as a pull request pending).
>>>>>>
>>>>>> Thanks,
>>>>>> Jim
>>>>>>
>>>>>> On Wed, Mar 20, 2024 at 3:33 PM Juan Carlos Fischer via Nut-upsuser <
>>>>>> nut-upsuser at alioth-lists.debian.net> wrote:
>>>>>>
>>>>>>> Hello everyone
>>>>>>>
>>>>>>> I'm using: Raspberry Pi 4 Model B Rev 1.5 8 GB "Debian GNU/Linux 12
>>>>>>> (bookworm)"
>>>>>>>
>>>>>>> It all started when I updated from version 2.7.4 to version 2.8.0
>>>>>>> and the consequences were the following:
>>>>>>>
>>>>>>> pi at raspberrypi:~ $ sudo upsdrvctl start
>>>>>>>
>>>>>>> Network UPS Tools - UPS driver controller 2.8.0
>>>>>>> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
>>>>>>> USB communication driver (libusb 1.0) 0.43
>>>>>>> Using subdriver: Belkin/Liebert HID 0.18
>>>>>>> LineVoltage exponent looks wrong, but not correcting.
>>>>>>> LineVoltage exponent looks wrong, but not correcting.
>>>>>>> LineVoltage exponent looks wrong, but not correcting.
>>>>>>> ConfigVoltage exponent looks wrong, but not correcting.
>>>>>>>
>>>>>>> pi at raspberrypi:~ $ upsc Liebert
>>>>>>>
>>>>>>> Init SSL without certificate database
>>>>>>> battery.charge: 100
>>>>>>> battery.charge.low: 38
>>>>>>> battery.charge.warning: 38
>>>>>>> battery.type: PbAc
>>>>>>>
>>>>>>> *battery.voltage: 0.0 <------------battery.voltage.nominal: 0.0
>>>>>>> <----------*
>>>>>>> device.mfr: Emerson Network Power
>>>>>>> device.model: LiebertPSA
>>>>>>> device.serial:
>>>>>>> device.type: ups
>>>>>>> driver.name: usbhid-ups
>>>>>>> driver.parameter.bus: 001
>>>>>>> driver.parameter.pollfreq: 30
>>>>>>> driver.parameter.pollinterval: 15
>>>>>>> driver.parameter.port: auto
>>>>>>> driver.parameter.productid: 0001
>>>>>>> driver.parameter.synchronous: auto
>>>>>>> driver.parameter.vendorid: 10AF
>>>>>>> driver.version: 2.8.0
>>>>>>> driver.version.data: Belkin/Liebert HID 0.18
>>>>>>> driver.version.internal: 0.47
>>>>>>> driver.version.usb: libusb-1.0.26 (API: 0x1000109)
>>>>>>> input.frequency: 49.9
>>>>>>>
>>>>>>> *input.voltage: 0.0 <---------------output.voltage: 0.0
>>>>>>> <--------------*
>>>>>>> ups.load: 9
>>>>>>> ups.mfr: Emerson Network Power
>>>>>>> ups.model: LiebertPSA
>>>>>>> ups.productid: 0001
>>>>>>> ups.serial:
>>>>>>> ups.status: OL CHRG
>>>>>>> ups.vendorid: 10af
>>>>>>>
>>>>>>> Except for those marked, all values are correct.
>>>>>>>
>>>>>>> Any help would be appreciated.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Juan Carlos
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Nut-upsuser mailing list
>>>>>>> Nut-upsuser at alioth-lists.debian.net
>>>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240325/b47ded09/attachment-0001.htm>
More information about the Nut-upsuser
mailing list