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

Home Assistant users who rely on Z‑Wave door locks, thermostats, and battery-powered devices often notice a puzzling problem:

• An automation runs,
• Some actions fire correctly,
• But steps involving certain Z‑Wave devices are skipped or never complete—especially devices that are “sleepy” or battery‑powered.

In many of these cases, those devices are FLiRS devices and are behaving exactly as the Z‑Wave specification allows. The problem is not that FLiRS is “broken”, but that the timing and communication pattern of FLiRS often conflicts with how Home Assistant automations are written and evaluated.

This article explains:

• What FLiRS mode is in Z‑Wave
• How FLiRS affects communication timing and state updates
• Why that leads to “skipped” steps in Home Assistant automations
• Practical ways to design automations that remain reliable with FLiRS devices

1. What Is FLiRS in Z‑Wave?

FLiRS stands for Frequently Listening Routing Slave. It is a Z‑Wave power‑saving mechanism used by many battery devices that still need to respond relatively quickly to commands, such as:

• Smart door locks
• Thermostats
• Motorized shades or blinds
• Certain battery‑powered actuators

1.1 How FLiRS Works

A FLiRS device:

• Spends most of its time in a low‑power sleep state, but
• Wakes up briefly at regular intervals (typically every 250 ms or 1000 ms) to listen for a special “beam” signal.

The communication pattern is:

1. The controller (e.g., your Z‑Wave stick) sends a beam signal to wake the FLiRS device.
2. The FLiRS device wakes, listens longer, and accepts incoming commands.
3. After processing the command and sending any required reports, it returns to its low‑power listening schedule.

This allows the device to:

• Respond relatively quickly (hundreds of milliseconds–a few seconds),
• While maintaining good battery life.

However, this timing is very different from mains‑powered Z‑Wave devices, which are awake and always listening.

2. How Home Assistant Automations Expect Devices to Behave

A typical Home Assistant automation (using the Z‑Wave integration or Z‑Wave JS) runs like this:

1. Trigger fires
• Example: “Door unlocked”, “Time is 22:00”, or “Person arrives home”.
2. Conditions are evaluated
• Example: “Only if this lock is unlocked” or “Only if this sensor is off”.
3. Actions are executed in sequence
• Example:
• Turn on porch light
• Lock another door
• Send notification
• Wait until some state changes
• Turn off something else

For automations to feel smooth, Home Assistant implicitly assumes that:

• Devices respond to commands within a short, predictable time window.
• State updates (e.g., lock status, thermostat mode) are reflected quickly in Home Assistant.
• If a command is sent, the corresponding state will update before the next dependent step runs (or at least within configurable timeouts).

FLiRS devices violate some of these assumptions, especially when:

• Z‑Wave network quality is mediocre,
• Device firmware is slow or buggy,
• Automations chain several state‑dependent actions on FLiRS nodes.

This is where “skipped” or “out‑of‑order” behavior appears.

3. What “Skipping Steps” Looks Like in Practice

Common symptoms when FLiRS devices are involved:

• A “Goodnight” automation:
• Turns off lights,
• Fails to lock a Z‑Wave lock, or
• Locks it, but Home Assistant still shows it as “unlocking…” or unchanged.
• An “Arrive home” automation:
• Unlocks the front door,
• Is supposed to wait until it’s confirmed “unlocked”,
• Then turn on lights and disarm an alarm.
• In reality:
• The light comes on,
• The alarm may disarm,
• But the “wait until locked/unlocked” step times out or is skipped because the lock’s state update is late or missing.
• Automations with wait_template or choose blocks that:
• Depend on a FLiRS device’s new state within a short timeout,
• End up taking the default path or aborting, as if the desired state never happened.

To the user, this looks like Home Assistant skips steps, but technically:

• The automation is running exactly as written,
• It just never sees the expected state conditions become true in time, due to FLiRS timing and Z‑Wave communication behavior.

4. Why FLiRS Devices Cause Automation Steps to Be Skipped

There are several interacting reasons; most are related to timing, acknowledgements, and state reporting.

4.1 Delayed Command Delivery and Processing

When Home Assistant sends a command to a FLiRS device:

1. The command is queued to the Z‑Wave controller.
2. The controller must send a beam to wake the device.
3. The FLiRS device wakes, then accepts the command.
4. The device acts (lock, unlock, adjust temperature) and may send a status report.

If:

