[Nut-upsdev] MGE NMC and NutShutdownModule (and other stuff)

[Marco Chiappero]

Hi all,

some time ago I bought at discount price a NMC for managing a few
computers using the programmable outlets features available on my MGE
Evolution, unuseful otherwise (ATM). However, expecially for my server
machine, I don't like very much the NSM client provided by MGE/Eaton and 
I'd rather use only NUT from my distribution. So, looking at the 
netxml-ups driver, I started adding some code into the mge-xml 
subdriver, to power off the system whenever the NMC tells it's time to 
go down. Although the code is still a stub and incomplete, it seems to 
work fairly well with my own setup. However I'd like to know, first of 
all, the best way to integrate this functionality in NUT, and, after, 
whether there is some interest in including this feature in the upstream 
package.
Currently I added a management struct containing (almost) all management
data, including three (start/update/stop) callbacks called from
upsdrv_initinfo(), upsdrv_updateinfo() and upsdrv_cleanup(). Once the
subdriver is subscribed and connected with the NMC (currently using the
connected/tcp protocol only), it periodically reads xml alarm messages,
mainly the ones that indicate mains loss and low battery state for that
specific outlet (obviously a few driver specific parameters are needed).
However including the NSM functionality in this way some questions came
into my mind... so let's talk about them separately.


Topic #1: right place for NSM

As already said the temporary solution I adopted seems to work fine, it
is small and easy; at the moment the netxml-ups.c file looks a bit MGE
specific but it's not a big issue right now. The real downside is the
single UPS configuration support, there is no way to support redundant
configurations. How to deal with them? I see mainly one solution (above
writing something over upsd), a new driver for a "virtual" UPS as result
of one or more UPSes connected in a single or multiple UPSes
configuration. It should work very much like NSM: it should read the
configuration schema from the device_path var, retrieve basic data from
upsprop.xml summary page for every single UPS included in the
configuration file, calculate somehow the total runtime, load and so on,
dealing with NMC communication too, as NSM does. So, upsmon would just
monitor this virtual UPS, while for UPS specific data the netxml-ups
driver can be used. However some more effort and knowledge about the NSM
and NMC protocols is required (Arnaud, maybe you can help somehow?).
Moreover I just own a simple MGE Evolution, I've never dealt with
different scenarios.
Well, I don't expect much interest about a NutShutdownModule, but if I'm
wrong here I am for discussion. Suggestions are welcome. :)


Topic #2: new RunTimeToShutdown variable

Reading both alarm messages from NSM and the summary page I noticed the
System.RunTimeToShutdown/System.Outlet[2].RunTimeToShutdown/
System.Outlet[3].RunTimeToShutdown variables. If I'm not wrong it is
intended to provide the per outlet available runtime before sending the
BelowRemainingCapacityLimit/shutdown indication to the client. It would
not be bad to show this reading too. Do you think is ok to add the
outlet.runtime/outlet.X.runtime variables to cmdvartab, even though is a
MGE NMC specific value?


Topic #3: text messages system

Some alarm messages sent by the NMC contain some human readable text
(currently discarded). In the EATON/MGE NSM client these text strings
are stored for logging. So I asked myself why not to have such behaviour
in NUT as well? I know, it looks a bit strange, but let me explain a
little bit better. The basic idea is that any single UPS comes with
fixed buffer containing MSGs (or a list of MSG), human readable and HW
specific info text only, above the already present VARs and CMDs. So,
any driver can generate these messages, just for informational purpose,
and propagate them "upstairs" like they were VARs. It recalls me the
hard drive SMART, where along with variables and commands you have some
fixed logging text structures to be read by man. Once stored they could
be read through upsd. Let's consider a desktop computer, wouldn't be
good to have such messages shown, for example, by a notification daemon
(such as the one in ubuntu)? Or sent to a mailer, logger, whatever?

I know, neither the NSM idea nor this last one is going to interest you,
but suggestions don't hurt. :)


Regards,
Marco