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)


developerWorks Days Zurich 2012

This week I had a day out of the office to go to Zurich to talk at this years IBM developerWorks Days. I had 2 sessions back to back in the mobile stream, the first an introduction to Android Development and the second on MQTT.

The slots were only 35mins long (well 45mins, but we had to leave 5 mins on each end to let people move round) so there was a limit to how much detail I could go into. With this in mind I decided the best way to give people a introduction to Android Development in that amount of time was to quickly walk through writing reasonably simple application. The application had to be at least somewhat practical, but also very simple so after a little bit of thinking about I settled on an app to download the latest image from the web comic XKCD. There are a number apps on Google Play that already do this (and a lot better) but it does show a little Activity GUI design. I got through about 95% of the app live on stage and only had to copy & paste the details for the onPostExecute method to clear the progress dialog and update the image in the last minute to get it to the point I could run it in the emulator.

Here are the slides for this session

And here is the Eclipse project for the Application I created live on stage:
http://www.hardill.me.uk/XKCD-demo-android-app.zip

The MQTT pitch was a little easier to set up, there is loads of great content on MQTT.org to use as a source and of course I remembered to include the section on the MQTT enabled mouse traps and twittering ferries from Andy Stanford-Clark.

Here are the slides for the MQTT session:

For the Demo I used the Javascript d3 topic tree viewer I blogged about last week and my Raspberry Pi running a Mosquitto broker and a little script to publish the core temperature, load and uptime values. The broker was also bridged to my home broker to show the feed from my weather centre and some other sensors.

Recent hacktivity

This time of year seems to be hacking season and over the last few days I’ve been along to two hackdays!

Friday was IBM’s internal Social Business Hackday. There was some MQTT hacking, a z/OS hack, hacks with Lotus Connections, hacks that could be the future of Lotus Connections, and I was attempting to hack a work around for a Jazz work item. And that was just at the Hursley local event! We were able to link up with a few other labs, but over two days there were IBMers hacking around the globe. There are going to be a lot of amazing projects to choose from when it comes to voting.

(There are a few more photos from HackDay X, and previous hackdays, on the IBM hackday group on flickr.)

For round two, today was the soutHACKton hack day. By the time I arrived the soldering and drilling had already begun!! Unfortunately I wasn’t able to stay long so I’m hoping there’ll me more of these in the future. I did just about have time to try out an idea I had to hack an old doorbell to sense people using the door knocker. A while ago I had accidentally created a touch sensor with a 555 timer while attempting to build another circuit. So my cunning plan was to deliberately create a 555 touch switch and connect it to the bolt on the inside of the front door. Unfortunately the best I could manage today was a two wire touch sensor, which isn’t going to work. At least not without leaving a wire hanging out of the letter box with some instructions attached! Unless someone who knows more about electronics can suggest a plan B, I may just resort to a boring doorbell button instead!!


Even More MQTT enabled TVs

Kevin Modelling the headset

A project at work recently came up to do with using one of the Emotiv headsets to help out a former Italian IBMer who was suffering from locked in syndrome. The project was being led by Kevin Brown who was looking for ways to use the headset to drive things sending email and browsing the web but he was also looking for a way to interact with some other tech around the house. The TV was the first on the list.

Continuing on from my previous work with controlling TVs and video walls with MQTT I said I would have a crack at this. My earlier solution was limited to LG TVs with serial ports and this needed to work with any make so a different approach was needed. It also needed to run on Windows so it was also a chance to play with C# and .Net.

To be TV agnostic it was decided to use a USB IR remote from a company called RedRat. They make a number of solutions, but their RedRat III was perfect for what was needed.

RedRat IR transmitter & receiver

The RedRat API comes with bindings for C++, .Net on Windows (and a LIRC plugin for Linux). The RedRat III is not just a IR transmitter, it is also a receiver which means it can “learn” from existing remote controls so it can be used with any TV.

Kevin is using Emotiv headset to drive Dasher as the input device. Dasher is a sort of keyboard replacement that allows the user to build up words using at a minimum a single input e.g. a single push button. As well as building words other actions can be added to the selector, Kevin added actions for browsing and also to control the TV. These actions publish MQTT messages to a topic with payloads like “volUp”, “chanDown” or “power”.

