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.
This blog provides a general overview of the architecture. In the upcoming blogs I will go in-depth into each module.
At 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.
Communication 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.
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.