nut
nut copied to clipboard
networkupstools
Change battery threshold for shutdown on debian client
I have searched for hours but i can't find the setting for this. So I have the following machines :
- debian 11 running nut client
- windows 10 likewise
- eaton eclipse 1600 eco + rpi 4B running nut server I would like to control both windows 10 and debian 11 with NUT over network. I want windows to shutdown ASAP after outage, and debian 11 to shutdown last before the pi
IIRC I read somewhere that by default NUT sends shutdown signal if there's 10% remaining battery. On windows 10 client GUI there's an option to "Shutdown if battery lower than", with that I can change it to 90%.
But how do I change this on linux client? I need to change it to big numbers like 80% to test directly if my config is correct. Also is there any GUI similar like the windows client for debian? I've tested walnut, wmnut but none of them has settings to change remaining battery threshold rule.
For clarity, which versions of NUT are involved? Packaged? Custom-built?
In particular, NUT in distros tends to be v2.7.4 still (half a decade old); some experimental distro repos offer 2.8.0 also; custom-builds are usually recent GitHub master snapshots. NUT for Windows was built earlier as MSI packages based on 2.6.5 so last released about 9 years ago -- this effort was recently revived, nowadays there are CI builds with tarballs of binaries "as is" and no packaging. There may also be third-party projects which use NUT protocol and/or libraries (e.g. WinNUT-Client), but otherwise are not related or too well known to NUT team :)
With programs distributed by NUT project, there is a client like upsmon (most of the time) or upssched (for more complex setups, might be your case) which at least partially runs as root (to trigger shutdown when needed... might use sudo, pfexec, etc. instead), listens to the NUT data server upsd, and reacts to an alarming situation such as "was last known on battery, became low-battery or lost connection to server" or "got explicit FSD (forced shutdown) message from server". In this model, server and UPS config might involve different tolerance of remaining charge - what would be "low battery" but I am not sure this can be done per client. Maybe this description applies more to upsmon behavior, and YMMV with upssched or even custom client (there are C, C++, Python, Perl, Java... protocol bindings of different maturity, in-tree and third party).
X11 UI clients that I know of are "informative" and do not take care of actual OS shutdown (usually do not run privileged enough to even try).
Note that "ASAP after outage" may be too eager, e.g. mis-diagnostics (including heavy CPU/Net load causing missed messages), and short-lived events like tripping a power switch back and forth.
Also note that for tests you can specify a SHUTDOWNCMD echoing something to wall or a file in tmpfs, so you know the program reacted in a certain way but without actually shutting down the OSes.
nut/stable,now 2.7.4-13 all [installed]
I see, I knew the windows version is too good to be true.. I will try to explore upssched, If it doesn't work I think I'll try usb to rj45. Ideally (and alot simpler) the debian should act as ups server with eaton's IPP app. The problem is there's like 40ft distance between the UPS and the debian machine, hopefully it will work with usb to rj45..
Well, enhancing NUT to scratch an itch, and posting a PR is always an option ;)
Just in case, that UPS is not networked, right? Eaton units with NetXML support (and possibly those with SNMP) tend to support UPS-side client profiles, so everyone runs their client set (netxml-ups driver, upsd, upsmon) and gets tailored alerts in due time. Usually to shut down less-critical load on one outlet group to let other groups live longer...
And "too good to be true" - you did not say which "NUT for Windows" you were running. Eventually we do hope to bring it up to spec, practical help would be welcome :)
Regarding long-distance USB, length may be an issue. I believe it is spec'ed to 6m max (20ft or so) although it may depend on the USB version, did not check further. Two things I'd look out for would be round-trip time related issue if any (cable length impacts that), or EMI noise collected over that run gets enough to make poor signal - that might be amended by shielded and grounded cabling, and laying it far from noise sources (motors like fridges, quasars like "starters" of luminescent lighting, etc.).
Sorry for the late reply, the UPS is not networked, And yes indeed there's usb length limit. But I juts tested with bafo usb to rj45 converter and it seems to be stable for 12-13 meters. Eaton IPP has everything I want, it even has MQTT option so perhaps there is a way to integrate it as NUT server maybe?
Still I'm looking forward to the new version of NUT, one that is less complicated i hope. Thanks for answering my question.
"Eaton IPP" actually refers to several distinct products with different feature sets depending on the platform (Windows and Linux being in one heap, and "other Unix" being augmented NUT). I don't think IPP ever aimed to be NUT-compatible ("as a NUT server maybe"), or otherwise API-stable for third parties, but probably one could code a NUT driver to talk to it at least for single-UPS info sourcing and management. Technologically (web interactions, nut-scanner discovery) it might be a similar effort to NUT netxml-ups driver for MGE (now Eaton) devices whose NMC serves a sort of REST API with XML payloads. In this case I suppose a computer running IPP would be the "NMC" and no quick ideas about the application protocol to talk when a new NUT driver emulates a browser effectively.
I think an MQTT driver for NUT was PoC'ed at some point but not completed. May be a worthy contribution to find and revive that effort if it existed in the open, or make another from scratch.
Thinking of it, got one more idea: you could try the NUT clone driver (and/or dummy-ups in repeater mode) to virtually serve several NUT UPSes using info of one device and overriding certain values in the clone. Per docs it is used to e.g. delegate access to certain outlet group management of a larger device to different subsets of IT population.
This might help you monitor "different UPSes" (as far as NUT protocol is concerned) with different upsmon clients, with different tolerance for battery charge level (or runtime remaining) to trigger a shutdown.
- https://networkupstools.org/docs/man/clone.html
- https://github.com/networkupstools/nut/blob/master/drivers/clone-outlet.c - seems a manpage was not published => #1686
- https://networkupstools.org/docs/man/dummy-ups.html