[nSLUG] linux home or workplace automation and Universal Powerline Bus
D G Teed
donald.teed at gmail.com
Sat Sep 20 16:48:17 ADT 2008
On Sat, Sep 20, 2008 at 2:52 PM, George N. White III <gnwiii at gmail.com> wrote:
> What I want to do:
> 1. detect loss of line power (e.g., UPS goes to battery)
Does your UPS work with snmp queries? If yours
works with a standard UPS MIB, you can monitor
it with nagios or make your own script to initiate
actions when the UPS shows a certain number of
minutes of battery power have elapsed. I can
send you the query we use if your UPS is
working with the standard UPS MIB format.
If you have a APC UPS, there is apcupsd. It has
multiple platform client support. Even if you don't
have an APC UPS, you can buy a cheap one,
plug nothing into it, and merely use it to monitor
the power situation from one admin server.
Client apcupsd can be set up to shutdown
at their own trigger points (typically, number of
minutes on battery power, but the script
could be changed to work based on UPS temperature).
> 2. with a short period (1-2 mins), initiate shutdown of the
> lower priority systems -- a) they don't get generator
> power so will have to be shutdown, and b) to reduce
> the heat going into the room
> 3. if the generator comes on, start the A/C after the
> specified delay, otherwise, initiate shutdown of the
> remaining systems so they can do a clean shutdown
> before overtemp is triggered or the UPS dies.
The temperature of the internal of the UPS can be
obtained by apcupsd. In my experience, it is representative
of the server room temperature in small UPS units. In
large UPS units, the temperature will soar higher
than the room temperature when it runs on batteries.
This is another advantage of the small APC UPS for
You can monitor temperature by crons and
use it to trigger shutdowns to systems which
should stay up as long as possible. Alternately or also,
trigger nagios alerts to your pager in the event
things are melting.
> Each of these events needs to be logged locally and
> somewhere that is accessible from outside the
> building (there have been a number of cases where
> the building was closed and I had to wait to get back
> in to access the damage -- for various reasons, we
> have to evacuate the building when the power is off
> for any extended period). Many sites so this sort of
> control using ethernet wiring, but using the power
> line has some advantages since you need power
> for anything to work, while ethernet tends to degrade
> when there are power problems:
Nagios and cacti both work well with snmp based
monitoring and/or alerts. Otherwise, regular file logging
or emails from your cron scripts can help.
If you notice network problems when power is lost,
I'd think there is something not on UPS power. Another
possibility is that some devices or systems obtain
IP addresses by DHCP, and if for some reason that
fails, it can trigger a series of service or routing
failures. Hard wiring all IPs - perhaps in devices
you tend not to think about - can reduce
reliance on DHCP.
For example, we initally had false nagios
alerts related to our UPS power being out
merely because the DHCP was down for an
hour and then the UPS ethernet was offline.
I hard wired the IP into the UPS and never
had a false alarm afterward.
> 1. there have been UPS failures in the network
> closets. We have had power outages that
> killed UPS's -- you can get really big spikes
> when high voltage wires touch the lower
> voltage lines.
I don't know what can help protect you from this.
Talk to an electrician?
It sounds like you are interested in the UPB path
because it won't involve ethernet to monitor
the systems and control the shutdown. But
ethernet problems are not really a "given"
when the power goes out. This issue is
likely solvable with analysis. If you are not
using cacti or nagios already, it would
be an idea to set them up to send alerts
and/or graphically log the availability of hosts,
router ports, etc. Then the next time you
lose power it might be possible to trace
the thing that goes down when the lights
More information about the nSLUG