NUT 2.8.1-3 "Can't claim USB device [051d:0002]@0/0: Entity not found" using usbhid-ups #2666
Comments
ErikDB87
changed the title
|
I thought removing and installing the package again might solve the problem. I also removed But somehow, the directory So I did this: And now: Somehow, I made it worse... But I don't understand how installing the packages again fails to install these files...? EDIT But |
|
I believe some answers around this general issue are in the mailing list. As for packaging, NUT team does not impact it directly, so it is technically a distro matter. That said, probably different packages defined for NUT there which deliver files which might need configuration files, all deliver the |
|
Of course I didn't expect my amended config files to appear. :) But the standard ones - which were installed when I first installed NUT, didn't reappear... I manually added Anyway, I had hoped this reinstall would have reset all the permissions. But I was wrong... But it looks like I'm where I started out; so maybe no harm no foul? |
|
Probably no foul. As you edited Re-check if the unit does exist and does not complain (like on the mailing list) - if so, go on to |
|
I'm not sure I fully understand what you mean... I'm not really a Linux master :) But here are some outputs: There seem to be some problems with |
|
Looks great actually:
(if on the same machine as WARNING: The This usually means either mismatch between I am a bit puzzled about |
Indeed:
I had hoped a fresh install would have reset all the permissions... Do you have any idea which commands might fix the permissions issues? |
jimklimov
added
DDL
APC
USB
impacts-release-2.8.1
|
Looking at your earlier post, the Also note, with an APC BX###MI device, #2565 and related issues and PRs may be relevant. That fix is not part of a released version yet though, so if you'd end up needing it before a release is cut and gets through distro packaging queues - a custom build would be required, e.g. per https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests |
|
As for file permissions, can you post |
I see... Shame on me for following the guide, and not reading the readme. I did that eventually for a few other conf files, but not this one... I assume this would be better? ? (I'll have access to the Linux server later today; I'll run |
|
Well, coming from legacy long ago, before my time, that
|
So it should be: ? |
|
Maybe, if it does work to mix it like that. If something still complains, separate this into two users for two use-cases, e.g.: (and then use |
|
Thanks for all your time and effort, @jimklimov! Although we're not out of the woods yet, I'm afraid... Now (Although I don't understand where this
Now: Unfortunately, even after a Linux reboot, still: As requested: EDIT But trying it again, resulted in failure again: Puzzling... |
|
Looks cool about getting the driver and I think I think with #1917 in NUT v2.8.1 the driver program should have tried to communicate with the previous instance over its local socket (same as communications with |
|
Also note, that if you get You may be after |
|
Alternately, you can try sending commands to the UPS (using the |
The UPS didn't power cylce.
The Linux box shut down, but the UPS didn't power cycle...
You mean like so: ? Unfortunately, again no power cycle. (I've got a table lamp lit, so a power loss should be visible.) |
|
Looking at current code for the driver, the command sequence in Lines 969 to 993 in d244d73 |
I assume you mean the other options mentioned in that Java code? No power cycle... I also tried: But no effect on the lamp. FYI: |
|
"OK" there means the command was accepted by the driver. Please try It may also be that the device model/firmware does not actually support that command, or we poke a wrong USB endpoint for that (e.g. worked for other related devices but not this one). |
|
And that's plain old C code ;) |
But no effect on the lamp...
What would that mean for my setup? End of the line? Or are there more avenues to be walked? :) |
…usb adding its CFLAGS and LIBS into the loop [networkupstools#2666] Signed-off-by: Jim Klimov <[email protected]>
Signed-off-by: Jim Klimov <[email protected]>
…le libmodbus [networkupstools#2666] Signed-off-by: Jim Klimov <[email protected]>
…bmodbus was used to build this driver [networkupstools#2666] Signed-off-by: Jim Klimov <[email protected]>
…ls#2666] Signed-off-by: Jim Klimov <[email protected]>
…th-modbus+usb=yes and fix a typo checking --with-drivers there [networkupstools#2666] Signed-off-by: Jim Klimov <[email protected]>
…AME [networkupstools#2666] Signed-off-by: Jim Klimov <[email protected]>
|
So, the prospective fix was published as a PR #2677. You can try building that branch of NUT which is a source of the PR, with a separate checkout location, e.g.: ...assuming the static build of libmodbus is still under Now it should more actively reject build combinations where we implicitly seem to want, or explicitly request, the use of usb-capable libmodbus (for |
Am I doing something wrong? |
|
Aha, I figured it out: |
|
Initially: Hooray! But the actual driver part still isn't successful... I tried without and later with Two lines look suspect, I would think... Awaiting further orders. ;) (If there's any log document that might be useful, I'll gladly provide it.) Or does this mean the modbus driver also doesn't work on my UPS? I forgot this avenue was only a possible solution... |
Argh, my bad, deleted too much cruft from the copied URL. Glad you found your way around this bit , and sorry again :D |
|
So, finally, these lines confirm the correct code got built: (ignore the "2.7.4" as baseline + 10K commits afterwards: it is based on git tags you workspace has downloaded or not). As for "Resource temporarily unavailable" - are you sure your driver dried earlier is stopped (likely wrapped as a |
I ran |
|
Should have... maybe there is one running from |
It took me a while to figure this output out: I couldn't I played around with it a bit, and maybe this is something? And for the sake of completeness... |
|
Just in case, CCing @EchterAgo - maybe there are some ideas about "_apc_modbus_usb_callback: Failed to match!: Resource temporarily unavailable"? But in short, probably the device does not support the protocol, until proven otherwise... |
Could this be a way to find out the command? Or would that also not work, because we can't seem to be able to 'reach' the USB port? In any case, the Windows PowerChute or what was its name did shut down the UPS, so there must be a command somewhere... I assume it's impossible to 'open up' that Windows program and take a look inside? :) |
|
At least worth a try. I am not sure exploring finds supported commands, or only data reports. @aquette might know more on this, if online... As for vendor programs, there's always good old sniffing (e.g. with Wireshark equivalent for USB) to check the protocol, but my knowledge is vague on how that is generally done or the next steps how to investigate those dumps and make code. I am sure there are blogs or mailing list entries on that, maybe even docs in NUT sources... |
Is there an effective way to search these mailing list entries? Opening every month's list is not that. :p
I assume the raw data it generates will be too raw for my understanding, but I'll give this a go! |
|
Thanks to this guide (https://www.youtube.com/watch?v=0MC-D_oNzbk) I was able to generate two logs. The scenario was both initially the same: I unplugged the UPS from the electricity grid, and the
The only caveat is of course that I don't know whether the (I can't upload the log files, because they're not an allowed file type, so here's a link to a directory on my Google Drive, where they can be found: https://drive.google.com/drive/folders/12xLZH4YWJGXEjNETs2YBJix4boIUVDAE?usp=sharing.) Maybe I should open a new issue and/or start a new mail chain, focused on retrieving the command from these data? That probably reaches more people, who have categorized the current issue as not for them? |
What about this, by the way? |
Makes sense :)
That's a path to Unix local socket filem by which driver talks to upsd, and since 2.8.1 or so two copies of the driver (running and newly launched) can talk to each other e.g. to reload or exit older copy and start a new (older alternative to send OS signals is not as flexible/scalable). The message means no older socket was found - since no older driver was running (earlier attempt could not connect to device and exited). |
|
Read that in 30 seconds so... |
I'm afraid my knowledge of NUT (of Linux for that matter) is fairly limited... I don't really understand what you mean. Jim mentioned something about |
|
@jimklimov, @aquette, I tried to do some digging in the elaborate docs, and based on this, this and this info, I tried the following: But alas, no success: I wasn't able to figure out what "explore vs rw" exactly means... Or "ML"...? All help is appreciated! :) |
|
Hi @ErikDB87 I'm unsure if your device is USB hid compliant. An lsusb -v as root may help My ML (machine learning) vs explore (usbhid-ups flag) relates to the explore output of this driver, and snmp-ups somehow. I made some automations to extract data for these, to create new drivers. And I had some follow-up work to ease more, using a sort of ML... For @jimklimov |
|
Hi, @aquette I see something about HID? But I can't make anything out of it, of course... I'm not sure what you mean with "rey apx_modbus"...? The machine learning part sounds interesting. :) But I gather you haven't worked with these (By the way, I made another "sniff" log ( |
Hi all,
Yesterday, I bought a UPS for the first time in my life, and was eager to dive into NUT. But not all is working as expected... I saw a similar thread started on 18 October, but it didn't help me. (I also spent a handful of hours searching the web for solutions, and of course read the manual and FAQ - "queequeg".)
I tried shutting my UPS (APC "Back-UPS BX750MI FW:295202G -302202G") down with
sudo upsdrvctl shutdown, but no response. Digging around, I found a few things that raised my suspicion, but I can't figure it out...I followed this fine gentleman's guide (but tweaked it a bit - I don't know why he uses
masterandslavefor example?): https://technotim.live/posts/NUT-server-guide/.I must add that I created a few users and user groups during installation and configuration, following the documentation. But in the end, I lost oversight, and everything didn't work. So it's entirely possible there's a permissions issue somewhere. But I don't have any idea where...
Because of the trial-and-error approach, in the
.conffiles (shown below), a lot of stuff is commented out. I assume I can delete it, but I also assume the#should be adequate? Anyway, I keep it in the output below for clarity.I'll just paste various outputs here, I hope that's a reasonable approach?
Thanks in advance for anyone's help!
Kind regards,
Erik
This seems strange? But after some googling, I found the below alternative - although I would expect it to work without
/lib/nut/):The text was updated successfully, but these errors were encountered: