<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi All,</p>
<p>Recently, Jim over on the apcupsd mailing list said the
following:</p>
<div>"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.</div>
<div><br>
</div>
<div>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 :)"</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div><a
href="https://github.com/tmittelstaedt/UPS-HID-and-NUT-Monitoring">tmittelstaedt/UPS-HID-and-NUT-Monitoring:
Monitoring & shutdown scripts for UPSes that use USB
connections</a></div>
<div><br>
</div>
<div>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)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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??!!?!?!?)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:<br>
</div>
<p>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)<br>
</p>
<p>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<br>
</p>
<p>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.<br>
</p>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Enjoy!</div>
<div><br>
</div>
<div>Ted <br>
</div>
</body>
</html>