Home automation using HomeAssistant

2025-05-15 23:03 by Ian

This is a running log of my HomeAssistant setup.

Overview

Yeah, that about sums it up...
There are a handful of "smart devices" in my house, and I absolutely refuse to allow them to touch the internet, for reasons that should be obvious to the infosec crowd. I have them all VLAN'd off into an isolated subnet so that they can't report usage or intelligence they may have gathered about my internal network. Also, I don't want them to be able to update firmware (thus changing their behavior). So as a first-principle, this entire effort will be an on-prem/never-cloud affair.

HA Host

The SBC hosting HomeAssistant is a Raspi3b+ with no special modifications, apart from its milled aluminum heatsink case. I moved from a Pine Rock64 due to the difficulty of keeping the thing running reliably. This is the only computer in the house that straddles both VLANs. It has no duties apart from running HomeAssistant and a handful of custom scripts that I wrote to mediate control between devices. It is expected to be always running (even during power outages), and so should be as low power as is practical.

root@dietpi-iOT:~# echo "HOME-iOT" > /etc/hostname

Welcome to this world, HOME-iOT.

DietPi provides a convenient breakout for the installation of HomeAssistant via its dietpi-software tool. I also installed ESPHomeAdmin, but I probably won't use it for anything more than evaluations. Many of the wall switches I'm using are based on Tasmota.
Some of the software needs were more granular than dietpi-software had broken out. So I just installed them directly. 

root@HOME-iOT:~# apt install vim net-tools python3 htop minicom nmap git mosquitto openvpn iotop

HOME-iOT will be statically assigned on my common class C subnet. This system is now a piece of infrastructure.

Managing the batteries and inverters

TODO: This machine should be responsible for monitoring and managing the house's UPS. I have been tinkering to add the inverters into HA, but to no useful ends, yet.

Casting it in stone

Once the machine is configured as desired, it should be made robust and difficult to change. I'm confident in my network's internal security, so I'm less worried about exposure of threat surfaces. My primary concern is the sort of problems that embedded operating systems cause for themselves when deployed:

All of these are solvable with a USB thumb drive and some layered mounts. But reduce the logging as much as practical.

Cameras are a special layer of Hell

If you've taken apart as much embedded firmware as I have, you wouldn't trust any of it. One of the benefits of having costly network gear is that you can setup mirror ports and listen to them with a promiscuous interface to snoop every packet that a device sends and receives. If 100% of that last sentence didn't make sense to you, then take my word for it: Don't use IP-connected cameras unless you isolate them from the internet. They should all be assumed to be hostile actors unless proven otherwise. So I built a few of my own using more Raspi SBCs, and a few PoE shields.

I have been dissatisfied so far with any of the DVR software I have tried using, so for now I just connect to them directly. I had good results with motion, but bending it into a multichannel DVR is not something I yet know how to do.

Update 2025.06.20: I hated the layered mounts approach on the HA host. Instead of wearing a hole in the SDcard, I wore one in the USB drive I was using. The SDcard needs to remain read-only unless manually re-mounted for updates/maintenance.

This machine will be the last man-standing as the batteries expend their final potential. The NAS will be powered down in a power outage. So I may have to mount a RAM drive that hosts the HA DB, and is periodically rsync'd back to the NAS opportunistically. Doing that might greatly reduce draw, as well. Depending on how much time the CPU spends idled-up waiting for glacial I/O operations to be finished.
I'm told by iotop that HA is writing to the DB file more than once/sec. So it needs to be a RAM drive.

Update 2025.08.25: Uptime is at 9-weeks. I found the source of my periodic file I/O, and logging is now happening to RAM. This system is also providing my network's DNS (via pihole) for all DHCP clients. Not only does this offer my users some protection from bad-actor domains and ads, but it also represents a site reliability improvement.
DNS services can now remain operational at much less energy cost. My main application server can now be shut down in an outage (>100W), and DNS remains available as a network service until the last gasp from the backup batteries. To top it off, the 15W of draw I added can be taken directly from the DC chain, thus removing it from the inverter load.
If every power conversion step costs 10% of the load power, than DC (Batteries) ---> DC-5V (SBC) might cost 15W from the batteries, and DC (Batteries) ---> AC (Inverter) ---> DC-5V (SBC) might cost more than 18W at the battery.

Previous:
Next: