Raspberry Pi with RFM12Pi and wireless sensors and actuators

These days while I wait for Galileo I’m using RPi as a house controller.  On it I have:

You need at least 4GB of SD for this much software.

As I mentioned Galileo I should also mention the BeagleBone Black.  This would also do the job in that it’s easy to interface and runs linux and therefore all the nice stuff like object brokers and node.js.  However, I really like the RFM12Pi and this is Pi-only at the moment.

My plan is that sensor devices will usually not hang off the RPi. This is largely for packaging reasons.  Obviously they could be hung on the local Ethernet, although this will make them more costly.  One great low-cost alternative is to connect them by simple wireless networks on the 868MHz band.

This is where the RFM12Pi comes in.  It’s a little module that fits inside the RPi’s case.  It contains a wireless transceiver and an Atmel 328 MCU that is programmable Arduino-style. Being based on JeeLabs device protocol it is compatible with numerous devices.


I’ve started with these two wireless devices:


The software I needed to make this fly consists of an MQTT client written in node.js to publish the sensor data and subscribe to the commands to drive the power sockets.  An early version of this is on github.

Wireless connections have obvious advantages when controlling mains-powered devices such as lights and motors – they provide complete isolation of mains voltages from the control electronics and they save wiring.  A small price to pay is the need to change batteries on the sensors.  This will get better over time as sensor implementations improve so that less power is needed.

The emonTH (and emonTX) sensors, also have the same MCU and and programmable.  At first you might think this is a minor feature.  However, in putting this together it was essential to be able to mess with the data format while testing it and writing the the MQTT client code.

Putting it all together: this is where MQTT comes in.  Once again I demonstrated this with a thermostat application that switches power to a (virtual) boiler when the temperature is lower than the set-point.  This can be built in nodeRED with the following flow:

thermostat demo

The control panel has a lot of unused sliders and switches.  One slider controls the set-point and another acts as a dial showing the current temperature, being updated by subscribing to the output from the temperature sensor.  The thermostat function contains the logic.  When that says to make heat it publishes that to the mains socket supplying the virtual boiler.

For more detail on how I do the UI please see my earlier blog.

You may notice a function called “make integer”. That’s because the MQTT client is producing a string when we need a number.  Arguably, that should not be needed.

To complete this picture I’ll add the following when time allows:

  • a multi-day, multi-session timer UI to control where heat is required
  • holidays could be sourced form my google calendar
  • an outside temperature sensor (or link to weather underground)
  • a function to calculate the optimum start and stop for the virtual boiler

At this point I could connect up my real boiler and replace my OWL boiler controls.  I probably won’t though. Unless you live alone there are some things in life that should just work and should not be tinkered with 😉

nodeRED and creating end-user UIs

The #IoT world is spawning some nice new gizmos at the moment.  For me as a systems guy, one of the most important is @nodeRED, “a visual tool for wiring the Internet of Things“, recently launched by @knolleary and team at IBM.

In my world of IoT systems development the key features of nodeRed are:

  • its ability to talk a lot of protocols
  • its ability to implement rules (via “functions”)
  • its light weight (runs just fine on ‘Pi and ‘Bone) and
  • its openness and extensibility.

OK, so it doesn’t do websockets at the moment.  Not a problem, I added a couple of “nodes” that do that via a proxy so we’re up and running.  It would (currently) struggle with a large number of nodes and functions (rules). Not a problem, it will be easy to link in other subsystems and rules engines.

And another thing I should mention as an early-adopter: the turn-around on issues is impressive.  I found a few and was pleasantly surprised when they were fixed within hours.

There are already a few very useful blogs out there and I won’t repeat all that here, not that I’ve done all those things myself.  See these:

As we all know, the IoT must include people so we need to be able to hook end-user interfaces into a nodeRED flow.

One possibility is to pair nodeRED with something like OpenRemote.  However, after looking into that I decided it did not give enough flexibility.  Given all the great tools around jQuery UI, the benefits of a ready-made system are not that significant unless home entertainment is your focus.

So I’ve augmented the basic nodeRed with a user control panel.  This is important for me as I am current testing a system that is based on an #MQTT bus.  I need to be able to prod it and poke the system and nodeRED looks ideal for that given a few extensions.

Now nodeRed does have “inject” and “debug” which provide user interaction.  These are for developers of course, not end-users.  Even for devs, we need a method of control that does not require re-deployment and we need a more visual way to monitor what’s going on.

The solution is an html page which talks to nodeRed via a pubsub protocol.  Right now I am using faye, courtesy of @jcoglan.  This is based on websockets and implements the bayeux protocol.  I have written “nodes” fayein and fayeout for nodeRED and will publish these when they’re stable.  These are both clients and need a broker running in the background, just like MQTT does. So you fire up the faye server before using nodeRED with these nodes.

This is what a control panel looks like when making use of jquery ui and plugins on top of that. I have juxtaposed it with the node UI as you would need for testing.  Once tested the user would just get their control panel. As you can see, this one is mobile-sized.  With Phonegap it could be converted to a native phone app.


The above user UI elements could be auto-generated (next project) although these were hand-written.  They include switches and sliders for input and dials and lamps for output.  In this example I have used sliders doubling as dials to save space and all these controls are useful for both input and output.

BTW. You can do part of this with httpin.  However, as httpout does not (yet) support pubsub to a browser I preferred that both input and output work the same way, hence using faye for both.

For the demo I added two other hacks:

  • a jQuery button that looks like an electrical switch;
  • a modification to inject to allow it to generate random temperatures (easier than hooking up a sensor when testing the flow).

As you can see, the flow to implement thermostat functionality is very simple. The thermostat “function” just compares the temperature with the current set-point and sends out a command to the heater/ boiler.

I have also tested this with some other devices connected via MQTT.  These are easily hooked into the above nodeRED flow. Similarly one could easily send the data to xively and pull it back into a graph.  This would be a separate control panel element connected to xively via websockets. (I use highcharts or flot for this, configurable with jQuery.)

The next task is to extend this demo to more sensors and actuators using all 8 controls.  I’d also like to generate the dashboard html and specific .js automagically with server-side scripting to create a desired number of controls of each type.

I’ll report back here with more info after I use this on my real project and knock the wrinkles out of it.