The info here is a bit dated – I’ve been updating my builds here.
Home automation and sensing using Arduino, OpenHAB, and MQTT. With emphasis on low cost (less than $20) wireless sensor nodes. Here’s an example using Arduino to monitor the position of a garage door, and wirelessly report the position to OpenHAB, to be displayed the web interface.
Eventually, I’d like to get to this point.
I want to share a setup for home automation and remote sensing using Arduino and Raspberry Pi. This post will get updated gradually as I build up the system, learn more, make changes to my sketches, or make corrections. So please don’t treat this as a static page. So far, I’ve implemented a single Arduino sensor node in the garage that reports door open/close status, temperature/humidity and light level to OpenHAB, and I have remote access to the OpenHAB interface. There are lots of commercial solutions out there for home automation. Insteon, SmartThings, Revolv, Wemo to name just a few. They differ in the variety of end devices offered as well as the amount of control they provide. I haven’t used any of these systems, partly because they seem to want to trap you into their ecosystem, and partly because the price seems too high for the capability. Building your own home automation system is a lot of fun and you maintain total control over how it works. This is a description of a design based on Arduino and the OpenHAB platform. To establish my requirements for a home automation system, I’ll list the components first:
2) Field device (node and sensor / actuator)
3) User Interface
The gateway is where all the field device data gets sent. It is also the backend to the user interface. The gateway provides the basic functionality of the home automation system. My requirements for the gateway:
- Interface with multiple device protocols (more details later)
- Provide rules/scenes for automation (if this, then that). The rule generation scheme needs to be flexible. The IF parameter can be sensor data value, sensor data event, time of day, or some input coming from the User Interface. The THEN parameter, the action, should be able to handle actuators in the system, or send emails/notifications, log data for permanent storage, or run a script.
- Provide data historization, so you can bring up a chart of sensor data, output status, etc…
- Run on a low power computer. The gateway is on 24-7, so energy use is a consideration.
The field device is the node to which sensors or actuators are directly attached. It needs to be:
- Cheap, so that you can scale up and have many sensors.
- Powered by both wall power and batteries, so installation is flexible. For battery power, it should accept cheap batteries and be energy efficient.
- The GPIO interface should be capable of accepting many sensors and protocols:
- $1.50 PIR presence sensors, digital input
- $0.10 photo resistor light sensor, analog input
- $2.50 temperature/humidity sensor, serial communications
- Use wireless transceivers with good range
And of course the field node should communicate wirelessly. Interface The interface for the automation system is ultimately driven by the gateway, so the interface capabilities are tied to the gateway capabilities.
- Be able to view sensor status from the interface
- Actuate outputs connected to your field devices from the interface
- View historical data as a chart
- Be able to use the interface on a mobile phone app, or web browser, or perhaps a tablet that can be a permanent home status and control console.
- Security – when accessing the gateway remotely, use authentication and encryption.
Field Node Details
I picked Arduino for the field device node. It’s cheap – an Arduino clone is only $10 from ebay. It’s also flexible – there are many detailed discussions online regarding how to build your own Arduino to optimize it for battery power. The ATMEGA328 microcontroller on the Arduino has digital inputs and outputs, analog inputs and outputs, and is capable of talking I2C, SPI, and 1-wire. This covers most sensors out there, as well as display devices like OLED displays, GPS modules, stepper and servo motors amplifiers, etc. There’s also a great community of Arduino users out there to help with programming and wiring. I was able to build my setup thanks to their help.
Whatever sensors you connect to an Arduino, you have to send the data back to the gateway somehow. A key component to the entire Arduino-sensor system is the wireless transceiver selection. I ruled out the wifi module – too expensive and power hungry. Z-wave and Xbee are possibilities, but even the cheap ones are expensive, and the cheap ones have poor range. Bluetooth doesn’t have enough range or wall penetration. I’ve personally tested these two different modules: nRF24L01+ and RFM69HW. The nRF24L01+ is probably one of the best known wireless transceiver modules in the Arduino community. It’s cheap. The low power version is $2, and the high power version is $7 (that’s the “+” on the part number). There are multiple libraries available, and the device seems in general to be well supported and widely available. The module and libraries provide basic encryption, so your neighbors can’t monitor your wireless transmissions or actuate your devices. It runs on the 2.4GHz band – the same frequency band as your home wifi. I decided against using it because of the limited range. Here’s a link to a nicely presented range test of the nRF24L01 module. Although he used the low power modules, his results were pretty close to my experience with the high power modules. For me, two high power modules could just barely make it across my house. Start factoring in basements and it gets hairy. I’m also not sure how wifi traffic interferes with the nRF24L01 traffic. Note that I didn’t make any efforts to optimize range by changing the data rates or modifying the antenna. It seems other people were able to get much better range than what I got out of these. I ultimately selected the RFM69HW for my wireless transceiver. It’s a relative newcomer to the Arduino community, and not as well known as the nRF24L01. The Arduino library for the RFM69HW comes from Felix of Low Power Labs. He pretty much single highhandedly provides all the support for this library on his forum. Like the nRF, the RFM69 comes in a standard version (RFM69) and a high power version (RFM69HW), both cost around $4. Here is my personal range test of the RFM69HW modules using a simple 5cm wire antenna. The sender is an Arduino with a GPS module, sending the GPS coordinates using a RFM69HW. The receiver is an Arduino with another RFM69HW, receiving the data as a struct and relaying the data via serial monitor to my computer. The RFM69HW easily makes it through several walls of the house. Communication was pretty reliable up to 7 houses away! That’s way better than my nRF24L01+ results. It’s not quite an apples-apples comparison – the default data rate on the RFM69HW library was lower than the nRF24L01. But the wireless characteristic lead me to deciding on the RFM69HW.
One down side of the RFM69HW is that it’s not 5V tolerant. So you either have to power your Arduino with 3.3V, or level shift/voltage divide the pins going to the RFM69HW from the Arduino. It’s not too bad a complication. The RFM69HW is manufactured by HopeRF in China, and it seems you can only get it from their single US distributor, either from ebay or direct from their website. I’ve never had trouble obtaining it, but it seems to be a single sourced component, and perhaps not as widely available as the nRF24L01 if you live in other parts of the world. And HopeRF will stop manufacturing it someday, hopefully not soon. However, it is possible to combine different wireless transceiver modules in the end setup, so it won’t ruin the infrastructure if you change wireless transceivers.
To sum it up:
|Characteristic||HopeRF’s RFM69HW||Nordic semiconductor’s nRF24L01+|
|Range||Over 700ft reliably, good wall penetration with 915MHz frequency||Poor wall penetration, barely makes it across the house, uses the busy 2.4GHz range|
|Electrical Characteristics||Not 5V tolerant, level shifting required for input pins||Is 5V tolerant, easier to integrate into Arduino|
|Power||Both modules use 3.3V for power|
|Price||$4 + reasonable shipping||$6.00|
|Availability||Single sourced from HopeRF||Seems to be widely available from more than one source|
|Support||Not as well known in the community, but decent support from Low Power Labs forum.||Very well supported by Arduino community, several libraries available|
|Encryption||Both wireless modules offer encryption via shared key|
I picked OpenHAB for my gateway. OpenHAB is a Java application that runs on a computer (Windows, Mac, or Linux). It provides pretty much everything I wanted from a gateway. Once you get the Arduino sensor data into OpenHAB, you can use it’s built-in webserver to display these screen shots below. The OpenHAB interface works as well on a web browser as it does on the Android/iPhone app. The interface is fairly customizable. You define the order and grouping of devices in the list. OpenHAB provides rules and scripts for those “if this then that” situations. You can send email and Android push (or Apple prowl) notifications to your smart phone based on sensor values, time of day, etc. OpenHAB runs on anything that has a recent Java runtime installed – so you can run it from a Windows PC, Apple, or low power $40 Raspberry Pi. The community is friendly, active, responsive, and forward thinking. Best of all, aside from integrating your Arduino sensors and actuators, you can use it to integrate commercial home automation systems via the many bindings. Your OpenHAB infrastructure can support not just your Arduino wireless sensors, but also Insteon, Wemo, Phillips Hue, Z-Wave devices and many more. Expansive!
For more interface examples, check out their demo and their wiki page. I’ve read about several other gateway platforms. Domoticz seems closest to the capabilities offered by OpenHAB, as well as being open sourced. I’d be interested in hearing about others. It does take some time to set up and learn about OpenHAB. Be prepared for that. The optimal installation is on a single board computer with low power consumption running Linux, but you can experiment on a Windows machine, and maybe use one of the newer low power windows set-top boxes.
Tying it all together
I’ll put together wiring diagrams and sketches for the Arduinos in the resource section at the bottom. The key to tying together Arduino with OpenHAB is the MQTT binding. OpenHAB has multiple bindings (plugins) to allow it to talk different protocols, and one such is this MQTT. It’s an open protocol for passing simple messages over ethernet, and is often used by IoT devices for communication. It just so happens that there is also an Arduino library that implements MQTT.
For this to work, you need a central MQTT broker program to receive the messages and disseminate these message to the message subscribers . Besides running the OpenHAB runtime, the Raspberry Pi also runs this MQTT broker program called Mosquitto. The gateway Arduino receives the wireless sensor data via the RFM69HW. Using the Wiznet 5100 ethernet module and the MQTT library from knolleary, the gateway Arduino posts MQTT messages to Mosquitto. OpenHAB uses the MQTT binding to subscribe to MQTT messages from Mosquitto, which is how OpenHAB receives the sensor data. From there, OpenHAB displays the data on the user interface the way you’ve configured. OpenHAB can also act on the data – it can push notifications to your phone when the values exceed some condition you set.
There are other ways of binding data from Arduino to OpenHAB. Some people use the serial binding. The advantage of the serial method is you don’t have to install a MQTT broker like Mosquitto. But there are some compelling reasons to choose MQTT over serial binding.
- Placement flexibility – with MQTT, the OpenHAB host computer doesn’t have to be near the wireless Arduino gateway – they just have to be on the same LAN. You can optimize the placement of the Arduino gateway for wireless reception, and place the OpenHAB host computer in a room where you might use it to play audio alarms on sensor events. With serial, the Arduino gateway and OpenHAB host have to be next to each other.
- With MQTT, it’s easy to eavesdrop on what the Arduino gateway is transmitting out to OpenHAB; use “mosquitto_sub”.
- The MQTT data can be shared by multiple separate OpenHAB installations. There’s a couple scenarios where that might come in handy.
- MQTT is useful for other things. Other types of automation systems use MQTT. I plan on doing a project using OwnTracks for GPS mapping (thanks to Jan-Piet Mens’ great contribution there).
The terminology gets kind of messy here. The “gateway” I talk about is really OpenHAB running on the Raspberry Pi. The “Arduino Gateway” on the other hand is an Arduino that translates wireless sensor data into ethernet MQTT packets. Ideally, I would just need one Arduino that has a RFM69 transceiver and a Wiznet ethernet shield. But I couldn’t figure out how to get both the RFM69 and the ethernet shield working on the same Arduino – they both talk over SPI, and I hit a wall on changing the device select pin on either the ethernet library or the RFM69 library. So my workaround for this problem is to use two Arduinos – one equipped with the RFM69HW, the other one equipped with the ethernet shield. The RFM-equipped Arduino simply forwards the wireless data to the ethernet-equipped Arduino via I2C master/slave communication. Maybe someday I can fix this issue, or a reader can point the way to a solution, but for now, that’s how it works. Just know that the “Arduino gateway” is actually composed of two Arduinos, and the “gateway” is a Raspberry Pi running OpenHAB and Mosquitto.
The Home Automation Part
So none of this is really “home automation”. It’s just sensing. The automation part is handled by OpenHAB, and you can get a much clearer idea of the possibilities by going over to the tips section of the OpenHAB wiki. As an example, you can have the Raspberry Pi tell you about the garage door by adding a few lines in /configuration/rules/demo.rules:
rule “Say Garage Door”
when Item itm_garage_door changed from CLOSED to OPEN
then say(“Someone messed with the garage door, Batman!”)
Oh yeah, did I mention that OpenHAB talks? It’s that cool. Replace the $2 ultrasonic distance sensor with a $2 PIR presence sensor. You can have it announce that someone is at the door, or send a email to you when presence is detected.
Reliability and Future Plans
The simple system I have right now has been running 24/7 for a few weeks. It recovers gracefully from power failures. I had one hiccup when I was messing with it to take pictures for this post, one of the wires for the I2C between the gateway Arduinos came off. It required a power cycle of the Arduinos to get going again. Everything could do with a bit more soldering and a bit less breadboard prototyping.
As of now, my setup only works for one way communication – field nodes sending sensor data to OpenHAB. This is because the I2C master-slave communication between the two gateway Arduinos is unidirectional. I’ll have to investigate if I can use another RFM-Arduino to be the I2C slave that receives commands from the Ethernet-Arduino. Otherwise, it’ll be trivial to add yet another pair of Arduino gateways strictly for MQTT message monitoring – MQTT messages from OpenHAB to the Arduino for actions. But that seems cumbersome. The whole problem might go away if I’m able to use a single Arduino for the gateway, or use serial communication between the gateway Arduinos instead of master/slave I2C.
I’ll also be experimenting with a battery powered Arduino design in the near future. Being battery powered adds a whole set of other design requirements.
Click here for Part 2, giving more details on how the two gateway Arduinos are programmed and how to form topic names.
Future work for this post
1) clean up comments in Arduino sketch, better explain struct usage for sensor data, and the arbitrary numbering scheme for MQTT topic name.
2) post wiring diagrams
3) post sanitized OpenHAB config, item file, sitemap file
4) post Mosquitto configuration
5) post common issues to look out for, and all the other details I’ve not had time to write out.
Go to my github for all Arduino sketches and openhab configurations regarding this topic.
Links to Components:
1) $4 RFM69HW wireless transceiver, 915MHz version for US. If you’re in Europe, get the 868MHz version.
2) $10 Arduino Buono: a nice Arduino clone that has a 3.3V / 5V switch. Set switch to 3.3V to avoid frying the RFM69HW. Also, this clone has a pretty high max amps for the 3.3V power rail, so no need to use another voltage regulator to power the RFM69HW. You can search ebay for “Arduino Buono” to find it.
3) $5 Arduino prototype shield, check ebay.
4) $9 Arduino Wiznet 5100 ethernet shield, check ebay.
5) $21 The Moteino is an Arduino clone that can be purchased with the RFM69HW built in. The creator of the RFM69 library, Felix of Low Power Labs, sells it on his webstore. It comes all soldered up and is pretty energy efficient, good for battery powered sensors. So if you don’t want to do any soldering, you can use this instead of the Arduino. Felix seems like a nice guy, shares a lot of his knowledge freely. The Low Power Lab blog has some neat project ideas.
Links to resources:
Arduino MQTT library, works with Wiznet 5100 ethernet shield
Using I2C master writer / slave receiver wire.h library