# Experience with nut



## gpw928 (Apr 26, 2022)

I have now installed and configured sysutils/nut on FreeBSD.  It's a UPS management package.

It took some effort, but was worthwhile, as I got exactly what I wanted in the end.

Some of the sentiment I tripped across while doing the research was that sysutils/apcupsd (which does a similar function) was easier to set up -- but the ports description says it's only for APC UPS models.  I got the feeling that APC UPS models were well regarded (and frequently emulated).

I have a CyberPower CP1500EPFCLCD.

The documentation for nut was above average with a user manual in both online and PDF formats, plus there was an excellent set of Configuration Examples.

I initially installed it with everything in default configuration.  This worked, shutting down the server when the UPS battery got low.  But I wanted the shutdown to occur three minutes after the wall power failed.  There was good documentation on how to do this (its called a "timed shutdown"), but you the need to study the examples and write a number of custom scripts to get the job done.

I also had a fully functional network shutdown strategy in place, using one-shot ssh(1) commands, so I chose to set nut up using a single UPS controlling a single server (my ZFS server).  When it comes time to perform the final shutdown of the ZFS server after a power failure (through nut), I just reach out using ssh to shut down all the other hosts that share the UPS.  [This meant that I did not need a nut client on every host on the network, and works well in a home office context -- where I am the only user to placate.]

It took a few days to get it all running perfectly, and right near the end I tripped across a nut/CyberPower problem.  It took a while to hunt down, but I finally got the lead I needed.

The nut manual says set ups.delay.start (default 30) as the interval to wait before restarting the load (seconds) [after UPS power returns]. CyberPower UPSs restart ups.delay.start seconds after the UPS shutdown commences, *regardless* of the wall power status.  Nut sets the value of ups.delay.start using the value of "ondelay" in ups.conf.  Regardless of mains status, with:

ondelay = 0,  UPS powers on the load immediately mains return;
ondelay = -1, UPS never powers on the load, even when mains return;
ondelay = xx, UPS powers on the load after xx (roughly) seconds after `/usr/sbin/upsdrvctl shutdown` is executed.
To stop the UPS rising like Lazarus after every shutdown, set "ondelay = 0" in ups.conf.  This will set ups.delay.start to 0, and fix the problem. However, when wall power returns, there will be no delay in the UPS powering up the load.  So, if your battery is flat, you could go into an endless reboot loop -- but that's a universal problem.

The "ups.delay.start" bug is not well appreciated, and clearly a common cause of frustration with CyberPower UPSs.

Now, when the wall power drops, all my hosts shut down cleanly after a three minute time delay.  When the wall power returns, their BIOS settings allow them to reboot as soon as the UPS supplies power -- which is immediately.

If the wall power returns before the three minute timer expires, the shutdown is cancelled.  Micro-blackouts are frequent where I live, so this is a common outcome.

I have attached a zip archive of the custom changes I made.  They "make install" to supply the configuration and custom scripts for the port/package.


----------



## sko (Apr 26, 2022)

I've been using nut for years now. I particularly like the modular approach and baked-in network capabilities. The upsc tool makes it really easy to write small wrapper scripts to export UPS data e.g. via SNMP or poll a UPS from zabbix.

As for the 'endless reboot loop' - most Cyberpower UPS outputs can be configured in groups with different delays. E.g. at home I've put my switches and gateways in the primary group that is powered up first (IIRC you can specify a minimum battery charge for outputs to be re-enabled); the second group (servers) is delayed by 3 minutes. this way the initial load is rather low (~100W) and the infrastructure is online before the servers come up (and services would fail left and right without a working network)


----------



## gpw928 (Apr 27, 2022)

sko said:


> IIRC you can specify a minimum battery charge for outputs to be re-enabled


The Network UPS Tools User Manual mentions several parameters that influence the UPS restart after power-off.  They are:

ups.delay.start -- Interval to wait before restarting the load (seconds)
battery.charge.restart -- Minimum battery level for UPS restart after power-off
battery.runtime.restart -- Minimum battery runtime for UPS restart after power-off (seconds) 
outlet.n.delay.start -- Interval to wait before restarting this outlet (seconds)
Unfortunately, the CyberPower CP1500EPFCLCD does not support any of these except for "ups.delay.start":
	
	



```
# upsc cp1500 | egrep "delay|restart"
driver.parameter.offdelay: 90
driver.parameter.ondelay: 0
ups.delay.shutdown: 90
ups.delay.start: 0
```
And, since "ups.delay.start" does not behave as nut expects (see first post above), the options to delay the power up sequencing seem to be quite limited (well, non existent).
~


----------



## sko (Apr 27, 2022)

It seems those parameters are only available for UPSs with more than one output group. Also the "home user" graded UPS (e.g. "Back UPS" series) seem to be even further crippled in that regard.

The smallest UPS I have at hand is a PR1500ELCD (/w network management card), and it offers time and charge based restore options as well as time based delay for the non-critical load bank ("Power Restore" and "NCL Bank" in the screenshot).
For the older ones with the 4-button LCD panel IIRC you could at least specify the minimum charge to re-apply power via some sub-menu; but this might be also exclusive to the "bigger" (i.e. not home-user-graded) UPS...


----------



## Zagzigger (Dec 8, 2022)

I hesitate to write this in view of the glowing reports above.
When I installed nut-2.8.0_13 from pkg on 13.1-RELEASE-p3 FreeBSD 13.1-RELEASE-p3 GENERIC amd64, everything was fine until I rebooted the next day.
Then udev wouldn't start because of a parse error in a nut config file - so I lost my mouse. 
Had to go in and remove the offending file usr/local/etc/devd/nut-usb.conf to recover. 
This is out of my confidence zone, so I hesitate to play around and repeat the experience.
I pass this information as a suggested problem rather than a definite one - but I cannot think of much more to add. 
I hope someone more knowledgeable can check this out and get it defined properly - but I don't think I can help more. 
If anyone thinks I should post this somewhere else, please let me know.
Thanks


----------

