Rysz

There is nothing in the logs regarding the previous shutdown, please make sure to enable this: And then post the NUT Debug Package again next time you get a shutdown, directly on the first boot after the shutdown. The BX series is known to be bugged (we spoke on GitHub about this) but it shouldn't cause any shutdowns, at least it didn't for any of the other affected people so far. NUT should in general never cause unclean shutdowns (and parity checks) unless something on your server was taking extremely long to stop - resulting in a forced shutdown (but this would also happen without NUT if you press "Shutdown" and something gets stuck). So even if your UPS reported a false power event the shutdown should always have been a clean shutdown. In any case we would need the logs from before the shutdown to really diagnose the problem that led to the unclean shutdown so this is guesswork on my part at best. Regarding the other problems now having stopped on another USB port, I'm guessing the USB port you were previously connecting your UPS to is maybe faulty or the USB cable between the PC and the UPS is in the process of dying. There's a lot of USB related events in the logs, so I'd monitor the situation and if it happens again on the new USB port I'd consider exchanging the cable (can be found on Amazon for around 10$). Sorry I can't really help more at this point, but do report back with new logs in case it happens again.

Please post the NUT Debug Package found in NUT Settings.

In that case you can always go back to the previous backend "previous" (2.8.1 stable) in NUT Settings.

The APC BX series seems to have a firmware (or compatibility) issue affecting both APCUPSD ("UPS Settings") and NUT. Symptoms of this issue include common low battery notifications, despite the UPS being online/fully charged, as well as frequent battery replacement notifications and increasing NUMXFERS. The situation on APCUPSD seems more severe as unwanted shutdowns have been reported by affected users as well. It is therefore recommended to use NUT for this affected UPS series, where the problem also appears but is seemingly limited to wrongful low battery and battery replacement events being reported in the SYSLOG but the UPS functioning normally otherwise (including on battery notifications and graceful shutdowns from power events). It is possible to disable battery replacement notifications in NUT's settings, so the falsely reported events would be limited to the SYSLOG and a minor annoyance rather than a deal-breaker rendering the UPS entirely unusable on Unraid. If you have been using NUT before: It is recommended to first "Reset Config" in the NUT Settings before setting up NUT again, as an existing configuration might be stored on your USB still. This ensures starting with a fresh configuration where this issue has been taken into consideration, as opposed to older legacy configurations reporting such false low battery events through Unraid's notification services often. The respective issues can be found here: https://sourceforge.net/p/apcupsd/mailman/message/58740970/ (APCUPSD) https://github.com/networkupstools/nut/issues/2347 (NUT)

No problem - glad it works for you and thanks for using NUT. 🙂

Please post the diagnostics package, those messages are normal and just means it's skipping over packages for other Unraid versions. Can you not see NUT Settings anymore after updating or what is not working? If the backend says NUT 2.8.2 in NUT Settings the update installed fine.

Just to follow up on this for you and other users with the affected APC BX series. Users who are getting intermittent LOWBATT (low battery) notifications can silence these wrongful LOWBATT notifications by resetting their configuration using "Reset Config" and setting up NUT with a fresh configuration. In the new configuration layout such LOWBATT events will no longer raise notifications through Unraid's notification service and only appear in the SYSLOG. For intermittent REPLBATT (battery replacement) notifications, those can be controlled through the GUI and will have to be disabled for your UPS in case they still occur wrongfully - which unforatunately seems to frequently happen on the affected APC BX series. The issue itself is still under investigation, we're suspecting that the UPS is cycling through those states while doing some sort of battery calibration process - follow the process over at: https://github.com/networkupstools/nut/issues/2347

The APC BX series is bugged both with APCUPSD ("UPS Settings") and NUT: https://sourceforge.net/p/apcupsd/mailman/message/58740970/ (APCUPSD) https://github.com/networkupstools/nut/issues/2347 (NUT) Basically low battery states are falsely interpreted, in turn leading to wrongful shutdowns. This is most likely due to unexpected changes in the APC UPS firmware on that series which the respective drivers cannot (yet) handle. For NUT, at least, an investigation into this is underway, so hopefully we'll get this fixed before too long as many people seem to be having these problems. Feel free to comment in the GitHub issue that you're also affected with your specific UPS model so the issue will gain more traction and visibility.

