Why Home Assistant Runs My House, Not a Single Manufacturer

This post may contain affiliate links. As an Amazon Associate we earn from qualifying purchases. Disclosure.

The first installer who walked my building site had a catalog under his arm and a plan for everything in it. One brand for the lights, the same brand for the blinds, the same app, the same account, one number to call. It sounded restful. I asked him what happens if that company gets bought, or decides the hub I paid for is now end of life, and he shrugged in a way that answered the question perfectly.

So the house got built the other way round. Home Assistant runs the logic on a small machine in the utility room, Google Home handles voice for the family, Somfy drives the shades, and four more commercial brands sit underneath doing whatever each of them does best. This is why I chose that structure, and what it costs.

Why is every box in this house from a different company?

Because nobody makes the best product in all six categories, and pretending otherwise is how you end up with fourth-best lighting because you liked somebody's door lock. So let's clear up what this article is not. It isn't a purity test about proprietary systems, because almost everything I own is one.

I buy the leader in each category, and no two of them are the same company:

• iRobot for vacuuming, because the mapping and the dock still beat the field on the floors I have.
• Satel for the alarm, a wired panel an installer programs, which works with the internet unplugged and reaches Home Assistant over local TCP.
• Reolink for cameras, chosen for handing me an RTSP stream and a local integration rather than for the sharpest sensor.
• Somfy for blinds, external shades, and awnings, specified before the windows were ordered.
• Gardena for irrigation and mowing, valves and controllers built for a garden that freezes in winter rather than a permanently warm lawn.
• Fujitsu and Gree for heating and cooling, chosen per room for quiet operation and the numbers at part load.

Lighting is the exception that proves the rule, and I'll say it plainly because it cuts against the paragraph above. The house is wired for unbranded Zigbee controllers paired straight to a USB dongle on the Home Assistant machine, and that hardware is the next thing I buy rather than something I can already show you. No bridge, no app, no account. There is no category leader in ceiling light worth its own bridge, so I took the trade the other way: no firmware guarantees and colour consistency that varies between batches, in exchange for a bulb with no opinion about who controls it and a replacement I can buy from anyone. I spent ten years in a flat collecting one bridge per brand. That was the mistake I most wanted the house not to repeat.

Every one of those is proprietary. Every one arrives with its own app, its own account, and its own opinion about how a house works.

The decision that couldn't be taken back

It wasn't a philosophical choice. It was a wiring choice, and wiring choices are the ones you can't undo. Cable in a wall, a motor in a blind box, a valve under a screed: those are supposed to last twenty years, and none of them care about software. The software dies first.

So the question I had to answer before the plasterboard went up wasn't "which app do I like" but "what still works when the company behind it stops caring". Would you bet a buried motor on a startup's roadmap? The build forced this order on me, roughly the reverse of how most people shop:

1. Decide where the logic runs, local or cloud. Every choice below inherits this one.
2. Pick the radios the house will speak: Zigbee, Z-Wave, Thread, Matter, or wired.
3. Pull cable and conduit for anything mains-powered, motorized, or behind plaster.
4. Choose the category leaders that fit steps one and two.
5. Add the household layer, voice and phone widgets, last of all.

Most people start at step five with a speaker that was on sale. Starting at step one killed the single-vendor plan in about a day.

Six leaders means six apps

I know how that ends, because I did it by accident for ten years. The flat I lived in before this build collected its smart home the way most people do: a SmartThings hub first, Philips Hue when I wanted light worth having, an eQ-3 MAX! Cube running the heating on 868 MHz, then Tuya and Xiaomi devices bought one annoyance at a time. Four ecosystems, none of them chosen against the others, every one of them a reasonable purchase on the day. What I actually owned by the end was four apps and a flat where nothing could react to anything else.

The moment you buy six category leaders, you own six apps, and that is the real, daily, unglamorous problem. It is much bigger than the philosophical one. Six icons on a phone, six notification styles, six logins my family would have to keep straight, and not one of those apps can see a single device belonging to any of the others.

