Home Assistant Works Great Until It Doesn't: 10 Years of Lessons

When the vendor pulls the rug

Nobody warns you about this one clearly enough. Companies change their APIs, sometimes overnight, and your devices stop working without any notice to you.

My smart thermostat ran flawlessly for two years. Then the manufacturer pushed a "platform upgrade" and the Home Assistant integration broke. The maintainer was a volunteer with a day job and a kid. It took three weeks to get a fix merged. I had no programmatic thermostat control for three weeks in February. I kept the heat running manually and bought a dumb programmable thermostat as backup that same week. Best $30 I spent on this system.

This pattern repeats constantly. MyQ garage doors had their local API locked down. Various Tuya-based plugs changed their cloud handshake. A weather service I used switched authentication methods. The "local control" promise is real for many devices, but even local devices often phone home for firmware updates that can change behavior or add cloud-required authentication where there was none before. The only real protection is choosing devices with well-documented local protocols: Zigbee, Z-Wave, proper Matter implementations. Treat anything that needs a cloud handshake as temporary.

2.4 GHz in a dense apartment is not a solvable problem

I live in an apartment. A 2.4 GHz scan shows somewhere around forty-seven neighboring networks, depending on the day.

My ESP32-based sensors drop offline unpredictably. Not due to bad code, not due to bad hardware. The 2.4 GHz band is saturated. I have a bedroom sensor that loses connectivity for hours at a stretch when my downstairs neighbor apparently runs something particularly RF-noisy. I never nailed down exactly what. Could be a microwave, could be a baby monitor, could be a cheap router blasting on a wide channel.

I tried everything in the ESPHome toolkit: static IP reservations (in the router, not the firmware), wifi_reboot_timeout, fast_connect: true, placing the access point as close as physically possible. The ESPHome community was genuinely helpful, but the conclusion was always the same: 2.4 GHz in dense housing is a contested shared resource. There's no fix. You manage it, you don't solve it.

For critical sensors, anything feeding an automation I'd actually notice failing, I switched to Zigbee or Z-Wave. WiFi ESP32 devices now handle non-critical monitoring only: temperature logging, power sensing, things where an hour of missed readings doesn't matter.

Zigbee's real interference problem

Zigbee is supposed to solve the WiFi reliability problem. Separate protocol, mesh self-healing, lower power, designed for exactly this use case. In a detached house with a single router, it probably works beautifully.

The catch: Zigbee also runs on 2.4 GHz, and its channel numbering is independent from WiFi's. WiFi channels 1, 6, and 11, the standard non-overlapping set most routers use, overlap directly with Zigbee channels 11 through 22. If your coordinator is sitting on Zigbee channel 11 and your neighbor's router is blasting on WiFi channel 1, they're fighting over the same frequencies. Zigbee loses, because it transmits at much lower power.

The right move, which I didn't do when I set up my network, is to pick a Zigbee channel before pairing any devices, based on a scan of the local WiFi environment. Zigbee channels 25 and 26 sit above the standard WiFi interference window entirely, though not all devices support channel 26, and channel 25 can catch the upper sideband of WiFi channel 11. Channel 15 or 20 are reasonable middle choices if your neighbors are mostly on WiFi channels 1 and 6. The problem is that changing your Zigbee channel after the fact requires re-pairing every device on the network. I've done this twice. It's a full weekend project with forty devices.

Even with a well-chosen channel, I still get ghost dropouts. A sensor shows "unavailable" for forty minutes, then comes back with no log entry explaining why. Aqara, IKEA Tradfri, and Third Reality devices all exhibit this to varying degrees. I've learned to set a considered_unavailable timeout of several hours on non-critical sensors so I'm not getting 2 AM notifications about a bathroom motion sensor that'll be back by morning.

My coordinator is a Sonoff ZBDongle-E. One thing that genuinely helped was mounting it on a USB extension cable away from the PC's USB 3.0 ports. USB 3.0 is a known source of 2.4 GHz interference due to its switching frequency. That's the kind of thing you find buried in a Zigbee2MQTT GitHub issue at midnight.

The stack is genuinely large

My current setup:

• Proxmox - host os
• Home Assistant Core: the main application
• MariaDB: for long-term history (SQLite bogs down past a few weeks with many sensors)
• Zigbee2MQTT: I switched from ZHA after the 2023.6 incident; Z2M's device support and debug tooling is better
• Mosquitto: the MQTT broker Z2M talks through
• ESPHome: for custom ESP32/ESP8266 devices
• Several HACS integrations, including one I should probably have replaced by now
• Node-RED, for automations complex enough that Home Assistant's native automation editor becomes painful

Every single component in that list has broken at some point. Not all at once, usually, but in combination. When a Zigbee device goes unavailable, I now run through a checklist: is the Z2M add-on running? Is the MQTT broker running? Is the coordinator physically connected (it works loose sometimes)? Is it just this device or all of them? Is this a Z2M issue or a Home Assistant entity issue? That diagnostic process takes five to ten minutes before I even start fixing anything.

Some automations that actually run reliably:

• Power monitoring via IotaWatt on my breaker panel. I get notifications when the dryer cycle ends and alerts when the AC runs for more than ninety minutes straight. IotaWatt has a local HTTP API and has never needed a cloud service. It's the most reliable thing in my stack.
• Motion-based lighting throughout the apartment. Bathroom lights on when occupied, hallway at 20% brightness after 9 PM. These work about 95% of the time. The other 5% is Zigbee flakiness.
• Alexa voice control via the Home Assistant Alexa integration. I exposed my instance via a reverse proxy and custom skill.
• Printer head maintenance: if I haven't printed in two days, HA triggers a test page via the Brother integration. Genuinely useful and has saved one printhead.

