[Nut-upsdev] feature request -- talk to the router, not the UPS

[elliot smith]

For clarity, I guess I'll call what I'm proposing here "UPS state
inference", meaning that instead of communicating with the UPS, NUT
indirectly infers the state of the UPS (running on mains power or running
on battery) by communicating instead with some other device that is
powered from an outlet NOT connected to the UPS.  Ideas that have been
floated include pinging the router to see if it went down or is still
powered on, or watching to see when an extra USB device (printer,
jury-rigged cybernetic mouse, etc) goes off-line.

Presently I don't think I have the needed know-how to be able to develop
and maintain a driver, so this being the case I appreciate that I
shouldn't expect anyone to take on an extensive development effort unless
they are inspired to do so for their own reasons.

Charles, I agree with you on polling.  I was thinking the easiest way
would be to use the system PING command, but even this wouldn't be my
first choice, especially not via TCP/IP.  There are various scenarios that
can break it.  DHCP can be buggy, going through switches can be
problematic, etc.  The reason I would still be happy to compromise and
accept this polling approach, however, is that personally, my primary
concern is not reliability, rather, my primary concern is that NUT should
support UPS state inference out of the box, using the same user interface
mechanism it uses for its standard functionality.  This is my primary
concern, because what I want is that when a project like FreeNAS provides
a NUT interface that allows the user to select the driver and specify the
shutdown timer, etc., I want that same interface to support UPS state
inference without the need for any additional behind-the-scenes
configuration or script installation needed on the part of the end user
and without any extra configuration or support required on the part of the
FreeNAS project.

Finding the most reliable way to provide state inference would be nice,
(in as much as state inference can be reliable), however, if the mechanism
is 100% reliable but is not available without the user being capable of
installing a script, then unfortunately that mechanism is going to simply
not be available to many users.  Many users such as myself run "live-CD"
stuff like FreeNAS and are lucky they were able to figure out how to burn
an ISO image, and so they haven't got the first idea how to configure or
install anything that isn't directly supported in the GUI.

Of course, a script solution that requires installation and configuration
outside of the GUI could also be interesting to many users.  Either way
I'm glad if I've sparked any interest in further development of UPS state
inference.  Stuart has expressed some interest in it, so it'll be
interesting to see what he comes up with.  And who knows maybe eventually
here I'll figure this linux stuff out enough to be able to do some
development of my own.

Thanks for the feedback on this idea,
-Elliot

.

On Mon, June 2, 2014 6:28 am, Charles Lepple wrote:
On Jun 2, 2014, at 7:27 AM, elliot smith wrote:

> For example I am using FreeNAS.  Rather than supporting my unorthodox
> UPS
> signaling scheme by installing it as a script in FreeNAS, (and me
> probably
> messing something up in the process) this scheme could be supported
> instead by NUT.

Bear in mind that all of the NUT drivers have authors who are expected to
be maintainers of that driver. Are you volunteering?

> For the port, when I'm configuring my "UPS" settings in
> the FreeNAS GUI, instead of specifying one of the USB ports, I would
> specify the TCI/IP port, with the IP of the device to ping.

Are you referring to an ICMP ping here? Some OSes require root privileges
to open a raw socket to send the ping echo-request, and NUT is designed to
drop root privileges when a driver starts.

Alternatively, you could call out to the system's ping binary. I haven't
checked, but I suspect this would require a bunch of options to handle
various command line options and return codes.

You could also have an option for a TCP or UDP "ping" to some service on
whatever device you are trying to contact, but I think this explosion of
options points to some sort of scripting solution coupled with an existing
driver.

Note that we are happy to include these sorts of scripts in NUT.

> On Mon, June 2, 2014 2:50 am, Ted Mittelstaedt wrote:
>
>> That kind of scheme should be handled by scripting - not by NUT.
>>
>> As far as having a _perfectly good UPS with no driver_, ANY UPS can
>> be converted into a "dumb" UPS with the addition of 2 relays.

There was also this discussion last summer (similar to Ted's printer idea,
but lower power):

http://news.gmane.org/find-root.php?message_id=20130703045347.55D4172182%40mail.gishpuppy.com

I'm not a huge fan of polling when edge-triggered events are available.
(That said, dummy-ups polls its state file once a second, and that could
be improved upon with something like inotify.)

In most cases, you can add a devd (FreeBSD) or udev (Linux) rule that
triggers when a device disappears, without affecting normal operation of
that device while it is connected. Both devd and udev will simply run all
of the matching rules when the specified action occurs.

--
Charles Lepple
clepple at gmail