Local vs cloud control: the five places a command gets processed

Why "is it local?" is the wrong question#

Ask a vendor whether a product works locally and you will get a yes, because almost everything is local at some layer. A Wi-Fi plug is local in the sense that it holds an IP address on your network. That tells you nothing about whether the app can reach it when your cable modem is down.

The useful question is narrower: for this specific action, which machine makes the decision, and what has to be reachable for that machine to hear about it? Every other reliability property falls out of the answer. Latency is the sum of the hops. Outage behavior is whether any hop crosses your router's WAN port. Shutdown risk is how many companies own a hop. Privacy exposure is how many of them write the event to a disk they control.

Most homes use all five locations at once, often for the same physical light.

The five processing locations#

1. Device to device: binding and association#

This is the floor, and nothing beats it. In Zigbee, a binding writes an entry into the remote's own binding table naming a target device and cluster. Press the button and the remote transmits a command addressed straight at the bulb. No coordinator is consulted, no rule is evaluated, no packet leaves the 802.15.4 radio. Zigbee2MQTT's documentation states the consequence plainly: a binding works even when the coordinator and the home automation software are down.

Z-Wave calls the same idea an association. Matter has an analogous concept in group messaging: a controller writes group membership to the devices and one multicast command addresses the whole group, which is what should prevent the "popcorn effect" where grouped lights turn on one by one. How well that works still varies by controller in 2026.

The cost of binding is expressiveness. A bound remote does one thing to one set of targets. It cannot check whether it is after sunset or whether anyone is home. That is precisely why it never fails, and why the controls people reach for when they are annoyed are the ones worth binding.

2. A hub on your LAN#

The sensor reports to a hub, the hub evaluates a rule, the hub sends a command. This is how Hubitat, Home Assistant, Homey Pro and Apple Home with a HomePod or Apple TV work, and how SmartThings Edge drivers execute on the hub rather than in Samsung's cloud.

Latency is two radio hops plus rule evaluation: small, not zero, and it grows with mesh depth and rule complexity. This is the sweet spot for almost everyone, because you get real conditional logic and it still runs with the WAN port unplugged. Apple documents that a home hub is what runs automations and enables remote access, which is why an Apple household without one has no automation at all.

Two things still break it. The hub is a single box with a power supply and usually a memory card or eMMC that wears out. And the hub being local does not make your access to it local, which is rung three.

3. Your phone, on your LAN#

Apple's Home app talks to a HomeKit or Matter accessory directly over your Wi-Fi, and Home Assistant's app connects to your server's local address. Matter is designed this way: controller and device hold shared credentials in a fabric and talk over local IP, which is why the CSA lists local connectivity as a core property of the standard.

The catch is that an app is software with an account behind it, and account software wants a login server. This failure is the least intuitive one here, so it is worth stating directly: a platform whose automations run locally can still leave you unable to open the app during an outage. Homey Pro owners report exactly this, a mobile app that periodically needs internet access to reauthorize, which is why it scores half marks for local app control in our Local Control Index. The automations kept running. The owner could not see them.

The other common failure on this rung is discovery. Your phone finds Matter and HomeKit accessories over mDNS multicast, and home networks are full of things that quietly eat multicast: client isolation on a guest SSID, aggressive IGMP snooping, a VLAN with no reflector. Home Assistant's Matter documentation warns about exactly this. See the network setup a smart home wants.

4. One vendor cloud#

Your app sends the request to the internet. A server authenticates it, decides what to do, and pushes a command back down to the device, which holds an outbound connection open for exactly this purpose. That is the standard architecture for cheap Wi-Fi devices and for every camera with a subscription attached.

Latency is now dominated by internet round trips rather than radio time, which is why cloud control feels different rather than merely slower: usually fine, occasionally terrible, because the tail depends on congestion, DNS and how busy the vendor's region is. It also means the vendor sees every command.

Cloud processing is not automatically a mistake. It is how a $20 plug ships without a hub and how firmware reaches a device nobody thinks about. It becomes a mistake when it is applied to something with a physical consequence you cannot wait for: a lock, a garage door, the only light in a stairwell.

5. Two clouds, chained#

You say "Alexa, turn on the lamp". The Echo streams audio to Amazon. Amazon parses it, matches the device, and calls the lamp maker's cloud API, which looks up your account, finds the lamp's open session and sends the command. Three companies, four network legs, two authentication systems, and one OAuth token between them that can and does expire.

This is where the classic "it worked yesterday" failure lives. Nothing is broken. The link between two accounts has gone stale, usually after a password change, an app reinstall, or a vendor migrating an API. Amazon retired its Smart Home API v2 on 1 November 2025 and Routines Kit on 13 May 2026, and every integration built on either had to be rewritten or it stopped working. Chaining also multiplies outage exposure: every company in the chain has to be up simultaneously, and you can see none of them.

Where the seven platforms land#

Automation execution and app access are separate properties, and most platforms are stronger on one than the other. Apple and Homey run rules locally and lean on the cloud for access and voice. Google's local Matter control covers lights, plugs and switches only. Alexa keeps devices reachable at the protocol level but does nothing useful in the Alexa layer without the internet, a position that hardened when Amazon removed on-device voice processing on 28 March 2025 with no opt-out. Full rubric at /methodology/.

Latency, honestly#

Do not trust a latency number without a mechanism behind it, including ours. A single 802.15.4 hop carries a small frame at 250 kbit/s and waits for an acknowledgement, so radio time is a small fraction of the total and the delay you perceive is device-side: how fast the bulb's firmware acts, and whether a dimmer ramps. That is why bound Zigbee remotes feel instant. A hub adds another radio hop plus rule evaluation, and a mesh adds a hop per relay, which is one reason automations run late as a mesh grows.

Cross the WAN and the floor changes: you pay a round trip to a data center and back for each cloud in the chain, which no amount of good engineering removes. Sleepy battery devices add their own delay, because a sleepy end device has its radio off between polls and a command waits at its parent until the child wakes. That is a feature, not a fault, and it is why sensors report but rarely receive.

How to move down the ladder#

You do not have to rebuild anything. In rough order of payoff per hour spent:

1. Bind the physical controls. Zigbee bindings and Z-Wave associations on the switches people actually touch. Which radio for which job covers what supports it.
2. Get automations onto a hub you own. Even within Apple or SmartThings this is mostly a matter of owning the right box.
3. Prefer Matter or Thread devices over cloud Wi-Fi for anything with a physical consequence. Matter's control path is local by design, a genuine change from the Wi-Fi cloud generation it replaces.
4. Replace the two-cloud paths. A device that only reaches your platform through a vendor integration is on rung 5. A bridge that exposes it locally moves it down two rungs at once.
5. Keep a manual path. Wall switches that still switch, a lock with a key. Treat it as a design rule, not a fallback.