MQTT Joggler

Spurred on by the success of getting Mosquitto working on a Raspberry Pi, I recently had a play with MQTT on the Joggler. The O2 Joggler is still a great device for hacking and I currently have SqeezePlay OS running on it.

The reason I wanted to try and get MQTT on the Joggler was to make use of its light sensor, and publish light levels over MQTT. It all turned out to be pretty simple since most of the work has already been done by other people!

First thing to do was read the light sensor and get that working with an MQTT client. I had to skip some of Andy’s instructions and just built the client code rather than attempting to get doxygen working. Once I’d mashed up the light sensor code and publish example I could compile the worlds most pointless MQTT publisher:

gcc -Wall publightsensor.c -L../bin/linux_ia32 -I../src -lmqttv3c -lpthread -o publightsensor

Next it was time to check the results. This too was quick and easy thanks to the MQTT sandbox server, which has a handy HTTP bridge. And the final result… was a completely unscientific and slightly dingy light level 4! Now I’ll be able to turn on a lamp using an unreliable RF controlled socket and see whether it worked or not!

Update: the code really is all in the existing examples but I’ve created a Github Gist in case it’s any help: mqttjogglermashup.c (11 February 2013)

Explaining the auto kitchen light plan

Since a few people seem interested/skeptical on Twitter, here’s a very quick explanation of a small update to the kitchen lights. Since getting a Current Cost meter it’s been obvious that the biggest waste of electricity are the halogen spotlights in the kitchen. (It amazes me that ordinary incandescent light bulbs are being phased out while at the same time many new houses are full of halogen bulbs, but that’s for a future post!)

Most of the time the two lights under the cupboards would be good enough, but the switch for those is a bit hidden away, so we usually use the five ceiling lights instead. The first part of the cunning kitchen light plan is to connect the two worktop lights to a Home Easy remote control ceiling switch. Now we could put an ordinary remote switch in easy reach next to the main light switch but where’s the fun in that? I got tentative spousal approval to use an indoor PIR remote control instead…

Results so far seem promising: the lights aren’t triggered walking past the kitchen because the sensor is looking inwards from above the existing light switch, and there’s often no need to resort to the manual switch to turn on the electricity burning main lights… which is actually quite lucky because they aren’t there at the moment!

Only temporarily removed due to some planned ceiling painting* but it was a good excuse to automate the backup lights.

* Well, it seemed pointless painting the tiny ceiling in the porch on it’s own, so the kitchen is getting a fresh coat as well.

My second CurrentCost development board circuit

My first attempt at monitoring gas use with a CurrentCost development board was partially successful. I could get a reasonable idea of when the boiler was firing but I didn’t really find that information particularly useful. So, plan B was to actually count the pulses from the gas meter. The second circuit, which is described in the 8. More about triggering section of this 555 timer page, has been running ok for a few weeks now, so I’m thinking about actually soldering it together. Thanks to Richard for suggesting VeeCAD, which led me to TinyCad, this is circuit number two (much easier than using MS Paint!).

I’ve been using R1 and C1 values of 122k Ohms and 47u F for the 555 timer, to trigger an output pulse that’s just long enough to get transmitted by the CurrentCost development board (~6 seconds). I may yet tinker with the timing to make it long enough for three transmissions; the time between pulses on the gas meter is long enough and it might make receiving pulses more reliably.

Thanks to Mark and Andrew for some ideas for laying out a circuit on strip board, here’s what I hope is the same circuit using VeeCAD:

Might get the soldering iron out next time Jo’s away!

Update: For plenty more advice on moving from breadboard to a more permanent prototype, have a look on the Evil Mad Scientist Laboratories blog. (11 March 2010)

Update: Finally got round to pulling everything off the breadboard and soldering it together…

…and it actually still works! (14 March 2010)

Techno Bears

I was only planning to have a quick play with the LCD display I bought recently, but ended up finishing off my Arduino + Home Easy polar bear controller project as well. Not that it actually needed a display you understand, but I’d wired it up, so why not!

…complete with a manual override should it annoy Jo a bit too much! I finished a bit ahead of schedule in the end; the polar bears aren’t actually out yet… because it’s not Christmas! I have dug the tree up though, and as soon as it’s indoors we’ll have some ambient bears to tell us when to turn something off. Here’s the sketch so far, warts and all:

