Starting a new project

Why another home automation software stack

There are already many home automation software stacks available. Some of them are open source, other ones are proprietary, and some are tied to a vendor product line. With the recent hype surrounding IoT and smart home there are probably 100th of them available. However none of them currently match my needs : they inevitably fall in one of these two categories:

• Very complex system usable only by geeks.
• Very limited systems working only with a vendor products.

Some solutions are even capable of being classified in the two categories by being both very complex and working only with a vendor products. The product I need combines these two categories but the other way: A system easy to use that supports a reasonable number of products.

Easy to use means that my parents must be able to use it by themselves (and If my grandparents can use it, it is even better). However it does not mean that only simple things can be done with it. This is where the home automation system should be smart: provide advanced features in a very simple and intuitive way. This is an area where almost all solutions fail currently. Nest seems to be one of the only companies trying solutions in this direction.

Supporting a reasonable number of device is probably the key to provide a simple system while providing advanced features. Supporting all available devices will inevitably bring complexity to the software and the user interactions. On the over way supporting too few devices limits dramatically the interest of the system.

The requirements for a good product

This product definitions translates to the following requirements. The base requirements are:

The system is controlled via a mobile application. This may seem obvious but many home automation systems provide a web ui via an embedded web server. This allows to control the system from a mobile device but is far from ideal because they are not designed for touch based devices. Moreover this does not allow to control the system outside of the home network.

The system must be controllable from anywhere, providing an internet connection is available : Controlling the system from the cloud is the default way. In order to ensure a maximum service availability, the system must also be available on the home network when there is no internet connectivity.

Now come the devices requirements:

Low price. This is the most important point: there is no way I pay 60 euros for a temperature sensor when the sensor component cost only few cents.

Low power. This is very important for non powered sensors. Changing batteries every few months is a no way as soon as you have several of them. This is less important for powered devices as long as their consumption is limited.

Security : I do not really care if my neighbors see my temperature sensors, but nobody must be able to control any of my devices. So the system must be secured and allow only authorized people to use it. It should also be noted that exposing a sensor value to anybody becomes a problem as soon as this value is used to control the system : if the information not secured then it can be spoofed, allowing for example an attacker to control the heat regulation.

Finally here are the never do that requirements:

Complex setup. device pairing must be very easy. For example, no average user will be able to provide the protocol used by the device or even its id.

Scenarios. I sometimes read reviews where the tester said a home automation system is not complete if it does not allow to define user scenarios. I would rather say that a smart home system supporting scenarios is a failure to be smart. This is often a quite complex feature to use and where many improvements are possible.

Support everything. Home automation is a very large term that can cover a lot of use cases. Restricting to only few of them but doing them very well is better than supporting almost everything almost correctly.

RF protocols

There is no definitive choice on the protocols that will be supported, but I started to use 2 of them. I consider only RF protocols : they are the only ones that potentially allow a simple setup.

Enocean is the choice I initially made to monitor the temperature. The sensors are great because they are powered by solar cells, so there is no need to change the batteries. However they fail on the other device requirements : they are expensive and offer no security. The pairing button is only used to discover the device faster.

I then made a no choice for development purposes only: the rfxcom transceiver. It is not a protocol in itself but an aggregator of many proprietary protocols on the 433MHz band. For example it can be used with the inexpensive Oregon scientific temperature sensors or Chacon power plugs. Also the last version supports the Somfy RTS protocol. This is not a long term solution: the transceiver in itself is quite expensive and most protocols are not secured. It is however a nice tool to develop the software and face security issues : It is very easy to sniff devices and control them.

There are other protocols that I am closely watching : Z-Wave and Bluetooth Low Energy (BLE). Z-Wave seems to be more and more popular. I did not try it yet because the devices are quite expensive and it seems that batteries life is quite short. It also seem that interoperability between vendors is not there yet which is a shame for certified products. It is however one of the protocols that have security features.

BLE may finally be the IoT protocol promised a lot of times : An open standard supported by many manufacturers with security features. For now it seems to be used only by IoT devices and not home automation devices. If the protocol gains traction this may change rapidly.

The field of RF protocols is moving very fast with the promised revolution of IoT. But unfortunately we are still at the stage where to many protocols exist and none is globally adopted. BLE may be the one, the in-progress low power wifi (aka 802.11.ah) may also become popular. However since new protocols are announced each month, it is also possible that the future widely used protocol for home automation does not exist yet.

Global system design

Now let’s see how is structured this new project. The global design is the following:

It is composed of four main components:

The devices. These are the sensors and actuators present in the home. They can use different RF protocols and behave in different ways.

The concentrator. This is a term extracted from the xmpp IoT specifications. The concentrator is the box in the home that allows to aggregate all devices present in the home.

Cloud service. This is the internet based service that provides additional services to the concentrator. There might be several technical reasons to provide a service on the cloud rather than on the concentrator. Here are few of them : Features that must be available even when the concentrator is not connected, features that are based on real-time aggregation of several sources of information, or keep an algorithm private.

Mobile application. This is the most visible part for the end user. It should be very easy to use yet allow to control every aspects of the home automation system.

Here is the current development status of these components:

Concentrator : The hardware is a cubox-i. This board is much more powerful than needed, but I had one of them available. It is running a Linux system built with yocto. I use a dedicated yocto layer, so it will be very easy to make it run on other boards such as the raspberrypi. All the code is written in python and using twisted.

Cloud service : This part is pretty limited for now. An ejabberd xmpp server is running on a server allowing realtime communication between the concentrator and the mobile application. Xmpp is the most relevant choice I found because it contains all features needed for such a communication : real-time (almost), bi-directionnal, publish/subscribe. Another really good point is that it can be used via different transport protocols : TLS is used by the concentrator, but the mobile application can use BOSH as a fallback. The main drawback is that it is based on XML which is far from being the most efficient way to encode data.

Mobile application : In order to ease portability between Android and iOS, it is is developed in HTML packaged with Cordova. Native parts will be written latter for better integration in each system. The application is developed with enyojs which is the only real web application framework. For now it is tested only on android devices.

What’s next ?

As said on the begining of the article, I will open-source some of the elements. I will start with some of the concentrator parts. By the way I expect to release most of them as soon as they are in a good shape. More posts will come, detailing specific parts of these four components.