If data was what I needed, the question was “how was I going to get it?”. I already knew that I wasn’t going to get the data if I had to walk to each room, on a schedule, and measure it. So automation was the way to go. But just because a sensor would be read on a schedule still didn’t solve the part of collecting the data in one place. That’s where it made logical sense to make each sensor wireless, with one station collecting the data for the entire set.
The design revolved around two major factors:
- It had to be cheap, as I was going to be putting more than one of these together. The minimum would be seven sensor nodes, but potentially more.
- I wanted it to be easy. I didn’t have all the time in the world to devote to this project, and like any good geek, I have a million and one other projects I’m working on. Not to mention the normal obligations of a day job and family.
Other factors that bubbled up while contemplating the design of the system:
- The sensor node had to be battery efficient, or would have to be able to be close to a wall socket. Battery efficient meant more than 3 months on a set of batteries.
- It needed to have a central repository where the data was collected and available on the network for me to get to from my laptop. This could be a cloud service, or a database on a raspberry pi, or whatever. Being available also meant I could work on it on my lunch hour, or when monitoring other activities.
With this small set of requirements, I started looking into my options for wireless communications. There were a couple of options available to me at the time:
- cc3100 wifi chipset
- 433mhz wireless link
- ZigBee module (like xbee), or other 802.15.4 chips and stacks like Microchip’s MiWi stack on top of ZigBee hardware
- Nordic Semiconductor’s nRF24L01+ chipset
This one was costly at first, somewhere around $30/module (it’s predecessor was, it’s now down around $10). It was out because it was too expensive for the small single purpose sensors.
433mhz wireless links
These are the cheap $2-$3 modules on eBay. They’re easy to interface with, but they’re also not smart, so collision avoidance and noise are things you have to put into your software stack to deal with the physical layer that this is. So they meet the cheap requirement, but they don’t meet the easy.
ZigBee chips or modules
I’ve loved the idea of ZigBee from the first time I heard of it. A mesh network for embedded communications is an awesome idea. Unfortunately, I’ve found that it’s a heavy lift to get into the ZigBee stacks. The benefit of ZigBee’s design is that the software stack is where most of the work is done for mesh networking. The downside though is that you need a stack, and if you’re not coding it up yourself, you’re going to need to get one prewritten. That can mean extra license fees. Microchip has a chipset and stack called MiWi that attempts to solve the problem that ZigBee was made to solve, with a lighter weight stack. MiWi might be better, but again, it’d take some dedication to get into it. They’re also not too cheap, or weren’t. The later chips and popularity have brought these down to affordable prices for small modules. The modules from Microchip are about $10. The XBee modules are still in the $30 to $40 range, so that’s too expensive for this project.
Nordic Semiconductor’s nRF24L01+
These chips (and the modules I bought) met the requirements of cheap, but they weren’t as easy as I would have liked. However, there were good examples and there was good code to use to begin understanding the details of using them. You can get them for a good price on eBay, but beware, the really cheap modules that you can get for sub $2, are probably counterfeit and your failure rate might be high. Out of the modules I bought, half of them had a problem with ACK’ing packets sent to them. They could read, they could write, but while the other side saw the packet and had no problems with the exchange, the sending side said that it didn’t get an ACK. Dan, a good friend of mine, has used them in his product for quite a few years. His are the genuine chips, and don’t have the problems mine did. Mine were either counterfeit or marginal chips that got made into modules and sold for surplus prices.
Since the nRF24L01+ met the cheap, and mostly easy requirements, it was the wireless link I started moving forward with. The design started with an Arduino mini pro driving a nRF24L01+ module for each sensor node, with a Raspberry Pi on the other end listening to a nRF24L01+ module on it’s SPI port. The Pi was going to be the gateway of the sensor net. I got to the point of getting the example code pinging back and forth between two arduinos, and between an arduino and the pi. I was able to do strength tests throughout my house, and found a sweet spot for where the Pi could sit, and hear the entire house.
This is where the project got derailed. Any geek will tell you there’s far too many projects that beg to be completed, and usually if a project isn’t in high demand, it gets shelved in favor of spending that time on the new and shiny. During the winters, since the demand for AC wasn’t there, there was always a “I’ll get back to it before summer” excuse, and off it went to the mental shelf to collect dust. It’s not that I couldn’t use the sensor net throughout the year, my house has issues with the cold just as it does with the heat, but it’s easier solved with space heaters, so the demand for this project just wasn’t there in the winter.
The game changer: ESP8266
It wasn’t until the advent of the ESP8266 that this idea became a reality. The ESP8266 solved many problems, not just the two main criteria of easy and cheap. The ability to program this module with code meant that I also could consolidate the microcontroller functionality into it. Now we’re less one component in the design. It’s built-in support for WiFi removed the need for an additional computer, like a Raspberry Pi, for use as a gateway. The sensors could communicate directly with the data store. Given the Arduino environment and boot code, this module also could use standard libraries for many things.
Now it looked as if my sensor core design could be simplified quite a bit. The microcontroller and the wifi link could be one module/chip and the data collector could be anything, anywhere I could get to on the network.
Next article I’ll detail the server design and choices. I started with the server because I could get that done quickly, and test it without needing to have the sensor core done
Easy is quite subjective here. If you’ve never heard the phrase, “penny wise but pound foolish”, it perfectly describes this term. There are many times we pick something to be “easy” (cutting some corners) but end up paying more elsewhere (for example the time spent learning a new platform just to make use of a library). Luckily, that wasn’t the case here. The new platform I learned was an good choice for future projects.