Posts Tagged ‘mqtt’

HomeCamp ‘08

Sunday, November 30th, 2008

Today was the first homecamp - “an unconference about using technology to monitor and automate the home for greener resource use and to save costs”.

Whilst I hadn’t entirely planned to, I found myself stood up front leading a couple sessions; one on what I’ve been doing with arduino and one a brief overview of what MQTT is.

As the wireless was only staying up for 30 minutes at a time, my arduino talk is split over a couple UStream videos. I come in at about 22:40 of this first one…

…and the rest is here with only a small gap missing between them.

Here’s the brief piece I did on all things MQTT, RSMB and MicroBroker. You should listen to Chris talk about his SketchUp plugin for Pachube at the start of the video, or you can skip to me at 14:20.

The rest of the videos are worth watching - they can be found on the homecamp ustream page.

Here are the slides I was using for the arduino talk. I will add some notes to them over the next couple days, so be sure to check back on slideshare.

One other contribution I made to the day was winning the race to respond to Andy’s request for a homecamp logo. You can see my effort at the top of this post as well as on the official homecamp friendfeed room. Since then, @ribot has produced this decidedly more shiny one.

Today was a lot of fun with plenty of interesting and inspiring conversations. A big thank you and well done to Chris and Dale for putting this together so quickly. I look forward to HomeCamp ‘09.

DIY Ambient Orb: Redux

Tuesday, November 25th, 2008

Orb

Orb Base

RJ11

/************************************************
 * Enables a BlinkM to be controlled over MQTT.
 *  - subscribes to the topic 'blinkm'
 *  - expects messages of the format 'RRGGBB'
 *  - doesn't do any error handling
 *
 *    Nicholas O'Leary
 *    http://knolleary.net
 ************************************************/
#include <Wire.h>
#include <Ethernet.h>
#include <PubSubClient.h>
#include <BlinkM_funcs.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 172, 16, 0, 50 };
byte server[] = { 172, 16, 0, 100 };

void callback(char* topic, byte* payload,int length) {
  byte a = toHex( payload[0],payload[1] );
  byte b = toHex( payload[2],payload[3] );
  byte c = toHex( payload[4],payload[5] );
  BlinkM_fadeToRGB( 0x09, a,b,c);
}

PubSubClient client(server, 1883, callback);

void setup()
{
  BlinkM_beginWithPower();
  BlinkM_setAddress( 0x09 );
  BlinkM_stopScript( 0x09 );

  Ethernet.begin(mac, ip);

  if (mqttClient.connect("blinkr")) {
    mqttClient.subscribe((uint8_t*)"blinkm");
  }
}

void loop()
{
  mqttClient.loop();
  delay(500);
}

// a really cheap strtol(s,NULL,16) - taken from BlinkMTester
#include <ctype.h>
uint8_t toHex(char hi, char lo)
{
    uint8_t b;
    hi = toupper(hi);
    if( isxdigit(hi) ) {
        if( hi > '9' ) hi -= 7;
        hi -= 0x30;
        b = hi<<4;
        lo = toupper(lo);
        if( isxdigit(lo) ) {
            if( lo > '9' ) lo -= 7;
            lo -= 0x30;
            b = b + lo;
            return b;
        }
    }
    return 0;
}

CurrentCostuino

Wednesday, November 19th, 2008

With homecamp fast approaching I spent some time last weekend reviving some CurrentCost hacking I started in the summer.

One of the downsides of the data connection on the CurrentCost is the need for an always-on computer in order to capture the data. In practice, the existence of low powered machines like the MPC-L, or slug, make this a pretty inconsequential downside. That said, it was enough motivation to see what I could do with an Arduino and Ethernet Shield.

I have previously mentioned that part of the setup used to graph the power data online was to publish the data to a broker-in-the-sky using MQTT. To achieve this with an arduino it was clear that I needed one thing in particular - an arduino that is capable of connecting and publishing to an MQTT server.

With my ethernet shield in hand, I set about implementing enough of the MQTT spec to support basic publishing and subscribing. With that working, I looked into getting the arduino and CurrentCost talking. Thanks to Alexis, this was very straightforward, although I did rework the parsing of the data to take advantage of its somewhat-fixed length format.

Here’s the sketch I ended up with:

#include <Ethernet.h>
#include <PubSubClient.h>
#include <SoftwareSerial.h>

byte mac[] = {  0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 172, 16, 0, 50 };
byte server[] = { 172, 16, 0, 103 };