• The network is busy,
• The beam or command must be retried,
• Routing is sub‑optimal,

then this sequence can take significantly longer than a second or two.

Meanwhile, your automation might:

• Move on to the next step,
• Evaluate a condition, or
• Hit a wait_template timeout,
  before the actual device state has changed or been reported.

Result: The automation never sees the state it’s waiting for, and so that step is effectively skipped or fails.

4.2 Missing or Unreliable State Reports

Some FLiRS devices (particularly older locks and thermostats):

• Do not always send unsolicited reports after a state change, or
• Only send limited information, or
• Rely heavily on polling rather than push updates.

If Home Assistant is:

• Waiting for a lock.locked or lock.unlocked state event,
• But the lock only sends that report inconsistently,

then:

• Even if the lock successfully changes state,
• The automation may never see the updated state in the entity,
• So conditional or wait_* steps that depend on that state never become true.

From the automation’s perspective, its condition fails or times out, so it goes on to the next branch or exits, i.e. it “skips” a logical step.

4.3 Tight Timeouts in wait_template or wait_for_trigger

Automations often use constructs like:

YAML

- service: lock.lock

  target:

    entity_id: lock.front_door

 

- wait_template: "{{ is_state('lock.front_door', 'locked') }}"

  timeout: "00:00:05"

  continue_on_timeout: false

If the FLiRS lock:

• Needs more than 5 seconds to:
• Wake,
• Process the command,
• Send the updated status,

the wait_template times out. Depending on configuration:

• The automation may abort or
• Skip subsequent steps because continue_on_timeout: false.

Even if the lock successfully locked a moment later, the automation already gave up waiting.

4.4 Race Conditions Between Multiple Commands

Chained actions often look like:

• Lock door A
• Then lock door B
• Then check both are locked
• Then turn off lights

With multiple FLiRS devices, you may see:

• Commands being queued and interleaved,
• Devices waking at slightly different times,
• State reports arriving out of the order you expect.

If your logic assumes:

• “First lock A, wait until locked, then lock B, then wait, then do X”,

but the underlying Z‑Wave network:

• Batch processes or parallelizes these commands,
• Or state updates arrive with jitter,

the automation might evaluate conditions in the wrong moment, making it appear like some steps are skipped.

4.5 Driver / Integration and Secure Inclusion Overhead

In Home Assistant, FLiRS devices are usually controlled via:

• Z‑Wave JS integration (current standard), or historically
• The older OpenZWave or legacy integrations.

FLiRS devices are often security‑enabled (S0/S2), especially locks. Secure communication adds:

• Extra round trips for encryption handshakes,
• More bandwidth per command,
• More processing time on both ends.

On a busy or marginal network, these overheads can:

• Increase latency further,
• Make timeouts in automations more likely,
• Cause dropped or requeued commands.

Again, automations that assume instant or near‑instant state transitions are vulnerable.

5. How to Confirm FLiRS and Z‑Wave Timing Are Causing the Problem

To avoid guessing, you can:

5.1 Check the Device Type

In Z‑Wave JS UI or your Z‑Wave controller tools, inspect the device info:

• Many drivers explicitly label devices as FLiRS or “Frequently Listening Routing Slave”.
• Door locks, thermostats and battery actuators are strong candidates.

If the problematic devices are indeed FLiRS, timing issues are very likely.

5.2 Review Z‑Wave JS Logs

Enable debug or detailed logging for the Z‑Wave integration and:

1. Run the automation.
2. Look at the timestamps for:
• When commands are sent to the FLiRS device.
• When acknowledgements and status reports arrive.

If you see:

• Long gaps,
• Multiple retries, or
• No report following a command,

then the “skipped” automation step is really a timeout or missing event, not a logic error.

5.3 Test Device Responsiveness Manually

From Home Assistant UI:

• Call the service to lock/unlock or control the FLiRS device.
• Time how long it takes for:
• The physical change to occur, and
• The integration’s entity state to update.

If the delay is close to or exceeds timeouts you use in automations, adjust your logic accordingly.

6. How to Design Automations That Work Reliably With FLiRS Devices

You can’t change how FLiRS works, but you can design around it.

6.1 Avoid Strict Short Timeouts on FLiRS State

If you use wait_template or wait_for_trigger:

