[Nut-upsuser] UPS configuration issue?

[Jim Klimov]

Ok, thanks!

  So that did not help immediately and the older NUT version's logs still
do not clarify the issue.

  Check that there are no other programs (including NUT drivers or
experiments with vendor software) trying to access the device, and that the
devfs node permissions allow nut, e.g. on my Linux test box:

----
# lsusb
...
Bus 003 Device 002: ID 0463:ffff MGE UPS Systems UPS
...

# find /sys /dev -group nut -o -user nut
/dev/bus/usb/003/002

# ls -la /dev/bus/usb/003/002
crw-rw-r-- 1 root nut 189, 257 May 13 11:43 /dev/bus/usb/003/002
----

  The "Can't claim USB device [0001:0000]@0/0: No such file or directory"
looks odd, if the device does exist, but may be an artifact (or
misunderstanding) of the older libusb-0.1 used in the build you run.
  Potentially it might also be about older NUT's expectation that matched
the practice for decades, that USB devices have everything interesting on
"interface #0" - but in recent years more and more devices (first seen with
Arduino DIY battery controllers, but now also even non-experimental "real"
UPSes) appear with USB data on non-default interfaces and endpoints. Newer
NUT versions allow to tune these numbers as you lockpick access to your
device, but 2.8.0 lacked that ability IIRC.

  Try adding `debug_min=6` to `ups.conf` (global or device section) and
restart the driver service.
  There should be a lot of logs so it would be better seen via `journalctl
-lu nut-driver at nutdev1`.

  For more details on this bit see
https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity#nut-v2-8-0-and-newer

  A possibly easier alternative, while setting this up, may be to
`systemctl stop nut-driver at nutdev1 ; systemctl disable nut-driver at nutdev1`
and run the driver program directly (initially as root), e.g.
`/lib/nut/nutdrv_qx -a nutdev1 -DDDDDD -d 1` to run one data collecting
loop, dump the info and exit, all in high debug mode. After the driver
usability is fixed, you can re-enable the service.

Hope this helps,
Jim Klimov

On Tue, May 13, 2025 at 9:13 AM Stephen Davies <sdavies at sdc.com.au> wrote:

> Output from systemctl restart nut-driver at nutdev1 after removing the
> directory:
>
> May 13 16:35:08 mustang.sdc.com.au systemd[1]: Starting Network UPS
> Tools - device driver for NUT device 'nutdev1'...
> May 13 16:35:08 mustang.sdc.com.au nut-driver at nutdev1[16999]: Can't
> claim USB device [0001:0000]@0/0: No such file or directory
> May 13 16:35:08 mustang.sdc.com.au nut-driver at nutdev1[16999]: Network
> UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
> May 13 16:35:08 mustang.sdc.com.au nut-driver at nutdev1[16999]: USB
> communication driver (libusb 0.1) 0.43
> May 13 16:35:08 mustang.sdc.com.au nut-driver at nutdev1[16999]: Driver
> failed to start (exit status=1)
>
> [root at mustang system]# lsusb
> Bus 001 Device 005: ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth
> Bus 001 Device 006: ID 0461:4e70 Primax Electronics, Ltd
> Bus 001 Device 003: ID 04ca:007d Lite-On Technology Corp.
> Bus 001 Device 002: ID 0438:7900 Advanced Micro Devices, Inc. Root Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 002 Device 002: ID 0bda:0153 Realtek Semiconductor Corp. 3-in-1
> (SD/SDHC/SDXC) Card Reader
> Bus 002 Device 006: ID 0001:0000 Fry's Electronics
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> [nutdev1]
>   driver = "nutdrv_qx"
>   port = auto
>   vendorid = 0001
>   productid = 0000
>   bus = 002
>   protocol = hunnox
>   subdriver = hunnox
>
> Cheers,
> Stephen
> ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20250513/8d9ed87b/attachment-0001.htm>