On May 2, 2026, at 12:25 PM, Gavin Davenport <[email protected]> wrote:
> It appears to be periodically making a new device file - shortly after boot
> dmesg emits:
That's not ideal. ushbid-ups tries to reconnect, but if you have a physical
layer USB issue that results in frequent disconnections, I'd want to resolve
that first, because the reconnection takes time and can't possibly cover all
corner cases.
> I don't understand why udev is no help here. Is there any reference
> information i can look at to understand why (I can’t use udev rules to help) ?
As background, most of the USB drivers in NUT use libusb, mostly libusb-1.0 but
nut-2.8.4 still has libusb-0.1 compatibility code, and can switch between them
at build time. Regardless of the version, libusb targets more than just Linux.
It's similar to this thread:
https://sourceforge.net/p/libusb/mailman/libusb-devel/thread/[email protected]/
At the time when I was more actively working on the usbhid-ups code, we used
the most straightforward API for opening USB devices (iterating over devices,
matching VID/PID and potentially other information), and that didn't include
topology information beyond the bus number.
It looks like there is also "busport" in 2.8.4, which might help (though it
also does not use /dev node names):
https://networkupstools.org/docs/man/usbhid-ups.html#:~:text=busport%20=%20regex,-OPTIONAL%2C%20NOT%20RECOMMENDED
Maybe someone else (Jim?) can comment on the "Optional, not recommended" note.
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
