I’m working on a project were I have to build a network of battery powered sensors over a territory the size of a small town.The sensors will monitor power consumption, temperature and humidity in energy poor households. Often the families in that situation can’t afford an internet connection at home so WiFi is out of question. GPRS would be an option but lately other radio technologies have come to my interest.
I’m a core member of The Things Network Community in Catalunya. LoRa is one such technologies. The (soon) availability of affordable gateways and the open nature of the software stack (from gateway firmware to backends to handlers) make it a great candidate to build an open, libre wireless sensor network that can cover large territories with few gateways.
Someday soon I’ll talk about the gateways, backends and so. Now I’m focusing on nodes. The idea is very similar to my previous post about a Moteino energy monitor node with an RFM69 radio, but using a LoRa radio and LoRaWan protocol instead. There are several options here. The cheaper and more common is to use a HopeRF RFM9X LoRa module and implement the LoRaWan specification in code. There are already libraries for arduino and alike that implement the LoraMAC specification almost at 100%. But for my first try I used another approach.
Microchip is selling a serial module that implements the full LoRaWan stack and communicates with your favourite uC through serial. The Microchip RN2483 (in the EU) is very easy to use and it’s price is not very different from HopeRF modules (both are about 15 euros at DigiKey). It’s the same module that the people at The Things Network have used for their The Things Uno prototyping platform (and Arduino Uno with a RN2483 module).
Question is: is the RN2483 a good choice for a battery powered LoRaWan node?
Moving from the ESP8266 world I’ve been diving lately I still love the simplicity of battery powered Moteino nodes. You might know I’m migrating my XBee-based sensor network at home to an RFM69 one. So long I have changed my door monitor and my weather station. They are sensing and reporting to my RFM69GW, an ESP8266 bridge board using a custom firmware.
Time to go for the power monitor. A long time ago (actually 2 years but it really feels like a century ago) I was living in a big city and we had one of those fancy “smart meters” with a LED pulsing 4000 times every kWh. Back then I used an Arduino micro to count the LED pulses and report the power every minute through an XBee link.
But now I live in a small town and my house electrical system is somewhat “old”. My power meter comes from somewhen in the 60s (maybe not so old). So a non-invasive current sensor makes a bit more sense (ehem).
A few weeks ago I wrote about my new door monitor. It was the first step towards migrating my XBee based wireless sensors network to RFM69 radios using Moteino platform by LowPowerLab. I was truly impressed by the low power consumption so I committed myself to keep on working with them.
Coincidentally Felix Russo, the guy behind LowPowerLab, released the new version of it’s Weather Shield for Moteino. So it was time to update (or completely revamp) my trusty Arduino FIO based weather station… and last week I received a parcel from LowPowerLab with a pair of shields to play with: the new WeatherShield R2 and the PowerShield R3. They are both compatible with the Moteino (off course).
From left to right: PowerShield R3, Moteino and the new WeatherShield R2
Some days ago I posted about the RFM69 to MQTT gateway based on the ESP8266 I am working on. Over these days I’ve been fine tuning the gateway at the same time I was migrating one of my home sensors to Moteino: the Door Monitor. The previous version was based on an XBee radio and has been on duty for almost 3 years and a half. Real life battery time has been around 3 months for a CR2032 coin cell, which is not bad at all, but still…
Aside from using a Moteino and a RFM69 868MHz radio instead of the XBee, I have reduced the components list by moving hardware logic to software logic. This means using sleeping capabilities of both the ATMega328 and the RFM69 and coding in a clever way to reduce awake time.
Some 3 years ago I started building my own wireless sensor network at home. The technology I used at the moment has proven to be the right choice, mostly because it is flexible and modular.
MQTT is the keystone of the network. The publisher-subscriber pattern gives the flexibility to work on small, replaceable, simple components that can be attached or detached from the network at any moment. Over this time is has gone through some changes, like switching from a series of python daemons to Node-RED to manage persistence, notifications and reporting to several “cloud” services.
But MQTT talks TCP, which means you need some kind of translators for other “languages”. The picture below is from one of my firsts posts about my Home Monitoring System, and it shows some components I had working at the time.
All those gears in the image are those translators, sometimes called drivers, sometimes bridges, sometimes gateways. Most of them have been replaced by Node-RED nodes. But not all of them. This is the story of one of those gateways.