Yeah, PF is probably wonky for you because it shows less VA than W for power consumption and it's calculated W/VA usually.

Ah, it was you, the username seemed familiar. I'll see if I can get the other driver functional somehow in the meantime, no promises though.

Thanks for the information, I'm compiling and starting the testing tonight - if all goes well I'll package it up for an update tomorrow. 🙂

That driver is not supported on Unraid due to various dependencies. The 9PX should work over SNMP though, can you check if that works for you instead using the "snmp-ups" driver? You'll probably have to activate it on the UPS somewhere too.

Don't know how I missed that 😳 - thanks, closing.

Thanks a lot again and sorry for the inconvenience, this helped me identify two important issues for fixing in the next update. You can also just remove and reinstall NUT after changing the backend setting and you'll be on the new version again without rebooting. 🙂

Thanks, it's a problem with either the username or password (or both). This is very important information for me because I'll have to fix this, thank you for your help. Can you confirm it works for you now with an easier combination of usernames and passwords?

Also I noticed you have very long passwords, can you try setting both passwords to something easy like 123 just for sake of confirming it's not a problem with the passwords? Also make sure the usernames and passwords do not contain any spaces.

I cannot find a problem with your configuration, can you run the command and show me the output: /etc/rc.d/rc.nut start If you don't know how to run commands, can you try "Reset Config" and set up NUT with a fresh configuration? Please let me know if it works for you then.

The logs show everything starts up just fine: Mar 30 11:42:01 Hoth ool www[21065]: /usr/local/emhttp/plugins/nut-dw/scripts/start Mar 30 11:42:02 Hoth root: Writing NUT configuration... Mar 30 11:42:03 Hoth root: Updating permissions for NUT... Mar 30 11:42:03 Hoth root: Adding UDEV lines to rc.6 for NUT Mar 30 11:42:03 Hoth root: Adding UPS shutdown lines to rc.6 for NUT Mar 30 11:42:03 Hoth root: Checking if the NUT Runtime Statistics Module should be enabled... Mar 30 11:42:03 Hoth root: Enabling the NUT Runtime Statistics Module... Mar 30 11:42:08 Hoth root: Using subdriver: MGE HID 1.46 Mar 30 11:42:09 Hoth root: Network UPS Tools - Generic HID driver 0.47 (2.8.0) Mar 30 11:42:09 Hoth root: USB communication driver (libusb 1.0) 0.43 Mar 30 11:42:11 Hoth usbhid-ups[21958]: Startup successful Mar 30 11:42:11 Hoth root: Network UPS Tools - UPS driver controller 2.8.0 Mar 30 11:42:12 Hoth upsd[21987]: listening on 0.XXX.XXX.0 port 3493 Mar 30 11:42:12 Hoth upsd[21987]: Connected to UPS [ups]: usbhid-ups-ups Mar 30 11:42:12 Hoth usbhid-ups[21958]: sock_connect: enabling asynchronous mode (auto) Mar 30 11:42:12 Hoth upsd[21988]: Startup successful Mar 30 11:42:12 Hoth root: Network UPS Tools upsmon 2.8.0 Mar 30 11:42:12 Hoth upsd[21988]: User [email protected] logged into UPS [ups] ### [PREVIOUS LINE REPEATED 1 TIMES] ### Can you post a screenshot of your NUT Settings page? What exactly isn't working for you? Did you try clearing the browser cache or from another browser? Please also post the NUT Debug Package found on the NUT Settings page.

Better to stick with "blazer_usb" then, the battery charge is important. Glad it works now, powertop can be unpredictable and I'm not a fan of it overall personally. Regarding the runtime it's possible your UPS does not send this information for NUT to read. Unfortunately you cannot do anything about that, but you can still use the "Shutdown Mode": "Battery Level" and "Time on Battery", which are the more reliable shutdown modes anyhow. "Runtime Left" is the least reliable shutdown mode and that's the only one that won't work for you because of the missing runtime variable. So basically NUT already has all the information it needs to work reliably and that's good even if some of the variables are missing here. You will see some more information (not the runtime, but at least the power consumed) if you set this setting as follows with your values (1500/900 in your case):