Which of them is supposed to decide that the shades go down because the air conditioning is about to lose the argument with the afternoon sun? None of them can. Hue has no idea the Gree unit exists. Gardena can't read a forecast. iRobot can't tell whether the house is empty. That gap is the job I needed filled, and it is why the layer above matters more than any box below it.

Do the aggregators already solve this?

Partly, and I run one of them myself. Google Home and Samsung SmartThings both aggregate brands, and both do it well enough that the objection is fair. Neither could be the brain of this house, though, for two reasons: where the cross-brand logic is evaluated, and how far you can push the platform when the vendor never imagined your case.

Where the logic runs

Home Assistant evaluates every automation on the machine in my utility room, which is the one property none of the commercial aggregators can offer. Both platforms think in a data center. SmartThings pushed a lot of work down onto the hub with Edge drivers, so more survives an outage than people expect, and a Nest hub keeps some Matter and Thread devices reachable locally. The routines you actually built, though, the ones spanning several brands, are evaluated on somebody else's servers.

So the fiber drops at 8pm on a Sunday, and the house stops being smart. Lights, heating, and shading are not features. They're the building working. Nothing that fails when a router reboots belongs in that layer, and that single sentence decided more of this build than any product review did.

What you're allowed to build on top

The second reason is the one that settled it, and it gets far less attention. On a closed platform you get what the vendor built: their trigger list, their conditions, their dashboard, their idea of what a good interface looks like. The moment your case isn't on the list, the conversation ends.

Both have a developer surface, Edge drivers on SmartThings and the Home APIs on Google's side, so this isn't a wall exactly. You're building inside somebody's sandbox with their review process and their deprecation schedule. You can decorate the platform. You can't fix it. The SmartThings comparison walks through where that boundary sits in practice. Ask what happens the day you want something nobody planned for: on one platform that's a feature request nobody reads, on the other it's an afternoon.

What does vendor lock-in actually cost?

Real money and real hardware, on a schedule that repeats every couple of years. Three shutdowns in the last six years make the pattern hard to miss: Insteon in April 2022, Wink's forced subscription in May 2020, and Belkin ending Wemo support with most of that hardware losing app control in January 2026. I own the survivor's version of this story. My old flat's heating ran on eQ-3 MAX!: radiator valves, window contacts, and wall controllers on 868 MHz, all reporting to a MAX! Cube LAN gateway. eQ-3 stopped caring about the line years ago. The valves still work. They still work because the Cube is a box on my own network that speaks to Home Assistant's maxcube integration over LAN, and no part of that chain needs a company to still exist. Compare that to the Wemo owners below, who did nothing wrong and lost app control anyway. Same age of hardware, opposite outcome, and the only difference is where the logic lived.

Then a window contact died, and I found the other half of the lesson. There was nowhere to buy another one. Not out of stock, not expensive, just gone: a discontinued 868 MHz sensor from a line the manufacturer had walked away from years earlier. Local control saved my automations. It did nothing whatsoever about the supply chain. The system still runs and it will keep running until the next piece of plastic gives up, and every failure from here is permanent.

So the rule I'd add to every lock-in argument, including my own: ask where the spare comes from. Local control protects the logic you built. Only a protocol somebody else still manufactures for protects the hardware. That is the actual reason the house went Zigbee, Z-Wave, and Matter instead of any vendor's clever radio, and it's why a dead window contact changed my buying rules more than any company's shutdown announcement did. None of what follows is an argument against buying commercial systems. It's an argument about which layer you let one company own. Buy the best camera on the market, by all means. Just don't let the company that made it decide whether your lights come on. The cost of getting that wrong is measured in hardware that still powers up and no longer does anything, sitting in a wall box you'd have to open to replace it.

