My Quest for Home Automation, Part 1

As the cold season started creeping in and the need to balance energy savings while keeping the house warm became more important, I began laying out plans for doing home automation “the modern way”, i.e., without clockwork timers all over the place and with some intelligence thrown in.

Update: Part 2 is here, with a fair amount of extra detail

As you’d probably expect, it quickly got out of hand and turned into a full-blown “Internet Of Things” saga, of which this is but the first installment.

Back when X10 was a thing, home automation was too much of a pain (and costly) to get into, but these days, thanks to inexpensive microcontrollers like the ESP8266 and the Alexa/Cortana/Google Home hype, all sorts of solutions are competing for market share as supporting pillars for the lofty vision of the omnipresent, omniscient home assistant that turns on the mood lights, plays some light jazz and orders pizza when you get home.

I, however, have a rather more pragmatic take on things. The staple of X10 was physical monitoring and control: sensors of all kinds, lighting, outlets, shades, etc., and that’s largely what I put together, focusing on a very simple use case–lowering our power bill by managing heaters during the cold season, and laying down the groundwork for doing the same to the AC later in the year.

Monitoring power consumption on a per-device basis isn’t one of my goals–I have a pretty good idea of which appliances spend what and already replaced the vast majority of my lamps with LED lighting, so I’m only concerned about the overall consumption (which I’m working on monitoring centrally¹).

So my use case effectively boils down to:

• Switching heaters on and off via some a smart outlet
• Controlling the ACs (which use pretty nasty infra-red remotes)
• Placing and monitoring some sensors around the house

There were, however, five things I tried to stick to in my approach:

• As simple as humanly possible (quick operation, manual overrides, etc.)
• Avoiding bleeding edge/proprietary solutions
• Minimal reliance on Internet access for operation (above all, zero open ports to the outside)
• MQTT-based integration
• Not breaking the bank

Even as I started getting into the nitty-gritty of hardware and building my own sensors², I began checking out possible Open Source automation solutions–of which there are now literally dozens out there.

I tried out Domoticz, Home Assistant, etc., but most of them were overly complex, although Home Assistant struck my fancy, given that it’s written in Python and has, by far, the most extensive device coverage I’ve seen yet.

However, I didn’t want to rely on web interfaces. And even though I wasn’t originally looking for voice control (reading Charles Stross’ books and watching Black Mirror tends to deflate the excitement around having an active microphone in your home), I tried to get the original Google AIY Voice kit (which was made out of pure unobtainium for many months) to test Google Assistant and Alexa in a controlled environment.

I eventually got a ReSpeaker dual-mic HAT, which let me play around with various speech recognition APIs and understand how the home automation integrations worked at a very low level. As everything else related to Linux audio, that little board is somewhat temperamental, but I managed to get both Alexa and Google working for quick tests; the Alexa SDK worked (slowly) on a Raspberry Pi Zero, but the Google SDK required armv7, so I only managed to get it working on a Pi 3.

This took a fairly long time (i.e., most of November), during which I realized I wasn’t keen on having to connect my home devices to somebody else’s cloud, especially given the varying (sometimes haphazard) levels of security required (some scenarios required me to expose devices on the Internet, even if indirectly, or to let them “phone home” to their manufacturers, which, to be honest, I’m not at all keen on allowing).

So I turned back to Apple. HomeKit is LAN-centric by default (your devices can talk to cloud services of their own, but they’re controlled via the LAN), and only relies on Apple servers for remote control (using an Apple TV or an iPad as relay).

Since all iOS devices now include the Home app (which even given its dumbed down interface is still a lot better than fiddling with web UIs), it also solved the problem of having an easy-to-use³ UI to control and monitor devices.

But it had a nice side benefit: it let me use Siri–a big challenge in terms of brains (or apparent lack thereof when compared to the Alexa and Google integrations I’ve been playing around with), but a big advantage in terms of hardware: Siri works beautifully with my Apple Watch, and it’s with me in every room.

Siri does rely on Apple servers for speech processing, but automation and device control is entirely local to my LAN–I don’t have to open ports on my home router for Alexa/Google/etc. API callbacks, and everything else is reasonably easy to lock down.

And there are a lot of HomeKit integrations out there, the most popular of which is HomeBridge, an Open Source HomeKit bridge with dozens of plugins, including MQTT support.

Going “the Apple way” and just buying stuff that works^TM was something I’d love to do, but HomeKit-certified hardware is still a little thin in the ground, and spending €200+ on a brand new Apple TV is something I have budgeted for next Autumn (or whenever the living room TV dies and we can go 4K). On top of that, all the interesting hardware seems to be US-only and/or expensive, and I certainly wasn’t going to pay €50 for a smart socket.

So I hunted down alternatives, the most interesting of which was the ITEAD S20 Smart Socket, which is part of an entire family of products with the same internals and can be had for around €12 if you shop around.

Plus (and this is the amazing bit) is based on the ESP8266 and can be re-flashed with Open Source firmware, enabling support for add-on sensors:

Plus it has a physical button you can press to toggle the outlet state (which is pretty useful in a couple of places where the outlets are raised and/or easy to reach).

I ordered 4 S20s back in November and re-flashed them with Sonoff-Tasmota firmware using a very neat project called SonOTA, that spoofs the ITEAD OTA upgrade server and lets you re-flash the devices without having to open them and wire them up to an FTDI adapter (which is doable, but undesirable given the proximity to live mains).

You should be aware that ITEAD has recently started shipping a firmware version (1.6) that prevents SonOTA from working, but outlets I ordered 2 weeks ago were still running version 1.5. Your mileage may vary.

This effectively removes any chance of the devices calling home to the manufacturer or punching holes in my LAN–all they talk to is a local MQTT broker and HomeBridge, thanks to a plugin called homebridge-mqtt-switch-tasmota.

The end result is pretty decent–it all works fine from both the Apple Home app and Siri, and I soon realized that the entire system ran pretty well without any sensors given that all the heaters have built-in thermostats.

So most of the power optimization boiled down to some smart scheduling depending on where we were in the house. Scheduling with simple constraints works fine with my iPad mini as a Home Hub, but I’ve been investigating other options.

There are a few, obviously. The first is that there is a degree of assembly required if you want to have a sane, easy to manage configuration, since HomeBridge requires NodeJS.

I’ve sorted that out by running it as a custom, isolated container on my ODROID, alongside separate containers for Node-RED, the MQTT broker and some Python services that manage specific topics.

The second is that Homekit only lets you share control of your entire house, which is… well, sub-optimal. I’d like to have finer-grained delegation, and (ideally) scheduled delegation.

The third is that Apple’s Home app is pretty much useless for anything more complex than on/off buttons. I don’t have any smart light bulbs (or plan to), but I’m reliably told that the Philips Hue app puts Apple’s attempts to shame.

But the Home app is enough for providing device names (and speech intents) for Siri, which in turn is clever enough to “turn off all outlets” or “everything in the living room” provided you name your devices properly–although it can be a bit trying at times, since many keywords are reserved for Apple apps.

Finally, there are a few things where HomeBridge itself falls short. For starters, each individual platform/accessory plugin is its own private little universe, and there is no central API for checking or setting device statuses or even a way to manipulate all acessories programmatically.

But there are workarounds, and on the next post I’ll go into the nitty-gritty details (and into more hardware).