What the project is actually measuring
The software runs on a local machine — typically a small server or a dedicated stick — and talks directly to devices on the same network, bypassing vendor clouds entirely. That architecture is the point. A device controlled through Home Assistant does not need its manufacturer to keep a server running, and it does not stop working when a company is acquired or simply loses interest. The integration list, which numbered over three thousand by early 2025, is less a feature catalogue than a ledger of dependencies that someone had to manually unpick.
Each integration represents a protocol, a proprietary API, or a cloud relay that a volunteer had to reverse-engineer or document. Many of those entries exist because the original vendor path failed — either the service shut down, or the tethered device model made the hardware useless without a subscription. When Nest shut down the Revolv hub's servers in 2016, owners of a three-hundred-dollar device were left with dead hardware. Local control, had it existed, would have been the difference between a working hub and a paperweight.
What the numbers tell you
- 3,000+ — Home Assistant integrations listed by early 2025, each representing a protocol or API that required explicit community effort
- 2022 — Year the Connectivity Standards Alliance ratified the Matter standard
- 2016 — Year Nest shut down Revolv hub servers, rendering hardware inoperable
The technical gap it fills
A device can be physically repairable and still be remotely bricked by a firmware update or a server shutdown.
A device that authenticates against a remote server has a lifespan governed by someone else's budget. A device that speaks an open radio protocol — Zigbee or Z-Wave, for instance — and is controlled locally has a lifespan closer to that of the hardware itself. Home Assistant bridges both worlds: it will talk to open-protocol devices natively, and it will also wrap proprietary APIs in a local proxy layer that at least reduces the dependency on any single vendor's uptime.
The Matter standard, ratified by the Connectivity Standards Alliance in 2022, was meant to reduce the need for this kind of rescue work by mandating a common application layer. Whether it delivers that promise over time depends on whether manufacturers implement it fully and whether they honour the local-control clause — which is technically present but, in practice, unevenly applied. Home Assistant's developers have tracked compliance closely enough that their public testing reports have become a de-facto accountability layer the standard's own body does not provide.
The right-to-repair framing, now backed by statute in the EU and several US states, addresses hardware: the European Commission's ecodesign regulations ↗ require that spare parts and repair documentation be available for certain product categories. Software dependency is a separate problem. A device can be physically repairable and still be remotely bricked by a firmware update or a server shutdown. Local control addresses the software half; repair law addresses the physical half. Neither alone is sufficient.
What the integration count signals
The size of the Home Assistant integration list is, in the end, an indirect measure of the industry's trust deficit. Every cloud-mandatory device that a user migrated to local control was a device whose manufacturer had decided that the user's continued access to their own hardware was optional. The project's documented integration library ↗ functions as an involuntary archive of that decision-making.
For a buyer deciding what to purchase today, the integration list is also a practical signal: a device with an active Home Assistant integration has, in effect, a fallback that does not depend on vendor goodwill. A device with no integration and no open protocol has a lifespan that ends when the service does. The hardware cost is the same either way; the five-year value is not.