So now we had the inputs it was time to get round to writing the code to turn those messages into IR signals. There are 2 MQTT .NET libraries listed on the MQTT.org software page. I grabbed the first off the list MqttDotNet and got things working pretty quickly.

The following few lines sets up a connection and subscribes to a topic.

String connectionString = "tcp://" +
  Properties.Settings.Default.host.Trim() + ":" +
  Properties.Settings.Default.port;
IMqtt client = MqttClientFactory.CreateClient(connectionString, "mqtt2ir");
try
{
	client.Connect(true);
	client.PublishArrived += new PublishArrivedDelegate(onMessage);
	client.ConnectionLost += new ConnectionDelegate(connectionLost);
	client.Subscribe(Properties.Settings.Default.topic.Trim(),
	  QoS.BestEfforts);
}

Where the onMessage callback looks like this:

bool onMessage(object sender, PublishArrivedArgs msg)
{
	String command = msg.Payload.ToString().Trim();
	IRPacket packet = loadSignal(command);
	if (packet != null)
	{
		redrat.OutputModulatedSignal(packet);
	}
	return true;
}

MQTT2IR Settings Window

And that is pretty much the meat of the whole application, the rest was just some code to initialise the RedRat and to turn it into a System Tray application with a window for entering the broker details and training the commands.

Unfortunately just a few days before we were due to have delivered this project we learned that the intended recipient had picked up a respiratory infection and had passed away. I would like to extend my thoughts to their family and I hope we can find somebody who may find this work useful in the future.

MQTT powered video wall

Scaling things up a little from my first eightbar post.

This was one of those projects that just sort of “turned up”. About 3 weeks ago one of the managers for the ETS department in Hursley got a call from the team building the new IBM Forum in IBM South Bank. IBM Forums are locations where IBM can showcase technologies and solutions for customers. The team were looking for a way to control a video wall and a projector to make them show specific videos on request. The requests will come from pedestals known as “provokers”, each having a perspex dome holding a thought-provoking item. The initial suggestions had been incredibility expensive and we were asked if we could come up with a solution.

Provoker

The provokers have access to power and an Ethernet connection. Taking all that into account a few ideas came to mind but the best seamed to be an Arduino board with Ethernet support and a button/sensor to trigger the video. There is a relatively new arduino board available that has a built in Ethernet shield which seemed perfect for this project. Also, since a number of the items in the provokers would be related to IBM’s Smarter Planet initiative, it made sense to use MQTT as a messaging layer as this has been used to implement a number of solutions in this space.

Nick O’Leary was enlisted to put together the hardware and also the sketch for the Arduino as he had already written a MQTT client for Arduino in the past.

Each provoker will publish a message containing a playload of “play” to a topic like

provoker/{n}/action

Where ‘{n}’ is the unique number identifying which of the 6 provokers sent the message.

To provide some feedback to the guest that pressed the button, the LED has been made to pulse while one of the provoker-specific videos is playing. This is controlled by each provoker subscribing to the following topic

provoker/{n}/ack

Sending “play” to this topic causes the LED pluse, sending “stop” turns the LED solid again.

The video wall will be driven by software called Scala InfoChannel which has a scripting interface supporting (among other things) Python. So a short script to subscribe to the ‘action’ topics and to publish on on the ‘ack’ got the videos changing on demand.

And sat in the middle is an instance of the Really Small Message Broker to tie everything together.

Arduino in a box

This was also the perfect place to use some of my new “MQTT Inside” stickers.

First sticker deployed

This project only used one of the digital channels (for the button) and one of the analogue channels (for the LED) available on the Arduino – which leaves a lot of room for expansion for these type of devices. I can see them being used for future projects.

Parts list

  1. Arduino Ethernet
  2. Blue LED Illuminated Button
  3. A single resistor to protect the LED
  4. 9v power supply
  5. Sparkfun Case

Bang went the theory…

As with yesterday’s post, I really don’t have to do too much work on this one, as the detail has already been written up elsewhere…

If you watched this week’s edition of Bang Goes The Theory on BBC1, you will have seen Nick O’Leary and Kevin Brown from IBM Hursley helping Jem and Dallas to drive taxis. That probably wouldn’t have been entirely revolutionary, had it not been done through a combination of an Emotiv brain-signal-reading headset, and some MQTT and Arduino funkiness… no hands on the wheel or feet on the pedals!