#include <Bounce.h>
#include <HomeEasyCtrl.h>
#include <Messenger.h>
#include <LiquidCrystal.h>

#define WIRELESS 6
#define BUTTON 7
#define LED 13

// Define a metronome
unsigned long previousMillis = 0;

// Set the default interval to every 3 minutes -
//   enough time for a cup of tea
unsigned long interval = 180000;

// Instantiate a Bounce object with a 5 millisecond debounce time
Bounce bouncer = Bounce(BUTTON,5); 

// Instantiate Home Easy controller with transmitter on pin 4 and LED on 13
HomeEasyCtrl lightController(WIRELESS,LED);

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(12, 11, 10, 5, 4, 3, 2);

// Instantiate Messenger object with the message function and the default separator (the space character)
Messenger message = Messenger(); 

// Flag indicating the desired state of the lights
bool deviceOn = false;

// Flag indicating whether bears are on manual!
bool manual = false;

// Last energy reading in watts
int watts = 0;

// Energy use messages
int energyUse = 0;
char* energyUseMessages[]={"Energy: low", "Energy: normal", "Energy: high"};

// Define messenger function
void messageCompleted() {
 int elementCount = 0;
 int last = 0;
 Serial.println("Message received");

 // Loop through all the available elements of the message
 while ( message.available() ) {
 int value = message.readInt();

 if ((value == 0) || (elementCount > 2)) {

 Serial.println(value, DEC);

 // wait for same value twice for simple
 // error checking
 if (value == last) {
 watts = value;
 } else {
 last = value;
 Serial.println(watts, DEC);


void checkEnergyUse() {
 if (watts < 50 || watts > 350) {
 deviceOn = false;
 previousMillis = millis();
 // Don't mind waiting for things to go off
 if (watts < 50) {
 energyUse = 0; // low
 } else {
 energyUse = 2; // high
 } else if (watts > 100 && watts < 300) {
 deviceOn = true;
 previousMillis = millis();
 energyUse = 1; // normal
 // Want things to come on immediately
 } // otherwise, no change


void updateDisplay() {

 // 1st line
 if (manual) {
 lcd.print("Manual override");
 } else {

 // 2nd line
 if (deviceOn) {
 lcd.print("Polar bears: on");
 } else {
 lcd.print("Polar bears: off");

void setup() {

 // Initiate Serial Communication

 // set up the LCD's number of rows and columns:
 lcd.begin(16, 2);
 lcd.print("Polar bears: off");

 // set up incoming message processor

void loop() {

 // Check push button for manual override
 if ( bouncer.update() ) {
 if ( == LOW) {
 if (!manual) {
 manual = true;
 deviceOn = true;
 } else {
 if (deviceOn) {
 deviceOn = false;
 } else {
 manual = false;

 // The following line is the most effective way of
 // feeding the serial data to Messenger
 while ( Serial.available( ) ) message.process( ) );

 // Keep the device in the desired state
 if ( millis() - previousMillis > interval ) {
 previousMillis = millis();

 if (deviceOn) {
 } else {

No polar bears have been harmed in the making of this post. At least not yet anyway.

Update: Seems to be working quite well, although the manual override button seems to have problems- it seems to randomly flip back on when I want it to stay off. Still, the button works well enough to pair with a Home Easy socket which is the main thing. Tree and polar bears should be up this weekend. (16 Dec 2009)

Meet the team

It looks 2009 is the year for people I work with to start blogging, and they’re all on Twitter… coincidence? So if you’re looking for a good read, you might like to check them out. Starting with the newest blog…

February 2010 (the power of peer pressure brings out another blogger in the team in 2010!)

Iain’s Blog (@iainduncani)

A web 2.0 skeptical geek all rounder planning to write about technology, politics, growing vegetables, board games and walking.

October 2009

Ed’s World (@ejellard)

Off to a flying start with some great home automation with arduino, Home Easy, MQTT and a helping of hackery.

Limboworld’s blog (@jaylimburn)

Conducting a scientific experiment in to the value of blogging, so make sure you get as many people to read it as possible! Some good DIY posts to kick things off. (There would have been a few DIY posts here if I’d started this blog before fitting the kitchen!)

September 2009

The World Of Gavin (@gavinwillingham)

Definite technology slant with an enjoyable hint of grumpy old man which I’m definitely hoping will continue!

April 2009

Cobweb (@techcobweb)

Some really varied arduino projects in addition to home automation and tweeting cats. While the only circuit I’ve cobbled together recently is sitting in an ice cream tub in the porch, Mike is a master at packaging projects- his scalextric race timer is a work of art!

May 2006 (so blogging way longer than the rest of us!)

Nigel’s blog (@planetf1)

Not as easy to sum up given the number of posts but a distinct focus on technology of various kinds. Probably need to run it through wordle to get a better idea!

The trouble with making lists like this is that I am bound to have missed a few! I’ll just sneakily add more if I have… which reminds me, I was going to make more of an effort with a blogroll at some point soon.

Updated: another blog for 2010! (8 March 2010)

Home Easy Hacking Wiki

I recently discovered that someone has created a useful looking Home Easy Hacking Wiki to pull together what information there currently is about hacking a range or related home automation hardware. Unfortunately it doesn’t yet answer Jerd’s question about the automatic protocol, so if you’ve got something working, it would be fantastic if you could add a few more details to the wiki.

Hoping to get back to finishing off a Freeduino Home Easy controller before too much longer- I didn’t even get as far as unwrapping the transmitter last time! I’m currently wondering if the Finite State Machine library that Mike used in his latest project would be useful to handle transmitting and receiving from the same controller.

If you’ve done anything like this before, any tips would be most welcome!

Update: maybe the Southampton Hack Day (via Benjie) would be a suitable opportunity to work on this. (4 Sept 2009)

Update: Thanks to Paul’s post I’ve just discovered another page documenting various 433 MHz AM signals, including devices using PT2262/PT2272 encoder/decoder chips, which klik-aan klik-uit uses apparently. (24 Sept 2009)

And there’s more:

Must get round to finishing this off myself sometime soon! Here are a couple more people who have Home Easy working with the Arduino:

(29 Oct 2009)

My first CurrentCost development board circuit

The result of a fair bit of googling and a weekend of hacking is… [drum roll]… a circuit to connect my gas meter to a CurrentCost Envi using a nice little dev board from CurrentCost


Now I’m much more familiar with messing about with software, not all this messy hardware stuff, so I’m really hoping to get some feedback to improve this early prototype!

So, my theory is that the stuff on the left will trigger the timer on the positive edge of the pulse from the gas meter. R1 and C1 control the 555 timing; more on that in a second. And the stuff on the right (LED and the CurrentCost dev board) should be triggered whenever the gas meter is running and emitting pulses. It all seems to work, except that I can’t seem to get the timing quite right. The gas meter takes about 1m40s between pulses, and I can choose values for R1 and C1 that trigger the output for the right length of time when a single pulse is detected, unfortunately subsequent pulses don’t keep the output on as I was hoping. The best I’ve managed is with R1 = 3M ohms and C1 = 100uF, which does stay on as long as there are pulses from the meter… unfortunately just for a little too long at 5 minutes. Still, at least the CurrentCost Envi will get a reading all the time the boiler is running, and it won’t get stuck on if the meter stops on the portion of the dial where the reed switch is closed.

Any comments with glaring errors, small problems, improvements, or a completely different way to do it?!

Updated: looks like I was having problems with left and right in my first description! Hopefully I’ve got them the right way round now! (2 July 2009)

Update: for an alternative approach (latching a pulse and clearing it when the cc board transmits) take a look at the circuit and photos on John’s blog. (9 July 2009)

Update: an on/off indicator for the boiler hasn’t been all that useful. Instead, to count pulses, I’ve now modified the circuit to simply trigger an output pulse that’s long enough to get transmitted by the CurrentCost development board (~6 seconds). The circuit is described in the 8. More about triggering section of this 555 timer page, with R1 and C values of 122k Ohms and 47u F. (25 January 2010)

Update: posted some more info. on my second CurrentCost development board circuit. (23 February 2010)