Reliability: keeping a smart home working
A light switch has a service level agreement of about forty years. Most smart home products are not built to that standard, but you can get close.
The one question underneath everything#
When you tap a button and a light turns on, something somewhere decided to send that command. The single most useful thing you can know about any smart home product is where that decision happens. There are only five candidates, and they range from a radio chip inside a wall remote to a chain of two commercial data centers.
That location determines latency, what happens during an outage, what a vendor can take away from you, and how much of your household's activity is written down on someone else's disk. It is one question with four consequences, which is why it comes first: local vs cloud control is the mental model page for this entire cluster, and the rest of these pages are applications of it.
The uncomfortable part is that "local" is a spectrum, not a checkbox. A platform can execute automations on a box in your hallway and still lock you out of the app during an outage because the app wants to reauthorize against a login server. A device can speak a fully local protocol and still be useless when its manufacturer turns off the cloud service that its app depends on. We score these distinctions rather than argue about them: the Local Control Index breaks seven platforms into eight criteria, with the rubric published at /methodology/.
What is in here#
- Local vs cloud control, explained properlyBinding, hub on the LAN, phone on the LAN, one vendor cloud, two chained clouds. What each rung costs in latency and in failure modes.
- What still works when the internet goes downDevice class by device class and platform by platform, what keeps working with the WAN port unplugged, and the mechanism behind each answer.
- When a smart home company shuts downThe 2025 and 2026 shutdown record, what survived each one and why, plus the signals that show up months before the announcement.
- Smart home privacy without the paranoiaDevice class by device class: what leaves the house, what it reveals, and the settings, purchases and network moves that reduce it.
- Securing a smart home networkCredentials, exposed services, firmware and segmentation, ranked by what attackers actually do rather than by what sounds alarming.
- The network setup a smart home wantsThe build: separate IoT SSID, band steering, VLANs and the mDNS consequence, IPv6 for Matter, and DHCP reservations for the things that matter.
Read in this order#
- Local vs cloud control gives you the five processing locations and what each costs you in latency and failure surface. Everything else assumes it.
- What still works when the internet goes down turns that model into a device-by-device and platform-by-platform table. If you only read one page before buying, read this one.
- When a smart home company shuts down covers the slower failure, using Belkin's Wemo shutdown on 31 January 2026 as the worked example, and gives the warning signs that show up months ahead.
- Smart home privacy without paranoia is about what leaves the house, class of device by class of device, and which of it you can turn off.
- Securing a smart home network separates what actually gets attacked from what people worry about.
- The network setup a smart home wants is the practical build: an IoT SSID, band steering, VLANs, mDNS, IPv6 and DHCP reservations.
Three ideas that do most of the work#
Binding beats automation. A Zigbee wall remote bound directly to a bulb sends its command over the radio to the bulb, with no hub in the path at all. The Zigbee2MQTT documentation is blunt about the payoff: a binding works even when the coordinator and the home automation software are down. Z-Wave associations do the same job. Nothing else in the smart home comes close to that reliability, because there is nothing left to fail except the two devices and the air between them. Zigbee and Z-Wave both cover the mechanism.
Keep the physical control working. The most common reliability complaint is not a dead server, it is a smart bulb behind a wall switch that somebody turned off. Choosing smart switches over smart bulbs in high-traffic rooms removes a whole category of failure, and the general principle appears throughout automation design: the manual path must always work, even when the clever path does not.
The failure is usually your LAN, not the product. Matter and Thread rely on IPv6 and mDNS multicast moving freely around your network. Home Assistant's own Matter documentation warns that router settings meant to optimize multicast traffic will break device discovery, and Google requires IPv6 on your router for Matter to work reliably at all. A device that pairs and then goes unresponsive is far more often a multicast problem than a broken device. Start at device shows as unresponsive or Thread troubleshooting before you return anything.
Where the platforms actually sit#
| Platform | Score /100 | Local app control on the LAN | Local automation execution | Survives a vendor shutdown |
|---|---|---|---|---|
| Home Assistant | 100 | 20 / 20 | 20 / 20 | 15 / 15 |
| Hubitat Elevation | 87.5 | 20 / 20 | 20 / 20 | 15 / 15 |
| Homey Pro | 62.5 | 10 / 20 | 20 / 20 | 7.5 / 15 |
| Apple Home | 60 | 20 / 20 | 20 / 20 | 7.5 / 15 |
| Samsung SmartThings | 30 | 10 / 20 | 10 / 20 | 0 / 15 |
| Google Home | 15 | 10 / 20 | 0 / 20 | 0 / 15 |
| Amazon Alexa | 5 | 0 / 20 | 0 / 20 | 0 / 15 |
The spread is wider than the marketing suggests. Two platforms run everything on hardware you own. Two run automations locally but depend on the cloud for voice and remote access. Two are cloud-first by design, which is a legitimate engineering trade for voice quality and setup simplicity, but it is a trade, and it should be a decision rather than a surprise. Google's outage on 18 August 2026 lasted about twelve hours and left Nest hubs unresponsive, which is what that trade looks like on a bad day.
If you are still choosing, the seven platforms compared puts local control next to everything else that matters, and the platform picker weights it against your actual requirements.
Tools in this area#
- Outage audit. Build your device list, get back what keeps working when the internet drops and what does not.
- Exit cost calculator. Estimate what leaving a platform would cost you in hardware and hours, before you are forced to find out.
What this cluster will not tell you#
It will not tell you that the cloud is bad. A cloud service is how you get a doorbell notification on your phone at work, how voice assistants understand a sentence they have never heard, and how a $25 plug can ship without a hub. It will also not tell you that a fully local setup is free: Home Assistant and Hubitat trade money and vendor obligation for your own time and attention.
What it will tell you is exactly which parts of your house depend on which service, so the failure is one you already planned for. That is the whole goal. See the pre-purchase checklist for the nine questions that keep the list short.
Primary sources
Specification and vendor documentation we checked while writing this page. Where a claim depends on firmware behaviour rather than a published spec, the page says so inline.