PubSubClient client(server, 1883,0);

#define rx 6
#define tx 7

SoftwareSerial softSerial =  SoftwareSerial(rx, tx);

void setup()  {
  pinMode(rx, INPUT);
  pinMode(tx, OUTPUT);
  softSerial.begin(9650);
  Ethernet.begin(mac, ip);
  delay(500);
}

void connect() {
  while(!client.connect("nolcc")) {
    delay(10000);
  }
  delay(200);
}

int offset = -1;
void loop() {
  if (!client.connected()) {
    connect();
    offset = -1;
  }
  client.loop();

  // scan the data for <msg>
  while(offset == -1) {
    char c = ' ';
    while (c!='<') {
      c = softSerial.read();
    }
    if (softSerial.read()=='m' &&
        softSerial.read()=='s' &&
        softSerial.read()=='g' &&
        softSerial.read()=='>') {
      offset = 5;
    }
  }

  // skip to the current value
  while(offset < 156) {
    offset++;
    softSerial.read();
  }
  char current[5];
  int value = 0;
  for (int i=0;i<5;i++) {
    current[i] = softSerial.read();
  }
  offset += 5;

  // skip to the temperature value
  while(offset < 243) {
    offset++;
    softSerial.read();
  }
  char temp[5];
  for (int i=0;i<4;i++) {
    temp[i] = softSerial.read();
  }
  offset += 4;

  client.publish("current",(uint8_t*)current,5);
  client.publish("temp",(uint8_t*)temp,4);

  // scan for </msg>
  while(offset != -1) {
    char c = ' ';
    while (c!='<') {
      c = softSerial.read();
    }
    if (softSerial.read()=='/' &&
        softSerial.read()=='m' &&
        softSerial.read()=='s' &&
        softSerial.read()=='g' &&
        softSerial.read()=='>') {
      offset = -1;
    }
  }
}

It publishes each power reading to a topic called ‘current’ and each temperature reading to a topic called ‘temp’. This isn’t quite the right configuration for the existing broker setup, but it wouldn’t take much to modify it appropriately.

You’ll note this sketch isn’t much use without the library that does the MQTT bit. Luckily, I have been given permission to release the library to the world. I should stress at this point, in case it wasn’t obvious from the fact I am releasing this code on my personal site, that my employer has nothing to do with it.

You’ll find the Client for MQTT library here.

If you want an MQTT server to play with, go buy Lotus Expeditor to get your hands on a microbroker <gratuitous-plug />, or check out the links on mqtt.org for the Really Small Message Broker.

Turning an Arduino into a Tweetject

Thursday, April 24th, 2008

A couple weeks ago I bought an Ethernet shield for my arduino with a plan to get it connecting to the world directly. The stripped down TCP implementation that comes with it is much more geared towards making the board act as a web-server rather than client. This means you have to poll for information rather than have the arduino send it out. Unfortunately, it is this second case that I am most interested in.

Julian Bleecker’s paper “Why Things Matter” introduced the term “blogjects” - objects that blog. A natural extension of which are “tweetjects” - objects that twitter. A good example being Tower Bridge which twitters whenever the bridge opens or closes and announces which ship is passing by. (Roo has written more on this stuff here.)

I see an ethernet-enabled arduino as a perfect platform for building such objects from. But to do this, it needs to establish the outgoing connection itself.

There is another shield that provides a much more powerful option based on the Lantronix XPort ethernet hardware. It even has a demo sketch that will post to twitter. The advantage of this shield is that it provides a serial interface to run the connection - putting much less strain on the arduino. However, this power comes at a cost - the XPort itself is around $50, whereas the Nuelectronics shield is £12.99 already assembled.

So for now, I am persevering with the cheaper board and have been learning far more about TCP packets than I ever thought necessary. So far, I have got my board doing an ARP request to map IP to MAC address, establishing a TCP connection and then sending a single blob of data (naturally, “HELLO WORLD”). This is all a couple layers lower down in the OSI model than I am used to working with in my day job.

It is still a bit too hard-coded to be easily reused and attempts to re-factor what I’ve done has broken it all; so I still have lots to do.

One thing I have discovered whilst playing with this all is Wireshark - a superb tool for sniffing packets on the network and examining their content. This has helped a lot in working out which bits and bytes are going awry in my packets.

DIY and decorating allowing, I hope to make progress on this over the next couple weeks.