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

SmartLife (Tuya) with IFTTT is a popular combination for cloud‑based automations:

If this happens in SmartLife, do that via IFTTT.

However, many users notice a strange pattern: when the Zigbee network behind the SmartLife hub becomes unstable and starts broadcasting route discovery packets, IFTTT routines that depend on those devices:

• Trigger late or not at all
• Run only part of the actions
• Show SmartLife devices as offline or stuck in the wrong state

This behaviour is linked directly to how Zigbee routing works, how SmartLife talks to the cloud, and how IFTTT expects clean, timely events.

This article explains what is happening and how to reduce misfires.

1. How SmartLife, IFTTT and Zigbee Actually Talk to Each Other

To understand why Zigbee route discovery can break routines, you need to see the full path.

1.1 Typical Architecture

A common setup looks like this:

• Zigbee end devices
• Sensors, switches, plugs and bulbs connect via Zigbee to a
• SmartLife (Tuya) Zigbee hub / gateway
• Acts as a Zigbee coordinator
• Connects to the SmartLife cloud over the internet
• IFTTT
• Integrates with the SmartLife cloud via the SmartLife service
• Receives triggers from SmartLife and sends back actions

So a single IFTTT routine such as:

“If this SmartLife motion sensor detects motion, then turn on that SmartLife plug”

actually runs as:

1. Motion sensor → Zigbee → SmartLife hub
2. Hub → SmartLife cloud
3. SmartLife cloud → IFTTT
4. IFTTT → SmartLife cloud → Hub → Zigbee plug

For this to be reliable:

• The Zigbee path to and from the hub must be stable.
• The hub must process Zigbee traffic and cloud traffic without overload.
• Events must reach the SmartLife cloud and IFTTT within a short, predictable time.

Route discovery broadcasts in the Zigbee mesh interfere with this chain.

2. What Are Zigbee Route Discovery Packets?

Zigbee uses mesh routing. Devices send messages via intermediate routers to reach the coordinator (your SmartLife hub). To find or repair routes, Zigbee uses route discovery:

• The source device sends a broadcast “route request” (RREQ) into the network.
• Routers forward the RREQ, building possible paths.
• The destination (or nodes with a known route) sends back a route reply (RREP).
• Each router updates its routing table.

2.1 When Route Discovery Is Triggered

Route discovery often happens when:

• A device first joins the network.
• A router (e.g., a powered plug or bulb) is unplugged, moved, or loses power.
• Radio conditions change (interference, walls, new neighbours’ Wi‑Fi).
• The network is large and constantly healing paths.

In a healthy, mostly static network, route discovery traffic is occasional and light.
In a poorly placed or frequently disturbed Zigbee mesh, route discovery can become:

• Frequent
• Broadcast‑heavy
• A source of temporary congestion on the Zigbee radio

This is exactly when SmartLife + IFTTT routines start to misfire.

3. How Route Discovery Broadcasts Break SmartLife / IFTTT Routines

3.1 Congestion on the Zigbee Radio

Route discovery packets are broadcasts, not unicast messages:

• Every nearby router receives and may forward them.
• In a dense network, this can create short “storms” of Zigbee traffic.

During these bursts:

• The SmartLife Zigbee hub must:
• Process a high volume of RREQ and RREP packets
• Update routing tables
• Handle normal application messages (sensor reports, on/off commands)

This can cause:

• Delayed processing of normal device messages
• Dropped or retried packets from sensors and actuators
• Short windows where the hub cannot decode or forward convenience traffic reliably

If a key event for an IFTTT routine happens in that window:

• The sensor report may be delayed or lost.
• The hub may not push that state change to the SmartLife cloud in time.
• IFTTT never receives a trigger, or receives it too late.

3.2 Hub CPU and Memory Pressure

Many SmartLife/Tuya hubs are low‑power embedded devices with limited CPU and RAM. A surge of Zigbee routing activity can:

• Consume processing time in the Zigbee stack and routing logic
• Delay the tasks that:
• Maintain persistent cloud connections
• Send webhooks or MQTT‑style updates to the SmartLife cloud
• Handle incoming commands from the cloud

Under heavy routing broadcasts, the hub may:

• Fail to send timely device status updates to the cloud
• “Miss” or delay trigger events that IFTTT depends on
• Appear to the cloud as laggy or partially unresponsive

From IFTTT’s perspective:

• The device becomes offline or inconsistent.
• Routines that expect a certain state or a rapid action may time out or report failure.

3.3 Lost or Delayed State Changes in the Cloud

IFTTT does not see Zigbee packets; it sees SmartLife cloud events. When route discovery is active:

• Some attribute reports (e.g., “motion detected”, “switch turned on”) do not reach the hub reliably.
• Or they reach the hub but are delayed enough that:
• The SmartLife cloud updates the device state late,
• IFTTT queries or webhooks see stale information.

This breaks two types of IFTTT logic:

1. Trigger‑based routines
• “If this SmartLife device turns on, then …”
• If the “on” event is delayed or dropped, the routine never fires.
2. Condition‑based logic
• “If SmartLife device A is on and B is off, then …”
• IFTTT evaluates state via the SmartLife API.
• If that state is lagging behind reality, conditions evaluate incorrectly.

Even if the route discovery event only lasts a few seconds, that is often enough for:

• Multiple cloud calls to time out
• One or more routines to misfire

3.4 Increased Error Rates and Rate Limiting

When devices experience poor Zigbee connectivity due to route discovery and topology changes, they may:

