"Kommatik" - Home Automation
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.
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...).
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.
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.
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.
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.
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.
The following options were available:
1) Fully customized solution
- Possibility to implement my vision fully
- Maximum flexibility
- Not enough free-time for full implementation available
- Not good for resale value of the building, might be perceived as too geeky and unmaintainable
2) KNX-only installation
- Industry standard
- Good for resale value since perceived as high-class
- Non-open standard (e.g. proprietary installation software)
- Working decentrally with vendor-defined functionality
- Constraints in flexibility (capabilities depend on the used devices)
3) Best of breed: Base installation based on KNX, advanced features customized
- Good value for money
- Can be done in time
- Technology mix
- Many aspects of my vision need to be dropped
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.
Physical set-up (cabling)
- Empty conduits in star-topology into all rooms (used initially for network cabling, antenna cabling, and bus cabling)
This poses initial invest but brings maximum flexibility for the future. Empty conduits are very useful for any changes that might be required in the future. Who knows what's state-of-the-art in 30 years? The additional costs are invested well.
- 235V cabling in star-topology to central junction in cellar
This is a very flexible and thus future-proof solution. Each socket gets a separate hot wire so that each socket can be switched independently of any other when required. This flexibility will hardly ever be needed, I assume. At least one would prepare for some switched sockets where the need can be anticipated. Whether to invest the increased cost for maximum flexibility is then a personal decision. I decided for a solution in which many but not all sockets get a separate hot wire (four switched sockets per bedroom); which ones are switched could be changed in-life.
- At least two wires of Cat6 network cabling in star-topology into most rooms (using some of the empty conduits)
There's no doubt that we well have lots of networked appliances in the future. I prefer wired network over wireless networks wherever reasonable due to the higher speeds and better reliability. I never installed any network socket in my life that did not get used in some point in time. Based on this experience and the low cost of the needed equipment (I purchase at wholesale), all rooms should be networked.
- Two wires of antenna cabling in star-topology into most rooms (using some of the empty conduits)
Today, antenna sockets in each room are appreciated by many buyers. The need for cable might shift to a need for optical fiber in the future. Due to the empty conduits we're future-proof.
- Multi-pair bus wire (2x6x0.8; 2x10x0.8 where needed) in star-topology into each room (using some of the empty conduits)
This is cabling for multiple purposes. Low voltage push-buttons (e.g. for switching light on and off), low-voltage switches (e.g. door contacts), low-voltage LEDs (for optical feedback), low-volage lighting, 1-wire bus, KNX bus, etc. Since my installation does not use decentral KNX components, the wire is not used for KNX bus. However, the wire gauge is high enough for use as KNX bus wire or for the higher currents of low-voltage lighting.
Bus systems used
- KNX TP
KNX, formerly known as EIB in Germany, is used to interconnect KNX devices which are used to implement some basic functions. The common variant using twisted pair cabling is used in my set-up.
Several 1-wire busses are used to connect inexpensive sensor devices in each room. Devices include temperature and humidity sensors.
An I2C bus connects the single-board computer with various electronical devices like 1-wire gateway, input/output interface ICs, and digital/analog converters within the distribution box.
Interconnecting devices in the distribution room, especially the heating
Ethernet is used as the "backbone". It interconnects visualization devices (e.g. tablet), the single-board computer, and the KNX/IP gateway.
Devices and electrical components set-up
In distribution box:
- KNX switching actors (bistable relais)
- KNX heating actuator
- KNX shutter actuator
- KNX 32x digital input/output
- KNX/IP gateway
- Single-board computer
- I2C level shifter
- I2C 4x digital/analog converter
- I2C to 8x 1-wire gateway
- I2C 16x digital input (5V and 24V)
- 1-wire 8x outputs
- 16x optocoupler array
- solid state 6x output drivers
- KNX power supply
- 24V power supply
- 5V power supply
- 5V power distribution
- 24V power distribution
- 24V/24V converter
- 24V/12V converter
- 5V/12V/24V control voltage distribution
- 42V(24V) push-buttons
- 24V 6-gang push-buttons with LED indicators
- 1-wire temperature and humidity sensors
- smoke detectors (centrally powered)