The cloud gets switched off. Insteon went dark in April 2022. Not a slow wind-down with a migration path, just servers offline over a weekend, the app dead, and remote control gone with it. The company only explained itself eight days later, after customers worked out for themselves that nobody was coming back. Local scenes kept limping along, which is exactly the point: the parts that didn't depend on a company still worked. Google retired Works with Nest in 2019 and broke a huge number of third-party integrations people had built their routines around. Belkin announced the end of Wemo support with a firm date of January 31, 2026, after which the app and every cloud feature stop, and devices not already paired to HomeKit can't be set up at all. Every one of those users bought a working product, installed it correctly, and lost function anyway. None of them did anything wrong, and none of them had a lever to pull. What is the warranty on a product whose value lives on somebody else's server?

The subscription arrives, or the rules change quietly. Wink shipped hubs for years as a one-time purchase, then in May 2020 gave existing owners a week's notice to start paying $4.99 a month or lose access to gear already screwed to their walls. The deadline slipped by another week after the backlash, which changed the date and nothing else. That's the part that bothers me most. The lock-in is what makes the pricing change possible, because a customer who can't leave isn't really a customer. I went through the arithmetic across platforms in smart home subscription costs, and the totals over five years aren't small.

The uglier version is when nothing breaks and the terms just shift underneath you. A camera company gets acquired and the new owner rewrites the privacy policy. A vacuum maker starts monetizing floor plans. I dug into that specific pattern in what happens to your data when a robot vacuum brand changes hands, and the answer is rarely "nothing".

Why Home Assistant, specifically?

Because it is the only option that satisfied all three things this house needed: local evaluation of every automation, integrations deep enough to cover the awkward device categories, and source code I'm allowed to change. Every automation in this house runs without touching the internet, and the only two integrations that do need it are the two I refuse to hang anything important on. Plenty of platforms claim openness, and a few even deliver parts of it, usually the part that costs them least. Here's what actually convinced me, in the order it mattered during the build, and the order I would check them in again if I were starting a second house tomorrow. Nothing here is about ideology. Every item is something that either saved me money or stopped a room going dark.

It runs on hardware I own

Home Assistant lives on a small fanless machine in the utility room, next to the switch and the patch panel, on the same UPS as both. Every automation evaluates there. When the fiber goes down, and it has, the lights, blinds, heating, and sensors carry on exactly as before. Nothing in that chain phones a data center to decide whether my hallway light should come on at dusk.

That single property changes what you are willing to wire in. A device that needs a working internet connection to toggle a relay is not something I want behind a wall plate, and it certainly isn't something I want driving a motor I'd have to open a ceiling to replace. That rule cost me two products I liked and saved me from a third I would still be cursing.

It speaks the protocols instead of a brand

The integrations directory runs to more than a thousand entries, but the number isn't the point. What matters is that Home Assistant talks Zigbee, Z-Wave, Thread, Matter, MQTT, and plain local HTTP, so my choice of light switch is not constrained by my choice of lock, and neither is constrained by whoever made my blinds. If you're still deciding which radios to standardize on, the protocol comparison is the piece I wish I had read before ordering anything.

Matter helps here, genuinely, and I use it. The Connectivity Standards Alliance built it precisely so a device can join more than one ecosystem, which is real progress. It's also not the escape hatch people expect, because a Matter device still needs a controller and the vendor still controls the firmware. I went through that gap in what Matter actually is.

The integrations reach the awkward categories

Protocols are only half of it. The other half is brand-level integrations, and this is where Home Assistant stops having competition. Somfy comes in through the official Overkiz integration, so my TaHoma box and every io-homecontrol motor behind it show up as normal cover entities. Philips Hue talks to the bridge locally.

