Protocol thoughts

As explained in my previous post, i will look for a way to push information into my monitoring system. I have not yet decided which protocol and format to use.

There are at least two protocol layers you have to care about: The application layer and the transport layer. While the application layer carries the payload data like sensor readings or actor commands, the transportation layers job is to ensure a correct transmission of that data.

For the application layer,  i thought about using something like XML or JSON. While these "full-grown" standard protocols offer the possibility to use the hole bunch of development tools and libraries, they add a lot of processing and transmission overhead. When thinking of wireless sensor networks, you always have to keep in mind the low bandwith of their connection and their sometimes very limited energy ressources. It would be cool to have a sensor node running of a mini solar panel for example. For this reason, i currently prefer a more simple binary protocol that just carries the data needed. 

Same thoughts apply to the transportation layer. First thing that came to my mind was "hey, lets just use TCP/IP". Cool things about IP and TCP are: it's

• stable
• provides a secure transportation layer
• is easy to program with all programming languages (standard sockets)
• easy to add a encryption layer and firewalling
• and you got big pile of standard debug, development and monitor solutions for it

so at first i thought it would be the perfect solution for my wireless nodes. But there are a number of disadvantages when using TCP/IP.

First: Overhead. Both in transport data volume and processing efford. There is a lot of information involved that is needed to keep the internet running - e.g. routable addresses

Second disadvantage is: TCP tries to ensure that all data send to the remote receiver gets submitted, using various tricks like ACKs, sequence numbers, the three-way-handshake, retransmissions, growing timeouts and congestion control. When you are transmitting data from a sensor network this does not always make sense. While some events should be transmitted with high security (like "the mailbox was filled" or "open the garage door") some other just get outdated too fast. When you transmit a temperature reading every 5 seconds or so, it just makes no sense to try to resubmit a lost transmission over and over again, as there might be a new sensor reading while the last one still is not transmitted. You better just try to submit it for a few times, and if that does not work, you just wait for the next reading and try again. Its sometime no problem to loose readings, its not critical.

Polling vs. Pushing

My current setup used a regular polling of the sensors to collect and update the environmental information. This was the easiest way to do it during development of the prototypes. The Ethersex-Framework provided all the functions necessary to run a webserver that could be reached via the 433 MHz transceiver (which is a pretty cool feature, BTW!). But of course HTTP adds a lot(!) of overhead to the payload data.

I now changing that polling method to something more efficient. Reading out HTTP is fine for fast progress during development, as you can use all the standard commandline tools like curl, cut, tail etc.. but is wont scale.

In general polling itself does not scale. When you think of running a battery operated sensor node, its just impossible to have the webserver reachable wireless all the time. What you need is an event-driven communication, where the senor wakes up upon an event or regularly, transmits its information and then goes back to low-power-suspend until next time. Only this way of operation will ensure an acceptable battery lifetime.

Home automation infrastructure

As my experiments with the energy meter are running fine and its all a lot of fun, im going to try to add some more sensors to my home.

This is what my current architecture looks like (in my mind, at least):



I already got a NAS (a Synology DS211, which is great btw) up and running at home and there is also the embedded linux controller. It is a bit redundant to have two devices running parallel, but the embedded linux box is a really low power one, running 24/7 consuming only 2-3 Watt while the NAS takes 20W and currently shuts down at night to save energy.

I have not yet finally decided whether the home automation stuff shall run on the one or the other device. I just started with the embedded board, as it runs a standard (ARM) debian distribution and i just needed some shell skripts and dont have a SQL integration yet. Maybe i'll also set up a toolchain for the NAS system to deploy the automation software there. But before doing that, i need some more sensors.

I think i makes sense to first add some sensors and monitoring software to see if the systems runs stable. After all, its a pretty complex setup involving many components. And any failing component would be a show stopper.

As the next steps i plan to monitor the temperatures, lightlevel and motion in all rooms. I also want to add a humidity sensor to the bathroom, maybe also the other rooms.

Therefore i just ordered some JeeNodes from Jeelabs. I still have some RFM12 units and sensors in my box, so i plan to start building more sensors based on them.

Internet of Things

Last winter i had the idea to add our flat some automation functions. I looked for solutions that were comercially available, but what i found would not thrill me. As i didnt want to put cables into every edge of our flat, i was basically limited to wireless solutions. I found two that seems ok to me: The FS20 system and its successor, called "Homematic". While FS20 has a wide range of different actors and sensors, and is pretty cheap, it has some basic limitations: communication takes place in only one direction, there is no acknowledgment of commands send to an actor. I think this is a bad thing in general, as it may lead to malfunctions. Home automation, including lightning and heating is not where i want to debug communication issues. This stuff simply has to work.
The other limitation is security: FS20 communication is completely unsecured, there is only a "house id" to prevent unwanted interaction with your neighbors devices..

The FS20 successor improves both limitations: It has bidirectional communication and encryption. What detained me from getting the homematic system then was the quite high price tag, the need to buy a special master station and some the design of the thermostats/radiator valve actors. Each rooms needs its own thermostat which then controlls the radiator actors. Adding the cost of the master station i would need to buy, i eventually ended up at a price of several hundred euros just for basics functionality. To much money for just playing around a little bit.

So last winter i decided to build some stuff on my own and did research on what would be a good point to start with. There are a lot of ressources on the net dealing with home automation stuff, but i had some preferences. As i already did a lot of projects using the AVR 8/32bit family of microcontroller from Atmel, i wanted to use one of these controllers. I also searched for solutions that provide many software components (drivers, servers, communications stacks, etc..) ready to use and tested. I know what effort it takes to get software from a quick-and-dirty hack to something useable for a reliable solution.

During my research i stumbled upon many interesting projects. I wont list them all, but some i kept following for some time, e.g. http://jeelabs.net/ building small wireless microcontroller notes or the Open Energy Monitor http://openenergymonitor.org/emon/

Eventually i got a pack of evaluation board available from http://www.pollin.de and startet with a software package named (badly) "Ethersex" http://www.ethersex.de

In the folloing i will describe some of the things i learned when playing aroung with this stuff.