A simple evening experiment: unplug the WAN cable from your router and walk around the apartment. Wi‑Fi is alive, the local network is in place — but in a typical “smart home” from marketplaces almost everything stops working: the lamp won’t turn on from the app, the robot vacuum won’t go, the speaker will be sulkily silent. Not because they inherently need the Internet for the task, but because the command “turn on the light” goes from your phone to the vendor’s server (often in China) and only then returns to the bulb three meters away.
This is not an abstract risk. The MyQ garage door manufacturer at some point simply turned off the API for its own clients — devices remained, integrations died. Vendors’ servers close, companies get bought, and cross‑border ping adds seconds to the scenario “entered the room — the lights come on.” Let’s break down by device class what will survive an internet outage, what won’t, and how to build a home that doesn’t need the cloud at all.
Home Assistant divides all integrations into four IoT classes: local push (the device reports events over the local network — ideal), local polling (HA polls the device locally), cloud push and cloud polling (everything goes through the vendor’s server). The class is listed on each integration’s page in the catalog — you should check it before buying a device, not after.
The three paths to locality
Path 1: Zigbee / Z-Wave. Classic local smart home: a separate radio protocol, a coordinator stick in a USB server, Zigbee2MQTT or ZHA in Home Assistant. Plus — complete independence from Wi‑Fi and maximum device compatibility. Cons — you need a server (even a Raspberry Pi) and some initial fuss with pairing.
Path 2: Matter / Thread. A newer standard, local by design: devices communicate over IPv6 directly in your network, control “doesn’t require Internet connection or cloud services” — this is a direct quote from the documentation. Bonus — multi-admin: one device can be added to Home Assistant, Apple Home, and Google Home simultaneously. Honest drawbacks: for Thread devices you need a border router (HomePod mini, Nest Hub, or OpenThread stick), and in complex networks with VLANs and multicast filtering Matter can be finicky. And the paradox of the ecosystem: for devices with good native integration (the same Philips Hue) Matter can offer fewer features than the vendor’s own protocol.
Path 3: Wi‑Fi, but local. Wi‑Fi itself is not a verdict — the verdict is the firmware. Devices on ESPHome/Tasmota (or flashable ones), Shelly with local API out of the box, LocalTuya instead of cloud Tuya — all of this works autonomously. Cons — each device requires individual attention, and reflashing is not available for everything and sometimes requires a soldering iron.
“Without the cloud” doesn’t mean “without remote access.” You can control the home from outside via your own VPN to the apartment — WireGuard on your router or home server handles this without any third‑party servers. On our forum there’s a full roadmap for a home server and a breakdown of docker stacks for self-hosting, where Home Assistant is naturally integrated.
It’s worth acknowledging the price: a local smart home requires a hub, some administration, and an intentional hardware choice. A cloud-enabled device “works out of the box” only as long as the cloud works — you pay not with money, but with dependence. Open Home Foundation frames this as “protect your privacy, wallet, and the planet by choosing products that work locally and will last ten years and more” — and provides a simple test of a cloud vendor’s resilience: does it have a clear business model that will survive ten years.
A pre-purchase checklist for any smart device: 1) find its integration in the Home Assistant catalog and check the IoT class — opt for local push/local polling; 2) for cameras — verify RTSP/ONVIF availability; 3) for Wi‑Fi devices — look for mentions of ESPHome/Tasmota/local API; 4) if the device only works through the vendor app and is labeled cloud — consider it as temporary use until the server closes.
Sources
- Matter in Home Assistant — official documentation
- Zigbee2MQTT — list of supported devices
- Open Home Foundation: How to judge devices for your home
- Catalog of Home Assistant integrations with IoT classes
Have you conducted such a stress test yourself? What failed first — and were you able to migrate it to local setups afterward? Especially interested in LocalTuya: which devices agreed to work without their native cloud?