[Nut-upsuser] UPS has no built-in monitor. [GishPuppy]

[Charles Lepple]

On Jul 3, 2013, at 7:33 AM, Julian H. Stacey wrote:

> Hi, Reference:
> 
> lists.vn1 at gishpuppy.com wrote:
>> OS: Debian Wheezy
>> Nut: 2.6.4-2.3
[...]
>> Where I currently live (Honduras), buying a UPS with monitoring capability means spending at least twice as much as a "plain-Jane" model - usually even more than that.  Thus, since I can't afford the ones with monitoring, all I have are ones that have absolutely no connection for monitoring.

Not even relay contacts? That used to be the least common denominator for notifying computers and industrial equipment, and it shouldn't add much expense to a basic model.

In case you find out that some proprietary connector on the UPS provides such an interface, you could use the genericups driver with a USB-to-serial adapter:

   http://www.networkupstools.org/docs/man/genericups.html

> Nice idea !
> Maybe you don't even need to use NUT, 
> (Or could feed into back end of NUT daemon (to inform hosts & do
> the countdown etc) from an alternate device input detector.)
> 
> In the case of FreeBSD, /etc/devd/*.conf allows programs to be
> automatically run on connection & disconnection of a USB device,
> (maybe your Linux offers similar ?).


Julian beat me to it. (Clever setup, by the way.)

On Linux, you can configure udev to run scripts when devices are attached or detached.

   http://reactivated.net/writing_udev_rules.html#external-run

You will probably want a mouse with different USB VendorID or ProductID values than your primary mouse, since low-speed USB devices often do not have a unique serial number to match against.

To broadcast those events to all NUT clients, I would have a pair of scripts which write 'ups.status: OL' and 'ups.status: OB LB' to an input file for dummy-ups:

   http://www.networkupstools.org/docs/man/dummy-ups.html

The one hitch I can imagine is that you would need extra logic to filter the power events. We usually recommend upssched for that purpose (schedule a shutdown X minutes after the on-battery event). However, since you have another system monitoring remotely, and you are generating the NUT events yourself, I would probably do something with a lock/PID file, and have the "on battery" udev script sleep for that delay time after announcing 'ups.status: OB'. Then, if it hasn't been killed by the "on line" script during that delay time (using the PID from the lock file), send 'ups.status: OB LB' to trigger the shutdown.

Let us know how this works. If this turns out well, we could add some example scripts and documentation to NUT.

-- 
Charles Lepple
clepple at gmail