The Case for a Local Smart Home
I like to think that I'm quite tech conscious, and that IoT can be a force for good, if installed properly and made easy enough to use. The most important thing, in my opinion, is that the 'smart' devices are just that, and will work reliably not just now, but a few years down the line. They shouldn't be a pain to maintain, or cause problems if the internet dies, or there's a power cut.
I started my smart home journey a few years ago, first with an Amazon Echo, then a few smart plugs, and a couple of smart bulbs. Since then, I've migrated away from Amazon to run my smart home primarily through Home Assistant, after many hours debugging custom scripts interacting with the Amazon API. Most of the time, Home Assistant has worked wonderfully, and although there is a bit more setup involved than simply linking your devices through Alexa, there are many more possibilities for automation.
Home Assistant
Unlike the Alexa- or Google-based services, Home Assistant runs on a server such as a Raspberry Pi, and devices can be configured to connect locally. My Home Assistant instance is running in a Docker container as one of my local services, alongside my Plex server, custom DNS, and SMB server.
The instance is also reverse proxied via the internet, to allow access to everything externally and allow the companion app to report a wealth of important data from the phone, including my current 'zone' which is either home or away, battery percentages, etc. As you can see from the image above, I have smartified a range of devices, including my monitors, several lamps, and an electric blanket.
In addition to plugs, you can interact with loads of different add-ons, including Plex, CCTV cameras, and simple sensors.
Energy Monitoring
Most of my smart plugs come with built-in power monitoring as standard, allowing me to see the current power draw of all my computing equipment, both instantaneously, and as a whole from the grid for the day. In the image below, you can see the power draw from my desk, allowing me to see how much my computers and servers are costing each month. From this data, I can see that the draw of my servers is 40W at idle, and my computer is about 160W when switched on and all monitors are also on.
Automations
Within Home Assistant, I have automations configured to automatically switch lights on and off at predetermined times of day, switch on and off my lights and monitors depending on my location, and to switch on my electric blanket an hour before I go to bed in the winter months, provided that the heating has been switched off for the night.
Another gimmick I had set up was to automatically dim the house lights when I pressed play on Plex, and then switch them on again when I paused the film, or it ended. I've also had a door contact on my bedroom door previously, to welcome me home or play an annoying sound when the door is opened.
Maintaining Compatibility with Alexa
When I first moved to Home Assistant, I had access to the plugs via the Tuya integration. This is not brilliant, as it means that access to the plugs is via the Tuya cloud, and not my local network, sometimes resulting in sluggish response times, or the lack of ability to control them when the network goes down.
Instead of paying the £6.50/mo that Nabu Casa wanted for their cloud-based model, I used the Emulated Hue integration, which meant that specific devices I wanted to have exposed would appear as lights to Alexa. This, unfortunately, required the Amazon Echo devices to be on the same network as the Home Assistant server, as I believe that the integration makes use of SSDP/UPnP and this is not easy to route between different subnets, being a broadcast-based protocol.
I'd consider Nabu Casa's service if I had more complicated devices on the network, or a need for one of the other services included, but £6.50/mo seems a bit steep for what is essentially a few API calls.
Device Technologies
Radios and Protocols
Each device has to connect to the server somehow, be that via an ethernet link, Wi-Fi, or another protocol such as Zigbee. In my setup, devices mostly make use of Wi-Fi, connecting to my IoT SSID. I've opted for this throughout the house, mostly due to good wireless coverage (no mesh networking needed), and costs. Wired connections don't make sense for anything that doesn't need to be 100% reliable, such as CCTV cameras, considering that it would also require me running ethernet to each device.
Zigbee makes more sense in a bigger house, and for small battery-powered sensors. Considering most of my devices are smart plugs, they have a constant power supply. Those that aren't plugs are currently Raspberry Pi Picos, either being used as a development board for my upcoming fridge temperature monitoring product, or are simply a few leads soldered to the right GPIO pins.
Firmware
All smart products require some sort of firmware to run. This firmware is what makes the device function and provides an interface from the control protocol to the physical device, helping translate commands such as RELAY OFF to actually switch the relay off.
Firmware on-device is in the form of a compiled binary, but the source code can be made available to the end user to allow them to audit it, or extend it to provide extra features, or alter the behaviour and servers it talks to.
ESPHome and Tasmota
These are two variants of firmware designed to run on ESP32-based (or more recently RP2040-based) devices. These projects have a strong following from the open source community and contain many modules allowing the user to program their device to do what they want with it. These firmwares typically talk to the wider world over a Wi-Fi radio, and the server (such as Home Assistant) queries the device to check the status or issue updates. These devices then only need be reachable from the internal network, and no requests leave the LAN, potentially opening up attack surfaces to third parties.
Proprietary
Many of these devices ship with a proprietary but well reverse-engineered firmware developed by Chinese tech giant Tuya, which constantly sends data over the internet, reporting 'essential device information'. Much of this data is probably not actually essential for the device to function, but conveniently provides the company access to the local network and thousands of potential bots for a nation-state level denial of service attack, or to gather intelligence about foreign nationals.
Besides this worrying revelation, the internet-based control can also be quite tedious. I once got back from a holiday to find that all my devices, which once used the Tuya smart cloud were not working at all. Apparently, as a home user, I need to pay upwards of $5000/yr for access to these basic features, as I was making API calls that again cost almost nothing to run.
Reflashing
You'd think that I could simply flash my own firmware to the device, but this would prove to be quite difficult. OTA flashing is only possible on some silicon revisions with fake access points and because of a vulnerability in older firmwares, otherwise end users need to dismantle and solder to the device, before programming with a USB-UART programming tool.
I did eventually have some success using the tuya-cloudcutter repository, then connecting via LocalTuya from my Home Assistant server, but this comes with risks of bricking the device and is not trivial for someone without a background in IT.
Closing Thoughts
Reliability
When choosing whether to have a smart home or stick with a dumb one, be prepared for hours of headaches on why devices don't connect, lots of configurations, and the inevitable loss of server or internet connection that means—god forbid—you have to manually go round and switch your lights on and off.
Make sure that devices and lights can still function without the server running, particularly the main light when you go into a room. Take regular backups of the Home Assistant configuration so that when your poor SD card inevitably dies you don't lose that dashboard you've spent months and months combing through, or even better, network boot your device and offload the fault tolerance to your NAS.
Security
These are all fairly standard. Restrict and isolate untrusted devices on your network, ideally with a dedicated IoT VLAN, prevent access to the outside internet from devices, only run trusted firmware when possible, ideally open source, so you can audit it, and ensure that other devices on the network have strong credentials, and are up to date.
Prevention of Headaches
Finally, if you can, make a list of what device is where, assign it a name, e.g., plug1, DNS record (if you can, e.g., plug1.iot.chza.me), and spend a bit more on good hardware with good firmware from the start.
Also ensure all access points for the network work well (especially with 802.11b/g/n clients, not just the latest Wi-Fi 6 MIMO 5.8GHz clients), and that signal strengths reported by devices are adequate. Try to avoid batteries if you can so you don't have to change them every \(n\) months.
I hope this post has demystified what a smart home is, what it means for it to run locally, and what options are available to make your life easier through e.g., automations. Personally, I really enjoy getting into a nice warm bed in the winter then saying 'Alexa, goodnight.' which starts my night routine, setting alarms, and finally switching all lights off.