-
-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proper solution for UPSes without unique serials #1273
Comments
I too have run head on into this wall... I am trying to monitor 2 Tripplite Smart3000RM2U UPSs, but what I have found is that the driver, tripplite_usb in my case, bails out the second instance with the message "Duplicate driver instance detected! Terminating other driver!" If there is not already a plan to address this somehow, I would offer to step up and look into it. |
NUT was written before libusb1, so there was no way to open a device in libusb0.1 by its port name. A better solution would be for UPS vendors to provide unique serial numbers accessible over USB. |
Software can't help and wish for hardware to do things. Sounds like the best solution is to update to libusb1. |
Note that port names are not guaranteed persistent (at least not on all
OSes) and can change as you reboot, plug things, etc.
The libusb1 support was added over time and merged last year, but I don't
think the notion of ignoring usb drivers' port parameter went away - PRs
welcome!
As a twist on the situation, consider that you bought a defective product -
their protocol provides for a serial number but does not provide one
uniquely per device. It is important for your use case. Do nag them, do
post requests to fix the firmware!
…On Fri, Aug 12, 2022, 20:54 melyux ***@***.***> wrote:
Software can't help and wish for hardware to do things. Sounds like the
best solution is to update to libusb1.
—
Reply to this email directly, view it on GitHub
<#1273 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFA3D5FL4K3G6JIRIU3VY2MYFANCNFSM5NDHQH5Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I am running a local modification that addresses this issue by allowing the code to skip devices that are already detected. I am running 2 Tripplite UPSs that do not have have serial numbers available in the USB query. I would have to check to see if I pushed these changes to a branch on github |
@ntwerdochlib : Cheers, I believe similar work was done in master branch, see PR #1770 |
@skl111 : I can't vouch for how precisely would Either way, it does not specify a tree but two values which I believe to logically map to an USB hub (as bus) and either its physical port (should be stable) or some logical identifier it assigned to an attached device (which potentially can change due to re-plugs of stuff). Or so I thought. In the tree view above, all device numbers happen to be unique (some devices have more than one interface), but the Bus is only reported for a root hub - which has a branch of further hubs each with its port numbers starting from 1. So the bus+device ID matching as implemented in NUT now(*) should suffice. (*) Note: there were fixes to "device" matching on the master branch this year, no official release since then yet => see #1763 and related PRs for details. On most OSes you would need a custom NUT build for now, https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests can help with that. |
@jimklimov thanks for the reply, lsusb uses libusb so that pr probably is accurate. |
FYI: I'll be mostly offline till mid-May. Good luck on your quest! |
I finally got around to getting this working on debian 11 and maybe I am missing something, but this does not solve the issue as it references the device # and if that device gets removed manually or by the device itself before nut can grab it, then that # increments and its no longer valid for the config. The device being CyberPower USB connected UPS's in particular. CyberPower Device shows connected
after the 2nd ups disconnected and reconnected.
I saw this option |
And update to this based on testing. I updated the udev rule for that series via a post in a gentoo forum about this issue to include
so it looks like
After a few reboots so far they are staying at dev 6 & 7. I think having nut-scanner scan the ports and when it finds CyberPower UPS's, to add the usb hub port # instead of the dev # so it starts trying to attach to the UPS on that port, would bypass the need for a udev rule change. And of course include a warning about these finicky CyberPower UPSs'
UPS.conf
|
Hi, just recently a PR #2054 has landed to add |
Thats exactly what it does, it increments the dev numbers if it doesn't get attached to, physically the same ports. |
I updated the local source and remvoed the udev rule modification as well as the device # and it looks to be working, I will monitor and update it if I do or do see any issues with it.
|
Ok, so just for making a note - on the hub whose topology libusb reports for us, the |
@skl111 : Also, looking at your earlier comment:
By code, I believe it should honour the regex options (if set), and just not abort the driver initialization if it has a hit but the discovered libusb device is busy - move on and find another hit. If documentation was not sufficiently clear about this, feel free to post a PR with a better understandable rephrasing - beauty is in the eyes of the beholder, I've re-read |
As of NUT v2.8.2 with PR #2221 in place, it was decided that OS enumeration dependent values are too flaky for generated and written config files to rely on. Currently
More copies of the |
I've been struggling to get NUT working with two CyberPower UPSes that have no serials. As such, the
ups.conf
has no way to tell them apart now thatusbhid-ups
ignores theport =
setting. I only discovered this silent ignoring of my nice differentiated symlinks when I did alsof
and found both driver instances accessing (and failing) the same UPS.The usual solution to USB devices that are not uniquely distinguishable is to use
udev
rules to distinguish them in some way using their physical ports and setting a symlink to a specific port (e.g./dev/ups_1
,/dev/ups_2
, etc.), which is the solution many use to great success in other cases. However, NUT seems to almost go out of its way to prevent this since theport
setting is ignored. As such, I can only connect to one UPS per machine. If I try more, the two running drivers end up trying to connect to the same UPS and nothing works.The master branch now allows setting the
device =
setting, but this isn't good enough since device number changes after reboots. A good solution would be if NUT can use something that's settable byudev
, like the device name or the device symlink (aka "port"), sinceudev
has the power to distinguish devices permanently. There have been many, many people over the years who have had this problem. Is there any way out of this?The text was updated successfully, but these errors were encountered: