"Kommatik" - Home Automation

  Development

2015

Home automation is a hobby that I liked to live out when constructing our house. As no fitting solution was available off-the-shelf, I assembled my own one.

Motivation

Home automation and building automation is a nice playground. With an increasing number of affordable devices, it starts reaching the mass market. However, I did not find the "ideal" solution yet. In my opinion, the following factors hinder wide adoption:

Openness and standards

There is a variety of proprietary solutions that only work with devices from the same vendor. Many vendor-specific protocols and approaches are badly documented or not documented at all. There still is a lack of standards (or too many approaches to create some...) that allow interoperable solutions.

Availability and dependability

Home automation devices that do not work as expected counteract one of the targets of home automation: convenience and comfort. If actions are not triggered manually but automatically instead, one must rely on the implemented logic being executed reliably. For instance, in case of a storm and some "lost" wirelessly sent commands (e.g. due to interference), blinds won't be shut and might get damaged. Also the reliability of devices itself is relevant. When the number of devices grows, the probability of defects grows too. In case of such a defect, it's impact is relevant: Can it be repaired easily? How much functionality of the overall home automation system is lost? Especially a defect of a central device can have a major impact (consider the "Woman Exceptance Factor" when it is no longer possible to switch on the lights...).

Energy efficiency

Lots of home automation devices require too much energy for their own operation. Switchable sockets that do not require installation and can be switched using a remote control often require one or two Watts of power - whether switched on or not. Summed up over a higher number of devices, a considerable amount of energy is simply wasted. Thus the energy efficiency of the home automation devices itself and the equipment needed for achieving their connectivity is of crucial importance - at least to me.

Security

Some vendors understand "Internet of Things" in a manner that every little device should be directly reachable from the Internet. This is a nightmare from security perspective. Who wants to take care that the latest security patch for the washing mashine or some lighting switches are installed? With a high number of devices, a manual approach is not feasible any more. Thus automatic updates are needed. Despite the fact that control is lost: what if they fail in some cases? Or when no patches are available any more (e.g. due to end of vendor support of a device)? Besides software vulnerabilities, there are lots of other security issues to consider. One is denial of service: If resource constraint embedded devices are reachable from the Internet, creating a denial-of-service against them is a simple task. Thus the attack surface needs to be decreased. Devices should only communicate in private networks that only have a tightly controlled gateway towards the Internet.

The communication media and communication protocols employed are also relevant to the security of the overall system: In case of wireless communication, the media is accessible to anybody. Since in most of today's solutions security is an afterthought or not considered at all, unwanted access and tampering is very easy.

Privacy

There tend to be three kinds of solutions: 1) Closed solutions that only work within the building or some parts of the building and that have a closed user group. Here the privacy issues are negligible. 2) Solutions that make use of cloud services. For flexibility reasons, usually all available data (sensors etc.) is sent to the cloud and processed there. In this case, the users are out of control of their data. 3) Some "geek" solutions that are running inside the building but have some outside access implemented. Since the user group is closed or can be closed as needed, the privacy issues are small.

In my opinion, data should be kept in the user's domain where possible. In case a sharing with the outside is wanted, the user should be in control.

Description

The following design decisions where taken:

Central vs. decentral architecture

Some vendors and approaches create central solutions, others decentral solutions. In my opinion, the truth is in the middle.

Central solutions have a central "brain" that controls everything. On the one hand, this is good: There is a single place where the whole solution can be administered and that provides a gateway to the outside world. This means that there is only a single system to update with security patches. Devices and sensors can be quite "dumb" and inexpensive, computationally expensive operations can be done centrally. But on the other hand, a central solution easily becomes a single point of failure. It is not nice when you no longer can switch on the light in the whole house in case some software or hardware crashes.

Decentral solutions are very fault-tolerant. Defective components only have localized impact.

I decided for an approach in which basic functionality (like switching the lights) works autonomously even in case central control is not available. Advanced and comfort functions are controlled by a central home controller. In my set-up this is currently a single board computer running Linux. But the hardware does not matter as long as it is running stable and replacement parts are available if need be.

Wired vs. wireless

Since I was building a new house, I decided for a wired installation. This is mostly for security and reliability reasons. Wireless sensors are just as an add-on for "unimportant" stuff like window sensors or for nice-to-have weather data.

External access

The solution completely runs in the home network. There is no dependency to Cloud services except getting some informational data like weather forecasts or local public transport timetables. The solution works fully even if there is no Internet connection available. No data at all is sent to the outside currently. Access from the Internet is only allowed via a restricted VPN.

Product portfolio

The following options were available:

1) Fully customized solution

Pros

Cons

2) KNX-only installation

Pros

Cons

3) Best of breed: Base installation based on KNX, advanced features customized

Pros

Cons

As the headline of the options already suggest, I decided for the third. KNX enables the use of some reliable off-the-shelf components and is also good for the resale value of the house. However, I decided not to use any decentral KNX components. Instead all cabling goes to a central junction. Less expensive KNX components with lots of inputs/outputs can be used there. For low-voltage comfort features, other bus systems like 1-Wire and I2C are used to interconnect self-made and some off-the-shelf components. The central "brain" for the comfort functions and custom home automation logic is a single-board computer running Linux.

Implementation

Physical set-up (cabling)

Bus systems used

Devices and electrical components set-up

In distribution box:

Power supply:

In rooms:

Software

References