Automations run late, and how to find the slow hop
A three second light is six or seven handoffs, and usually one of them is doing almost all the damage.
The chain, hop by hop#
Between something happening in the world and a light changing, a command crosses up to seven boundaries. Each has a characteristic cost and a characteristic smell.
| Hop | What happens | Typical scale | How it feels when it dominates |
|---|---|---|---|
| 1. Detection | The sensor's own hardware registers the event, plus any debounce or blind time it enforces | Milliseconds to tens of seconds | Motion is missed entirely, or a re-trigger is ignored |
| 2. Reporting | The device decides to tell someone: on change, or on its next scheduled report | Instant to minutes | Temperature and humidity feel stale, contact sensors feel fine |
| 3. Sleepy wait | A battery device with its radio off waits for its next poll before it can send or receive | Under a second to hours | Commands to the device are slow, events from it are fast |
| 4. Mesh transit | Thread, Zigbee or Z-Wave hops toward the coordinator or border router | Milliseconds per hop | Rarely dominant. Retries under congestion are the exception |
| 5. Hub evaluation | The controller matches the event to your rules and decides what to do | Milliseconds to a few hundred | Everything is uniformly slow, including simple rules |
| 6. Cloud round trip | The event leaves your house, is processed, and a command comes back | Hundreds of milliseconds when healthy, seconds when not | Latency varies wildly and gets much worse during outages |
| 7. Second cloud round trip | The action device belongs to a different vendor, so the command goes out again | Same again | Two vendors in one automation, and the delay roughly doubles |
The important asymmetry is hop 3. A sleepy device sends immediately when something happens, because it wakes up to transmit. It receives only when it polls. That is why a battery motion sensor triggers instantly while a battery lock takes seconds to respond to a command, using the same radio in the same house.
Matter names this behavior directly. Its intermittently connected device model has a short idle mode, polling at most every 15 seconds, and a long idle mode that is slower still, added in Matter 1.3, with idle durations that can run up to 18 hours. Zigbee end devices have their own poll intervals, and battery Z-Wave devices accept configuration only during a wakeup interval you set. Battery life and responsiveness are the same dial, and sensors explains where to set it.
The hops people get wrong#
Mesh hops. Thread's protocol ceiling is a route cost of 124, which is 31 hops at a link cost of 4, and Z-Wave classic mesh allows up to 4. In practice home meshes are two or three hops and each costs milliseconds. If your automation is three seconds late, the mesh did not do it. Congestion is the exception: when a radio cannot find the channel clear it retries, and retries do add up. That shows in logs as ChannelAccessFailure in OpenThread or MAC_CHANNEL_ACCESS_FAILURE in Zigbee, and it means interference, not distance. The channel planner is the fix.
The automation engine. Local engines evaluate rules in milliseconds. If everything is slow including a rule with one trigger and one action, suspect the hub's health or a cloud dependency you did not know about, not the complexity of your logic.
Sensor blind time. Many motion sensors enforce a cooldown after a trigger to save battery, and some let you configure it. A light that fails to come back on after you stood still is usually hitting that, not a slow automation.
The two cloud round trips#
This is where most multi-second delays live, and it is entirely a design choice you made when you bought things.
A cloud automation looks like this: the sensor reports to its vendor's cloud, the vendor's cloud tells your platform's cloud, your platform evaluates the rule, sends a command to the target's vendor cloud, and that cloud sends it to the device. Two internet round trips, four service boundaries, and every one of them can be slow or down.
Platform behavior varies a lot. Google's local Matter control covers lights, plugs and switches only, with routines and voice remaining cloud side. Alexa maps Matter clusters onto cloud-side capability interfaces. Apple Home and Hubitat run automations on local hardware. Home Assistant is local by default. Local versus cloud control maps all five places a command can be processed, and the Local Control Index scores the platforms against a published rubric.
The popcorn effect#
You turn on a group of eight lights and they come on one after another, over a second or two, like popcorn. This is one of the most reported Matter complaints, and it is not a performance problem in the usual sense.
The cause is that many controllers send individual unicast commands, one per device, in a loop. Each command is a separate transaction that has to be acknowledged. Eight devices means eight sequential exchanges, and you can watch them happen.
The fix exists in the protocol. Group commands use IPv6 multicast with a shared group ID and a shared group key, so one transmission addresses every member at once. Matter also supports wildcard paths, so a single action can address many endpoints. Both are standard, and neither is guaranteed to be used by the controller you own.
What you can actually do:
- Use your platform's native group or room object rather than listing individual devices in the automation. Controllers that implement group commands use them for groups, not for ad hoc lists.
- Prefer a single bridged group where the bridge handles it. A Hue Bridge switching a room is one command to the bridge, not eight.
- Consider Zigbee binding or Zigbee groups for lighting you control from a wall switch. A bound switch talks straight to the bulbs, with lower latency, and it keeps working when the coordinator is down.
- Reduce the group size if none of that is available. Four lights popcorn less visibly than twelve.
Smart lighting that stays compatible covers the bulb, switch and fixture choice underneath this, and Matter bridges explains what a bridge does and does not pass through.
Measuring the slow hop#
Guessing is the reason people spend weekends on this. The method below narrows it down in a few minutes with no special tools.
Time the manual command first
Open your app and toggle the target device by hand while watching it. This measures hops 5 through 7 only: hub, cloud, device. If the manual toggle is already slow, the trigger side is innocent and you are looking at a cloud path or the device itself.
Time the trigger separately
Trip the sensor while watching its state in the app or in your hub's event log. The gap between the physical event and the state change is hops 1 through 4. A contact sensor should be effectively immediate. If it is not, look at the sensor's reporting configuration and its parent device.
Read timestamps rather than counting seconds
Any hub with a log gives you the real numbers. Home Assistant's logbook and trace view timestamp the trigger, each condition and each action separately, which turns this whole exercise into arithmetic. If your platform has no log, this is a legitimate reason to add a local hub as an observer.
Compare a local target with a cloud target
Build a throwaway automation with the same trigger and a different action: one that hits a device you know is local, and one that hits a cloud device. The difference between the two is your cloud round trip, measured rather than assumed.
Test with the internet disconnected
Pull your WAN connection for two minutes and run the automation. If it still fires, everything in the path is local. If it stops, you have found a cloud dependency you may not have known about. What still works when the internet goes down lists what to expect per device class.
Check the target's reachability, not just its speed
A device that is slow every time behaves differently from one that is slow occasionally. Intermittent slowness with occasional failures is usually a radio or discovery problem wearing a latency costume, which is a device shows as unresponsive rather than a delay problem.
Design choices that remove delay permanently#
- Keep trigger and action on the same local system. A Zigbee motion sensor and a Zigbee bulb on one hub with a local rule is the fastest arrangement most homes can build, and it survives an outage.
- Do not put battery devices on the receiving end of a time-critical command. A sleepy device cannot hear you until it polls. Lights and locks that must respond instantly should be mains powered.
- Avoid crossing vendors mid-automation. Every vendor boundary is a potential cloud round trip. Running two platforms on purpose covers how to structure this deliberately.
- Use groups, not lists. It is the difference between one multicast transmission and twelve sequential ones.
- Fail safe. A rule that assumes the light responded and moves on is more robust than one that waits for confirmation. Automations that people do not turn off covers the patterns.
Why is there a delay between motion detection and my lights turning on?
Time the two halves separately. If the sensor's state changes instantly in your app, the delay is downstream: hub evaluation, or more likely a cloud round trip to the light's vendor. If the sensor state itself is slow to change, the delay is the sensor's detection, its blind time, or its reporting behavior.
Why do my smart lights turn on one at a time?
That is the popcorn effect. The controller is sending one unicast command per bulb in sequence rather than a single group command. Matter supports group commands over IPv6 multicast with a shared group key, and wildcard paths that address many endpoints at once, but not every controller uses them. Use your platform's native room or group object rather than listing bulbs individually.
Are mesh hops making my automations slow?
Almost never. Thread and Zigbee hops cost milliseconds, and typical homes are two or three hops deep. The exception is congestion, where the radio cannot find the channel clear and retries. That shows up in logs as channel access failures, and the fix is channel planning, not topology.
Why is my battery lock slow to respond when my battery sensor is instant?
Because sleepy devices transmit whenever they want and receive only when they poll. A sensor wakes up to report an event, so it looks instant. A lock waiting for a command has to reach its next poll before it hears anything. That asymmetry is designed in, and it is the price of multi-year battery life.
Does local control actually feel faster?
Yes, and the gap is structural rather than marginal. A local command crosses your LAN and a mesh hop or two. A cloud command crosses the internet twice, sometimes four times if the trigger and target belong to different vendors, and it inherits every queue and outage along the way.
How do I measure which part of my automation is slow?
Use timestamps rather than a stopwatch. Compare a manual command against a triggered one to separate the trigger side from the action side, then compare a local target against a cloud target to price the cloud round trip. A hub with a logbook or trace view gives you all of this directly.
Why did my automations get slower after adding devices?
Two likely causes. Airtime: more devices on the same 2.4 GHz spectrum means more retries, which shows in logs as channel access failures. And structure: a group that grew from four devices to twelve popcorns four times as visibly if your controller sends unicast commands per device.
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.