[Martin] is working on a RFM69-to-MQTT bridge device. If you’re at all interested in DIY home automation, this is going to be worth following. Why? When your home automation network gets big enough, you’re going to have to think seriously about how the different parts talk to each other. There are a number of ways to handle this messaging problem, but MQTT is certainly a contender.
MQTT is a “lightweight” publish-subscribe framework that’s aimed at machine-to-machine data sharing, and runs on top of a normal TCP/IP network. IBM has been a mover behind MQTT since the beginning, and now Amazon is using it too.
But most MQTT servers need a TCP/IP network, which pretty much means WiFi, and this can be a killer for remote sensors that you’d like to run on battery power, or with limited processing power. For these use cases, a low-power, simple sub-gigahertz radio module is a better choice than WiFi. But then how to do you get your low-power radios to speak to your MQTT devices?
That’s the point of [Martin]’s MQTT bridge. Previously he had built a sub-gig radio add-on for a Raspberry Pi, and let the Pi handle the networking. But it looks like there’s enough processing power in a lowly ESP8266 to handle the MQTT side of things (over WiFi, naturally). Which means that you could now connect your 868 MHz radio devices to MQTT for less than the cost of two pumpkin spice, double-pump lattes.
On the firmware side, [Martin] has enlisted the help of [Felix], who developed the Arduino-plus-RFM69 project, the Moteino. [Felix] has apparently ported his RFM69 library to the ESP8266. We’re dying to see this working.
For now, we’ve got some suggestive screenshots which hint at some LAN-exposed configuration screens. We’re especially interested in the RFM + MQTT debug console window, which should really help in figuring out what’s gone wrong in a system that spans two radio protocols.
The bottom line of all of this? Super-cheap, power-efficient RFM69-based radio nodes can talk with your sophisticated MQTT network. Keep your eyes on this project.
<3 Moteino. So easy to get going. And the 921 MHz radio has no trouble getting out of my metal garage where WiFi fails
I was just putting together an order for som RFm96’s because this device has built in aes which seems like a good idea if you want to do anything more than switching a few lights with your home automation and like Neil confirms, range seems to be above average for these little rf modules.
Woho, this is great!
This all feels like when I was connecting via dialup to the internet (expensive) or Fidonet (cheap), this solution is like PPP, SLIP or BBS for microcontrollers. Most bridge solutions with NRF24l01, 433MHz/815MHz (even the esp8266 to some extent) get stuck in doing custom conversion of not just the radio signal from the microcontroller but also the datastream.
This of course not a bad thing using a BBS/Fidonet/UUCP was a great thing during the Gulf war. The bad thing is that just as then you have to learn a lot to be able to send files over international borders.
So what can one learn from the old days when designing how the leaf nodes are sending data to the server?
Those interested might have a look at a similar solution at: https://github.com/computourist/RFM69-MQTT-client
It is discussed in a forum for RFM69 based solutions: http://homeautomation.proboards.com/
Those interested in this subject might have a look at the following forum where RFM-MQTT solutions in combination with Openhab are being discussed:
http://homeautomation.proboards.com/
There is a special MQTT protocol for wireless sensor devices. It can also run over a general purpose UDP network: MQTT-SN
Do you have any experience with BLE for low power battery powered sensors?
What are the advantages/disadvantages against 868/433 MHz radio?
BLE is very short range, the radio’s have less bandwidth but much longer range.
For low power you can use 802.14.5 (the physical and link layer under zigbee) and use IPv6 on top. I will give it a try and report back if I come up with something useful
With all the appreciation of this work, I think credit of the port should go where it’s due, it was implemented not by me but by Martin’s friend [Andrey]. Perhaps this should be corrected in the post above. Thanks for the mention guys.