One automation I gave up on entirely: presence detection. I tried the companion app with GPS zones, Bluetooth beacon tracking with an ESP32 in monitor mode running room-assistant, WiFi device tracking via the Unifi integration, and a combination approach. Every method had failure modes that made it unsuitable for driving "lights off when nobody's home" logic. The GPS approach turned the lights off when my phone's location services throttled. The Bluetooth approach worked until it didn't, with no clear pattern. I now use motion sensors with a 30-minute timeout as a proxy for occupancy. It's a compromise, but it's reliable.

The 2023.6 weekend

A few months ago a DNS misconfiguration meant Home Assistant couldn't resolve the MQTT broker by hostname. I'd never set up a local DNS entry; I'd been relying on the Supervisor's internal hostname resolution, which changed behavior in an OS update. Fixed it by hardcoding the IP. Minor, but the kind of thing where you need to know what DNS resolution is to even begin troubleshooting your coffee maker.

That was minor compared to June 2023. I updated to 2023.6.1 on a Saturday morning. Within an hour, every Zigbee device in the apartment showed "unavailable." The ZHA integration had a breaking dependency change in how it handled the zigpy library version. The GitHub issue documenting it existed, but it wasn't in the release notes in a way that would have caught my attention. The community forum was immediately full of people with the same problem.

I spent most of that weekend factory-resetting and re-pairing forty devices. Some pairings required removing the device from the network first via the coordinator, then resetting the physical device, then re-interviewing it. Aqara devices have a reset procedure that involves pressing a button a specific number of times within a specific window. I looked up that procedure for maybe fifteen devices over the course of two days. My wife asked at some point why I was doing this instead of being present on the weekend. I didn't have a good answer.

That incident is part of why I switched from ZHA to Zigbee2MQTT. Z2M stores its device database independently of Home Assistant, so a HA update can't invalidate your pairings. The separation has been worth the added configuration complexity.

The time cost is the real cost

Home Assistant is free software. The hardware is not expensive. Time is the real currency here.

I've tracked my troubleshooting hours fairly carefully for the past few years. I started logging them after the 2023.6 incident because I was curious. It averages out to roughly two hours a week, but that average hides a very skewed distribution. Most weeks are zero. Weeks with major updates or unusual failures are ten-plus hours. Over ten years, conservatively, I've spent more than 500 hours keeping this system operational. That's a significant fraction of a year of working time, for a system that still fails in ways I can't predict.

The community framing is that this time buys you privacy, local control, and flexibility unavailable anywhere else. That's true. What's less often said is that it also buys you a part-time job as sysadmin for your apartment.

Living with people who didn't sign up for this

My wife and daughter have no patience for my hobby. When the bathroom light turns off mid-shower because the motion sensor lost Zigbee connection, I hear about it. When the "goodnight" routine fails to run because MQTT had a hiccup, I hear about it. My daughter learned to flip the hallway switch twice to get the light to stay on. First flip turns it on, the second forces Home Assistant to register the state change so the automation does not turn it back off. She figured this out at age eight. No twelve-year-old should have to debug state machines to use the bathroom at night.

My parents visited once. My dad stood in the living room and said, pretty reasonably, "turn on the lights." Nothing happened. Alexa requires the exact invocation; you can't just talk at the room. He looked at me like I'd made something worse than what existed before. He still mentions it.

The system works beautifully when everyone using it understands its quirks and limitations. That's not most people. Most people want the light to turn on when they flip the switch, and they don't want to learn which switch in which mode causes which state drift in the automation engine.

How the alternatives actually compare

Home Assistant wins on customization and privacy. It loses on reliability and on what I'd call operational overhead. The amount of ongoing attention the system requires to stay functional. Hubitat is the closest thing to Home Assistant for people who want local control without maintaining a multi-service stack. HomeKit, if you're in the Apple ecosystem and your use case is relatively simple, has dramatically better day-to-day reliability.

Who should actually run this

Run Home Assistant if:

• Troubleshooting is something you find engaging rather than draining
• You can reliably spare a few hours most weeks, and sometimes an entire weekend
• Privacy and local control are genuinely non-negotiable for you
• You're treating this as a hobby, not a utility
• You have reasonable Linux/networking knowledge. Not expert level, but enough to know what a YAML syntax error looks like and what DNS does

Skip it if:

• You want the lights to reliably work
• You live with people who didn't opt into a temperamental system
• You'd rather spend free time on other things
• You need presence detection to function
• Technology failing unexpectedly is something you find genuinely stressful

Where I've landed

I'm not migrating off Home Assistant. The IotaWatt integration alone is worth staying for, and I've built enough custom logic over the years that rebuilding it elsewhere would be its own project. But I've significantly dialed back my ambitions for what the system should do.

Nothing safety-critical runs through Home Assistant. Every light has a physical switch that works independently of network state. The thermostat has a manual override. When the smart garage opener died, I went back to the original remote and didn't replace it with anything smart.

If I were starting from scratch today, I'd buy far fewer devices and be much more selective about protocols. Everything on the critical path would be Zigbee or Z-Wave with known-good local support, deployed on a carefully chosen channel, with the coordinator on a USB extension cable away from noisy USB 3.0 ports. I'd skip presence detection entirely. I'd probably use a Home Assistant Green instead of building my own box. The $99 hardware is worth not debugging SD card corruption.

The honest version is this: the automated home as it exists in practice is still a project, not a product. For some people that's the appeal. For most people, it's a reason to buy smart bulbs that work with HomeKit and leave it at that.