Hi, FYI: I'll be away from computers (and possibly internet) for a couple of weeks.
As for the logs, they are not "the same": the first one (with NUT 2.8.x) failed to connect to the device it liked -- "failed to claim USB device: Resource busy" (probably another program holds it, maybe a copy of the driver wrapped by a systemd unit - see https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE) for probable-cause details). The "endless output" makes sense as the driver is running in an infinite loop (until an exit signal) to collect and publish device information :) Logged strings like "assuming correction factor" in the latter (2.7.4) indicate it goes through drivers/belkin-hid.c which had some attention for a newly seen strain of Liebert devices just recently with: * https://github.com/networkupstools/nut/pull/2369 * https://github.com/networkupstools/nut/issues/2271 * https://github.com/networkupstools/nut/issues/2370 - thanks for the log, it would be helpful here specifically You might want to give a shot to a custom master-branch build to see if it works better with these changes, see https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests - or wait for eventual release and some time later packaging of NUT 2.8.2... Hope this helps, Jim Klimov On Mon, Mar 25, 2024 at 7:41 AM Juan Carlos Fischer < juancarlos.fisc...@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@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+...@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.fisc...@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@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@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+...@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.fisc...@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+...@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@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@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@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@alioth-lists.debian.net >>>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >>>>>>> >>>>>>
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser