If
your Google Home routine is supposed to turn on the lights “instantly” when
there’s motion, but you notice a delay specifically when both a Thread and a Zigbee
motion sensor report at the same time, you are running into a mix of network
paths, cloud processing, and event handling logic inside Google’s automation
engine.
This
isn’t a bug in one single device, but a sideeffect of how Google Home stitches
together different smart home standards.
How Google Home Actually Handles Motion
Triggers
Before
looking at the delay, it helps to understand what’s happening from the moment
you move until the routine runs.
1. The path for a Thread motion sensor
A
typical Threadbased motion sensor in Google’s ecosystem works like this:
1.
Motion detected by the sensor.
2.
The event travels over the Thread mesh to a Thread Border Router (for example:
Nest Hub 2nd gen, Nest Wifi Pro, some Nest routers).
3.
The border router forwards that event to the Google Home platform, often locally,
and then to the Google automation engine (cloud or local, depending on your
region and account features).
4.
The automation engine decides which routine to run and sends commands back to
your devices (lights, plugs, etc.).
This
path is usually fast and mostly local, which is why Thread/Matterbased motion
automations can feel very snappy.
2. The path for a Zigbee motion sensor
Most
Google Home setups do not use Zigbee directly on a Nest Hub. Instead, Zigbee
sensors are connected to a separate hub:
Philips Hue Bridge
SmartThings Hub
Aqara Hub
Another vendor’s Zigbee gateway
The
path now looks like this:
1.
Motion detected by the Zigbee sensor.
2.
The event travels over the Zigbee network to the vendor’s hub.
3.
The hub sends that event either:
Locally
to the light (if you automate inside that hub’s app), or
To
the cloud of that vendor (Hue Cloud, SmartThings Cloud, etc.).
4.
From there, it’s forwarded via a cloudtocloud integration to Google Home.
5.
Google Home’s automation engine runs your routine and sends commands back to
your devices.
This
path is usually slower and more variable, because it often depends on:
Vendor cloud latency
Internet latency between the vendor and
Google
Any throttling or rate limiting in the
integration
3. Where Google routines are executed
Historically,
almost all Google Home routines were executed in the cloud. Google has started
adding more local processing (especially with the revamped Google Home app and
Script Editor), but in many realworld setups:
Your trigger may be received locally or via
cloud.
Your routine logic may still be partly or
fully cloudbased.
Your actions (like turning on a WiFi or Zigbee
light through a hub) may again go through other clouds.
In
short: a “simple” motion routine can involve multiple hops, even if one of the
sensors is Thread.
What Happens When Two Sensors Fire at Once?
Now
to your specific scenario: both a Thread and a Zigbee motion sensor detect
motion at roughly the same time and are used as triggers for the same Google
Home routine.
Several
things can happen inside Google Home that explain the delay.
1. Debounce and deduplication windows
To
avoid:
Running the same routine twice, or
Creating loops where one routine triggers
another in rapid succession,
Google
Home likely uses a short debounce window. In practice, this can look like:
Google Home receives a motion trigger from the
Thread sensor.
Within a fraction of a second to a few
seconds, it also receives a second trigger from the Zigbee sensor for the same
routine or same room.
Instead of executing the routine twice, Google groups these triggers into one “event window” and runs the routine once, after a short internal delay.
That
grouping / deduplication window is often what you perceive as “Google Home is
slow when both sensors are active.”
2. Event queueing and cloud roundtrips
When
you mix Thread (often local) and Zigbee (often cloudbased):
The Thread motion event normally reaches
Google’s automation system first.
The Zigbee event arrives a bit later, after:
Zigbee
→ hub → vendor cloud → Google cloud.
Inside
Google’s systems, triggers are often placed into queues and evaluated by worker
services. When many devices and clouds are involved, Google may:
Wait briefly to see if multiple triggers for
the same routine arrive.
Normalize conflicting or duplicate
events.
Then execute the final set of actions once.
That
waiting and queueing can add 1–4 seconds quite easily, especially during busy
times or when a thirdparty cloud is slow.
3. “Slowest hop wins” behavior
If
your routine depends implicitly on both devices (for example: lights controlled
by Hue via Zigbee and power monitors over Thread), the routine’s overall speed
tends to match the slowest part of the chain.
Examples:
Thread motion sensor is super fast, but your Zigbee
lights through Hue have cloud delay → overall response feels slow.
Zigbee sensor is fast locally in its own hub,
but Google only sees the event after cloud sync → routine is held back by the
vendor’s cloud.
Even
if the Thread motion event arrives quickly, the full routine may not complete
until all actions and conditions (including devices managed by other clouds)
are resolved.
Other Sources of Delay You Might Be Seeing
Apart
from multisensor triggering, a few additional factors often amplify the
problem:
1. Sensor hardware behavior
Some motion sensors have a builtin delay or
“cooldown” (e.g., they only rereport motion every X seconds).
Some are optimized for battery life, not
speed, and intentionally delay or batch reports.
If your Thread and Zigbee sensors have different internal timings, their events arrive at different moments, increasing the chance that Google will see “multiple triggers in a short span” and apply more internal smoothing.
2. Vendor hubs and integrations
Each
hub or platform can add its own delay:
Philips Hue: fast locally to Hue lights,
slower when going via Google / Assistant.
SmartThings / Aqara / Tuya: may buffer or
throttle events before pushing to Google.
Some integrations are still pollingbased
rather than purely eventdriven, causing inconsistent latencies.
3. WiFi and network congestion
Even
if Thread is rocksolid, your WiFi, router, or internet connection might
introduce:
Delays sending triggers to the cloud
Delays receiving Google’s commands back to
your lights or switches
This
is especially noticeable if the routine action is on WiFi lights (e.g.,
Yeelight, Tapo, older smart bulbs) rather than on the same local network as the
trigger.
How to Reduce Routine Delays with Mixed Thread
and Zigbee Sensors
You
usually can’t control Google’s internal automation engine, but you can design
your setup to minimize the situations that cause debounce and crosscloud
delays.
1. Use one “primary” technology per room for
automations
If
possible:
Choose either Thread/Matter or Zigbee/cloud
per room for timecritical automations.
Use the other standard only for backup or noncritical
tasks (temperature logging, secondary illumination, etc.).
For
example:
Living room lights = Matter over Thread
Motion trigger = Thread motion sensor
Zigbee sensor in the same room = backup for
vendorspecific automations, not a direct trigger in Google Home
This
reduces the number of simultaneous triggers Google must merge or debounce.
2. Keep realtime motion logic on the local hub
when possible
If
your Zigbee hub supports it (Hue, SmartThings, Aqara, etc.):
Create the fastest, most timesensitive
automation inside that hub, not in Google Home.
Example: Hue motion sensor → Hue Bridge → Hue
lights (no Google involved).
Use Google Home only for:
Voice
control (“Hey Google, turn off living room”)
Higherlevel scenes and noninstant automations
This
way, even if Google is slow to react, your core motion ↔ light behavior is
immediate.
3. Prefer Matter/Thread devices that can run
fully local
When
buying new devices:
Prioritize Matter over Thread bulbs, switches,
and sensors that:
Talk
directly to your Nest Hub / Thread Border Router
Support local execution of Google routines (as
Google expands this).
A
full Matter/Thread path can look like:
Motion
(Thread) → Border Router (Nest Hub) → Local Google routine → Light
(Matter/Thread or LAN)
This
drastically reduces the cloud hops and makes delays much less noticeable.
4. Simplify Google routines that share
multiple motion sensors
If
you need both Thread and Zigbee sensors as triggers in the same Google routine:
Use “Any of these devices detects motion”
rather than complex logic requiring both.
Avoid chaining multiple routines that may retrigger
each other.
Test with only one sensor enabled and then add
the second to see exactly when the delay appears.
By
simplifying triggers, you reduce the chance that Google’s automation engine
will spend extra time reconciling competing events.
5. Use the Google Home Script Editor for more
control
If
available in your region/account:
Use the Google Home Script Editor to:
Control conditions more precisely.
Add
timebased throttling yourself (e.g., “ignore new motion events within X
seconds”).
Separate Threadbased and Zigbeebased
automations cleanly.
A
wellstructured script can sometimes avoid internal Google “guessing,” because you
explicitly define how multiple triggers should be handled.
When a Delay Is Actually Normal
Even
with a perfect setup, a 1–2 second delay is very common for:
Cloudbased routines
Crossplatform actions (Google → Hue → Zigbee),
or
Mixed technology environments (Thread + Zigbee + WiFi)
If
your delay is in the 3–6 second range only when both sensors trigger together,
that strongly points to:
Debounce / deduplication behavior in Google
Home, plus
Extra latency from the slowest device or cloud
path in the chain.
The
most effective strategy is not “tuning” one sensor, but simplifying your paths
and keeping the realtime logic as local and homogeneous (all Thread, or all
Zigbee inside a hub) as possible.