Software Architecture

To make the Thuis app as flexible and efficient as possible a solid architecture is needed for the system. Different systems have different properties, which are most important, for Thuis it’s important to provide the wanted functionality, be reliable, usable and adaptable.

Functionality and usability are the most obvious: without the wanted functionality the system doesn’t do anything. And when it’s not easier in use as the non-automated (old-fashioned) situation, it won’t be used at all. Thuis should be reliable because it’s influencing lots of functionality in the house: if for example the lights don’t work, this can be problematic when it’s dark. This includes recoverability as well: whenever something goes wrong it should not put the system in a non-working state, but should be able to at least do it’s basic functionality. The last property is adaptability, which is important since all products on the market evolve rapidly. It should be possible to keep up with the latest products and easily add new hard- and software to the system.

Architecture overview

Thuis Architecture

This blog provides a general overview of the architecture. In the upcoming blogs I will go in-depth into each module.


Raspberry PiAt the heart of Thuis there is a Java EE application running in a WildFly container on a Raspberry Pi 3. On the same node Z-Way (a Z-Wave controller), Mosquitto (a MQTT broker) and a database (which one is to be decided later) are running. They are sharing the same node to save budget, but because of the modular set up they can be split on to multiple nodes.

Initially the core application will be built around a MQTT observer: it subscribes to all available topics and knows what to do when certain messages arrive. All the rules live here, has knowledge of all devices, and keeps their status up-to-date. Different types of commands can be linked to each device and executed for them. Execution happens in prioritized JMS queue. This makes it possible to execute some commands in a predefined order and prioritize user initiated actions above background tasks.


MosquittoCommunication between the core modules takes place through MQTT. This is connectivity protocol designed for machine-to-machine communication, especially in IoT environments. It’s extremely light weight and provides a publish/subscribe way of communication.

MQTT in this case is used to provide a bus-structure, in a way comparable to the CAN bus used in cars. Each node can publish messages to any topic. These messages will be delivered to any nodes that are subscribed to that topic. For example when Z-Way detects a movement in the kitchen it publishes this to the topic Thuis/kitchen/movement. Another node is subscribed to this and can take action by turning on a light. This way the coupling between the different nodes is very loose and it’s possible to exchange devices easily.

While MQTT is available for a lot of platforms, it’s not possible to hook up anything directly to it. That’s why some modules use a bridge. The most important examples are the Z-Wave devices. A Z-Wave node can only communicate through Z-Wave with each other and the controller. In this case the controller acts as a bridge to connect it to the other parts of the system. The same is the case for services that have an API, but no extensions, like Plex. For these the Core will act as a bridge.

User interaction

As mentioned in the proposal user interaction takes place in several ways. From the start these are physical buttons (Z-Wave), some iPhones and an iPad. A web and voice interface will be added later. Just like any other modules they communicate through MQTT. To make the interfaces easily adjustable and maintainable several UI components will be developed which will be connected to one or more MQTT topics. They automatically update based on a subscription and can publish messages to a topic when a user interacts with them.

This should give you some more insight in the building blocks of the Thuis system. Next up will be the setup of the MQTT broker and the first integration: Z-Way.

Collecting materials

To make my proposal a reality I need quite some electronics in the house. Luckily we already have several Z-Wave devices and Raspberries in the house, and a sponsored Kit on the way. But what other hardware do we still need?

More Z-Wave devices

DimmersThe entrance, living room, kitchen and office already have most lights controllable through Z-Wave. We do however plan to make this happen in the bedroom (and bathroom) as well to create a wake-up light. For this I’ll order the Fibaro Dimmer 2 or Qubino Dimmer modules, plus some dimmable LED bulbs and switches. Before ordering I’ll try to find out which combination is working best nowadays, because in the office I’m using the first generation Fibaro Dimmer and that one unfortunately buzzes while it’s dimmed. In a later blogpost I’ll let you know which one I choose.


Estimote BeaconsNext to PIRs I’ll be using iBeacons to detect where in the house we are. I’ve chosen the latest generation of Estimote beacons for this. I’ve used the first generation before and they are nice little beacons with a very powerful SDK. Using at least 6 beacons it should be possible to give a quite accurate approximation of your location in the house. I’ll be giving it a try when they arrive.

This generation is brand new, so I had to pre-order them.


MOVEAnother pre-order is the MOVE, which is currently available on Indiegogo. The MOVE is a bluetooth controlled motor to motorize existing blinds and shades. There is a micro USB connector as well which can be used to control it, so when it arrives I’ll experiment with both Bluetooth and USB control.

It will be used in the bedroom as part of the wake-up light. The estimated shipping date is currently in June.

HDMI capturing

For the ambilight in the home cinema I intend to use Hyperion. A HDMI splitter will be used so I can intercept the signal to the TV and feed into HDMI-to-RCA converter and a capturing device, which in turn will feed the images into a Raspberry Pi. The software interprets the image and controls the LEDs through an Arduino. Most materials are ordered from AliExpress, so it will probably arrive in about a month.


Now it’s time to be patience and wait for the arrival of all materials. In the meanwhile I’ll be working on some other parts, more about that in the next post!


Sponsored Challenger

Pi IoT Design ChallengeGood news! I’ve been selected as a sponsored challenger in the Pi-IoT design challenge organized by element14. This gives me an extra boost to automate my home and also blog about it. One of the perks is that I’ll receive a very nice kit of materials:

The Raspberry Pi 3 will become the core of the system. Together with the LCD, the other Raspberry Pi will be one of the controllers. Depending on the exact EnOcean sensors they will probably be used next to the current Z-Wave sensors. I didn’t decide yet what the other components will be used for, but I bet something interesting will come up along the way!

To read all about my plans please have a look at the About page. I’m very glad I’ve been chosen as challenger and hope you’ll enjoy my home automation journey!