Nick has a great write-up of what sounds like a fun (but cold) event. You may still be able to catch the fun on iPlayer, or there are some clips over here.


(Image: Creative Commons Attribution Non-Commercial Share-Alike (2.0) from knolleary’s photostream, used with permission – full set)

A different kind of TV remote control

I’m very excited to be welcoming another Hursley innovator as a guest here on eightbar – Benjamin Hardill (you can find him on Twitter as @hardillb). Here’s some insight into what he’s been up to lately! More home automation, hardware hacking, and MQTT messaging adventures follow :-)

I got a new TV around Christmas last year and while unpacking it I noticed along with the HDMI, SCART and other sockets on the back it had a 9-pin socket labelled "RS232C IN CONTROL&SERVICE". I didn’t think that much of it at the time, but I remembered it last week while thinking about a couple of problems that had come up.

Tidy TV setup The first of these was that I had got home twice recently to find I’d left the TV turned on while I was at work, this was mainly because I use MythTV and I’d left it at the menu screen rather than turning the screen off as well. This had left shadow on the menu on the screen for a day or so afterwards (luckily no permanent damage as would have happened with a plasma or CRT TV).

The other point was from when we all first got hold of our Current Cost meters, there had been a lot of thought about how to work out exactly what appliances were on at any given time. While spotting when things like an electric water heater turned on was relatively easy, it was proving difficult to spot some of the lower power devices.

A plan started to form and I ordered a null modem cable from Amazon (£2.18 with free shipping) and went looking for some documentation on the protocol. The manual that came with the TV while being nearly an inch thick just covers the basics of how to plug it in and turn it on, but there was a CD-ROM with a much more detailed PDF document. The version for my TV is here. While searching round I found manuals for several other LG LCD/plasma TVs and they all seem to use the same basic protocol.

The protocol is relatively simple

[cmd1][cmd2] [setid] [data]

Where the cmd1 & cmd2 are 1 letter code, setid is for if you have multiple TVs connected to the same cable, the default id is 01 but you can change if needed, using 00 will work for all connected TVs. And data is a hex value of the option to pass the command.

The response from the TV looks like this for a success

[cmd2] [setid] OK[data]x

and like this for a failure

[cmd2] [setid] NG[data]x

The command to turn the TV on and off is "ka" so sending

ka 00 1

turns the TV on and sending

ka 00 0

turns it off. Most of the commands will reply with the current status if they are passed ff as the data. So sending

ka 00 ff

gets the following when the TV is off

a 00 OK0x

So now I had a way to turn the TV on and off along with checking its current status. The next step was to surface this some way and given the fascination we all seem to have with messaging, MQTT seemed like a good idea. A little bit of Java and the Java COMM API later and I had 2 topics TV/Commands & TV/Status.

I already have a topic that publishes if my mobile phone is in the flat by pinging it with Bluetooth. Combining this with the two new topics I can ensure that the TV is turned off when I leave. I’m also wondering if I should start to log the amount of time the TV is on, but I think the results may scare me a little…

Hursley: where innovation happens

I’m over in the US at the moment, and I was out of the office all of last week as well, but I see that the BBC has been visiting my friends and colleagues at the Hursley mothership.

The coverage is in two parts. Firstly there’s a nice article on the BBC News website which talks about the history of Hursley, some of the software developed at the lab such as CICS and MQTT, and (of course) Andy Stanford-Clark’s twittering house.

There’s also a set of interviews with IBMers such as Kevin Brown talking about the twittering Hursley minibus, in the May 5th episode of the Digital Planet podcast (here’s a direct link to the MP3). The IBM coverage starts from around about 17 minutes in to the programme.

So, if you were wondering what wild and wacky things we get up to at Hursley – we do a lot of different stuff, and it can be very cool indeed :-)

The amazing MQTT-enabled ducks!

This is a guest post by Hursley’s Chris Phillips (aka @cminion on Twitter). Take it away, Chris… and you’ll find more from him on his blog.

flashyduck-300x225

