-
-
Notifications
You must be signed in to change notification settings - Fork 380
NUT is not picking up accurate and timely data from APC UPS #2805
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
Comments
I can only guess the driver reports what the UPS controller firmware tells it, and maybe that controller gets stuck. Probably the act of USB connection re-plug (when you switched to PC with powerchute and back, or in the later test) resets the state of that controller or even reboots it. If that is the case, you might have some luck with software-driven reset of the USB connection without physical re-plugging, see e.g. https://github.com/networkupstools/nut/tree/master/scripts/usb_resetter Note that this may need extra hardware (an honestly-made USB hub that honours the individual port reset commands) if your built-in ports do not implement them as required by spec, or act as whole-hub reset and mess up your other devices on other ports. Too many vendors cut corners or otherwise can not read the spec, alas... |
After many attempts to fix this, I'm still experiencing the intermittent "Data stale" problem described here. My specific model identifies as USB ID 051d:0002 (American Power Conversion), which seems affected similarly to the BX1600MI-GR mentioned here. I see v2.8.3-rc2 is out with usbhid-ups fixes. Do you know if this release candidate is expected to address the problem discussed in this issue? |
Its unfortunate, the there is no HACS or add-on to reset USB port. I end up buying a USB dongle on/off with automation that has resolved the issue for me ( but I look forward to some one creating a add-on for that). |
Hello, I'm still experiencing the issues described in this thread with my APC UPS (USB ID 051d:0002) on Ubuntu 24.04 (Noble). This includes:
I'm keen to upgrade to the newly released NUT v2.8.3 to see if it resolves these problems, as Ubuntu's Noble repositories currently provide v2.8.1. I noted another user's comment about using a hardware USB power cycler as a workaround, which underscores the persistence of these types of issues. My main question is about the recommended method to install/upgrade to NUT v2.8.3 on Ubuntu 24.04 (Noble):
Thanks for any advice you can offer! |
Cheers, I am not aware of any PPAs myself (there is a long backlogged idea to provide "reference" packaging recipes in the source tree though, and then probably use OBS or GitHub runners etc. to create regular package builds - but we're not there yet). The primarily supported path is currently to point to https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests - with "in-place" mode, the current recipes should try to pick up as many settings as they can find from the already installed build (e.g. packaged) so it can be replaced with minimal mess left around. That said, |
As for the outages themselves, please check in your |
I have installed a ZigBee dongle to turn on/off the connection in between APS and USB to RPi. Automation script when there is no update below 100% for over 2 hours. Still wondering for such a simple thing why no one has developed an add-on or HACS to reset USB port in homeassistant. |
One problem is that this is a hardware issue. Vendors cut corners and bypass standards because it is cheaper, and "nobody" cares for edge cases - or they pay well for enterprise-ish products where this may be tested better. An USB reset should be something in the hub chip itself, including a specific-port reset. Often those, if implemented at all, reset the whole bus/chip instead - so e.g. a flickering mouse or USB camera connection resets everyone else too, even if those other links are not directly broken themselves - which may upset a few things. In other cases this is not implemented at all... As you wrote yourself, to get this right you had to use a dedicated hardware solution. I don't use HA so can't speak for it directly, but I think at least an attempt at software reset via existing kernel facilities on compliant hardware should be doable (probably needs root) - see https://github.com/networkupstools/nut/tree/master/scripts/usb_resetter; my guess is that generally HA manages some remote devices, and the issue might be about resetting their USB connection. And also determining that one is stalled at all (case-specific). And avoiding an outage because that ends up resetting 10 connections, and say HA detects it as 10 other resets to issue... |
I'm using NUT add-on and integration in Home assistant. My UPS is APC BX1200.
The integration data is delayed and doesn't update after a certain point. In this situation, the charge level is stuck at 99% while I unplugged the USB and attached the PC with Power Chute personal edition and got it as 100%. Then reconnecting is back to RPi it shows 100%.Turn off the input to UPS so it dropped to 95-96% and after a while it again stuck at 99% showing charging as not 100% despite it being 100% (confirmed from Power Chute) but the integration doesn't pick it up. Also any changes are displayed with a delay of 1-2 mins.
Not sure why it reports up to 99% fine and not after that. Yesterday it got stuck at 95% then did the same process of connecting to Power Chute and back.
The Add-on always have log entries of can't write to PID fopen issues so not sure if that is the root cause or not as others have the same PID fopen error but have not reported this data stale issue.
I raised this issue with HA home-assistant/core#125723
and after investigation advised the issue is NUT package and should raise it in here.
more
Same battery value of 98% with the utility
then I unplugged the USB cable (from the RPi USB port) to APC UPS and plugged back in and restarted the add-on and the integration both integration and the the utility are reporting the battery state correctly.
The text was updated successfully, but these errors were encountered: