I told myself this would be a weekend. Get Home Assistant running, pair the half-dozen smart plugs I already owned, turn a light on with my phone, done. That was three weekends ago. I now have a dashboard, a folder of YAML, a second Zigbee coordinator I did not strictly need, and a genuine opinion about MQTT topic naming. This is how it gets you.
The install was the easy part
I run it as a container rather than the full HassOS appliance, because I already have a homelab box doing other things and I did not want to dedicate hardware to it. Docker Compose, a volume for /config, host networking so discovery works, and it was up in ten minutes. The web UI walked me through the onboarding, found a couple of devices on the network on its own, and I had a working light toggle before the kettle had boiled.
services:
homeassistant:
image: ghcr.io/home-assistant/home-assistant:stable
volumes:
- ./config:/config
- /etc/localtime:/etc/localtime:ro
network_mode: host
restart: unless-stopped
The trap is that "working light toggle" is the start, not the finish. Once you can toggle one thing reliably, your brain immediately wants to toggle it based on something, and that something is never quite as clean as you hope.
Zigbee, and why I stopped using the cloud
My plugs were WiFi ones that phoned home to a vendor cloud, and every time the internet wobbled they went unresponsive. That offended me on a level I did not expect. So I bought a Sonoff Zigbee USB dongle, set up Zigbee2MQTT, and started replacing the cloud-dependent kit with local Zigbee devices that answer to nothing but my own coordinator.
The difference is night and day. Local devices respond in tens of milliseconds, they keep working when the broadband is down, and nothing I own is at the mercy of a startup deciding to sunset its app. Zigbee2MQTT publishes everything over MQTT, Home Assistant subscribes, and the whole thing is delightfully boring once it is set up. The setup itself involved learning what a "coordinator" versus a "router" versus an "end device" is, and discovering that my mains-powered bulbs double as routers and extend the mesh. That is the kind of fact that is useless until suddenly it explains why the plug at the far end of the house finally stopped dropping off.
Automations that actually earned their place
Most of the automations I built in the first flush of enthusiasm were nonsense. Motion-activated everything sounds clever until a light snaps off whilst you are sat reading perfectly still. The ones that survived are the dull, genuinely useful ones:
- Turn the hallway light on at 5% if motion is detected between midnight and 6am, so the nighttime trip downstairs does not involve a faceful of full brightness.
- Flip the immersion heater off if nobody is home and it has been on more than an hour.
- Nudge me on my phone if the freezer's temperature sensor climbs above a threshold, because a silently failing freezer is a genuinely expensive surprise.
The freezer one has already paid for the entire project, conceptually. None of these are impressive. None of them would demo well. But they remove small daily frictions and one large potential disaster, and that is exactly the right ambition for home automation. The flashy stuff, voice control, scenes with names like "Movie Night", I tried and quietly abandoned. The toggle for those is my hand, and my hand has excellent uptime.
What I would tell past me
Start local. Buy the Zigbee dongle on day one and skip the cloud-plug phase entirely, it only teaches you bad habits. Keep your automations in version control, because you will break something at 11pm and want to know what you changed. And accept, going in, that the appeal is not really the convenience. The convenience is marginal. The appeal is that it is a tidy, contained, observable little system that does what you tell it and nothing more, in a house full of devices that increasingly do not. After a few weeks of fighting cloud APIs at work, owning the whole stack in my own home is oddly restful. Even if it did eat my evenings.