So you’ve set up a Wireless Sensor Network, i.e. 2 or more “nodes”, talking to each other via RF. This being a JeeLabs article, let’s say you’re using a JeeNode, JeeLink, or other ATmega/tiny-based board with an RFM12 or RFM69 wireless radio module - or perhaps some self-made variation, using some neat flashy ARM µC.
Everything is working fine. Great! And as time passes, you add more nodes. Fun! Some nodes are just like the previous one, for example a “Room Node” to monitor temperature, humidity, motion, and light levels in a room, and some nodes are different, such as an OOK Relay, or a LED Node to control LED strips, or … whatever, you get the idea.
In many cases, similar nodes will only differ in the “node ID” used to identify them, and such nodes can all run the same firmware, with the difference stored in EEPROM. Sometimes, you need to set up a node in just a slightly different way, and you start editing the source code to upload a slightly different build. Easy! The Arduino IDE, Eclipse, or Makefile-based build environment can make this sort of tinkering oodles of (sheer endless!) fun.
What could possibly go wrong, then?
The trouble with this way of working with more than one node, is that the tools used to build the code usually operate in “edit, build, upload, fire-and-forget” mode: each build stands on its own, but the build environment in no way helps you manage multiple nodes and all their variations.
What variations, you ask?
Here are a few, most of them will be pretty obvious:
- one node needs to report on wireless as ID 16, the other as ID 17
- one node is running on a JeeNode v4, the other on a JeeNode v6
- one node is a room node with a Pressure Plug added, the other without
- one node is running with an RFM12, the other with an RFM69
- one node has an ATmega328P, the other one uses the new ATmega328PB
- one node runs as an AVR-based door sensor, the other is ARM-based
- one node talks directly to the central node, the other uses a repeater
The list is endless. This is what happens over time. And this is the way to create a (potentially) huge mess when it comes to keeping track of all such variations.
With the Arduino IDE, you may have to readjust the build settings in the
“Tools” menu for each different “sketch”, for example. Or worse: re-adjust a
#define hidden somewhere deep in one of the included libraries.
In some scenarios, this variability can be ignored: nodes get set up, you test them, you install them in their remote spot, and that’s it. In fact, here at JeeLabs, over a dozen nodes have been running this way for years on end, with only occasional battery replacements to keep ‘em going.
But the world is not a fixed place, and neither is the home. A lot can change in the course of a few years - more nodes, to the point where things become a bit crowded on the RF band perhaps, or maybe improvements such as tracking RF signal levels and adjust the TX/RX sides to optimise for lowest packet loss - it’s most unlikely that all your home-grown designs will stay the same over the course of a few years, especially if you’ve got tinkering-for-fun in your genes!
One of the main underlying issues is the disconnect between source code and remote nodes: the source code is cross-compiled - by necessity! - (since a remote node can’t do it), and therefore it runs - by definition! - on a different machine from where it’s intended be used.
We can use wonderful version control tools such as Git and GitHub all we like, they can’t address the fact that at the end of the day, the generated machine code will be out there on some small embedded µC, with no mechanism in place to track the association to the exact source code, tool versions, and upload style used when it was originally “flashed” into that device. Say bye, bye to tweaking or bug fixing, after a while.
And then there are the technological advances: of course there will be new, flashier, smarter, cheaper, more flexible, better performing options over time. Should we replace our entire setup every year? Of course not: a working room node is still a working room node, even if isn’t the latest trend, buzz word, or fad. The reality is that over the years, any home environment is bound to become a collection of old and new. And newer still. Sure, it’d be neat to run 28V DC all over the house and base everything on LED lighting with simple central control - but are we really going to rip out existing AC mains wiring, with its hazards and security requirements? Nah…
This is the situation here at JeeLabs now, and it may actually be in a better shape than some, since many - if not all - of the nodes here have been described and documented as weblog posts over the years, with their code incorporated as examples in the JeeLib repository on GitHub.
Node-by-node development doesn’t scale, neither for hardware, nor for software!
If you’re setting up a home-monitoring / home-automation system, and you’re not assembling it 100% from stable, officially long-term-supported products, then it probably isn’t such a great idea to just keep on adding stuff to what is essentially becoming a personalised environment which no-one else, including your family members, will be able to deal with in the LONG run. And what if… ehm, you’re not always around? Or you simply forgot some of the details as the years go by? (as years tend to do…)
Spouse calls significant other: “the heating isn’t working, what do I do now?” … sound familiar?