Many eightbar readers may have received one of those gadget catalogues you get through the door, with weird and wonderful widgets to ostensibly help with everyday life. “How have I ever coped without a Wifi Fondue set?” and similar thoughts may have run your mind. However, one thing these catalogues aim to promise is the integration of technology into everyday life; the dream that if technology is pervasive enough, it could remove all those little annoyances that we experience: forgetting a recipe, not knowing when our friends are turning up at the pub, having to get up twice to make a cup of tea, and so on… missing a phone call, because the phone is not loud enough, or set to vibrate, or other such vagaries of the modern telecommunications device. If only one could make a normally unobtrusive device that would alert one to a phone call, or a doorbell, or a new email, in fact pretty much anything!

Back in January I made some MQTT ducks. The aim was to make them flash on or off when receiving signals from my Ubuntu server.

Now, you may wonder why I would want 20 rubber ducks to flash when my phone goes off. Well, this was about the same time as I decided I wanted to make a unobtrusive alerting device. There is no scientific or technical reason in itself. I just had a Mini Cooper’s worth of rubber ducks sitting around, unemployed. Therefore I designed a simple project to get to grips with the world of Arduinos not only educating me but also putting the lazy mallards to use. I found some cheap fairylights just before Christmas and had the aforementioned large supply of rubber ducks (as you do).

Components

  • 1 x Freeduino
  • 1 x 20 LED Fairy lights (£3)
  • 1 x USB Printer Cable (via theattick.tv)
  • 20 x Rubber Ducks

IMG_5145

Tools

  • GlueGun (£1.50 from Woolworths during the closing down sale)
  • Scissors

The construction was very simple. Making a small hole in the bottom of each duck, I inserted an LED and glue gunned it into place. I checked the effect with the batteries to see the result.

1097743

Removing the battery component with a pair of scissors and stripping the wire coating revealed the multi-core ends. These were plugged into the digital pin thirteen and the digital ground on the Arduino. To confirm the wires were plugged into the correct pin I pressed the reset button. The ducks and LED thirteen on the Arduino would then quickly flash.

IMG_5148

Coding for Arduinos is very basic. The program I wrote received a 1 or a 0 down the USB cable. When it received a 1 (49 in ASCII) it turned the ducks on. When it received a 0 (48 in ASCII) it turned them off.

int LEDPin  = 13;
int inByte =0;

void setup() {
    pinMode(LEDPin,OUTPUT);
    Serial.begin(9600);
}
void loop(){
    if (Serial.available() > 0) {
      inByte = Serial.read();
      Serial.print(inByte);
    }
    if (inByte == 49 ) {
      digitalWrite(LEDPin,HIGH);
    }
    if (inByte == 48 ) {
      digitalWrite(LEDPin,LOW);
    }
}

To connect this to my Really Small Message Broker using MQTT, I modified an excellent & simple Perl script written by Andy Stanford-Clark. His script reads RSMB topics for specific entries. I created a listener that watched for messages being passed on to the Ducks/ topic. If the content of the message was on it sent 1 down the wire to the Arduino, and if it received off it sent 0.

Next move… well someone at Pachube put forward the idea on Twitter of controlling with their infrastructure. Now, I can send an on or off message to a Pachube feed using Twitter. My server at home then checks this feed every 15 seconds for any changes and sends a message to my RSMB as required.

Thanks to the guys from http://greatduckcaper.com/ for providing their leftover ducks and theAttick.tv for providing the USB cable!

Mad scientists?

IMG_3669 4.JPG IMG_3670 4.JPG

Just an average day in the Hursley tea bar!

Martin Dix from CurrentCost visited to deliver a bunch of meters for people who had attended Home Camp 08. Whilst he was with us, Andy Stanford-Clark hooked up a (battery-powered) meter to one of his mousetraps to show how it is possible to detect traps going off using the meter – this is the same technique he uses in his automated home system. He also showed the same message arriving in his MQTT broker on his Ubuntu laptop. The table was soon awash with gadgets, wires and tools. I brought along a camera or two, Dale brought along some questions about the software internals of the new devices, and a great time was had by a bunch of geeks over tea…

No mice were harmed during this meetup, but a few wooden coffee stirrers were put through their paces in some vicious mousetraps.