Why do my Philips Hue bulbs turn on by themselves after a power outage, even when I set them to “PowerOn Behavior: Last State”?

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.