[Nut-upsdev] Scripting approach to replace/supplement WinNUT and other NUT clients

[Ted Mittelstaedt]

Hi All,

Recently, Jim over on the apcupsd mailing list said the following:

"I am a bit sceptical about python etc. scripts replacing apcupsd or 
NUT: surely, they can handle a particular device, solving one job maybe 
even perfectly (do some definition of perfection). But you need another 
script if you have a different device, and something else to orchestrate 
them if your work or home lab has several different UPSes. This is the 
part where at least NUT shines, with its library of dozens of driver 
protocols for different media (serial, USB, SNMP, NetXML, IPMI, etc.) 
looking and acting the same way, at some level of abstraction. And there 
are many recent community contributions about adding and fixing drivers, 
that are far from being concentrated on only USB HID - dialects of 
Megatec QX are quite prolific, some proprietary binary protocols pop up, 
SBC enthusiasts have some GPIO and I2C connections to batteries, and so on.

Another aspect is embedded systems, where some Python or Rust or Java 
run-time alone is larger than the system storage device. We have had 
reports of people running a selection of NUT programs on their 
OpenWRT-based routers, with some 128M of storage altogether. One driver 
and `upsd` can be apparently (cross-)built and linked and stripped in 
such a lean manner that one's router with its USB port can represent the 
home UPS on the network. Haven't tried that myself, yet, so I'm just 
passing on the lore here :)"

Well, Jim I'm going to tweak your beard here a bit an introduce the 
following github repository  that does exactly this:  It's a library of 
script some of which are NUT clients, for both Windows and Macintosh:

tmittelstaedt/UPS-HID-and-NUT-Monitoring: Monitoring & shutdown scripts 
for UPSes that use USB connections 
<https://github.com/tmittelstaedt/UPS-HID-and-NUT-Monitoring>

Now presumably everyone knows the importance of a NUT client - a NUT 
client is what you use when you have -multiple- devices plugged into one 
large UPS and you want them all to shut down at the same time.  So you 
designate one device as a NUT server, load NUT on it, plug the UPS 
monitoring cable into it, then run NUT clients on all of your other 
devices that are slaved to the NUT server (oh dear, there I go being 
politically incorrect)

For years, the party line with both NUT and APCupsd was that the way you 
accomplish network distributed shutdown information was you just run 
copies of NUT or APCupsd on everything you want to shut down.

But a decade ago I became entranced by the idea that the shutdown 
information distributed by both APCupsd and NUT is just nothing more 
than a network protocol.  It was an incredibly POORLY DEFINED protocol 
(folks, saying "the code documents it" is equivalent to telling a newbie 
"here's a nickle kid go by yourself a real computer") but as a protocol 
- that meant ANY application could implement it.  Not just NUT or apupsd.

So I went to the trouble and work of writing both Java and .NET C# 
programs that implemented the apcupsd protocol as clients.  And they 
worked!  But, nobody was really that interested in seeing an elephant 
dance - interesting, perhaps, but of little practical value.  So I set 
the work aside.

But in the meantime computer and operating system technology continued 
to advance.  Apple eventually came to the understanding that the primo 
scripting engine on Macintosh was gonna be Python - they are specialists 
in torture after all - and began embedding it in MacOS.   Microsoft as 
usual couldn't be bothered doing the obvious thing of adopting what 
everyone else was doing and created PowerShell (or PowerHell as some 
people call it)  But these scripting language implementations, over 
time, became powerful enough to actually be used to implement network 
client programs even though you had to be a completely 
cracked-in-the-head lost soul to write anything in them (defining a 
function based on the level of -indentation-?!?!  Really??!!?!?!?)

Until the advent of AI.  Which while AI seems to have been developed 
mainly as a method of making money putting C-rated actors out of work 
producing radio and TV commercials and B-movies, just so happens to have 
the unintended consequence of being really excellent at following arcane 
cracked-in-the-head rules used by these written-by-idiot-savants 
scripting languages Powershell and Python to mention nothing of Gtk, 
AppKit and all the rest of the idiotic nonsense required to make these 
scripting languages do anything useful.

And, just as Mother Nature grows something wonderful out of heaps of BS 
piled in a corner, so have I done so here.  The benefits of using 
scripting languages to implement UPS shutdown clients are many:

1) if the operating system does something that caps out your compiled 
program you have to recompile and fix whatever bugs were introduced.  
However a patch to a script can be immediately distributed and added by 
users without having to go to the work of installing the toolchain or 
waiting until the developer gets around to doing it and releases a fixed 
binary (we are still waiting for a final on WinNUT I might add, and the 
toolchain to recompile apcupsd for windows is a little shop of horrors)

2) With the advent of cheap Raspberry Pis' and the plethora of discarded 
wifi gear that OpenWRT can run on, any old SoC can be appropriated for 
use as a dedicated NUT server for a large UPS that serves many clients, 
so it is no longer necessary to plug the UPS USB cable into your $15,000 
HP Proliant Gen 12 server and run a NUT (or apcupsd) server on it, the 
USB cable can go to it's own dedicated NUT server

3) A new OS can be easily supported as long as a python or powershell 
engine comes with it - and any brand new OS today that does not, is 
stillborn.  Even Microsoft recognized this by making a python 3 engine 
runnable on WSL   While none of the elephants making new OSes gives 
tinker's damn about NUT being available on their distros they damn sure 
care about Python or Powershell being available.

4) Desktop OS'es are becoming increasingly inhospitable to running NUT 
(or apcupsd) anyway.  When MacOS boots if it sees an APC UPS (or ANY UPS 
that implements UPS-HID over USB which all of them do now) it 
immediately seizes that for it's power management and UPS monitoring and 
like hell if your going to pry the OS off that USB hardware ID.  
Microsoft does the same although at least they had the grace to leave an 
easy method to unload their default USB UPS driver (which is crap city, 
treating the UPS as a flipping BATTERY) and replace it with your own - 
of course, you then have to write AND SIGN your own driver.  But scripts 
fly under their radars here and can be used to hook into the OS 's 
crappy drivers- as the scripts in my repo demonstrate.

Anyway, enough ranting.  Everything here is version 1 - it's been 
tested, it works in the test environment - but that's a small 
environment.  It's proof of concept of an idea that I thinks time has 
come and Jim is welcome to incorporate any of the NUT stuff into the NUT 
repo.

Enjoy!

Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20260902/5460c0c1/attachment.htm>