1000² Architecture and Software

This article is part of my 1000² Smart Home project. Check out the Architecture and Software and then move on to Hardware. An most importantly, check the Lessons learned and why I did what I did. There are already some first results, connecting all parts of the system.

Starting with a top down approach – what the system should do, it soon became clear that some devices will be custom and some will be off the shelf. Determining which is a long story in itself, but this heterogeneous environment needs to be administered somehow.

Architecture

The system architecture is decides based on the requirements:

• Give the user some interface, which should be accessible from the outside without compromising security.
• Provide ways to interconnect multiple types of commercial off the shelf devices which can have different interfaces (X, Y, Z).
• Interface with low power custom devices, called nodes.
• Provide a simple way to create rules, automate and provide relevant information to the user.
• Benefit from Artificial Intelligence to save the human from writing custom rules

This brings us the general picture of how things will interact. Briefly: MQTT will be used as transportation, OpenHAB takes care of the user interface as well as interacting with commercial devices. Low power sensor nodes use a gateway (GW) to exchange information. Rules and automation is handled both by Node-RED and openHAB, with a addition of AI later.

Software

OpenHAB

The central part of home automation is the control software. While this concept might be outdated in the world of IoT where every manufacturer wants to sell only his own, plenty of open source and commercial option for controller software have emerged. This “controller” type of software is supposes to control, manage, display, graph, talk etc while working with products from multiple manufacturers. This gives the user a nice central interface to control and display, coupled, of course with automation rules and scheduling, as opposed to using multiple applications or panels for each part of the system.

OpenHAB is my favourite of the few I have played with. I have selected it because it is open and has a comprehensive list of devices it can talk to, although I own extremely few such devices. They, of course, have rules for the user to program behaviour, nice graphs and working on persistence. On the negative side, they have multiple user interfaces, with occasional features scattered, making none of them the ultimate winner. I am planning on using Open HAB for the user interface and some rule making.

Node Red

Node Red is a cool new idea, coming from IBM, implementing flow based design. Multiple people use it for home automation and just like Open HAB it has a plethora of ready made possibilities to interface with existing products. It can run quite smoothly on a raspberry Pi offering a web interface for designing the flow. It provides ways to build a dashboard through simple hierarchies and predefined widgets, although some things are more limited than I would like.

At this moment is seems like the best support to try crazy stuff, like making the umbrella blink if it is going to rain tomorrow.

MQTT

MQTT is something that is not really needed, using either Node Red or Open HAB messages can have any kind of format. But I decided to use it because it provides structure and can interface different software components, as plenty have built in support. The principle of MQTT is simple: there’s a central broker through which all messages go through.  A message is made of a topic, which is hierarchical, (like house/first_floor/bathroom/temperature) and a payload containing the value. I find the hierarchical naming a little bit against human nature but it does provide the benefit of easily selecting similar things through wildcards.

Continue to Hardware to check out the hardware I will use in this project and some first results.