Over the past two years, I have gradually increased my use of home automation in our small city apartment. I started with an IKEA TRÅDFRI light and a button, and today have over 40 devices doing useful things, saving electricity and making our living more pleasant. I won’t lie: I have done a lot of this just for fun and learnt quite a bit in the process. But if it doesn’t eventually result in utility or aesthetics, then I get rid of it. I can’t stand keeping frivolous stuff in the long run.

In this post, I’d like to describe the architecture of our home automation and specifically talk about how a graceful degradation of capabilities is crucial to the reliable operation of devices at home, which itself has important safety implications. Unfortunately, most people do not have access to a setup like mine, and it takes an industry and perhaps regulation to streamline these fundamental capabilities into smart home devices. On the other hand, if you have the time and the skills, this post should have some useful tips.

I chose Zigbee by accident, as the first few devices I purchased from IKEA were Zigbee. It turned out to be a great platform, so I have continued to invest in it. I appreciate that it is an open platform that is not tied to any one company. Furthermore, Zigbee devices purchased today will continue to operate practically forever.

Zigbee, like WiFi, is a network of devices that communicate with each other securely over a wireless link. Unlike common WiFi deployments, Zigbee is a mesh network. This means that devices cooperate with each other to pass messages along the network via the best path. This enables a more robust network that is resilient to signal degradation. Battery powered devices also last longer on a single charge, as they only need to reach their neighbors and not necessarily the main access point.

Zigbee protocol is not trivial to directly interact with. As such, an abstraction layer or a bridge is often put in place to manage the network (pair/configure devices) and provide an easy to use interface for other components to interface with. I use Zigbee2mqtt for this purpose. It interfaces with a Zigbee adapter (much like a WiFi card) and translates the Zigbee messages to and from MQTT messages that are published to an MQTT broker. It also provides convenient ways of adding, removing and configuring devices.

It is now possible to control devices in a simple way and add logic and automation. For example, we can write a program to subscribe to the appropriate MQTT topic and listen for a button click. Once a click message is received, we can then publish a message to turn on a light. This creates a simple light switch. I use Node-RED for both logic and automation. Node-RED provides a nice GUI with lots of built-in functions that mostly eliminates the need to write programs manually. Some examples of automation are: turning on plant lights at sunrise and turning them off at sunset; turning on the bathroom ventilation when a humidity threshold is crossed.

One "neat" feature of Zigbee is that it allows devices to be bound together directly. For example, IKEA buttons can be configured to directly control the state and brightness of a light bulb (of any brand!). This means that even if Zigbee2mqtt is offline, the button continues to control the light! This is an example of graceful degradation. And that is a good segway to talking about the overall architecture.

Below is a diagram of my home network, showing how various components are impacted if one component goes offline. An arrow indicates dependency, with the dependent component pointing to the dependee. In other words, if any component goes offline, only the components that are directly or indirectly pointing towards the offline component will be impacted.

To better understand how this setup degrades as components go offline, let’s take the simple example of controlling a light bulb:

• With everything working, the light can be controlled via the Home app on my iPhone over the Internet (Apple servers talk to the HomeKit hub which is either Apple TV or HomePod mini).
• If I lose Internet connection, I can continue to control the lights with my iPhone as long as I’m connected to the WiFi since the phone directly talks to the HomeKit hub without going over the Internet.
• If I lose WiFi or even my ethernet (wired) network, my home automation (e.g. light on at sunset) continues to work since it runs on Raspberry Pi, the same device that has the Zigbee adapter.
• If I lose power to the Raspberry Pi, I can continue to control the light with its bound Zigbee button.
• If my button stops working, I can continue to use the wired light switch.
• In case of the bathroom light, if the light stops working or if the main power goes out, battery powered emergency backup lights come on (since the bathroom has no windows and becomes pitch black — with hard surfaces and no light, it becomes a very dangerous place to be).
• I have thoroughly tested all the above failure scenarios.

I still have some devices that are not on the Zigbee network (such as my hand-rolled intercom controller) so they will stop working when WiFi goes out. I also have some Bluetooth devices which are as resilient as Zigbee devices (albeit with shorter range, until I deploy Bluetooth Mesh).

I have spent many hours building and maintaining my home automation system. Hopefully, with developments like Matter, increasingly less effort is needed to maintain a sane smart home and do so without special skills, such that more people can benefit.