For years I had a reason to ignore Home Assistant, and I thought it was a good one.
I already had HomeKit. Anything that did not speak HomeKit natively went through Homebridge, and later HOOBS. It worked. Why would I run a whole other automation platform to do the thing I was already doing?
That reasoning held right up until I actually audited my own network.
Counting the bridges #
The audit was not even about automation. I was going through what was on my network, and I started counting bridges.
Philips Hue. IKEA. Sonoff. ThirdReality. Leviton. Then the devices that were not behind a bridge at all but still wanted a cloud account and a phone app: the robot vacuum, and a long tail of things that never supported HomeKit in the first place.
Every one of those is a device sitting on my LAN that can phone home, pull firmware on its own schedule, and do things I have no realistic way to review. Individually each one is defensible. Collectively, I had quietly built a fleet of unmanaged appliances inside my own network, and I had done it one convenient purchase at a time.
That is the part that actually bothered me. Not the clutter. The attack surface.
The protocols were fine, the vendors were not #
The deeper I went, the clearer it got: Zigbee, Z-Wave, Matter and Thread are consistent. They are genuinely good standards. The problem was never the protocol layer.
The problem is that every manufacturer wants the protocol to run through their hardware.
Here is the example that broke my patience. I paired a Jasco Products Zigbee wall switch with the IKEA bridge. It paired fine — that is Zigbee doing exactly what Zigbee is supposed to do. But IKEA would not expose that switch to HomeKit. So I stood up Matter to bridge it across, and IKEA cheerfully exposed all of its devices through that path too. Now I had duplicates of everything in HomeKit.
The madness was too much. I had used an open standard to work around a vendor, and the vendor’s response was to flood the workaround.
The brunch that changed my mind #
Meanwhile Homebridge was doing a lot of quiet heavy lifting, and the cracks showed most with UniFi Protect. Plenty of plugins existed. Not enough of them were stable enough to actually depend on. Random disconnections, usually at the worst possible time.
Here is the worst possible time.
I was away on vacation. I had an open work order with the property managers where I lived, so somebody was expected to be in my home. My motion sensor fired and told me there was movement in the house.
I did what anyone would do — I opened HomeKit. And there it was, the notice every Homebridge user knows on sight:
No Response.
Now, to be clear: UniFi Protect was up the entire time. The cameras were fine. The footage was there. Nothing was actually broken about my ability to see who was in my house.
But that is not what happened in my head. My first instinct was not “open Protect.” My first instinct was “damn, I didn’t bring my laptop to brunch” — because I had been trained to think that when HomeKit says No Response, my job is to go fix Homebridge. Only after that did I remember Protect existed and open it.
So: two apps, one of which was down, to answer a question as simple as who just walked into my house — and did they take off their shoes?
That is the moment the trade-off stopped being theoretical, and it is not really about Homebridge being unstable. It is that the alert and the evidence lived in two different systems. The notification came from one place and the answer lived somewhere else, and the gap between them landed on me, at a restaurant, in another country, with no laptop.
Later I did use UniFi Teleport to VPN home and fix Homebridge. But by then I had already learned the actual lesson. A home automation setup that makes you guess which app to open during a security event is not an automation setup. It is a scavenger hunt with multiple motion sensors attached, and you are left constantly guessing which one is active.
Four apps, one room #
To be completely fair to all of them: IKEA Home, UniFi Protect, UniFi Network, Philips Hue, LG ThinQ, AC Infinity, Sonoff eWeLink, Leviton, August, Sonos, Bambu, HP, Apple TV, ThirdReality, Magic Home, Govee — they all work perfectly.
With their own devices. In their own apps.
They do not work with each other. My Magic Home living room mood light would not talk to the IKEA LED strip on the console in the same room, or the Govee strip behind the TV, or the Leviton dimmer on the wall.
So explain to me why I need to open four apps to control the lights in one room.
Oh, and I almost forgot the Meross gear. And the Tuya devices. Talking through it like this makes my house sound like a zoo for IoT devices. Nobody warned me that home automation had to be this complicated.
Enter Home Assistant #
Then Home Assistant walked in and said “hold my drink, I’m about to whip these kids into shape.”
And whip them into shape she did.
The AC Infinity app is off my phone. That is not a small thing — the AirTap in my bedroom is Bluetooth, and it had been sitting there working in isolation for months because nothing could reach it. Now it runs through an ESP32 Bluetooth proxy and is paired with my ecobee thermostat in a real automation. When the HVAC turns on, the AirTap turns on with it. When the HVAC goes off, the AirTap follows. The way it should be in one house.
I turn on one mood light in the living room, and the Leviton dimmer turns off while every other mood light comes up and matches the one I touched. One action. Four vendors. No apps.
What is already gone #
The Sonoff bridge is decommissioned. The Hue bridge is decommissioned. The IKEA bridge is in transition.
All of this runs on the Intel NUC I moved Home Assistant onto, which I wrote about in moving Home Assistant from a Raspberry Pi 4 to an Intel NUC.
Set it, forget it, build a new one #
The Leviton Decora MLWSB is getting removed entirely, and I will say plainly that it is the worst automation device I have ever used.
It does not speak Zigbee, Z-Wave or Matter — just its own thing, in its own app, on its own terms. But honestly, that is the least of my problems with it. Plenty of proprietary gear is perfectly reliable. This is not that.
The real issue is the instability. Devices drop off at random, and I have to go and manually re-adopt a switch that has already been adopted thirty times. Then comes the ritual: open the Leviton app, check for a firmware update, hope this is the one that finally fixes the thing that has been broken for months. Repeat.
As I am literally writing this post, the bridge disconnected again. I re-adopted it. My dining room light switch is still showing offline in the bridge, and I have tried to re-adopt that one several times with no luck.
The manual switch on the wall still works, so the lights turn on. But manual switches working is not why I automated my house in the first place. If the fallback position of my smart home is “walk over and press it yourself,” then I have paid for a very expensive light switch.
Here is my philosophy, and it is not complicated:
Set it, forget it, build a new one.
I want to install something, have it work, stop thinking about it, and go spend my attention on the next project. Anything that demands constant tinkering just to keep doing the job it was sold to do is not “high maintenance” or “a bit finicky.”
In my book, it is broken.
The security argument is the real one #
The automation improvements are great. But the reason I am actually committed to this is the security posture.
I would rather point all of my security tooling at one server than try to police half a dozen vendor bridges and switches scattered across my network, each one able to phone home and pull firmware on its own schedule without me reviewing any of it.
And I do not just mean IDS and IPS. I mean the logs and the metrics too. One place to collect from, one place to reason about, one place to keep history.
That last part matters more than I expected. UniFi is great at showing me what is happening right now, but it does not hold logs anywhere near long enough for the questions I actually want to ask. So I started shipping the history somewhere that does: ClickHouse. Netflow via Akvorado, and alongside it the activity coming out of Home Assistant.
Then I pointed my own local model — MikeOsude AI — at that history for predictive analysis, mostly to help me build dynamic firewall rules. To be precise about what that means: I still write the rules. The model does not touch my firewall. It tells me where to focus my energy, which is a very different and much more useful job.
One system to harden, monitor and reason about. That is a defensible design. What I had before was not — it was just familiar.
What the data actually told me #
Here is the part I did not anticipate. Once everything lands in one place, you stop guessing about your own house.
My motion sensors were lying to me. I ran a query expecting a fairly even spread and found that I spend the overwhelming majority of my time in my office. That was useful on its own, but the more important finding was a limitation: PIR motion sensors detect movement, not presence. Sit still at a desk and read for twenty minutes and, as far as the sensor is concerned, you left. That is the wrong signal to build occupancy automations on. mmWave presence sensors are the way to go, and I only know that because I had enough history to see the shape of the error.
My cooling costs were an HVAC problem, not a thermostat problem. I have an ecobee Thermostat Pro, which is a genuinely good device — it just expects a modern, staged HVAC unit. Mine is an older system that only understands all on or all off. So a one-degree drop does not trim the output; it kicks the compressor and the entire unit back on. That is where the money was going.
There are settings that remediate exactly this. They are not exposed anywhere useful in the ecobee app.
So the fix was the same fix as everything else in this post: disable ecobee’s own automations and scheduling, and hand the decision-making to Home Assistant, where I can actually see the data I am deciding on. This is also why the AirTap and ecobee pairing earlier in this post matters — it is not a novelty automation, it is compensating for a unit that has exactly one gear.
None of those conclusions were available to me when my smart home was spread across many apps. Not because the data did not exist, but because it existed in too many places and never in the same query.
Credit where it is due #
My hat goes off to Nabu Casa and to every developer working on Home Assistant and its integrations. This is a genuinely hard problem, and the reason it works is that a lot of people did the unglamorous work of making other companies’ hardware behave.
I avoided this platform for years because I thought I already had the problem solved. I did not. I just had it distributed across too many apps and a pile of bridges, and I had stopped noticing.