Monthly Archives: October 2013

Wake up your computers after a power outage with a Raspberry Pi


Even a snazzy networked NUT setup, covering all your windows and linux boxes at home, making sure they all shut down when your over-kill UPS goes into the Low Battery state can seem like a waste of time if you have to come back home and start everything manually before your batcave is back online.

Enter the Raspberry Pi. This is a linux box that will immediately start booting when your power comes back on, assuming you’ve connected it directly to the outlet and not through your UPS. All that’s left is just to wake the rest of your boxes once the Pi’s booted.

In my case I wrote a short script and put it in /usr/local/scripts/


sleep 600

echo "Waking up everybody"
wakeonlan -f /etc/homeLan.wol

The sleep in there will make sure you won’t start your other computer before a full 10 minutes have passed after the Pi finished booting. this will prevent “flapping”.

/etc/homeLan.wol is a file in the following format:

# This an example of a text file containing hardware addresses
# File structure
# --------------
# - blank lines are ignored
# - comment lines are ignored (lines starting with a hash mark '#')
# - other lines are considered valid records and can have 3 columns:
#       Hardware address, IP address, destination port
#   the last two are optional, in which case the following defaults
#   are used:
#       IP address: (the limited broadcast address)
#       port:       9 (the discard port)



Finally, we need to actually run this when the Pi boots, this can be easily done by adding the invocation to /etc/rc.local:

#!/bin/sh -e
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
# In order to enable or disable this script just change the execution
# bits.
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"

/usr/local/scripts/ &

exit 0

UPS monitoring with NUT, Nagios and Check_MK

Nagios, Check_MK and NUT

I have two UPS units at home, powering my batcave, which will get its own post sometime. Check_MK’s agent architecture really appeals to me, I naturally wanted to leverage it into the solution.

Basically, the Check_MK Agent is a small bash script that dumps a whole lot of plain text info out to STDOUT, this output is usually exposed over the network using xinetd, so when you open a socket on the port (6556 by default), with a telnet command, for example, you just get the whole output dumped right out.
This means that adding output is very simple, especially as the agent will try to run any executable files in the plugins dir, you can just read the agent script to see where that is on your installation. Creating the following script in the plugins dir, simply adds the output to the text dumped by the agent when it’s being invoked.

if which upsc > /dev/null 2>&1 ; then
    echo '<<<nut>>>'
    for ups in $(upsc -l)
         upsc $ups| sed "s,^,$ups ,"

On my box, the output looks like this:

VT650 battery.voltage: 14.10
VT650 battery.voltage.high: -1.08
VT650 battery.voltage.low: -0.87
VT650 device.type: ups
VT650 blazer_usb
VT650 driver.parameter.bus: 005
VT650 driver.parameter.pollinterval: 2
VT650 driver.parameter.port: auto
VT650 driver.version: 2.6.4
VT650 driver.version.internal: 0.08
VT650 input.frequency: 49.9
VT650 input.voltage: 237.3
VT650 input.voltage.fault: 140.0
VT650 output.voltage: 238.3
VT650 ups.beeper.status: enabled
VT650 ups.delay.shutdown: 30
VT650 ups.delay.start: 180
VT650 ups.load: 25
VT650 ups.productid: 0000
VT650 ups.status: OL
VT650 ups.temperature: 30.0
VT650 ups.type: offline / line interactive
VT650 ups.vendorid: ffff
JP2000 battery.voltage: 28.10
JP2000 battery.voltage.high: -1.08
JP2000 battery.voltage.low: -0.87
JP2000 device.type: ups
JP2000 blazer_usb
JP2000 driver.parameter.bus: 004
JP2000 driver.parameter.pollinterval: 2
JP2000 driver.parameter.port: auto
JP2000 driver.version: 2.6.4
JP2000 driver.version.internal: 0.08
JP2000 input.frequency: 49.9
JP2000 input.voltage: 231.8
JP2000 input.voltage.fault: 150.0
JP2000 output.voltage: 235.2
JP2000 ups.beeper.status: enabled
JP2000 ups.delay.shutdown: 30
JP2000 ups.delay.start: 180
JP2000 ups.load: 20
JP2000 ups.productid: 0000
JP2000 ups.status: OL
JP2000 ups.temperature: 30.0
JP2000 ups.type: offline / line interactive
JP2000 ups.vendorid: ffff

I’ll go into further detail on my NUT setup in a later post.

Now we have the data which is great, but Check_MK can’t make heads or tails of it. We need to parse it on the server side. Since Check_MK uses a python API, we are forced to use python to parse our data. The Check_MK parser should be in your check_MK server’s checks directory.

Since the python script itself is a bit on the long side of things, you can find it in my Check_MK plugin repo on github. This script has been created for Check_MK v1.1.12p7, but if you’re interested in adapting it to the latest (and more elegant)  API, you’re welcome to fork it on github or ask me to do it.

The end result is quite pleasing and allows me to easily track my UPS load, get live email alerts about power outages at home and have all this data collected into RRDtool graphs through PNP4Nagios.

A green metric is a happy metric.
A green metric is a happy metric.
Low load percentages will allow your UPS to keep your equipment up longer

Making an audio mixing box

A few months ago, I got a new desktop and handed down my previous desktop to my wife as a gaming rig to complement her day-to-day laptop.
Ending up with two computers, but with the same single set of speakers we had before raised the question of how to connect the audio from both computers to the speakers.

One’s immediate instinct is to just connect all the wires and let ‘er rip. However, that’s a very bad idea.

Your science is bad and you should feel bad!
Your science is bad and you should feel bad!

This post explains exactly why this is a bad idea and describes a simple mixer circuit that sums together two inputs into one output. However, it doesn’t allow any mixing control.

Simple and useful
Simple, useful, yet lacking.

In case you’re not familiar with circuits and whatnots, check out for some tutorial goodness.

This doesn’t deal with a very common situation where the volumes on the two inputs might not be set to comparatively reasonable levels, causing the output to effectively feel one sided. with no means to control the mixing ratio, I felt it wasn’t good enough. Additionally, if one of the inputs is connected to a computer that’s shut down at the moment, some static noises might be annoying, so an option to disconnect one of the inputs temporarily might be nice.

Complete with switches and double pots.
Complete with switches and double pots.

My design required a few specific components, for example the two pots are actually a double potentiometer (two pots on a shared axis) affecting both left and right channels in the same intensity. the switches are also double switches (123circuits only had triple switches) so both U1_S1 and U1_S2 should connect and disconnect together, without actually touching one another electrically (crossing the streams, sword-fighting if you will).

It took me a while to collect everything I needed, including buying solder for the first time in like a decade. but last week I was finally ready to build.

here’s the final result:

A very "sound" design
A very “sound” design

Using it is as intuitive as pointing the knob in the direction of the input you want to be more dominant. I skipped on the switches as the ones I had from were a bit flimsy and messed the audio a bit. I will probably post an update once those are added.

Plugs go here.
Plugs go here.

The actual inputs are aligned with the labels and directionality of the pot, so it should all just “make sense” to the user. Output is in the middle.

a quick lookie loo
A quick look inside

This was my first soldering work in over a decade so I won’t be posting any close ups of that poor poor PCB.