Friday, 10 June 2011

What's all this gibberish about?

After a few readers asked why I wanted to read a webpage using my mBed dev board, which appeared to contain nothing but gibberish, it's probably time for a fuller explanation.

The idea was, of course, to get a simple prototype working, then post a series of blog entries detailing how we got it to work. But since we're not at that stage yet, and recent posts have stirred interest, here's what we're trying to do:

The mBed will form the heart of a switching unit.
We've already built something similar, years ago - a PIC based board which can activate (and de-activate) a number of relays. The relays provide isolation to a 240V mains supply - so we can use a microcontroller to switch things off and on around the house.

With the mBed we had hoped to take this a stage further.
The problem with the PIC-based approach was that it was a USB device, and so needed to be connected to a PC all the time. By using the ethernet support on the mBed, we could do away with the PC altogether - the microcontroller could talk to the web server directly and receive messages. (yes, this could be achieved with a bluetooth-to-serial type adapter, to talk to the router via wi-fi and relay messages back to the MCU over serial, but this project was originally to help us learn to use ethernet for something useful!)

Anyway, here's where we're up to:
We want to be able to send messages over the internet, to get the switching unit to turn things on and off. In fact, we wanted to take this idea further and to send text messages to our little switching unit. The final aim - and proof that it works - is to be able to send a text message on the journey home from one of our BuildBrighton meetings, and have the kettle/coffee pot switch on, so there's a nice hot cup of coffee waiting when we get in!

In the fullness of time (and when we've got two-way messaging working, so the switching unit can report back it's status) this sort of thing could actually be useful for vulnerable or disabled people, to help support them in their homes....

Anyway, while we're still trying to get the microcontroller to talk to the router, we ploughed on ahead to set up the text messaging side of the project. By using a text-to-web gateway, we can provide two means of accessing/controlling our switching unit while away from home. As before, other ways of achieving the same result exist (get the microcontroller to talk to a SIM card and send text messages directly to the unit) but we decided on the text-to-web approach and are determined to stick with it!

To send text messages to any internet connected device, we:

1) bought a keyword for a shared shortcode from
This costs about £6/month (because we picked the cheapest keyword they did)
2) created a script on our web server to capture messages and store them in a database
3) told the interface about the script

So what happens now is that whenever a message beginning with the keyword 2MBED is sent to 88802, it is forwarded (by the textmarketer server) to our web script which stores it in an online database (why the awkward keyword 2mbed? Keywords that begin with numbers cost £6/month, keywords beginning with letters cost £12/month - this is for a proof of concept, so we didn't want to go splashing the cash!).

We then built a separate web page which reads this database and displays any captured messages, using special characters as delimiters so we can break the data up for parsing at a later date. It is this web page that we want the mBed device to poll, and act on any messages received

As you can see from this screenshot, we've already captured a few text messages. The web output includes a number of messages in the form:

GUID (32-character globally unique id to identify the message)
Date message was received (in YYYY-MM-DD-hh-mm format)
Phone number the message was sent from (obscured for privacy reasons!)
The actual message (everything following 2MBED in the SMS body)

Each of these bits of data is stored separately in the database (the textmarketer web API also captures the network used to send the message if this is of any use). We write this data out to a web page, using the carat (^) symbol to denote the end of a field, and the hash character (#) to denote the end of an SMS message.

That's it really. Quite simple.
We've also added some extra trickery into the web script to allow you to try it out, without the need to pay for your own short code. Simply visit and follow the instructions to create your own keyword for a text-to-web interface.

Note: sending text messages to shortcode 88802 only works from within the UK