• Increase timeout for FLiRS devices (e.g., 15–30 seconds instead of 3–5).
• Or, where possible, design automations that:
• Do not depend on immediate confirmation of the FLiRS state, or
• Use notifications or follow‑up checks rather than blocking waits.

Example adjustment:

YAML

- service: lock.lock

  target:

    entity_id: lock.front_door

 

- wait_template: "{{ is_state('lock.front_door', 'locked') }}"

  timeout: "00:00:20"

  continue_on_timeout: true

 

- choose:

    - conditions: "{{ is_state('lock.front_door', 'locked') }}"

      sequence:

        - service: notify.mobile_app_phone

          data:

            message: "Front door locked successfully."

  default:

    - service: notify.mobile_app_phone

      data:

        message: "Front door may not have locked, please check."

The automation no longer “hangs” or silently skips; it handles FLiRS latency explicitly.

6.2 Use Event‑Based or Command Acknowledgements When Available

Some devices and Z‑Wave drivers expose reliable events when commands succeed, e.g.:

• Specific lock operation reports,
• Thermostat mode reports.

If you can trigger follow‑up steps from those events (or device‑specific entities) rather than naive state reads, your automations align better with how the device actually reports status.

6.3 Simplify and Decouple Critical Sequences

Instead of writing one long linear automation that does everything in order, consider:

• Splitting into multiple smaller automations or scripts:
• One to send the command to the FLiRS device.
• Another to react when the device finally reports the desired state.

For example:

1. Automation A:
• Trigger: “Goodnight scene activated.”
• Action: Send lock commands to all locks; send a notification that locking was requested.
2. Automation B:
• Trigger: “Lock entity changes to locked.”
• Action: Append to a log or send a confirmation message.

This way, you don’t create a big chain of actions that can stall or misbehave because of one slow FLiRS step.

6.4 Optimize Your Z‑Wave Network

A healthier Z‑Wave network reduces FLiRS latency:

• Place enough mains‑powered Z‑Wave repeaters (switches, plugs, outlets) between the controller and FLiRS devices.
• Avoid long, marginal radio links—ensure good signal paths to locks and thermostats near doors and edges of the house.
• Position your Z‑Wave USB dongle:
• On a USB extension cable, away from the host and metal,
• Centrally in your home.
• Keep the Z‑Wave JS driver and controller firmware up to date.

Better routing and fewer retries mean FLiRS devices respond more predictably, so Home Assistant is less likely to run ahead of reality.

6.5 Re‑Interview / Reconfigure FLiRS Devices

Sometimes the issue is:

• Incomplete device interview,
• Wrong command classes enabled, or
• Poor parameter defaults.

Use Z‑Wave JS tools to:

• Re‑interview the device so the integration knows all supported reports and behaviors.
• Check device‑specific config hints or community docs:
• Some locks need extra parameters enabled to send unsolicited status reports.
• If the device supports it, enable hail/report on local operation so that manual usage (keypad, thumbturn) is reflected quickly.

6.6 Rethink “All‑or‑Nothing” Logic With FLiRS Nodes

Avoid writing logic like:

“If lock A, lock B, and lock C are all locked within 5 seconds, then do X, else do Y.”

FLiRS nodes notoriously do not guarantee synchronized completion like that. Instead:

• Treat each FLiRS device’s success or failure as something to log or notify about,

Don’t hinge an entire automation’s behavior on a tight timeframe.

7. Summary

Home Assistant automations often appear to skip steps when Z‑Wave devices enter or operate in FLiRS mode because:

• FLiRS devices sleep and only wake periodically to receive commands, adding latency.
• Status reports may be delayed, inconsistent, or missing, particularly on older or poorly configured locks and thermostats.
• Automations that use short timeouts or tightly chained state‑dependent actions often time out or evaluate conditions before the FLiRS device has finished updating.
• Secure inclusion, routing, and network quality can amplify these delays.

The automation engine is not randomly ignoring steps; it is following the logic you defined, but that logic may not match the real‑world timing and reporting behavior of FLiRS devices.

To make automations reliable with FLiRS nodes:

• Avoid strict, short waits on FLiRS state; increase timeouts or use notifications.
• Design decoupled, event‑driven flows instead of long linear chains.
• Optimize your Z‑Wave network and device configuration to reduce latency and improve reporting.
• Re‑interview and tune device parameters where needed.

With these adjustments, Home Assistant and Z‑Wave FLiRS devices can work together without “skipped” steps, even in complex smart home automations.