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

OS: Debian Wheezy
Nut: 2.6.4-2.3
Installation method: Synaptic
Device: CDP B-UPR505
Traces, debugs, etc.: Not available or irrelevant

Description:

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.

Many years ago, when monitoring just wasn't common yet, I developed a device
to attached to a serial port and plug into an unprotected wall outlet and then
wrote a C program to run as a daemon on my SCO Xenix systems to check whether
that serial port could be opened or not.  When the power went out, the device
(not being connected to the UPS) would lose power, my program would not be able
to open that serial port and the program would wait a couple of minutes (in case
the power came back on) and then issue the shutdown command.

Nowadays, the computers no longer have serial ports, so I have modified my
concept by inserting a small relay into a USB mouse, hooking the coil to a wall
transformer, cutting the USB power wire and hooking the resulting ends to the
normally-open contacts of the relay.  Thus, when there is power, the mouse
works.  When there isn't power, it's as though the mouse isn't even
connected to the machine.  (This can be done with an old, second mouse, so as
not to interfere with the operation of the mouse I'd actually be moving
around the screen.)

So, here's my question: how can I get Nut to recognize such a set-up? 
Obviously, it's USB, but it's NOT the typical USB-HID that existing
drivers would expect.  With my programming experience, I'd probably be able
to write the sub-driver for this, but I really don't know much about USB. 
For that matter, depending upon the USB information I get, I may even be able to
write my own simple daemon (or even a shell script) without using Nut, at all,
but it would be nice to be able to integrate it into Nut so I could have the
Windows Nut client get info from the Linux machine, rather than my having to
attempt such programming in the Windows environment.

Of course, if someone has already developed what I described, then that would be
even better, but I haven't found it in the Nut lists or documentation, yet.

Thank you for any assistance you may provide.

Gishpuppy | To change the delivery settings for this email, click here: 
http://www.gishpuppy.com/cgi-bin/edit.py?email=lists.vn1 at gishpuppy.com

Hi, Reference:

lists.vn1 at gishpuppy.com wrote:
> OS: Debian Wheezy
> Nut: 2.6.4-2.3
> Installation method: Synaptic
> Device: CDP B-UPR505
> Traces, debugs, etc.: Not available or irrelevant
> 
> Description:
> 
> 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.
> 
> Many years ago, when monitoring just wasn't common yet, I developed a
device to attached to a serial port and plug into an unprotected wall outlet and
then wrote a C program to run as a daemon on my SCO Xenix systems to check
whether that serial port could be opened or not.  When the power went out, the
device (not being connected to the UPS) would lose power, my program would not
be able to open that serial port and the program would wait a couple of minutes
(in case the power came back on) and then issue the shutdown command.
> 
> Nowadays, the computers no longer have serial ports, so I have modified my
concept by inserting a small relay into a USB mouse, hooking the coil to a wall
transformer, cutting the USB power wire and hooking the resulting ends to the
normally-open contacts of the relay.  Thus, when there is power, the mouse
works.  When there isn't power, it's as though the mouse isn't even
connected to the machine.  (This can be done with an old, second mouse, so as
not to interfere with the operation of the mouse I'd actually be moving
around the screen.)
> 
> So, here's my question: how can I get Nut to recognize such a set-up? 
Obviously, it's USB, but it's NOT the typical USB-HID that existing
drivers would expect.  With my programming experience, I'd probably be able
to write the sub-driver for this, but I really don't know much about USB. 
For that matter, depending upon the USB information I get, I may even be able to
write my own simple daemon (or even a shell script) without using Nut, at all,
but it would be nice to be able to integrate it into Nut so I could have the
Windows Nut client get info from the Linux machine, rather than my having to
attempt such programming in the Windows environment.
> 
> Of course, if someone has already developed what I described, then that
would be even better, but I haven't found it in the Nut lists or
documentation, yet.
> 
> Thank you for any assistance you may provide.
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 ?).

Examples of FreeBSD USB `attach` & `detach` manual & command 
  /usr/src/sbin/devd/devd.conf.5
  http://svnweb.freebsd.org/base/head/sbin/devd/devd.conf.5?view=markup
  http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/src/jhs/etc/devd/jhs.conf

Cheers,
Julian
-- 
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
 Reply below not above, like a play script.  Indent old text with ">
".
 Send plain text.  No quoted-printable, HTML, base64, multipart/alternative.

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