jimklimov
commented
4 months ago Hello, thanks for the report - interesting questions :)
Regarding that corrupt-looking ID, I am not sure OTOH if nut-scanner does some data conversion/normalization of invalid characters (e.g. if it "keeps" the ? as part of string, or just the terminal or the program can not display it in that locale and it is only converted visually). Probably if you redirect its output into a file and view it with e.g. HEX mode of mcview that bit can get clarified. Otherwise, for practical purposes, NUT (and you) can treat the matched values as an exact string first, and as a regex subsequently (so a . for "any character" can help here). For nutdev4 (per nut-scanner dump) this is probably the issue, since if there really is a question mark character, the regex mode looks for "zero or one G immediately followed by 336...".
While at it, can you please also post the ups.conf file contents? Specifically, I wonder if some of your other UPSes only specify a vendorid and productid or even nothing at all (not constraining to check the serial or vendor strings), and so grab this device instead of their intended one. And also if they were enumerated in same order as the printout of the tool above, so if nutdevN here and in service unit names (from ups.conf) use the same N across the board (some things seem to not match up, so...)
Also it seems that some of those serial values actually have trailing spaces in lsusb and in driver debug. This should not matter for regex match where your configured string is a sub-string of what the device reports, but still - worth exploring if nothing else helps.
For the test with the driver directly - I am not sure why nutdev3 here says it matched with the second seen device (serial GE333A0480), so assuming a mix-up of nutdevN numbering in actual ups.conf and in shown nut-scanner dump. In that case, maybe a running driver from the service unit (as prepared by NDE - see https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE) article) - can be holding the device and conflicting with the command-line driver, as detailed in that article.
From the original post title, Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions) -- this is actually normal: 1D6B:0003 is not known to NUT as an UPS VID:PID combo, so it is not built into /usr/lib/udev/rules.d/62-nut-usbups.rules (assuming you have a Debian/Ubuntu derived package of NUT) and the OS does not assign permissions for nut user/group to own that devfs node.
I wonder now if udev might struggle assigning such rights to several devfs nodes for 0463:ffff so only the first device would be seen in detail by NUT?.. Given that the 3 other UPSes work, this is probably not the issue.
As one last thought so far, maybe the broken reported serial number is indicative of some memory/flash corruption on the UPS controller or noise in internal wiring/connectors so it is just defective, and the Entity not found is actually due to its unresponsiveness elsewhere in the USB HID dialogs? @arnaudquette-eaton - WDYT?
For a quick test to rule out any confusion, I'd also try stopping all NUT driver services, unplugging the 3 working UPS connections, to leave only the troublesome one in place, and running e.g. /lib/nut/usbhid-ups -s testdev -DDDDDD -x vendorid=0463 -x productid=ffff -d1 to try and poll the device exclusively (with no competitors) for one data dump. If it works in such sandbox, there may be some NUT or OS integration problem. If not even then - more likely a HW problem. You've tried cables; try also a different USB port (preferably on a different motherboard USB hub, or computer altogether) just in case it is the computer's problem.
peterge-misoft
Hey, we have 4 USVs, 2 of them are Eaton 9130. One works, but the other one doesnt. I dont get why the one in Rack 1 is not working. I replaced the cable multiple times, compared every setting of the USV in its settings menu and tried to fix this for hours now. I dont know what I am doing wrong.
Here are my debug commands:
Strange is that the ID shows up as
Gï336A0278in lsusb -v. I guess this is why nut-scanner detects it with the IDG?336A0278. My guess is that something might be corrupt there and the number gets read wrong. I saw the same result with 3 different cables now, which do work. I read that 5m cables could cause this, we are using 2m cables. But I do not get why this Access denied error shows up, might there be anything else cause these permission errors? Everything is configured the same for the other USV and worked out of the box, so I dont get why this one does not work...