Nut upsdev - Jun 2014 - feature request -- talk to the router, not the UPS

Hi Ted,

Thanks for the reply.  I didn't realize that tapping into the serial port
could be that simple.  I might do that - for my application all I would
need would be the first relay.  I can simply set the timer in the FreeNAS
GUI to wait a few minutes to see if the UPS comes back up before it does a
system shut down, so I can be okay without the low battery signal.

I respectfully disagree that the scripting functionality I'm proposing
isn't appropriate for NUT.  Even though it is unorthodox, and technically
easy (for some people, but not for many others) to implement this in other
places, this script idea does still provide functionality, and this
functionality does seem to be congruent with the mission of NUT.  The
benefit of having this functionality embedded at the low level of NUT in
the architecture is that then a whole lot of different software packages
that employ NUT might automatically support this functionality, without
having to reinvent the wheel, without duplicating effort and any possible
security concerns that are involved in scripts that control stuff.  (I
honestly don't know what if any those concerns would be as I'm not
familiar enough with this OS.)

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.  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.

One way to make the argument for NUT supporting this is as follows:  If a
new signaling protocol becomes ubiquitous on UPSes, like say, firewire,
then NUT would want to support that interface, however odd it was.  Well
you can think of pinging the router as the 'psychic interface' to the
UPS... Yes, it's odd, but we're 'inferring' that the UPS is
still up based
on some assumptions... this is not a whole lot different than what the UPS
it's self does when it reports via the serial port or the USB port... the
UPS is inferring that it is still working or not based on the assumption
that its internal hardware is still working as intended, that no relays
have gotten stuck, etc.

So, this pinging of the router is a way to talk to the UPS, it's just,
less reliable, and very round-about.  But I mean, for some users in some
applications, a given level of reliability might be okay.  You wouldn't
buy a UPS at a flea market for a mission critical application, but a home
user might give it a try.

So... NUT is all about knowing what the UPS is up to... going over the
network to the router achieves this almost as surely as does going over
the USB port to the UPS.

So that's my case, as best I understand it.  In any event thanks for
considering the suggestion,

-Elliot


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.

The first relay is a primary 110 (or 220v) AC coil and a set of NO
contacts.  When main power fails the contacts close.

The second relay is a primary 12v DC coil and a variable resistor and a
set of NO contacts.  It is wired across the lead-acid battery contacts
in the UPS.  The UPS is unplugged from the wall and battery voltage powers
the load until the UPS drops out.  The amount of time this takes is
measured.  Then the batteries are recharged and the second relay and
variable resistor is connected across the battery terminals, and the UPS
is run for 1/2 of the time with the load attached, at that time the
variable resistor is turned to reduce voltage across the relay until
the relay contacts drop out.

You end up with a set of 2 contacts, one is connected on loss of AC
power, the second is connected on Low Battery.  These contacts can be
wired to a serial port on the PC and the Generic UPS driver in NUT
can then be used.  The relays and adjustment pot can be put in a
small plastic case and put inside the UPS in the battery compartment.

A variation on that would be if your UPS has a low-battery light,
that light can also be used with a relay.

Or someone can get fancier and use opto-isolators to do this as well.

Incidentally, there are many other schemes that can be used to get
power state into a PC.  Here are some:

1) An attached USB printer can be plugged into NON-UPS power.  A script
can be run that polls the printer.  When the printer goes away the
system is shut down.

2) Most server-class systems have dual power supplies.  You plug one
supply into a UPS the other into the wall.  When the wall supply goes
offline, the system is shut down.  (look into ipmi to learn how to test
for status of dual supplies in a server)

3) An old junky ethernet switch can be plugged into non-UPS power and
a cable plugged into a spare NIC port on the server.  A script polls
that port and when it sees the port lose link, it shuts the system down.

Ted

On 6/2/2014 1:38 AM, elliot smith wrote:
> Hello,
>
> I want to propose a universal UPS driver that will work with any and all
> UPSes out there.  That driver is called:  PING :-)
>
> It works like this... the user plugs their router into a power source
> OTHER than the UPS.  Instead of talking to the UPS, NUT pings the router
> every say, 30 seconds.  If the router doesn't respond to the PING, NUT
> keeps trying for a user-configurable amount of time, say, keep trying
> every 10 seconds for the next 2 minutes... if the router is still down,
> then NUT initiates shut-down, no differently than if the UPS driver was
> reporting the the UPS was was running on battery power.
>
> Sounds stupid, right?  Well it is stupid!  But having to replace a
> perfectly good working UPS just because you don't have a needed driver
> is
> also stupid.  So it's a lesser of two evils sort of thing.  This router
> PING scheme would provide a bare minimum of functionality for users who
> have a non-supported UPS but can not afford to get a new UPS, for users
> who don't need any extra functionality, or for users who are simply
> waiting for a new UPS to arrive.  It would also be great for users who
> are
> simply too lazy to figure out the right USB port and driver to select.
> I
> guess it could also be an option for the user to configure this router
> PING as a backup for in case the server loses the connection with the
> UPS.
>   (cat chews through the cable?  needed to borrow the USB cable for a
> printer?  etc.)
>
> This scheme is simple, and would be effective, and might be good enough
> for users who aren't running a datacenter and who live with cats.
> https://www.youtube.com/watch?v=aQeIDhz-_eg
>
> Please advise if this is something that can be implemented?
>
> Thanks!
> -Elliot
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

_______________________________________________
Nut-upsdev mailing list
Nut-upsdev at lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

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

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

On 6/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
>
That one does not monitor for low battery.
> 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.)
>
Say what?  A lot of those setups connect DSR to the relay contact and 
when that line isn't raised high the serial port under UNIX is closed - 
why does the generic UPS driver still attempt to poll it?????  Sloppy
coding?

The hardware design is so that the driver can go to open the com port 
then just block until DSR is asserted.  Then you can start the polling, 
looking for the CD line to go high (indicating a low battery)
> 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.
>
the hack posted (inserting a relay in a spare mouse, really!?!?) that 
you linked to is really unbelievable.

Ted