Beyond the usual lighting and sensors, there are whole device domains for the categories that break other platforms: robot vacuums from Roborock, Ecovacs, and Dreame with maps and per-room cleaning, ovens and washing machines through Home Connect, LG ThinQ, or SmartThings, and televisions and AV receivers from LG, Samsung, Sony, Denon, and Yamaha sitting in the same dashboard as the door sensors. That breadth is the practical difference. My hallway script can dim a Hue group, drop the Somfy shades, pause the vacuum, and mute the receiver in four lines, because all four are entities in one system rather than four apps on a phone.

The systems talk to each other, not just to me

Here's the part that sold me, and it took a while to realize it was the main event rather than a bonus. Once six brands are entities in one system, they can act on each other's data. Four that run here daily:

• Sun elevation and outdoor temperature drop the Somfy external shades before the Gree unit in that room has to fight the afternoon. Shading beats cooling, every time, and a shade that closes at the right hour is worth more than a degree on the thermostat.
• Rain in the forecast tells Gardena to skip the cycle. The controller has no idea what tomorrow looks like. Home Assistant does.
• The Roomba runs when the house is empty and nobody is on a call, not on a fixed 10am schedule that ambushes whoever works from home that day.
• A window sensor opening kills the Fujitsu unit in that room, because cooling the garden is an expensive habit.

Not one of those can exist inside a vendor's own app, because each app only sees its own hardware. The value isn't in the boxes. It's in the sentences you can write between them.

Which integrations are local, and which are borrowed

Worth being honest about how each one arrives, because it isn't equal. Hue, Gree, and the vacuum talk locally on my network, so a dead router changes nothing about how they behave. Gardena and Fujitsu come in through cloud APIs with community-maintained integrations. That works well, but it is still somebody else's server plus a volunteer's spare time, so nothing safety-critical hangs off either of them. Knowing which of your integrations is local and which is borrowed is worth more than any feature list. My own rule of thumb after two years of this: if losing an integration would leave a room cold, dark, or unlocked, it has to be local. Everything else can borrow somebody's API and I'll live with the outage.

Where a single-box hub runs out of road

I looked hard at the commercial hubs before committing, Homey Pro most of all. They are genuinely nicer to set up, the apps are polished, and for lights, plugs, sensors, and switches they cover the mainstream brands well. If that is your whole house, buy one and enjoy your weekend.

My problem was the long tail. Support on those platforms works per app, and an app only exists if the vendor or a volunteer wrote one for your exact model and still maintains it. The mainstream lighting is fine, and then you go looking for the vacuum's room-by-room cleaning, the washing machine's cycle-finished notification, or input switching on the AV receiver, and it is either missing, half-implemented, or a community app that stopped being updated two firmware versions ago. Ask yourself which devices you'd end up controlling from their own apps anyway, because that is the real measure of a hub. The Homey Pro versus Home Assistant comparison goes through the trade-off in detail, and the effort difference is real. I still went the other way, because a house that automates the lights but leaves the vacuum, the oven, and the TV outside the system is only partly automated.

When it doesn't exist, I write it

I've written software for a living for twenty years, so this weighs more for me than it will for most people. Home Assistant is Python and YAML, all of it open, all of it on a machine I own. That turns dead ends into afternoons. A device with no integration gets a custom component, and the API is usually two HTTP calls once you sniff the app's traffic. A dashboard nobody sells gets a Lovelace card in plain JavaScript. A number that exists nowhere gets a template sensor built from three others. Logic too tangled for YAML moves into AppDaemon or Node-RED, still my code on my hardware.

The shading logic here is the example I'd point at. It reads sun azimuth and elevation, which facade the room sits on, indoor temperature, and tomorrow's forecast, then decides how far each Somfy shade drops and when. No product on the market ships that, and none ever will, because it's specific to one building. It's forty lines. On a closed aggregator it would have been a feature request nobody answered. That's the ceiling difference: on a vendor platform a wall ends the conversation, and here the wall is a file I can open.

The files are mine, and nobody can sell the project

