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

 

Many smart home users notice a specific and frustrating problem:

multi-condition automations in Google Home stop working as soon as one of the Matter devices (often a Thread-based sensor, switch, or plug) loses border router access.

The routine might have worked perfectly before. Then suddenly:

• The routine no longer triggers.
• Nothing obvious seems wrong in the Google Home app.
• The only visible clue is that one Matter device shows as “Offline” or “Not responding”.

This is not random. It is the direct result of how:

• Google Home evaluates multi-condition automations, and
• Matter devices depend on a Thread border router for connectivity and state reporting.

This article explains why this failure happens and how to design more robust automations that behave predictably when Matter devices lose border router access.

1. How Multi-Condition Automations Work in Google Home

Google Home supports Household Routines and Home & Away automations that can use:

• Starters / Triggers (e.g., “When motion is detected”, “At sunset”, “When a device turns on”)
• Additional Conditions (e.g., “And only if this light is off”, “And only if it’s after 9 PM”)
• Actions (e.g., “Turn lights on”, “Change thermostat”, “Send a notification”)

A typical multi-condition automation might look like this:

When
– Motion is detected in the hallway
And
– The hallway Matter light is off
Then
– Turn on that light to 30% brightness

For Google Home to run this automation reliably, it must:

9.                  Receive the trigger event (motion detected).

10.              Check every condition (e.g., confirm that the Matter light is off).

11.              If all conditions evaluate to true, run the actions.

If any condition cannot be evaluated, Google generally treats the entire automation as not satisfied and skips the actions. This is exactly where a Matter device losing border router access causes trouble.

2. How Matter and Border Routers Work

2.1 What is a Matter Device?

Matter is a smart home standard that allows devices to be:

• Controlled locally over IP (no cloud dependency required by design)
• Shared across ecosystems (Google Home, Apple Home, Alexa, etc.)
• Run on multiple transports, commonly:
• Wi‑Fi
• Thread (a low-power mesh network)

Many modern sensors, plugs, and switches are Matter over Thread devices.

2.2 What is a Thread Border Router?

A Thread border router is a device that:

• Connects a Thread mesh network to your IP network (Wi‑Fi or Ethernet).
• Lets controllers (like Google Home) talk to Thread-based Matter devices.

In the Google ecosystem, Thread border routers include devices such as:

• Nest Hub (2nd gen)
• Nest Hub Max
• Nest Wifi Pro
• Some Nest Wifi / Google Wifi models with Thread capabilities

When a Matter-over-Thread device loses border router access, it means:

• The Thread device itself might still be powered and on its mesh, but
• It can no longer reach the IP network and thus cannot communicate with Google Home on your phone, speakers, or cloud.

From Google Home’s perspective, that Matter device is now effectively offline.

3. What Really Happens When a Matter Device Loses Border Router Access

When a Matter device loses its border router:

23.              State updates and events stop reaching Google Home.

24.              Google Home cannot:

• Read the device’s current state (on/off, open/closed, etc.).
• Receive real-time events (button presses, motion, contact changes).

25.              The device appears in the app as:

• “Offline”, “Not responding”, or a similar status.

For basic control, this is straightforward:
You tap a tile in the Google Home app and nothing happens because the controller can’t reach the device.

For automations, it’s more subtle but more disruptive—especially when multiple conditions are involved.

4. Why Multi-Condition Automations Fail When a Matter Device Is Offline

4.1 When the Matter Device Is the Trigger

If your automation uses a Matter device as the starter, like:

• “When this Matter motion sensor detects motion…”
• “When this Matter contact sensor opens…”
• “When this Matter switch turns on…”

then:

• The event must travel:
• From the Matter device → across Thread → via the border router → to Google Home.
• If the border router is unavailable or unreachable:
• That event never reaches Google Home.
• The automation never starts at all.

In this case, no matter how many other conditions you have, nothing will happen because:

The routine’s first requirement – the trigger – is never observed.

4.2 When the Matter Device Is a Secondary Condition in AND Logic

A more subtle case is when the Matter device is not the main trigger, but is part of the extra conditions, for example:

Starter:
– When the bedroom motion sensor (non-Matter, e.g., Wi‑Fi) detects motion

Conditions:
– And only if the Matter bedside lamp is off
– And only if the time is after 9 PM

Here:

31.              The primary trigger (bedroom motion) can still reach Google Home just fine.

32.              When motion is detected, Google Home tries to evaluate all conditions:

• Time after 9 PM → can be evaluated locally.
• Matter lamp is off → requires Google Home to read the current state from the lamp.

33.              If the Matter lamp has lost border router access:

• Google Home cannot get the state of the lamp.
• That condition becomes “unknown” or “unresolvable”.

For reliability and safety, Google treats that unresolved condition as not satisfied, so the entire:

motion AND lamp_is_off AND time_after_9pm

expression evaluates to false.
Result: the automation does not run.

This behavior is by design: Google prefers to skip the automation rather than execute actions based on stale or guessed device states.

4.3 How Google Home Handles Offline States Internally

While Google does not publicly document every detail of the internal logic, the observed behavior is consistent with this rule:

• Every condition must be successfully evaluated for a multi-condition automation to run.
• If any condition depends on a device that is offline or unreachable:
• That condition fails.
• The entire automation is skipped.

This prevents:

• Lights turning off in a room you think is empty, when occupancy sensors are offline.
• Security-related automations acting on outdated sensor states.

The downside is what you see: as soon as a Matter device used in any condition loses border router access, the whole multi-condition automation fails.

5. Why Single-Condition Automations Often Seem Less Affected

You may notice that simple automations behave differently, for example:

