These days while I wait for Galileo I’m using RPi as a house controller. On it I have:
- Adafruiit’s Occidentalis v0.2 linux
- OpenEnergyMonitor’s RFM12Pi 868MHz transceiver
- node.js v0.10.7 (built from sources – 6 hours)
- MQTT.js client module for node.js
- mosquitto MQTT broker v1.1
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:
- OpenEnergyMonitor’s emonTH dual sensor module (prototype at time of writing)
- ByeByeStandby wireless power sockets/ switches
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:
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 😉