This little project was born out of a wish to control a DAB tuner from other rooms of the house and a couple of hours on a Sunday afternoon made it reality. A Nanode (an original Nanode 5 in this case) is plugged into my ethernet network and an infrared emitter is connected to digital pin 3, on visiting the ip address of the Nanode using a web browser you will see a series of buttons (shown on my phone in the screenshot on the right, click to see it full size) and selecting the various options makes the Nanode transmit the relevant infrared code to operate the DAB tuner.

The hard work here is done by the IR Remote library by Ken Shirriff available here. This infrared library has direct support for several common IR protocols (NEC, Sony SIRC and Philips RC5 and RC6) but not the one that my DAB tuner uses, fortunately this isn’t a problem as the library also makes it easy to read and transmit using the raw infrared codes (mark and space intervals) from any remote control.
NB. If you are using Arduino IDE 1.0 note the comment on the library page about changing WProgram.h for Arduino.h – that’s the only change required for 1.0

Getting the codes from the original remote control

The first step is to use an IR receiver connected to the Nanode to read the codes from the original remote control. An IR receiver is basically a photocell that is tuned to the infrared spectrum along with a demodulator that gives an inverted logic level output. I used a Vishay TSOP31238 IR sensor (63p +VAT from Farnell) and connected it to the Nanode as shown on the left.

To read the codes load the IRrecvDump example sketch that is included with the IR library onto the Nanode, open the serial monitor and point the remote control you want to get the codes from at the sensor, for supported protocols it will output the protocol, a hex value, the number of bits and the raw code as each button is pressed, for an unsupported protocol it will return “Could not decode message” and output the raw code only.

Press each button in turn and save the codes in a safe place. Once all the necessary codes have been gathered the IR receiver is no longer required for this project but has lots of potential for future use.

Sending the codes from the Nanode

To transmit the IR codes you need an infrared emitter – a type of LED that emits infrared light. I used a Vishay TSAL7400 2.6V IR emitter (18p +VAT from Farnell) connected via a 27 Ohm resistor (as I’m using a 5V Nanode 5) to pin 3 of the Nanode as shown on the right.

The codes are transmitted by the library using pulse width modulation so a PWM pin must be used on the Nanode, the library is configured to use pin 3 which is convenient as it is free for use on a Nanode 5 (and on a Nanode Classic or RF provided you aren’t using an MCP7941x RTC).

Supported protocol codes

To send a code using one of the supported protocols you just need to use to use the relevant irsend command with the hex value and the number of bits, for example to send an NEC protocol command that IRrecvDump reported as “Decoded NEC: A10C800F (32 bits)“ you would use:

irsend.sendNEC(A10C800F, 32)

Change sendNEC to sendSony, sendRC5 or sendRC6 depending on the protocol that IRrecvDump reported.

Raw Codes

For raw codes we first need to modify the output from the IRrecvDump sketch slightly, just remove the first group of digits and make all the numbers positive, then add commas between each group and put it into an array.

eg. The code received from the IRrecvDump sketch:

-14368 4500 -4500 600 -500 600 -1650 600 -550 550 -550 600 -500 600 -550 600 -500 600 -1650 600 -550 550 -1700 550 -550 600 -550 550 -550 600 -500 600 -550 600 -1600 600 -1650 600 -550 550 -550 600 -550 550 -550 600 -550 550 -550 600 -550 550 -550 600 -1650 600 -1600 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 

becomes

unsigned int rawCode[68] = {4500, 4500, 600, 500, 600, 1650, 600, 550, 550, 550, 600, 500, 600, 550, 600, 500, 600, 1650, 600, 550, 550, 1700, 550, 550, 600, 550, 550, 550, 600, 500, 600, 550, 600, 1600, 600, 1650, 600, 550, 550, 550, 600, 550, 550, 550, 600, 550, 550, 550, 600, 550, 550, 550, 600, 1650, 600, 1600, 600, 1650, 600, 1650, 600, 1650, 600, 1650, 600, 1650, 600};

and then to send it we use the sendRaw command with the array name, array length and the frequency (38kHz):

irsend.sendRaw(rawCode,68,38);

Turning all this into a functional web based remote control

So now I have all the relevant codes for my target device and can send them from the Nanode to control it, the next step was to build a simple web server on the Nanode to allow easy selection of the various codes.