• A routine with only time-based conditions continues to work, since time does not depend on any device.
• A routine that triggers on one device and only performs actions on an offline Matter device may still start, but the action will fail or be delayed.

Key differences:

40.              No device-based condition:
If an automation does not check the state of any offline Matter device, it can still run even if that device is unavailable.

41.              Actions vs. conditions:

• Conditions must be evaluated exactly at the moment the routine runs.
• Actions are best-effort: if a device is offline, the action may:
• Fail silently.
• Time out.
• Queue until the device reconnects (depending on implementation).

Because multi-condition automations often use several devices as conditions, they have a higher chance of touching at least one offline Matter device, which is why they appear to “break” more easily when border router issues arise.

6. How to Confirm That Border Router Loss Is the Cause

To avoid guessing, you can verify the problem step by step.

6.1 Check the Matter Device Status in Google Home

42.              Open the Google Home app.

43.              Go to Devices (or your home’s room view).

44.              Find the Matter device involved in the automation.

Look for:

• “Offline”, “Not responding”, or a greyed-out tile.
• Delays or errors when you try to control it manually.

If the device is:

• Offline, and
• Used as either a starter or a condition in your multi-condition automation,

then that automation is at high risk of failing exactly as you observe.

6.2 Temporarily Remove the Matter Device from the Automation

49.              Duplicate the routine or create a test version.

50.              Remove the Matter device from:

• Starters, and
• “Only if…” conditions.

51.              Leave the rest (time, presence, other devices) unchanged.

If the modified routine starts working reliably again:

• The failure is strongly tied to the state of that Matter device and its connectivity, not to the logic of the other conditions.

7. How to Fix or Work Around the Problem

You have several practical options, depending on how critical that automation is.

7.1 Improve Border Router Reliability and Coverage

Because Matter-over-Thread devices are heavily dependent on the border router, stability here is crucial:

• Ensure your Nest Hub / Nest Wifi Pro / other border router:
• Has stable power.
• Has reliable Wi‑Fi or Ethernet backhaul.
• Is placed where it has good radio coverage to Thread devices.
• Avoid frequently unplugging or moving border routers.
• Keep firmware up-to-date on:
• Border routers.
• Matter devices.
• For large homes or dense walls, consider adding additional Thread border routers within the same ecosystem to create a more resilient Thread mesh.

Better border router reliability means fewer periods where your Matter devices become unreachable and break automations.

7.2 Avoid Using Unstable Matter Devices as Critical Conditions

If a particular Matter device is often borderline in terms of range or reliability, avoid depending on its live state for key conditions:

• Use it as an action target (e.g., “Turn this lamp on”) rather than as a gate condition (e.g., “Only if this lamp is off”).
• Prefer:
• Time-based conditions
• Presence / location conditions
• States of more reliable Wi‑Fi or hardwired devices

For example, instead of:

When motion is detected
And only if the Matter lamp is off
Then turn it on

You might simplify to:

When motion is detected
Then turn the Matter lamp on to 50%

Most modern smart lamps will simply turn on regardless of their previous state, so checking whether they are off is often unnecessary.

7.3 Split Complex Routines into Multiple Simpler Automations

Instead of one complex multi-condition automation, consider several smaller ones, each less dependent on multiple device states.

For example, replace:

Trigger: motion
Conditions: Matter lamp off AND time after 9 PM
Action: turn on lamp

with:

59.              Routine A:

• Trigger: motion
• Condition: time after 9 PM
• Action: turn on lamp to 30%

60.              Routine B (optional fine-tuning)

• Trigger: lamp turns on
• Condition: none or time window
• Action: adjust brightness/scene

By removing the Matter lamp’s prior state from the condition list, you reduce the chance that an offline or unknown state will cancel the whole routine.

7.4 Use Another Platform or Hub for Critical Local Automations

If you rely on critical automations that must keep working even when Google Home or a specific border router has issues, you can:

• Use a dedicated local automation hub (e.g., Home Assistant with Matter support) as the primary automation engine.
• Let Google Home act mainly as a controller and voice interface, not the main automation host.

In this setup:

• The local hub may have direct Matter control (and may also act as a Thread border router).
• Automations run even if one ecosystem’s border router temporarily fails, provided another router/controller still has access.

This is an advanced option, but it can dramatically improve reliability in complex smart homes.

7.5 Recommission or Relink Problematic Matter Devices

If a particular device frequently appears offline:

• Remove it from Google Home (and from the Matter fabric, if necessary).
• Factory-reset the device following the manufacturer’s instructions.
• Re-add it to Google Home, making sure:
• It pairs through a nearby border router.
• It shows a healthy, stable connection after setup.

Sometimes a problematic initial pairing or weak Thread signal is the root cause of recurring border-router-related issues.

8. Summary

Multi-condition automations in Google Home tend to fail when a Matter device loses border router access because:

• The Matter device becomes offline in Google Home.
• If that device is used as a trigger, its events never reach Google, so the routine never starts.
• If that device is used as a condition, Google Home cannot evaluate its state:
• The condition becomes unresolvable.
• The entire multi-condition expression is treated as not satisfied, and the automation is skipped.
• Google Home deliberately avoids acting on stale or guessed states, prioritizing predictability and safety.

To restore reliable behavior:

• Improve the stability and coverage of your Thread border router(s).
• Avoid using frequently offline Matter devices as critical conditions in automations.
• Simplify or split complex routines so they depend less on live states from Thread devices.
• Consider advanced setups where a local hub handles primary automations.

Designing routines with these constraints in mind will make your Google Home automations more robust, especially in mixed Matter / Thread environments.