My automations are YAML on a drive I can hold. Backups are files. If I move the whole system to different hardware next year, that's a restore, not a migration project with an exporter and a support ticket. Try getting your automations out of a closed platform in a format anything else can read, and you'll find there usually isn't one. If you can't take your automations with you, did you ever really write them?

The project itself sits under the Open Home Foundation, a non-profit set up in 2024 specifically so Home Assistant cannot be acquired and monetized the way its commercial rivals have been. That's not a marketing line; it's a governance structure, and it's the closest thing to a guarantee this industry offers.

Where Google Home fits, and why that isn't a contradiction

I get asked about this a lot, usually with a raised eyebrow. If I care so much about independence, why is there a Google speaker in the kitchen?

Because independence is about where the logic lives. Home Assistant runs everything and exposes a curated set of entities to Google Home, which handles voice and the phone widgets my family actually uses. Nobody in this house is going to open a YAML file to turn off a lamp, and expecting them to would be a design failure on my part, not a virtue. If Google changed the terms tomorrow, I would lose voice control and keep every automation. That asymmetry is the whole point, and it's roughly the trade-off I described in the platform comparison.

The rule I apply: a cloud service can be a convenience layer, never a control layer.

Is Home Assistant just a nicer prison?

It's a dependency, yes, but a different sort, and I'd rather answer the challenge than pretend it doesn't exist. If the project imploded I'd have work to do. The difference is what survives the collapse.

My devices speak standard radio protocols to a coordinator I own, so they'd pair with openHAB, Hubitat, or whatever came next. My configuration is readable text. My history sits in a local database. Compare that with a platform where the devices only ever spoke to one company's servers, and the distinction stops being academic. There is a real cost, though, and it isn't money. It's that I'm the support desk. When something breaks at 11pm, no one is coming. That trade-off is examined honestly in is Home Assistant worth it, and it genuinely isn't the right answer for everyone.

The rules I buy hardware by now

Picking the category leader comes first. Then the shortlist, before anything gets ordered:

• Local control exists. The device can be operated with the internet unplugged, through Zigbee, Z-Wave, Thread, Matter, or a documented local API.
• It survives a router reboot without needing to be re-paired or re-authorized.
• The radio is standard, not a proprietary variant that only that vendor's hub understands.
• Firmware updates are optional, or at least do not brick features I already rely on.
• No mandatory account for basic operation. An account for extras is fine.
• Nothing critical is cloud-only. Locks, heating, and anything wired into the fabric of the building must work without a service.
• It shows up cleanly in both Home Assistant and Google Home, because a device my family cannot control by voice may as well not be smart.
• I can still buy the ninth one. More than one manufacturer makes something compatible, so a failed sensor is an order rather than the end of the system. This is the rule I learned the hard way, and it's the one most reviews never mention.

Anything that fails two of these doesn't get bought. Anything that fails the first one doesn't get wired in, no matter how good the app looks in the review videos.

What this actually cost me

Honesty demands the other column. Going this route cost me a weekend of initial setup, a mini PC, a Zigbee coordinator, and a running budget of maybe an evening a month keeping things tidy. It cost me the ability to phone one number when something misbehaves. It cost me a few devices I wanted but rejected because they were cloud-only. Is an evening a month a fair price for a house that ignores outages? For me it was never close.

What it bought is a house that behaves like one machine instead of six. One dashboard, one place where the automations live, one app the family opens, and six commercial systems underneath doing what each of them does best. The automation logic belongs to the house: no manufacturer owns it, and none can revoke it. No renewal date, no acquisition, and no policy update can reach in and rewrite the logic. Twelve blinds are on Somfy motors and TaHoma today, and bringing that into Home Assistant through the Overkiz integration is the next job rather than a finished one, which is exactly why I care that the integration is official and local rather than a favour somebody might withdraw. For a system that is literally built into the walls, that felt like the only sane way to spend the money.

If you are at the same fork, start with hardening the setup properly before you connect anything to the outside world. Local control only counts as an advantage if you don't undo it the first time you want remote access.