I based this on the Ethercard version of RESTduino by Andrew D Lindsay (itself based on the original by Jason Gullickson) modifying it to transmit IR codes instead of controlling the I/O pins and adding the menu. The only problem I ran into here was due to all the arrays for the raw codes eating up the RAM in the ATmega 328 but storing them in flash using PROGMEM instead solved that. I’m not sure the way I’m reading them back is the most elegant but it works!

My code for this is available on GitHub here and it would be simple to modify for other IR controlled devices. There is also an optional css file there to prettify the basic HTML output, due to the lack of RAM this would need to go on a separate web server. Another option would be to build a full fat web interface on another server and just call the Nanode’s URLs to send each command, eg. “http://192.168.0.188/4” to send the command for preset 4.

Other uses for infrared

The IR library along with the IR receiver makes it easy to use an arbitrary infra red remote control to control the Nanode (or any other Arduino compatible for that matter). It’s as simple as building a conditional structure in the loop to do what you want on reception of the relevant code, this could be used to turn outputs on and off or trigger events over the network or RF.

I’ve been struggling for thinking and tinkering time this week due to a bad cold that has totally wiped me out but I did have some more thoughts on further reducing the power usage of the TempTX V2. The first one is quite simple and will only have a minor effect but only needs a minor code change – it turns out that it is possible to reduce the time the DS18B20 temperature sensor takes to get a reading by reducing its resolution as shown in the table below. It is currently using a 12 bit resolution but even reducing it to the lowest setting of 9 bit, an effective resolution of 0.5°C at a time would be acceptable for most applications I think.

Milliseconds might only seem like a small difference but that is as much as an 8 fold difference and as I said in the last post, every little counts.

Secondly, a completely unrelated discussion on Twitter at the weekend lead to a likely explanation for the total drop out when the battery voltage reaches 2.7V, namely that the default BOD (Brown Out Detection) fuse setting for the ATmega328 when using the default Arduino bootloader is 2.7V (sound familiar?), when the voltage drops below this level the mcu is put into a reset loop until it rises again. That explains the sudden cut off at 2.7V.
With some fiddling and reflashing of the bootloader this BOD setting can be changed to 1.8V or even disabled completely and some brief research shows that the ATmega328 can run from as little as 1.8V (although it would be out of spec running at 16MHz at that low of a voltage) and that the RFM12B module should run OK down to 2.2V so there is plenty of room there. Surprisingly the DS18B20 temperature sensor is not so tolerant, the datasheet says it needs a minimum of 3.0V, however, I’ve already proved that it runs ok at 2.7V (at current average temperatures anyway) and a little research found some reports that it works down to around 2.6V before it starts to give errors and the addition of an electrolytic capacitor should be sufficient for it to get a reliable reading at even lower voltages, especially at the lower resolutions where it needs to be powered for a shorter amount of time. I might try some more voltage tests with the BOD disabled to see how low I can get the whole thing will go before it starts to become unreliable.
Another, maybe more sensible option might be to look at some different temperature sensors that are rated to work at lower voltages, there are several cheaper analogue alternatives to the DS18B20 that might make more sense, they would need to be calibrated though and it would mean only one sensor per input (not really a factor with the way I’ve been using these boards so far) but would have a secondary advantage in that the 1-wire and Dallas Temperature libraries wouldn’t be required which might mean that the code can be reduced to fit into one of the smaller ATmega microcontrollers thus reducing cost again.

Please feel free to post in the comments if you can think of any other suggestions or improvements.

I’ve been playing with some more GLCDs (Graphical Liquid Crystal Displays) recently, along with a Nintendo DS touchscreen. The parallel KS0108 display I used for my emonGLCD used an awful lot of pins, 16 including the power, which doesn’t leave a lot left over for anything else, so I thought I would try some of the serial displays that are available, one from SparkFun and a nice one from Adafruit that has a RGB backlight, you can see a montage of pictures of this display on the right.

Interfacing with and coding for each of these displays is subtly different as there isn’t a single unified Arduino library but none of them are complicated, it’s basically commands to move to a particular pixel of the display, select a font and print it, or for boxes, lines etc. you need to provide coordinates for the start and end points.

In combination with these screens I’ve also been experimenting with the Nintendo DS Touchscreen which is available on its own from a number of suppliers and makes for a cost effective method of adding touch control to screens of this size. When you only want to detect relatively large areas of the screen, such as for a menu, they are very easy to use.

SparkFun LCD-09351 Serial 128×64 GLCD

