Local vs cloud control
Local control means your hub talks to devices directly on your home network, so automations run with no internet — Matter, Zigbee, Z-Wave, and Thread are all local protocols. Cloud control means commands route through a vendor’s servers, adding latency and a dependency: if the service is down or discontinued, so is your smart home.
The protocol is only half the story; the platform decides where the logic runs. Home Assistant, Hubitat, and Homey Pro run automations on the hub itself, fully local. Apple Home runs Matter and HomeKit control locally through a home hub. Alexa, Google Home, and SmartThings are hybrids as of mid-2026 — device control may be local (SmartThings runs many automations on the hub; Alexa and Google control Matter devices locally) while voice processing and some routines still need the cloud. Wi-Fi devices tied to a vendor app, including much Tuya-based hardware, are often cloud-only unless rescued by a local integration.
Why it matters: latency (a local motion-to-light automation fires in tens of milliseconds; a cloud round-trip takes one to several seconds), resilience during internet outages, privacy, and longevity — cloud shutdowns have bricked entire product lines, while a local Zigbee sensor from 2015 still works today. Our hub pages note each platform’s local-control story.
| Hubs in this dataset with local control | 17 of the 32 we track |
|---|---|
| Local automation latency | Tens of milliseconds from sensor to light |
| Cloud round trip | Typically several hundred milliseconds to a couple of seconds |
| Local by protocol | Matter, Thread, Zigbee, and Z-Wave all carry commands without a server |
| Fully local hubs | Home Assistant, Hubitat, Homey Pro, SONOFF iHost, and any Zigbee2MQTT or ZHA coordinator |
| Usually cloud-executed | Alexa routines, Google Home automations, most SmartThings routines, Tuya |
Four things that can be local, and they are independent
Control is whether tapping a button in the app sends a packet across your LAN or across the internet and back. Automation execution is whether “motion after sunset turns on the hall light” is evaluated on a box in your house or on a server in a data centre. Administration is whether you can add, rename, and reconfigure devices with the internet down. Remote access is the opposite question — whether you can reach the house from outside without a vendor relay.
A platform can be local for one of these and cloud for another, and marketing blurs them deliberately. Alexa controls a Matter plug locally but evaluates the routine that triggers it in the cloud, so the plug responds instantly when you tap it and not at all when the internet is down. SmartThings runs a subset of automations on the hub and the rest on servers, without making the split visible.
The test that cuts through it: pull the WAN cable, wait a minute, then trigger a motion sensor. Whatever still happens is local. Do it before you build anything you depend on, not after.
The protocol is only half the answer
Matter, Thread, Zigbee, and Z-Wave are all local protocols — no cloud is required for a command to reach a device on any of them. That fact is often presented as if it settled the question. It does not, because the automation engine sits above the protocol. The same Matter plug is fully local in Apple Home, Home Assistant, Hubitat, or Homey Pro, and cloud-gated in Alexa or Google Home.
Wi-Fi devices are where the variance is widest. Some expose a documented local API and are genuinely local — Shelly hardware, anything running ESPHome or Tasmota, Hue’s bridge API. Much of the Tuya-manufactured market is cloud-only in its stock firmware, and the local integrations that exist for it depend on extracting keys and tend to break with app updates.
The awkward middle is voice. Even the most local household still sends voice to a vendor for recognition on Alexa, Google, or Siri, so a house that keeps all its logic local will still lose voice control in an outage. On-device voice options exist on some platforms, but they remain a niche.
What cloud dependence actually costs
Latency is the cost you feel daily. A local motion-to-light path completes in tens of milliseconds, fast enough that walking into a room and the light being on feel like one event. A cloud round trip runs from a few hundred milliseconds to a couple of seconds, which is exactly the delay that makes people reach for the switch — and that half-pressed switch is how smart lighting installations die.
Longevity is the cost you feel once, badly. Cloud shutdowns have bricked entire product lines: Revolv’s hub was switched off in 2016 after Nest acquired it, Lowe’s ended Iris in 2019, Wink moved existing owners behind a mandatory subscription in 2020, and Insteon’s servers went dark abruptly in 2022. In every case, local-protocol devices could be rescued by another hub and cloud-only ones could not. A Zigbee sensor from 2015 still works today because nothing had the authority to switch it off.
Then privacy and resilience. Local execution keeps occupancy patterns — when you wake, when the house is empty — inside the building rather than in a log somewhere. And an internet outage is exactly when you want the lights and locks to behave normally, which is the argument for keeping time-critical automations on a local layer even in a household that is otherwise happy in Alexa or Google Home.
Frequently asked questions
Which smart home hubs work without the internet?
Home Assistant, Hubitat, Homey Pro, and SONOFF iHost run control and automations entirely on the hub. Apple Home is local in practice once a home hub is set up, with Siri as the exception. Philips Hue, Aqara Hub M3, and Bosch Controller II are local within their own ecosystems. Alexa, Google Home, SmartThings, Homey Bridge, and Tuya gateways execute most routines in the cloud.
Is Matter local or does it use the cloud?
Matter control is local by design — commands travel over your LAN or Thread mesh directly to the device, authenticated with certificates rather than accounts. What is not guaranteed is where automations run. A Matter device in Alexa or Google Home still waits on their servers for a routine to fire, while the same device in Apple Home or Home Assistant is fully local.
Do Zigbee and Z-Wave work without internet?
The radios do — a Zigbee or Z-Wave command never touches the internet. Whether your house keeps working depends on the hub above them. A Hubitat or Home Assistant setup carries on normally; a cloud-dependent hub with a Zigbee radio can still leave you with devices that are perfectly reachable and an app that refuses to talk to them.
Does Apple Home work without internet?
Mostly yes. With a home hub — an Apple TV or HomePod — control and automations run on your local network, so schedules, sensor triggers, and the Home app all keep working while the WAN is down. Siri voice requests need the internet, and so does remote access from outside the house.
How can I tell whether a device is cloud-dependent before buying it?
Check the protocol first: Matter, Thread, Zigbee, and Z-Wave devices are local at the radio. For Wi-Fi devices, look for a documented local API or open firmware support. The reliable signal is whether the device works with a local platform — a device supported by Home Assistant, Zigbee2MQTT, or Z-Wave JS has a life beyond its manufacturer’s servers.