Rysz

Get this dependency package (the commands downloads it to /boot/extra and installs it, so it persists reboots): curl -o /boot/extra/libffi-3.3-x86_64-3.txz https://slackware.uk/slackware/slackware64-15.0/slackware64/l/libffi-3.3-x86_64-3.txz installpkg /boot/extra/libffi-3.3-x86_64-3.txz Please let me know if that worked for you!

Which version of Unraid are you on? This is a dependency problem with the Python package that you have installed on your OS.

Please post this in the relevant support topic:

Thanks a lot, I proposed the change upstream.

If it's not showing the power draw already, you can set these settings up with your UPS rated capacities: And it'll calculate the power draw from those settings in combination with the reported load percentage of the UPS. Other variables are not possible to be shown in the footer (yet), but I'll put that on the TO-DO list for the future. However you can already monitor/have charts for other variables with the NUT Runtime Statistics Module. The footer itself should look like this when everything's working as designed:

I just pushed an update to NUT with some new features and the new "preview" backend. @Masterwishx: The "preview" backend now includes your Eaton fixes (NUT GitHub PR#2604). @Vr2Io: The "preview" backend now includes your allow_killpower fixes (NUT GitHub PR#2606). Please let me know if the allow_killpower flag in UPS.CONF works for you now. 🙂

This already exists in /boot/extra (also prior to Unraid 7). Also, there's no real if NerdTools dies question anymore, it's already kind of dead. It's been abandoned by the original developers and many packages are incompatible with Unraid 7 now. It's only been kept around by the CA maintainers because there was still some demand for it on Unraid 6 iirc...

You can just put the USB into a new system, Unraid doesn't care about the hardware (except for HDDs).

Thanks for the detailed post and the debug package, you can indeed try adding: productid = 1000 to the end of UPS.CONF through the GUI configuration editor in NUT Settings. Make sure to put this on line 9 or later so it is not overwritten by the GUI settings. If this doesn't help, remove the line again and then I'd try with SNMP instead. With such more enterprise-oriented devices SNMP is usually the best choice. Most SNMP implementations use an industry standard MIB ensuring you'll see all values. Besides, SNMP is usually much more stable than USB, so I recommend it wherever available. The disadvantage is having to protect all network devices between the server and UPS too. You'll need to ensure that the network connection between the server and UPS always stays up. SNMP usually needs to be activated on the UPS device first, then you can use it with the UPS Driver "net-snmp" & setting the UPS Port to the IP of your UPS device (where SNMP is activated). I recommend using SNMP v1/v2 if available as v3 needs a more complicated (configuration file) setup. Please let me know if you got it to work with either of my suggestions... 🙂

It's basically the same with any application you install on any other operating system as well. Install from reputable sources and maintainers, and you'll likely never run into a major problem. Truth be told, containers likely are - by design - already much safer than any Windows machine connected to your server through SMB with read/write access or other random IoT device on your network.

APC has had some very weird firmware changes (bugs?) with more recent models (it seems). Some other of their UPS series have also had spurious false statuses being reported. Unfortunately, there's not much that can be done from the NUT (plugin) side. The important thing, as @Vr2Io pointed out, is that the "on battery" situation is detected correctly and no wrong shutdowns are caused in situations where the UPS is not in fact on "on battery". There is some major work being done in the NUT backend at the moment that might lead to an improvement of the parameters read from the UPSes, it can be followed here: https://github.com/networkupstools/nut/pull/2604. I'll push the next update to NUT once that pull request gets merged, which will also include the fix for your kill power issue which has since been merged ( @Vr2Io ) : https://github.com/networkupstools/nut/pull/2606.

My bad, I just saw your version - the array is optional starting from Unraid 7.0 beta2: https://unraid.net/blog/unraid-7-beta-2

Did you try setting the "Array" slots to 0 ?

NUT can't see any UPS devices on the USB bus, so this is likely a USB cable or port issue indeed.

Just to follow up, I think I've identified the underlying issue and have a proposed fix in the pipeline: https://github.com/networkupstools/nut/pull/2606 I'll let you know @Vr2Io when there is something to test (waiting on feedback from maintainers).

First of all you need to disable APCUPSD (the inbuilt UPS service controlled through "UPS Settings") as having that enabled at the same time with NUT will make both services fight for the UPS. Also your UPS seems to be switching to battery frequently due to fluctuations in input voltage: input.transfer.reason: input voltage out of range. If your power grid or electric installation is unstable in terms of input voltage, you may be able to reduce the UPS sensitivity (consult the UPS manual about this) to avoid such frequent switching (although not switching and related voltage spikes can harm your electronic devices too, so it's a fine balance there). If it's not, you may need to consider a hardware fault of your UPS detecting and acting on a wrongly measured input voltage. If your UPS does not actually go on battery (and you can't see any such LEDs or hear the inverter clicking/switching in such situations where you are notified) and it does really work in APCUPSD without any such issues, it may also be a compatibility issue with NUT, in which case you should better use APCUPSD (through "UPS Settings") instead.

Sure, same as with any other Linux terminal command (rm, dd, ...) that's run without double checking. Although this program actually makes you confirm your selection again, which most Linux terminal commands don't.

Please post the NUT Debug Package that can be found in NUT Settings.

Thanks for the update, I still hope we can get the configuration flag bug fixed as soon as possible, so you don't need to run this "upsrw" command every time you restart NUT and the configuration flag takes care of that in the future.

I think this is a bug, I've opened an issue on GitHub - you can follow it here: https://github.com/networkupstools/nut/issues/2605 The upsmon -k command has a different function, it won't help us here, I'm afraid.

Can you try setting: allow_killpower = 1 (and restart NUT afterwards) Yes, the driver state being quiet is normal and not a problem.

No, please put it at least on line 9 because line 1 - 8 are reserved and overwritten by GUI. So put it on line 9 or later to be safe, and restart NUT and afterwards try again. 🙂

By the way, upsmon -c fsd also does an immediate shutdown and bypasses all NUT shutdown conditions. But it does a graceful, safe OS shutdown (= same as clicking "Shutdown" in Web GUI), killing the UPS power with the other commands is the equivalent to pulling the cable from the power socket while the system is running.

You can do this, if you really want it, with upscmd. First you need to put allow_killpower at the end of UPS.CONF. After, restart NUT and you can run: upscmd -u admin -p adminpass ups driver.killpower The username and password are the NUT defaults, so you do not need to change them usually.