usbhid-ups status show alarm when build from source with EATON Ellipse ECO 1600 #1286
Comments
|
For a few days got access to an "Eaton Protection Station Protection Station" (consumer UPS with "Shuko" sockets), connected to a Mirabox (armv7) and in fact with recent NUT master build it behaves similarly with libusb-1.0 as well: (on a side note, required "pollonly" option - default interrupt mode said connection timed out). |
|
Interesting thought there. Extra bits set in a flag word because something came up negative that shouldn't have. Worth grabbing the debug info while you've got access to a device. |
|
I'd also look in the debug output for "Lookup ... failed ... for" -- I'm suspicious that the change to |
|
I'm not sure if I happen to be extremely lucky and someone with actual knowledge stumbled on the exact same error as me within days 9f me getting my new ups or if you're just so nice to get a loaner unit to investigate some random issue by an unknown guy like me, but thanks anyway for looking into it ;) |
|
@toxic0berliner -- try running (from nut/drivers if it's not an installed binary) |
|
Thanks @nbriggs for the directions ;) Thanks in advance for any help and feel free to ask for anything else I could do to help solve this ;) Not sure how to flag it, but while not a workaround, I can in fact revert to the packaged version of nut that reports the proper status for my prometheus/grafana monitoring, it only has issues when trying to change the beeper status from what I found, but now that I've set the ups to silent it doesn't get overwritten so I could totally live without this fix, so no pressure here ;) |
|
@toxic0berliner -- ok, got the log, things check out. Now, if I'm thinking correctly I could use one more log without the -x options, and at a higher debug level (5)-- I'm not one of the main developers here but recently I've been asked for ideas about some weird bugs because I tracked down a weird one that affected a NUT installation on a friend's system (only on big-endian, with 32/64 bit differences). |
|
Me having an access to that UPS was a coincidence, setting up for an acquaintance. Unfortunately, that setup got rebooted and now the alarm is not reproduced: or so I thought - Nick's comment above popped while I was posting this, so I re-checked... and now the alarm is there after a minute or two: |
|
eaton-ups-1.txt The status changes are sent out around 36'th second, probably at some half-a-minute refresh. Already around 4th second of driver uptime we can see e.g. "fanfail value 1", though not widely announced: and half a minute later, It looks very suspicious however that all those |
|
I don't quite get the log actually, gotta dig into code too I guess. For each "[D4] Entering libusb_get_report" there are often more than one Path's and (same) Reportbuf's so maybe some loop ran away or it is "lockpicking"?.. Many of those reports have different values after a new "Entering..." line, though still many values seem recurrent. |
|
I believe that |
|
The is a little odd. Look in string_to_path for how that can fail. I'll be offline for the next 12h, but I'll check in later. |
|
Good catch for the bit-by-bit, now I see it is indeed looking at different offsets with size 1 |
|
Thanks for string_to_path nudge, that must be it - and mea culpa from overly zealous bug hunting, it seems. The first block for usage table lookups with a After a few minutes of driver uptime, there is no alarm appearing, and the set of values is a bit different (e.g. no bogus ups.date catching my eye): |
…path(): range-check...) Closes: networkupstools#1286
|
@toxic0berliner : for a quick check, would be great if you can rebuild local NUT master with this essential fix applied: and verify that solves the bogus alarms for you too? |
|
Wow, all this went way over my head, but changing a line and rebuilding is in my skillset ;) |
|
Ok, thanks a lot! (and also ccache is your friend, if not yet deployed there) |
|
somehow it did build very fast anyway, had to reboot since I'm unclear as to the unit name for the upstart services, but after reboot, issue is fixed ! I read status as online, no Fan error anymore, and I still am able to disable/enable the beeper which was broken from the packaged version ! All fine for me with this fix ! Congrats, and thank you very very much for the incredible reactivity and help ! Now that won't help a bit with packaging this in the debian repos, and even less for my other UPS that runs a costomized nut version from synology, but hey, I have the latest one working perfectly on my pi ! thanks a lot ! And congrats again on the very nice instructions, it has been years since I compiled anything and you made it a breeze with your docs ! |
Hello,
Using an EATON Ellipse ECO 1600 USB at home, I encountered the known issue #9 : I was unable to change beeper status.
I saw in #801 that it seemed not to have been included in the packages, so I followed the instructions to build from source.
I'm happy to report that now I'm able to disable the beeper sucessfully.
Sadly, I now have an unhealthy status reported on this brand new UPS, I believe it's wrong... In fact, I'm seeing "Fan Failure!" error, but my unit has no fan to my knowledge, I see no vent on the box itself, and using the official Eaton companion app for Windows I get no error reported. As such I believe it's something in the driver I build that is misinterpreting what the UPS reports.
I'm using nut on a raspberry pi 1 model B, so building takes quite a while but I saw no specific error. I'm open to re-build & test or provide more details if anyone is nice enough to look into it.
Not sure what I can provide as traces, I'm not seeing anything in journalctl.
Here is the output of upsc :
Thanks in advance for any help.
The text was updated successfully, but these errors were encountered: