My Home Automation story, part 4: three years later, what has changed?

Posted by

In the previous parts of this series I described my objectives for and anticipated benefits of my home automation system (part 1), detailed the implementation (part 2), and described real benefits and some technical “lessons learned” (part 3).

Three years have passed since I wrote part 3, so it is time to look at what has changed: what do I see as the real benefits of the home automation today? What new technologies have I introduced, if any? What additional insights have I had? What would I do differently if I could start from scratch today?

More benefits

Notification of adverse events

With the many window and door sensors and power meters and motion sensors, a lot of data is available to the controller. This makes it possible to detect unwanted conditions, and notify the family of what is wrong:

  • when the freezer door is not quite closed, energy consumption goes up, and this is detected by the home automation controller — described in detail in this blog post.
  • sometimes, the front door won’t close properly after we come home. This is detected by the door sensor, and after a while the home automation controller alerts us to this fault condition.

I need to become aware of those notifications as soon as they are issued, so it can’t be via an email or a tweet, which I may not see until hours later. This is a good use of voice notifications, as described in this blog post.

New technologies

Voice

The most significant change in the past three years was the introduction of voice interaction, as described in this blog post.

Voice notifications make me aware of events and conditions around the house, and voice commands allow me to control lights and other devices from the comfort of my chair.

Zigbee

Actuators and sensors compatible with Zigbee are now available at low cost, so I decided to explore this technology, and compare the performance of, say, a €5 battery-powered Zigbee sensor for temperature and humidity from Aliexpress with my old homemade €5 MySensors climate sensor.

Setting up the software environment was easy enough, using Zigbee2mqtt running on the same virtual server as the home automation controller, with a SONOFF ZB Dongle-P Zigbee 3.0 USB Dongle Plus gateway connected to the server (through a USB extension cable, so I could strap it to a bookshelf, well above the boxes of metal under my desk).

I bought a couple of Tuya smart plugs with power meter function (model TS011F_plug_1), they appear to work just as well as the WiFi-based Gosund or Sonoff smart plugs I bought earlier. They consume about 0.4 W when on (compared to 0.6 W for the WiFi-based Gosund SP1 running Tasmota).

There are also a few RGB light bulbs (model TS0505B_2_1), which consume only 0.2 W when off, very good. I am planning to change my weather-mood-alarm-light to use one of these Zigbee bulbs rather than the custom-made RGB lamp.

The climate sensors are Xiaomi LYWSD03MMC, converted from BLE to Zigbee using these instructions. They are much prettier than my homemade stuff, of course, and they work ok, but the coin cell battery was empty after 8 months, less than what I had hoped for. Also, one of the 3 units stopped talking to the Zigbee gateway after a while, and I couldn’t revive it.

From Atmel to Espressif

The first IoT nodes I built were all based on ATmega328 microcontrollers and the MySensors wireless network. I still think this is a good platform for nodes that need to be small and run for years on a single CR2032 coin cell battery. However …

I built a few nodes using an ESP8266, but found the sleep handling complicated, and the logging capabilities limited. They are ok though for use in mains-powered programmable switches like the Light control for indoor plants project, which runs Tasmota software, i.e. I don’t have to write the software.

More recently, I have used ESP32 or ESP32-C3 processors for nodes like the soil moisture sensor or a revised version of the OpenHAB dashboard module, and found them easy to program, and very low power when in deep sleep mode, to the tune of 9 µA! It is nice to have “unlimited” RAM (compared to the 2 KB on an ATmega 328), and TCP/IP connectivity to communicate with an MQTT broker, or a Syslog server.

Updates

I have moved from openHAB 2.5 on Debian 10 to openHAB 4.1.1 on Debian 12, by setting up the new version in a separate VM, and running both side-by-side for a while. In each openHAB instance, I defined a master “live” switch that controlled whether the instance was only listening to incoming MQTT messages, or was also allowed to control things. This proved to be a good way t make the transition, without time pressure, which always having a working home automation system.

The Sonoff and Gosund switches and power meters now run mostly on Tasmota 14.0, each updated in multiple steps as recommend on the Tasmota website.

More insights

Architecture

The overall architecture I chose back then has worked well:

  • try to do all communication via MQTT, stay away from openHAB-specific bindings where possible. This made it easy to integrate Zigbee devices, because zigbee2mqtt also communicates via MQTT.
  • run the home automation controller software (currently openHAB) and associated services in a virtual machine, so I can upgrade to new versions, or try new features and services, while maintaining a working system at all times.

openHAB bindings

The only openHAB bindings that are actively used, because they are unavoidable, or just very convenient, are

  • the mqtt binding, obviously
  • the avmfritz and tr064 binding, for easy access to the phone book of my Fritz!box wireless router and VoIP interface, and notification about incoming calls,
  • the astro binding to get information about today’s sunrise and sunset times, for control of plant growth lights,
  • the network binding, to detect when my or my wife’s computer are turned on, and whether our mobile phones are in range.

I have stopped using the openweathermap binding, because it often stopped working. Instead of the binding, I use a small shell script run via crontab, which queries OpenWeatherMap and publishes the relevant numbers via MQTT.

Logging and instrumentation are important

Things do go wrong, and features stop working now and then. To understand the cause of those failures and then fix them, I find it essential do have a good understanding of what went on in the home automation system at the time the failure occurred. I have used the openHAB log files to see what events have occurred, and what items had their state changed. I have used my MySensorsTracker app to see which sensor node sent which message (or didn’t), and the link quality and battery level that they report. I am using the statistics collected by my ESP32-based MySensors gateway to learn about the error rate of low-power wireless connections.

MySensors nodes are very low-power

The system includes quite a few sensors build using the low-power 2.4 GHz NRF chips with the MySensors library. I am very impressed by their long battery life. There are 8 motion sensors powered by a pair of AA batteries, which typically last >3 years. There are >12 window or door sensors, powered by a CR2032 coin cell battery, which typically lasts >2 years. There are 2 sensor to read the gas meter, powered by a pair of AA batteries, which last >2 years.

Unfortunately, development on the MySensors library has stopped, as far as I can tell.

When voice commands are convenient, and when they are not

The voice commands capability is great. It allows me to easily create additional lighting scenes in the living room, without having to worry about providing an extra hardware button somewhere, or having to grab my smartphone and navigate to the right openHAB control page.

For frequently performed actions, however, I prefer being able to push a physical button to get the job done. The voice recognition performance is good, but not perfect, so I may have to repeat a command now and then, and e-nun-ci-ate very clearly, which can be tedious.

Summary

Yes, I would do it all over again, mostly the same way. I wish I had had all the logging and instrumentation features at the start, would have made some debugging sessions easier.

Leave a Reply