Many years ago, back when I was still writing software for a living, I was involved in creating some software that is now called WebSphere MQ. This was designed to integrate different types of software and systems together, easily and without disruption. I always used to describe it as email for programs. Over time that whole concept was refined and extended, and the basic concepts are now used as the basic building blocks for what is often called the internet of things. This a concept where sensors and actuators are connected together (usually via the internet) so they can be more easily accessed. IBM’s Smarter Planet theme takes these sensors and actuators, and applies intelligence to them, allowing us to gain incremental benefits sometimes even in unexpected areas.
For a long time now I’ve been monitoring various sensors around my home, connecting them to my own internal data network, where I’ve been able to process the output of these sensors in various ways. I’ve been doing this using a protocol called MQTT, implemented on a very simple server, called Real Small Message Broker (RSMB) which was written by a colleague of mine. This has worked really well for my needs, and being designed for embedded use, requires practically no resources to run.
However, some time ago a service become available on the Internet called Pachube (now renamed to Cosm), which is essentially a central clearing house to which anyone can publicly connect and classify their sensors, creating a potentially huge number of datafeeds. These can then be aggregated, selected and reused by other people, giving individuals access to untold numbers of sensors, allowing them to create innovative new services that eventually others will then build further services on. It’s a great concept that I wanted to contribute to. Initially, as a trial, I decided to share the temperature feed from my home office with the world.
To achieve that, I did the following:
- Created an account on Cosm.
- Defined a datafeed, which I named (“Study Temperature”), tagged with appropriate metadata (“physical”, “temperature”, etc)
- I then created and named a datastream to be associated with that datafeed, consisting of a set of single data points (namely the temperature in my study).
- I then created an API key to provide access to that datafeed. Normally you would limit the permissions associated with that key, but because of the way I intended to use it, I created a key that would grant complete access to all my Cosm resources.
- Since I am already capturing the temperature in my study and feeding it into the RSMB on my home server, I just needed to share that data with Cosm, which I was able to do by connecting my RSMB to Cosm with a Broker Connection, and some topic replication. See this post by Nicholas O’Leary, another colleague, who describes exactly how to do this. Note also my comments, where I conclusively prove that RSMB cannot do name resolution – you can only use dotted-quad IP addresses.
- Once the broker.cfg file has been saved, and the RSMB restarted, you should see data starting to arrive in Cosm.
At this point, I added a little icing to the cake. I could see that I was now sharing information to the world via Cosm, but Cosm also integrates with some other services on the internet, which together can be made to give some value back to me. In particular, we experience occasional power outages at our house, and I would like to know as soon as possible if our power has gone out so that (if necessary) I can call our key-holder and get them to flip the power back on and save the contents of our freezers.
Since I now have a permanent connection between my home server and the Cosm servers, I can use a feature of RSMB called notifications. When enabled, this publishes a message to a predefined topic on each broker describing the state of the connection between them. Essentially once a connection is established it writes “the connection is up” to that topic, and each broker tells the other ‘if you lose contact with me, write “the connection is down”‘ to that topic. This means Cosm can have a datastream whose content describes the current status of the connection between my house and Cosm.
So next I use the Cosm web GUI to define another Cosm datastream and datafeed for these notifications.
By then adding a Cosm trigger to that datastream, I can arrange to send a Tweet from Cosm to an account on Twitter. Simplistically I could simply get Cosm to send a Tweet to me. But in practice I have a separate Twitter account for my house (everyone has a twittering house these days) and so I get Cosm to send a Tweet to that account.
Note that when using the Cosm web interface to define the twitter trigger, the results under Firefox were so badly formatted as to not be usable. I swapped to Google’s Chromium browser instead, from which it was possible to actually get the trigger defined and working.
My Twitter account both follows my house’s Twitter account, and has arranged for Tweets from my house’s account to be enabled for mobile notifications (ie, they are sent, at no cost, to my mobile phone as SMS messages).
Finally, I update my RSMB broker.cfg configuration to enable notifications and name the notification topic, and restart RSMB.
What this means in practice is that whenever the connection between my house and Cosm changes (coming up or going down) a message is published to a Cosm datafeed, which triggers Cosm to send a Tweet to my houses Twitter feed, which then shows up on my Twitter feed, and also causes Twitter to send me a mobile notification (an SMS message to my mobile phone) containing the message that was originally written to the Cosm datafeed. From that SMS message I can tell (from anywhere in the world) when a power failure occurs at my house, and when it has been recovered.
Just for reference, if you want to replicate this, here is my broker.cfg. Be aware that it will be line-wrapped:
address 188.8.131.52 1883
topic “” out house/temperature/study /v2/feeds/63014/datastreams/0.csv