[RELEASE] Network UPS Tools (NUT) monitor and shutdown controller (upsmon)

This driver implements a UPS monitor and shutdown controller for use with Network UPS Tools (NUT).

The driver works in conjunction with a remote NUT upsd server, and provides the equivalent of NUT's upsmon for the Hubitat. In other words, it monitors the ups and shuts the hub down when the ups battery is low.

The driver is available via HPM, or for direct import from GitHub here.

Configuration is as shown below.

  • NUT server host: The hostname or IP address of the NUT server (upsd). It should look something like this: myhost.mydomain.net or 192.168.1.10

  • NUT server port: The port number for the NUT server (upsd), as defined in upsd.conf. This will usually be 3493.

  • UPS name: The name of the UPS to monitor, as defined in in ups.conf.

  • NUT username: The username for the connection, as defined in upsd.users

  • NUT password: The password for the connection, as defined in upsd.users

  • Polling frequency: How often to poll for UPS status. This is the equivalent of POLLFREQ found in upsmon.conf. The default is 5 seconds.

  • Enable Hub shutdown: If you want to allow NUT upsmon to shut down the hub, you must enable this. If you do not enable the option, the hub will not actually shut down when the ups battery runs out.

9 Likes

I'll have to look at this after I get my C8-zigbee issues solved.

I will take a look also. I have been running this one for a few years and have my own shutdown routines in rule machine:

Very cool - thanks.

Happy to have one more device following my DiskStation's NUT Server status.

nice work! I've also been using the same one as ronv42 and it has served me well. But it wasn't easy to get going and its never been available from HPM. We see smart shutdown posts in the forums quite frequently and NUT is the best way to do this if you have something running a NUT server. So hopefully lots of people find this useful! :slight_smile:

I installed yesterday and it monitors just fine. Didn't pull he plug for testing the power down aspect but I assume it works. As for monitoring there are classes of data that would be beneficial:

  • PowerSource
  • VoltageMeasurement

PowerSource will give a condition of being on Battery or Mains power which is great for writing rules in Rule Machine etc.

But all in all a very useful driver for those that need the ability to monitor the UPS and shutdown without using WebCORE or Rule Machine.

I also have been using the old discovery driver, I actually was not fond of the parent/child setup and would prefer a single driver like this. I will be checking this out for sure.

I was not really happy with the attributes on the other driver either, it had some things that really did not belong there and was missing the time remaining in minutes.

Here is what I ended up with after modifying the driver
image

The other driver also was taking up a bit of hub resources so I modified it so I could push the refresh interval out to 120 seconds, this caused the telnet to get idle disconnected frequently, so I then implemented a sort of NOP every 20 seconds to keep it alive.

Anyway... just sharing my thoughts and observations from using the other driver for a while. I will be looking to switching over to this one soon.

In NUT, power source is represented in the ups.status variable, which you will find in the "status" attribute. "Online" indicates that the UPS is running off the main power source, and "On Battery" indicates that the UPS is running off battery. These are always in the front of the status attribute.

As to voltage measurements and the like, I chose not to add these attributes. UPSs generally have between one and four dozen attributes available. My main UPS has over 40 attributes, 6 of which are voltage measurements alone. While many of these attributes are interesting, they aren't particularly useful for shutdown monitoring.

My target was shutdown management with minimal attribute monitoring. I didn't want to burden the hub with constantly asking for lots of variables from the UPS, so I stuck with the big three (battery, runtime, load) that most UPSs offer. These are generally useful for basic decisions (at least battery and runtime), and also give a reasonable indication that the system is working without requiring a UPS self test.

3 Likes

I love the parent child relationship. I have two UPS's on my NUT server and both show up on my Hubitat. I just have to know which one the hub is powered by. Disconnects are an issue with NUT. Even on the USB connected UPS's some just stop refreshing unless you reconfigure the polling. So far with the UPS's connected to my Proxmox server they aren't dropping anymore like they were on the Raspberry Pis.

Patent / child isn’t required to support multiple UPSs.

Hi,
I uses a Synology NAS as NUT server and that has restrictions on IP address rather then needing a user name and pwd. Can you make those optional? I tried and it is working. Made a little change on the upsdConnect:

        if (username) {
            telnetSend("USERNAME ${username}")
            telnetSend("PASSWORD ${password}")
            telnetSend("LOGIN ${upsName}")
        }    

Cheers Rene

[solved]. Thanks Denny. No need for this change. I wish I knew as much about this as you when I wrote my own simple driver for Vera years back. My head still shows the scratches.

The username/password is not optional.

To my knowledge Synology does not modify NUT in any way. The IP restrictions that were added in DSM 7 are actually done via a firewall in front of NUT, and are not part of NUT's access controls. If you do not supply a username/password, you are not authenticated as far as NUT is concerned.

By default NUT will allow limited access to UPS status even though you have not provided authentication. I would have to double check, but I believe that the failure is that the attach is ignored. You want the attach.

Short version, even with DSM 7 you still need a username and password for NUT. The username and password for DSM are hardcoded to "monuser" and "secret".

1 Like

I use the NUT Discovery driver with no user/pass and it works fine. So not sure what benefit the user/pass has. I do not think I have any special config on NUT to make it work without it. Unless this driver is accessing something else that needs it, I will have to try it out.

I see you said the "attach" is ignored. If that is something that keeps the telnet from getting disconnected, I did notice that issue where it disconnects but did not realize it could be from not logging in.

If memory serves, without authentication the attach fails. Without the attach, the sever will not view the hub as a secondary, and will not wait for the hub to detach before it begins shutdown. Yes, it should take a Synology much longer to shut down than the hub, but you can still have a situation with longer polling intervals wherein the Synology would get to the point of killing the NUT server before the hub polls again. The hub would simply view this as the connection to NUT being broken, and not know of the low battery situation and pending disconnect of mains power.

1 Like

Btw, it's occurred to me that in posts I am using verbs ATTACH and DETACH. These are the verbs used in the new NUT protocol specification, however if you are looking at the code, you will instead see LOGIN and LOGOUT, which are the verbs that the current version of NUT uses.

So, I'm trying to use my APC Smart-UPS 1000 connected to my Synology DS420+ (DSM 7.1.1) but not being able to connect. I configured the UPS network server on Synology and I can telnet to port 3493 on it... so it seems to be up/running. However, on device I keep getting "Unknown UPS".

Any ideas on what could be happening?

What did you use for the UPS name?

I use APC... should I have something else?

Synology hardcodes everything:

UPS name: ups
NUT username: monuser
NUT password: secret

1 Like

Worked! Thank you!

1 Like