The LCD-09351 from SparkFun is basically a parallel KS0108 with an ATmega168 based serial backpack attached and only needs 3 pins including the power. It’s not all fun out of the box though as the firmware that is supplied on it isn’t very good at all. Fortunately someone has written a much improved firware, available here. To update this you will need to use an ICSP programmer to flash it with AVRDUDE or WinAVR, this post on the SparkFun product page has details. Unfortunately the ICSP pads on the serial backpack are unpopulated and they aren’t the easiest thing to solder to when the backpack is fixed to the screen. I did it by pushing some wires up from between the two and soldering on the top.

Here is the pinout for the ICSP:

Once the new firmware from summoningdark has been flashed to the backpack you can use the serialglcdlib library here.

Another oddity of this screen is that VIN on the 4 pin header requires 6-7V for the display to work properly but on inspection this just goes to a regulator to feed 5V to the rest of the board so as long as you are providing it with a regulated 5V (eg. from an Arduino) you can just connect to the 5V pad on the opposite side of the board instead.

This is a nice display with a crisp output and good contrast, the 3 wire connection is very handy but on the downside it isn’t cheap, at £27+delivery from SK Pang it’s nearly twice the price of a bare KS0108. Also, unlike with the bare KS0108 it isn’t easy to use different fonts with this display, only two can be used and they can only be changed by compiling them into the firmware when flashing the backpack.

I’ve put some code on GitHub for using this display with an Arduino and RFM12B transceiver as a display for OpenEnergyMonitor.

Adafruit ST7565 Serial 128×64 GLCD with RGB backlight

Another display I’ve been playing with is a ST7565 based unit branded by Adafruit and sold in the UK by Proto-PIC at the great price of only £17.99 It’s the same resolution as the KS0108 displays (128×64) but is slightly larger and more readable in good light without the backlight on. The backlight is where this display differs from most 128×64 displays as it is an RGB backlight, essentially three in one, you have a common anode and a separate cathode for each of red, green and blue, which means you can drive them from separate pins on the Arduino and use PWM to fade and mix the colours giving you a whole range of colours, not just red, green and blue.

To drive the LCD part you can either use the Adafruit libary or the JeeLabs library. The Jeelabs library is an extension of the Adafruit one and is more actively developed, recently having been updated for Arduino 1.0 and has some nice additional functions including support for remote displays that I’ve not looked at yet. It’s also the one that OpenEnergyMonitor use so was the natural choice.

This screen runs on 3.3V so you can either run your whole system on 3.3V or Proto PIC have included a very handy CD4050BC chip which can be used as a logic level converter as described on this Adafruit tutorial.

I’ve been testing this on a 5V Arduino and in order to leave pins free for the RFM12B transceiver and Nintendo DS touchscreen that I am also be using I’ve connected it as follows:

Pins 3, 5 and 6 are used for the backlight as these pins can do hardware PWM which will allow the three colours to be dimmed individually.

The anode for the backlights is connected to 5V via a 270 Ohm resistor

Changes to the JeeLabs library

The JeeLabs library is written for their Graphics Board and if you want to use it with this display on an Arduino you will need to make a few minor changes.

Firstly, in GLCD_ST7565.cpp make sure the defines for the pins reflect what you are using, eg. I used:

#define PIN_SID 0
#define PIN_SCLK 1
#define PIN_A0 4
#define PIN_RST 7

Change LCDUNUSEDSTARTBYTES from 4 to 1 otherwise the display will be off to the right hand side:

#define LCDUNUSEDSTARTBYTES 1

Uncomment the slowSPI define:

// Switch from fast direct bit flipping to slower Arduino bit writes.
#define slowSPI

Change the PAGE_FLIP mode by changing from 0×7 to 0×3

// If the top line is appearing halfway down the screen, try the other mode.
//#define PAGE_FLIP 0×7
#define PAGE_FLIP 0×3

Adjust the contrast to your liking. I don’t think the contrast is as good on this as the KS0108 displays, you can adjust it in the library by changing the badly named st7565_Set_Brightness value in GLCD_ST7565.cpp, the default 0×15 was far too light for me and I settled on 0×19. 0×20 does gives slightly better text but then lines start to appear in the background with some colours.

st7565_Set_Brightness(0×19); // strictly speaking this is the contrast of the LCD panel, the twist on the crystals.

A minor point but the library has been written for a negative display so I reversed the colour defines in GLCD_ST7565.h to it makes more sense for a positive display, this will save some hair pulling later on I’m sure.

