When I started to automate my home late 2009, I foremost wanted to be able to control my city heating in a comfortable and scheduled manner on a room by room basis.
Budget was (and still is) an important concern and after some investigation I stumbled upon a system made by the German manufacturer ELV (based of the FS20 system). With this system each room has its own thermostat which subsequently controls the radiators in that room. The system was wireless and inexpensive so I decided to invest in it to set a first step on the (never ending as it seems) home automation path.
I wrote some windows services (in .NET) to control the system, and used google calendar to schedule the temperature in each room. There was need for a google calendar, opposed to the standard schedule present in the system, because I needed a schedule that lasted more than a week because every other week I stayed at my girlfriend’s place and the heating in my house could be turned off (well set to 15 degrees Celsius) then.
The system operated reasonably well for several years but had its quirks. Because it was wireless and not entirely bidirectional, one could never be sure if temperatures were actually set at the correct level. My software (obviously) took care of that through some sort of polling mechanism. But once in a while the system decided that is was overflowed and went dead for hours or sometimes even more than a day.
I could live with it reasonably well, but more recently the quirks seemed to increase in frequency and exceeded my irritation threshold.
So I decided to look for a new system. But this time it should definitely be bidirectional and still wireless (did not want to put wires to all my radiators and thermostats).
And since it is a new system I also decided to redesign the architecture of my home automation software to a more modern and flexible one. With the new system I wanted
- Wireless operation
- Full bidirectional support
- The ability to control it through (custom) software
- Communication through UTP instead of USB so the device could run independent of other hardware/servers.
Based on this list, and again the budget as a primary concern, I decided to try the Max! system from manufacturer eQ-3. One could say it is sort of the successor of my current system and this time bidirectional controlled and still inexpensive.
Because I already used some ZWave devices with an Aeon Labs USB stick, I decided to give that an upgrade too. Mainly because I wanted to get rid of the USB device in my server (which prohibits me from installing Windows 2012 Hyper-V Server because that does not support USB devices, well not easily anyway) and also wanted a chance (and excuse :P) to play around with a Raspberry PI, I bought a Raspberry PI type B (with 512MB RAM) computer together with the Razberry daughter board which enables ZWave on the Raspberry.
Since I am a .NET man myself, I wanted to use .NET on the Raspberry to control the Razberry. So there is where the MONO runtime comes into the picture. But installing that on a Raspberry is an entirely different kind of challenge on which I probably will post in a separate post.
On the architectural side of things, I wanted more flexibility in my system to glue different components or even systems together. I found some interesting posts about using the MQTT message protocol for Home Automation and decided to use that in the new system. I also looked on the net for existing systems which I could use or partly reuse, but they either seem to be written in ‘unwanted’ languages like python, perl, basic, java, jscript or they do not use a flexible communication protocol like MQTT.
With MQTT, and Mosquito as the message broker, I could write gateways for the Razberry and Max! which would translate the functions on the devices to a device and hardware independent communication protocol.
This would give me separation of concerns and the ability to write multiple small components who would communicate with each other through the MQTT protocol and therefore be agnostic of each other including the hardware on which the component runs. Some of the components could be (and probably will be)
- A gateway to the Max! system. This gateway would receive and send MQTT messages and translate them to functions on the Max! system.
- A gateway to the Razberry. This gateway would receive and send MQTT messages and translate them to ZWave functions on the Razberry.
- A calendar publisher component, which reads a google calendar and publishes scheduled events as MQTT messages.
- A Heating/Thermostat controller component, who receives MQTT calendar messages and send corresponding MQTT messages to the thermostats.
This system would be flexible and easy to enhance. The plan is to use .NET on the Raspberry to create all of the above components so the entire Home Automation system can run on the Raspberry. This will include Mosquito as an MQTT message broker and probably MySQL for the storage of data.
At the moment I have bought some hardware (both Max! and Razberry) and investigating the further possibilities. I intend to publish my software as open source so others can use (part of) it if they want to. Since the communication protocol will be based on MQTT messages, it is easy to expand the system with gateways for other hardware and modules to control other things. Like for instance a module which would publish dawn/dusk events as MQTT messages so they can be used (in another controller) to turn on/off some lights in the house.
I guess this will be a work in progress for the oncoming months and I hope to reflect the progress of my new Home Automation System in posts to come!