33
UPS monitor/shutdown service
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 27 Sep 2026
33 points (97.1% liked)
Selfhosted
62498 readers
217 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
What was the difficulty with NUT for you? The setup is pretty straightforward, IMHO.
Should be easy to wrap in a container, too.
I was hoping to setup a server and clients to shutdown the other Raspberry Pis and such, scattered around the house if the main server senses a power failure.
Also, I had an issue where it insisted on triggering a shutdown the SECOND the UPS triggered, even if it came right back. I might take another swing at it at some point, but I liked the look of that PVE-UPS things.
A basic NUT configuration does an immediate shutdown as soon as an ONBATT status is reached (upssched.conf has "at ONBATT execute...", which causes the upssched-cmd to run the shutdown command immediately). But you can change that to a timer, which can be cancelled if the UPS goes back online, or only shutdown at LOWBATT.
It's complicated, but NUT should be able to do everything you have stated as a goal. But it takes some testing.
One thing I found helpful while setting it up is the Dummy UPS driver that is included in the documentation. Rather than plug and unplug a physical UPS during testing you can make text files with various ups statuses and cp one to the dummy's input file target to make it change to battery power or back online. Use logger to log information into the system journal from upssched-cmd to see what's running in your script (with a unique keyword to grep on). Monitor in another terminal with
journalctl -f | grep yourkeywordto view your messages. This made it much easier to get the upssched stuff sorted out.One of my goals was unattended power-on management for when I was away from home. If power returned for an amount of time, send power commands to various smart outlets to bring everything back up in sequence. So I used a pretty big upssched-cmd, with timers for both shutdown and power up and different UPS battery levels (no power up until 30% battery, for example). It would have been pretty difficult to debug without the dummy UPS.
Anyway, NUT is really powerful.
Thanks. Good info. Feel like sharing your conf file to see how it's formatted in an example that actually works? Might make this my weeks evening project.
It's a lot. But here are my most recent notes.
Note that the pipe & lock locations different by distro, as does the nut username. So these files won't drop in and work anywhere.
The dummy driver will need to be installed and configured.
Mine also have several layers of timers on battery an online:
Most configs would have the client side cancel their timers if power returns. In my case I don't want that because I prefer more certainty of state so that I know it's safe to power cycle an outlet to bring a device back up. My NUT server runs on an old pi 3b with a read-only file system. So it never needs a safe shutdown. It's the last man standing to bring everything else back up if the UPS returns to line power before the battery is exhausted. That's why there is no local shutdown on the NUT server config.
Each
snmpset...is a truncated version of an outlet power command.Also, the wall commands were a debug aid. Uncomment to use, but test a command first. Wall doesn't work on some distros.
NUT Server
NUT.CONF:
UPS.CONF:
UPSD.CONF:
UPSD.USERS:
UPSMON.CONF:
UPSSCHED-CMD
NUT Client
NUT.CONF
UPS.CONF
UPSD.CONF
UPSD.USERS
UPSMON.CONF
UPSSCHED.CONF
UPSSCHED-CMD
On clients you mostly have to set
MODE=netclientin thenut.confand modify theupsmon.confaccording to the manual and detailed manual. By default, it should only shutdown systems when reaching a "low battery" situation, not immediately when switching to battery power.