#define BLACK 1
#define WHITE 0

My code for using this screen as a display for OpenEnergyMonitor with the backlight colour changing with power usage is also available on my GitHub page.

Using the Nintendo DS Touchscreen with the Arduino

The touchscreen from the Nintendo DS handheld game console makes a good companion to these small GLCDs, it’s slightly larger but this doesn’t matter and you could even use the extra off screen space for fixed (ie. none graphical) buttons.

They aren’t expensive either £5.65 for the screen and £2.51 for a breakout board/connector from Proto-PIC.

You WILL want the breakout board, don’t be tempted to try and solder to the ribbon connector, if you think it looks small in a picture I promise it is smaller in real life.

They are very easy to connect to an Arduino, it connects to four analogue pins and give you an x and y value of the place the screen was touched so you can build button areas by doing something like:

if (y>510 && x<490) { //top left quadrant touched }

There is some good info on using these touchscreens with an Arduino here and here.

The four connections from the touchscreen change purpose depending on which axis is being read, eg. to read the x value you need to put a positive voltage on X2 and ground on X1 the use the analogRead function to get the value of Y1. To read the y value you switch the positive to Y2, ground to Y1 and read X1

I haven’t used pull down resistors as the accuracy is fine for detecting large segments of the screen to use as buttons and not using resistors allows 3.3V to be used and I plan to use a WiNode which is 3.3V for my final build.

My code for the ST7565 display makes use of this touchscreen.

The original Nanode has proved to be a great success with a growing community of people building many interesting networked devices and this month, Ken Boak, the creator of the Nanode has launched several new additions to the line. The new Nanode RF is essentially an upgrade to the original Nanode 5 with an on board RFM12B wireless transceiver and options for several extras such as a real time clock (RTC), 32KB SRAM and a Micro SD socket.

The second new member of the Nanode family is the WiNode, a low cost wireless node that is available in several different configurations, all using the same PCB with just the installed components differentiating between them. As with the Nanode and Nanode RF, the WiNode can be fitted with the standard Arduino headers for compatibility with Arduino shields as well as the RTC (SOIC or DIP), 32KB SRAM and Micro SD options as with the Nanode RF. The WiNode also features four 16V tolerant analogue inputs and when fitted with a dual H-bridge driver chip it can provide 2A digital outputs for driving relays or motors (although you can’t use the SRAM/SD if the H-bridge is used). Due to a nifty bit of design the WiNode can also be built for use as a shield for the original Nanode to add RFM12B wireless capability and more. Prices are very good, with WiNode kits starting at £17.50 (or £15 if you buy a pair) for the basic stand alone wireless node or only £10 if you want to use one to expand an existing Nanode 5. The Nanode RF kits start at £30 and for the first time a fully assembled unit with all the options is available for £40.

Pictured  above is my first WiNode build, decked out with the SRAM and SOIC RTC options. I’ve fitted all the optional bits on this one, headers, screw terminals and even the socket for the H-bridge driver as I will keep this one aside for experimentation and prototyping, subsequent builds will just include whatever is required for the particular use. That’s the Nanode RF on the left.

As with the original Nanode, both the Nanode RF and WiNode are supplied as a kit for you to build yourself and anyone with basic soldering skills should find it very straightforward. Ian Chilton has already created a very comprehensive guide to building the Nanode RF which is available here and I suspect a WiNode version won’t be far behind (update: WiNode build guide is now almost complete).

Ken says he will have an online shop available shortly but for now you can order by sending a Paypal payment, for further details and prices of the various options see this blog post.

OpenEnergyMonitor is a project to implement an open source whole house energy monitoring system built on the Arduino platform. This guide will show you how to make a complete system that will monitor your mains power usage and transmit it over a wireless link to a base station which will upload the data to a web server where you can view graphs of your power usage over time. The image to the right shows one example of the output from the web interface.

There are many options when it comes to building an OpenEnergyMonitor system and you can have systems with multiple current sensors, pulse count sensors and temperature sensors. The OpenEnergyMonitor website is a mine of information but it is very spread out and there isn’t really a simple description of how to build a complete wireless system from end to end so I thought I would document how I made my single sensor system for use on single phase electricity systems such as that used in the UK.

First of all you are going to need some parts. I used a Nanode as the base station which receives the data from the transmitter and uploads it to a web app running on your server. For the transmitter I used a Xino Basic for Atmel which is a no frills Arduino compatible with a handy prototyping area which allows everything to be made on the one board. Here is my full parts list:

Parts list

1 x Nanode Kit
1 x Xino Basic for Atmel Kit
2 x RFM12B transceivers
2 x Jeelabs RFM12B breakout boards
1 x Efergy CT Sensor
1 x ATmega 328 chip with the Arduino bootloader
1 x 16 MHz crystal
8 x 10K resistors
6 x 4.7K resistors
1 x 24 Ohm resistor
2 x 22pF ceramic capacitors
4 x 0.1uF/100nF ceramic capacitors
2 x 10uF electrolytic capacitors
2 x 100uF electrolytic capacitors
1 x LM7805 5V voltage regulator
1 x MCP1702-33 low dropout 3.3V voltage regulator
1 x 8 way male header
1 x 5 way male header
2 x 165mm length of wire for antennas
1 x 7V to 9V DC power supply for the Xino
1 x 7V to 9V DC power supply for the Nanode or a USB power supply
1 x Stereo 2.5mm jack socket
2 x 2.1mm DC power sockets
2 x ABS plastic cases

The Sensor

The current is measured using a current transformer or CT sensor which works by induction. A CT sensor contains a split ferrite core which is clipped around the live wire bringing the mains feed into to the house, the current in the mains wire produces a magnetic field in the ferrite core which induces a current flow in a secondary coil that is proportional to the current in the mains wire. As the current in the secondary coil is electrically isolated from the primary current it offers a safe, non invasive way of measuring the mains current.

The efergy CT sensor I used needs to connected across a resistor (the 24 Ohm “burden resistor”) to get a voltage reading (some CT sensors have this resistor built in) and then a voltage divider is used to bias the output around 2.5V instead of 0V so that it can be connected to one of the analogue inputs on the transmitter (an Arduino needs a positive voltage).
I used the Efergy CT sensor which doesn’t appear to be available on their website at the moment but is available from them on eBay. If you want to use a different CT sensor you will need to know if it has a burden resistor built in and how many turns the secondary coil has.

The Transmitter (Xino)

Any Arduino type board can be used here, or you could even roll your own. I decided to use the Xino as it is very cost effective and the prototyping area allows the burden resistor, voltage divider and filter capacitor to be installed all on the one board.

The biased output from the CT sensor will connect to an analogue input on the Xino which will then transmit the power reading over a 433MHz radio link to the Nanode base station.

Build the Xino to match the picture below, you don’t need to fit the 6 pin headers or the 8 pin for the 0 to 7 digital pins but you will need the one for 8 to 15. You won’t need the 6 pin ICSP headers and you can also omit the power LED and the 1K resistor as I have.

Now we need to add the other components in the prototyping area of the Xino to regulate the power input and connect the CT sensor. Fit the 24 Ohm burden resistor, two 10K resistors, 10uF capacitor, two 100uF capacitors and the LM7805 voltage regulator as per the following diagram. Connect the two wires for the CT sensor to the tip and collar pins of the 2.5mm jack socket (it doesn’t matter which way round), the center ring isn’t used. The V IN and GND IN are for connection of your power supply, I connected these to a 2.1mm DC power socket so a standard 7 to 9V DC power supply can be used.

The Xino should now look like this:

The Base Station (Nanode)

The Nanode is an ethernet enabled Arduino workalike, it will act as the base station and receiver for the OpenEnergyMonitor, receiving the power reading from the Xino based transmitter and uploading it to the web server.

Build the Nanode as per the instructions here but note that you must make the modification to allow the RFM12B transceiver to be used at the same time as the ethernet, this involves not fitting R13 (the 10K resistor one down from the 1 ohm ferrite) and lifting pin 4 of the ENC28J60 so that it is not connected to the socket. You do not need to fit the standard Arduino headers  but you will need to fit one 8 way header for the RFM12B port. If you intend to power the Nanode via the USB port you won’t need to fit the screw terminals or voltage regulator and conversely if you intend to power using the screw terminals you wouldn’t need to fit the USB socket. I fitted both so I have the option.

Your Nanode should now look like this:

The Radio Link

To link the two boards wirelessly two 433MHz RFM12B transceivers are used, to connect these boards to the Arduino platform requires a few extra components and the easiest way to achieve this is to use a breakout board.

Build one RFM12B breakout board for the Xino with all the components. With the board positioned with the headers at the bottom you want to fit 3 x 4K7 resistors on the left and 3 x 10K on the right. Fit two 0.1uF/100nF ceramic capacitors in the C1 and C2 positions and a 10uF electrolytic capacitor in C4 (positive to the right hand side as marked on the board). Fit the MCP1702-33 to follow the orientation marked on the board and fit a 5 pin male header across the GND, SCK, SDO, SDI and SEL positions. When soldering the RFM12B to the breakout board you only need to solder the top 3 and bottom 3 pads on the left hand side and the bottom 2 on the right. Solder a 165mm length of solid core wire to the hole next to the top left pin of the RFM12B for use as an antenna.

Solder a wire from the 5V pin on the RFM12B breakout board to the 5V on the Xino and solder one from the IRQ pin to the Xino’s D2, plug the breakout board into the 8 way header on the Xino so that it is across the GND and D10 pins.

Build a second RFM12B breakout board for the Nanode but this time you don’t need to fit the capacitors or the voltage regulator as the Nanode will provide the 3.3V to run the RFM12B. Fit an 8 pin male header to this one and plug it into the 8 way header fitted to the Nanodes RFM12B port.

Fit the RFM12B boards to the Nanode and Xino and that is the hardware completed.

Software

Now you need to install the web interface and load the sketches onto the Nanode and Xino.

First install the emoncms2 package on your web server and register an account.

Now load the sketches onto the Nanode and Xino using the Arduino IDE and an FTDI cable/board. The Xino has a 5 pin header for programming so you might wanto make an adapter to convert it to a normal FTDI connector.

On the Xino upload the emonTx_SingleCT_Example_ sketch from the emonTxFirmware repository.
On the Nanode upload the nanodeRF_ctonly sketch from the NanodeRF repository.

Before uploading the Nanode sketch make sure you set the mac to something unique and change the emoncms details to reflect where you installed emoncms and copy the write only API key from your emoncms2 web interface.

If you now fit the CT sensor around your mains feed and plug it into the Xino transmitter and connect the Nanode receiver to your network or router and you should soon start to see data appearing in your emoncms web interface.

Calibration

The system is now working but should be calibrated against a known source. I used an old Owl energy monitor system I had for this, you need to adjust the “double CAL” value in the sketch for the Xino until the readings match your known source across a range of loads. If you change “#define SERIAL 0″ to “#define SERIAL 1″ you can use the Arduino IDE serial monitor to view the readings as they are read which can help speed this process up, don’t forget to change it back afterwards as it can apparently affect stability otherwise.

Finishing up

To make things a bit neater you will probably want to put the Nanode and Xino in a case. Ciseco, the maker of the Xino do a nice ABS plastic box which is perfect for housing Arduino boards and will just about fit a Nanode too once a hole is cut for the ethernet jack.

Here is my completed transmitter and receiver:

Next Steps

Next I’m going to look at making a graphical LCD display unit which will involve another Arduino based board with an RFM12B and some sort of graphical LCD. I found a nice 128×64 pixel display from an old car alarm programmer in my salvage pile that I hope to be able to use for this.

I’ve had my front door bell sending me text messages since 2004 using a combination of a hacked X10 wireless remote control and Misterhouse, initially through an email to SMS gateway (not ideal as it cost me every time someone pressed the door bell) and more recently using TTYtter. It worked well enough most of the time but the X10 (both the radio and mains components) was always the weak link in the chain.  I first had the idea of changing this over to an Arduino based system some time ago when I bought a Duemilanove clone and ethernet shield but it seemed like a lot of money to have tied up in a doorbell, that all changed with the Nanode of course, £22 seems like a much more reasonable figure.

So here is the first Nanode version working, it’s very simple, just a few small changes to the ethershield Twitter demo code that sends a tweet using Supertweet.net’s API proxy when a pin is grounded. I have set it up to send a message via another Twitter account which I have told Twitter to send me a text message for, the tweet from the Nanode includes a link to the web feed for my front door camera so I am just one link away from seeing who is there. Twitter won’t send two identical messages in succession so I’ve added a changing number to the URL for the camera so that each message is always different from the last, it’s a bit hacky at the moment but it works. I’m now thinking of other things I can connect to in the vicinity of the front door, a snail mail alert is an obvious next step.

The picture above shows the message coming into the Twitter client with the web interface in the background. There are another couple of pictures below, one showing the text message coming in and one showing the result of clicking on the link (yes my path needs weeding but where’s the fun in that?).

I need another Nanode now.