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

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

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

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 Mon, 2 Jun 2014, 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
Stupidly brilliant!
> Please advise if this is something that can be implemented?
Certainly.  I'm putting it on my TODO list, because remote customers often
accidentally disconnect their UPS, and having something pingable *not* on 
the UPS would be a great backup.  I have no idea when I could get to it,
however.

You'd want failover functionality for the backup application.  I.e., if
the something is not pingable, BUT the regular UPS monitoring is
working (and the power is actually on), then do NOT initial shutdown.
The customer accidentally disconnected the something instead.

On Mon, 2 Jun 2014, Ted Mittelstaedt wrote:
> Incidentally, there are many other schemes that can be used to get
> power state into a PC.  Here are some:
So maybe the dummy driver can be configured with a script to poll
power state (or a callback to get power state events).  That would be much 
safer that reinventing the shutdown logic.

Here is our use case:

A remote customer has a UPS with a normal monitoring interface.  All
works well ... until the customer disconnects the monitoring interface.
(Maybe they are swapping a USB backup drive and pull out the wrong
connector.)

Configure the hidups monitoring and the "ping" (or USB printer or
other
scheme you outlined) monitoring as two UPSes with MINSUPPLIES=1.

Problem:
If the hidups interface is working, and says power is out and battery
low, but the "ping" device is still up, then the customer
"helpfully"
plugged the ping device into the UPS like everything else, and we need
to shut down.