• Repeatedly attempt to report their status
• Try to reconnect to the hub
• Trigger the hub to push multiple retries to the SmartLife cloud

On the cloud side, this can:

• Increase the rate of API calls and events per account
• Lead to temporary throttling or rate limiting by SmartLife services

If IFTTT requests state or sends actions during such a period:

• Those requests can be rejected or delayed.
• Routines are seen as failed, even though the local Zigbee network might already have recovered.

3.5 Chain Reactions with Other Wireless Interference

Route discovery traffic often appears when the Zigbee network is already under stress from:

• Wi‑Fi interference (2.4 GHz overlap)
• Physical obstructions after moving devices
• Power cycling of mains‑powered Zigbee routers (bulbs, plugs)

During such times, 2.4 GHz is typically noisy:

• More packet retries overall
• Worse signal‑to‑noise ratio
• Higher latency for every message

This further increases:

• The impact of each route discovery burst
• The chances that simultaneous SmartLife cloud updates or IFTTT triggers will fail

4. Typical Symptoms You Will See

When Zigbee route discovery is affecting SmartLife + IFTTT, you may observe:

• IFTTT applets sometimes complete, sometimes do nothing, with no change in configuration
• SmartLife app shows:
• Devices randomly flipping between online/offline
• Scenes triggering only some of the Zigbee devices
• Delays of several seconds (or longer) between:
• A physical action (pressing a button, motion detection)
• The reaction triggered via IFTTT

Things may appear completely normal at some times of the day and very unreliable at others, especially when:

• You are pairing new devices
• You are frequently turning mains‑powered Zigbee plugs/bulbs on and off at the wall
• The environment has much RF activity (neighbours’ Wi‑Fi, microwaves, etc.)

5. How to Reduce Route Discovery and Improve IFTTT Reliability

You can’t eliminate Zigbee routing, but you can stabilize the mesh so route discovery broadcasts are rarer and shorter.

5.1 Build a Stable Zigbee Mesh

• Use enough mains‑powered Zigbee routers (plugs, in‑wall switches) distributed through your home.
• Avoid relying only on battery devices as repeaters (most do not route).
• Keep routers powered at all times:
• Do not use wall switches to cut power to smart bulbs or plugs that act as routers.
• Avoid frequently moving routers between rooms.

A stable router backbone means:

• Fewer broken routes
• Less need for broadcast route discovery
• More predictable behaviour for all Zigbee messages

5.2 Reduce Zigbee / Wi‑Fi Interference

• Place the SmartLife Zigbee hub away from Wi‑Fi access points and large metal objects.
• On your Wi‑Fi router:
• Choose 2.4 GHz channels that overlap less with your Zigbee channel.
• Consider channel 1 or 6 for Wi‑Fi and a higher Zigbee channel (e.g., 20–25) where possible.
• Keep the Zigbee hub elevated and central to reduce weak links that cause frequent route changes.

Cleaner RF conditions lower packet loss and reduce the need for route discovery broadcasts.

5.3 Avoid Constant Join/Leave Activity

Once devices are paired:

• Do not repeatedly reset and rejoin them unless necessary.
• Avoid automations that power‑cycle Zigbee routers as part of normal operation.
• When adding many new devices:
• Do it in batches and give the network time to stabilize in between.

Every join/leave or major topology change is a trigger for new route discovery. Keeping the network “quiet” structurally makes it much easier for SmartLife and IFTTT to stay in sync.

5.4 Choose Triggers Carefully for IFTTT

If certain Zigbee devices are:

• At the edge of coverage
• Known to be unstable or prone to going offline

avoid using them as critical triggers in IFTTT. Instead:

• Prefer stable Wi‑Fi devices for trigger roles when possible (cameras, Wi‑Fi plugs, always‑online sensors).
• If you must use a particular Zigbee device:
• Place additional routers nearby,
• Or consider relocating the device or hub to improve its link.

The more reliable the link between that device and the hub, the less impact route discovery will have.

5.5 Offload Complex Logic to a Local Automation Platform

For more robust setups:

• Use a local hub (e.g., Home Assistant, Hubitat, openHAB) that integrates directly with your Zigbee network.
• Let that hub run the primary automation logic locally.
• Use IFTTT mostly for:
• Cross‑cloud integrations
• Notifications
• Occasional non‑critical actions

Local automations:

• Do not depend on cloud round‑trips.
• Can better tolerate short spikes in Zigbee routing activity, because they see events directly rather than via the SmartLife cloud.

6. Summary

IFTTT SmartLife routines misfire when Zigbee devices broadcast route discovery packets because:

• Zigbee route discovery creates broadcast storms that consume radio airtime and hub resources.
• The SmartLife Zigbee hub must process extra routing traffic, delaying or dropping normal sensor and switch messages.
• As a result, the SmartLife cloud sees late or missing state changes, so IFTTT:
• Never receives triggers,
• Sees outdated device states,
• Or hits API rate limits and timeouts.
• RF interference, frequent join/leave events, and weak mesh design amplify the problem.

To improve reliability:

• Stabilize the Zigbee mesh with well‑placed routers and constant power.
• Reduce Wi‑Fi/Zigbee interference by careful channel planning and hub placement.
• Avoid depending on unstable devices as primary IFTTT triggers.
• Where possible, move critical automation logic to a local controller and use IFTTT only when cloud involvement is truly needed.

By addressing the underlying Zigbee routing behaviour, you can significantly reduce IFTTT misfires and restore consistency to your SmartLife automations.