Hello, nothing in the backend and drivers was changed over these past few months (since 11/2023 actually) so it's probably a coincidence with restarting NUT. Did you try stopping NUT, unplugging and replugging the USB cable and starting NUT again? Also I'd generally advise to use "nutdrv_qx" driver instead of "blazer_usb" (which is legacy) - can you try that and report back if it works then? Also please post the NUT Debug Package (can be found in NUT Settings) if possible.

By the way - this also applies to you - "blazer_usb" is the legacy driver of the newer "nutdrv_qx" driver, you can try setting the UPS Driver to "nutdrv_qx" and see if that will show more or better information (also regarding the runtime). If not or worse, you can still go back to "blazer_usb" if that works better for you.

Thanks for getting back to me and asking the manufacturer too, this is very interesting information to me. I also have an update in the works where I'm generally shortening the UPS statuses, e.g. the currently extremely long BYPASS status will simply be "On Bypass" in the future, which will look better in the dashboards and not exceed the table dimensions even when multiple statuses are present (e.g. OL DISCHRG CAL) as seen with some UPS. I don't think an explanation that long is necessary for most UPS statuses and it looks weird when grouped together in the dashboard like that. Extreme Example - Before: Extreme Example - After:

You did not do anything wrong, it's possible your UPS does not send this information for NUT to read. Unfortunately you cannot do anything about that, but you can still use the "Shutdown Mode": "Battery Level" and "Time on Battery", which are the more reliable shutdown modes anyhow. "Runtime Left" is the least reliable shutdown mode and that's the only one that won't work for you because of the missing runtime variable. So basically NUT already has all the information it needs to work reliably and that's good even if some of the variables are missing here. You will see some more information (not the runtime, but at least the power consumed) if you set this setting as follows: Yeah I understood the issue and the two settings you've now added should fix that problem for you. 🙂 Please let me know after the next test if your system has shutdown or if it is working for you as it should now. Yes, this is basically correct information being shown by NUT. The yellow colour is not an alert, it just means that something that is not 100% standard operation is happening for the user to be aware of: ECO mode: When the input voltage is within the set voltage range, the UPS will switch to bypass mode to achieve energy saving. In the event of a power outage, the switching time to battery power is <4ms. I agree that "no battery protection is available" is maybe not 100% correct in your case, but the UPS being on BYPASS is correctly reported by NUT. Usually BYPASS does mean that the UPS circuit is completely bypassed (like in datacenters during UPS battery maintenance) so in such cases there really is no battery protection available while the UPS is on BYPASS. It seems in your case they have a smart switching mechanism and not powering the rectifier and battery circuits is saving that energy and thermal heat to be called ECO mode. I'm also not sure if the UPS is able to condition input power (Volts and Hz) in ECO mode, if that's something that matters to you. By the way, "blazer_usb" is the legacy driver for the newer "nutdrv_qx" driver, you can try setting the UPS Driver to "nutdrv_qx" and see if that will show more or better information (also regarding the BYPASS) - it should work (see this report): https://github.com/networkupstools/nut/issues/1872

Yes, you could put this command in your /boot/config/go file or in a User Scripts (plugin) script configured to run at system startup - which will restart the NUT service 5 minutes after system startup: at -M now +5 minutes <<< "/etc/rc.d/rc.nut restart | logger" Regarding your startup problem I think you could be right about the now removed voltage estimation settings causing this, although I'm not sure why it happens only at startup for you and not always. This user reported a similar problem - maybe that thread has some more information: https://alioth-lists.debian.net/pipermail/nut-upsuser/2017-June/010757.html https://alioth-lists.debian.net/pipermail/nut-upsuser/2017-June/010759.html So all that said putting back the voltage estimation settings in the UPS.CONF file might be the "solution" to that issue at least, but I'd monitor the UPS closely nonetheless all things considered.