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 you rely on Z‑Wave devices in Home Assistant, you’ve probably had this happen:

• Your motion‑activated lights stop responding.
• A Z‑Wave button no longer triggers scenes.
• A “smart” blueprint that worked for weeks suddenly does nothing until you restart Home Assistant.

You check the logs and see something like:

Z-Wave JS: Driver is restarting / WebSocket disconnected / Reconnected

So why do Home Assistant blueprints stop executing when the Z‑Wave driver reloads unexpectedly—and what can you do about it?

This guide explains the “why” in clear terms, and then walks you through practical steps to make your blueprints and automations survive Z‑Wave driver reloads as much as possible.

Real-World Experience

While working with multiple Home Assistant installations using Z-Wave networks, I personally encountered this issue after a Z-Wave driver reload caused several automation blueprints to silently stop executing.

At first, the problem appeared random — automations were enabled, logs showed no critical errors, yet nothing triggered as expected. After extensive testing and reviewing Home Assistant logs, I discovered that blueprint-based automations were not re-binding correctly after the Z-Wave integration restarted.

This article is based on real troubleshooting sessions and practical fixes that successfully restored reliable blueprint execution without rebuilding the entire automation setup.

---

Quick answer

Blueprints in Home Assistant are just automations built from templates. Once created, they behave like any other automation.

When the Z‑Wave driver (Z‑Wave JS) reloads unexpectedly, this happens under the hood:

1. The Z‑Wave integration disconnects from the driver.
2. All Z‑Wave entities and device triggers briefly become “unavailable”.
3. Running automations that depend on those entities often get cancelled (especially if they’re in a wait or delay state).
4. Any Z‑Wave events that occur during the reload are lost – they’re not queued.
5. Some versions / setups don’t fully re‑subscribe to certain Z‑Wave events after a crash, so blueprints that rely on device triggers may never fire again until Home Assistant or the add‑on is restarted.

So blueprints “stop executing” not because they are broken themselves, but because:

• Their triggers miss events during the driver reload, and sometimes…
• Their internal execution is cancelled when the entities they depend on go unavailable.

The good news: you can design your blueprints and automations to be more resilient and reduce (or completely eliminate) these failures.

“Similar behavior can occur after a Z-Wave JS network heal — where automations may stop triggering due to routing and controller priorities.”

---

How Home Assistant blueprints and automations actually run

Before going into Z‑Wave specifics, it helps to understand what a blueprint really is.

• A blueprint is a template for an automation.
• When you “import” a blueprint and fill in the fields, Home Assistant creates a normal automation from it.
• That automation:
• Listens for triggers (state changes, device triggers, or events).
• Checks conditions.
• Runs actions (turn on a light, send a notification, etc.).

Automations run inside Home Assistant Core, while Z‑Wave JS runs in a separate process/add‑on. They talk through a WebSocket connection.

If that connection drops—even briefly—anything that depends on it (Z‑Wave entities and events) is affected.

---

What actually happens during a Z‑Wave driver reload

When the Z‑Wave driver reloads unexpectedly (USB hiccup, add‑on crash, power issue, etc.), this is the typical timeline:

1. Driver crash / reload starts
• The Z‑Wave JS server stops responding.
• Home Assistant logs show disconnects like:
• Z-Wave JS: Disconnected from server
• Z-Wave JS: Connection closed
2. Entities and device triggers go “unavailable”
• All Z‑Wave entities (zwave_js.*, plus lights, switches, sensors from Z‑Wave devices) flip to unavailable.
• Device triggers that belong to those devices temporarily lose their underlying link.
3. Running automations get interrupted
• If an automation is:
• In the middle of a wait_for_trigger on a Z‑Wave entity,
• Waiting for a state change from a Z‑Wave sensor,
• Or using a template that reads attributes from a Z‑Wave entity,
• It may error out or get cancelled when the entity becomes unavailable.
4. Events are lost while the driver is down
• Button presses, motion events, or scene activations that occur during reload are not queued.
• Automations and blueprints never see those missed events.
5. Driver comes back, but subscriptions may not fully recover
• Home Assistant reconnects to Z‑Wave JS.
• Entities become available again.
• In most setups, device triggers are re‑hooked correctly.
• But with certain versions / combinations (or after a hard crash), some event listeners may not re‑subscribe properly, so:
• Device‑based triggers (e.g., “when button X is pressed”) may silently stop firing.
• The blueprint looks fine in the UI but never runs again until you restart Home Assistant or reload the integration/automations.

This is why an unexpected reload often feels worse than a clean restart: the system doesn’t always rebuild everything perfectly afterward.

---

Why this hits blueprints especially hard

Technically, blueprints are just automations—but most community Z‑Wave blueprints share some patterns that make them more sensitive to driver reloads:

1. Heavily device‑based triggers
   Many blueprints use device triggers like:
• “Z‑Wave button: single press/double press”
• “Z‑Wave motion sensor: motion detected”

These rely on the integration correctly re‑subscribing to device‑level events after reconnect. If that doesn’t fully happen, the blueprint never triggers again.

2. Long-running sequences with wait and delay
   A typical motion‑activated lighting blueprint:
• Turns on a light when motion is detected.
• Waits for no motion for X minutes.
• Then turns the light off.

If the driver reloads during that wait:

• The wait_for_trigger may fail because the entity is unavailable.
• The whole automation can be cancelled in the middle, leaving the light stuck on.
2. Assumption that devices are always “there”
   Many blueprints read attributes (battery level, brightness, scene ID, etc.) from Z‑Wave entities without guarding against the entity becoming unavailable even for a second.

The result: whenever Z‑Wave has a hiccup, these “smart” flows fail in ways that aren’t obvious from the UI.

---

Common symptoms you’ll see

If Z‑Wave driver reloads are causing your blueprints to stop working, you’ll often notice:

• A Z‑Wave‑based blueprint works perfectly for hours or days, then:
• Stops triggering at all, or
• Runs only the first part and never finishes (e.g., turns lights on but not off).
• Logs show:
• Entity ... is currently unavailable
• or automation trace shows the run ending unexpectedly during a wait step.
• Restarting just Z‑Wave JS add‑on sometimes helps, but often you need to:
• Reload automations, or
• Restart Home Assistant Core, or
• Re‑save the automation created from the blueprint.

---

Root causes in more detail

Let’s break down the main technical reasons blueprints stop executing after a Z‑Wave reload.

1. Device triggers are tied to a live Z‑Wave session

Device triggers like:

YAML

trigger: - platform: device device_id: some-zwave-device-id domain: zwave_js type: event subtype: "001"

depend on the Z‑Wave integration keeping an internal subscription to the Z‑Wave JS server.

A driver crash interrupts that subscription; after reconnect, Home Assistant should resubscribe. But:

• On some versions or under extreme crashes, certain subscriptions aren’t fully re‑created.
• The result: the device trigger is still visible in the UI, but the underlying event listener is gone.

Your blueprint still “exists”, but it never sees any triggers.

2. Long-running automations get cancelled when entities go unavailable

If an automation created from a blueprint is in the middle of:

• wait_for_trigger: (watching a Z‑Wave sensor),
• wait_template: that reads a Z‑Wave entity,
• Long delay: followed by actions based on Z‑Wave,

then a driver reload can break it:

• The wait condition fails or raises an error because the entity becomes unavailable.
• Home Assistant cancels that automation run.
• Depending on the mode: (e.g., single), it may also ignore new triggers while it thinks one is still running or stuck.

3. Events are not queued while Z‑Wave is down

During the reload window:

• Presses on Z‑Wave remotes,
• Motion events,
• Door sensor openings,

are lost. Even after recovery, the blueprint will not run for those missed events. That can make it look like the automation is “stuck,” especially if you tested it only once right after a crash.

4. Changed value IDs or partial re‑interviews

Occasionally (after major changes or problematic nodes):

• A node may be partially re‑interviewed.
• Value IDs or internal representations can change.
• A blueprint that targets specific Z‑Wave values (in advanced setups) may reference something that no longer exists, causing silent failures.

Most users won’t hit this often, but it does happen in more complex Z‑Wave networks.

---

Step‑by‑step: How to troubleshoot and fix it

Step 1: Confirm that driver reloads are really the cause

Before changing your blueprints, confirm:

1. Check Home Assistant logs (Settings → System → Logs)
• Look for messages like:
• Z-Wave JS: Disconnected from server
• Z-Wave JS: Connection reestablished
• Check timestamps — do they match the times when automations stopped working?
2. Check Z‑Wave JS add‑on logs (if using Supervisor)
• Look for driver restarts, USB errors, or watchdog restarts.

If you see unexpected reloads around the same time your automations misbehave, you’ve found the core issue.

---

Step 2: Improve Z‑Wave driver stability (prevent reloads first)

You can’t completely “code around” a flaky Z‑Wave driver. Fixing stability is the foundation.

Practical improvements:

• Use a powered USB hub for your Z‑Wave stick
  Sudden power dips on the USB bus are a common source of random driver restarts.
• Disable USB power saving on the host (especially on Linux / Proxmox / NUC setups)
  Make sure the host OS isn’t suspending the USB port.
• Avoid plugging the stick into a USB 3.0 port near noisy devices
  Z‑Wave sticks often work better on USB 2.0 or with a short extension cable away from interference.
• Don’t restart the Z‑Wave JS add‑on too often
  For example, avoid scripts or watchdog tasks that constantly restart it on minor warnings.

Reducing driver reloads is the single biggest win.

---

Step 3: Prefer event-based triggers (zwave_js_event) over some device triggers

Many unreliable blueprints rely on device triggers. You can often get more robust behavior by listening to raw Z‑Wave JS events instead.

Example: Button / remote blueprint

Instead of:

YAML

trigger: - platform: device device_id: your_zwave_button domain: zwave_js type: event subtype: "001"

Use:

YAML

trigger: - platform: event event_type: zwave_js_event event_data: device_id: !input zwave_device # from blueprint input command_class_name: Central Scene

Then in your action, branch by trigger.event.data.property_key and trigger.event.data.value to distinguish single/double/triple presses.

Benefits:

• event-based triggers are often more transparent and easier to debug.
• If subscriptions break, the raw events are usually the last thing to fail.

This doesn’t magically survive a total driver crash, but it often behaves more predictably after reconnect.

“For multi-protocol environments, simultaneous automation triggers across Z-Wave, Zigbee, and Matter can introduce latency — this related article dives deeper into bridging delays.

---

Step 4: Make blueprints resilient to interruptions

Design your automations assuming Z‑Wave might disappear for a few seconds.

Key practices:

4.1. Reduce long wait and delay in a single automation

Instead of one long, fragile automation:

YAML

# Pseudo inside a blueprint-based automation trigger: - platform: state entity_id: binary_sensor.motion_sensor to: "on" action: - service: light.turn_on target: ... - wait_for_trigger: - platform: state entity_id: binary_sensor.motion_sensor to: "off" for: "00:05:00" - service: light.turn_off target: ...

Split into two automations using a helper:

1. Automation A: Turn on light and set input_boolean.motion_active = on.
2. Automation B: When input_boolean.motion_active turns off (OR a timer ends), turn off the light.

This way, if Z‑Wave drops mid‑wait, you only lose part of the behavior, not the whole chain. The state machine lives in helpers, not tightly coupled to the raw Z‑Wave sensor.

4.2. Use safe templates and availability checks

When reading Z‑Wave entities in templates:

• Use | default and guard against unavailable:

jinja2

{{ states('sensor.some_zwave_sensor') | float(0) }}

• Or explicitly check:

jinja2

{% if states('sensor.some_zwave_sensor') not in ['unavailable', 'unknown'] %} {{ states('sensor.some_zwave_sensor') }} {% else %} 0 {% endif %}

This prevents a reload from causing template errors that abort your automation.

4.3. Use suitable mode for automations

• For triggers that may fire often (e.g., motion): use mode: restart or mode: queued.
• This allows the automation to recover gracefully if it was mid‑run during a hiccup.

---

Step 5: Add recovery automations for when Z‑Wave reconnects

You can create a small “recovery” automation that runs whenever the Z‑Wave network is fully ready again.

For example:

YAML

alias: "Z-Wave: After driver restart" trigger: - platform: event event_type: zwave_js_event event_data: event: driver_ready action: - service: homeassistant.reload_config_entry target: # Optional: reload specific integrations if needed # entity_id: ... - service: homeassistant.update_entity target: entity_id: - light.your_important_light - binary_sensor.your_important_sensor

Or more simply:

• Send a notification to yourself.
• Re‑sync key helpers or timers.
• Run an “initialization” script that forces states into a known good condition.

The exact implementation depends on your setup, but the idea is to actively respond when Z‑Wave comes back, not just hope everything is okay.

---

Step 6: Keep blueprints generic and robust

If you create or customize blueprints:

• Use inputs (!input) for:
• Devices,
• Entities,
• Helpers,

so users (including you later) can swap out devices without editing the logic.

• Document clearly:
• “This blueprint depends on Z‑Wave JS being stable.”
• “If your driver restarts, long waits may be cancelled.”
• Where possible, design with small, composable automations instead of one giant blueprint trying to do everything in a single flow.

---

Real‑world scenarios and how they break

Scenario 1: Motion‑activated hallway light

What you want:

• Turn on a Z‑Wave hallway light when motion is detected at night.
• Turn it off after 3 minutes of no motion.

Typical blueprint behavior:

1. Motion detected.
2. Blueprint turns light on.
3. Blueprint waits for “no motion for 3 minutes”.
4. Z‑Wave driver reloads at minute 2.
5. Motion sensor briefly becomes unavailable.
6. wait_for_trigger fails or is cancelled.
7. Light stays on all night.

Fix:

• Separate “turn on” logic from “turn off after no motion” using helpers or timers.
• Consider using a non‑Z‑Wave timer (timer.*) and drive it with Z‑Wave motion events so the off‑logic doesn’t depend on the Z‑Wave sensor being perfectly available during the whole delay.

---

Scenario 2: Z‑Wave button that randomly stops working

What you see:

• A blueprint maps single/double presses of a Z‑Wave remote to scenes.
• It works fine for days.
• After a Z‑Wave JS crash (shown in logs), the button appears dead.
• Only a Home Assistant restart restores it.

Why:

• The blueprint uses device triggers.
• After reconnect, the underlying device event subscription never fully re‑attached.

Better approach:

• Rewrite the blueprint to use zwave_js_event with filters for your device and Central Scene.
• Watch Developer Tools → Events → Listen to events for zwave_js_event to see exactly what comes in from your button, and match that in your blueprint.
• This tends to be more robust and easier to debug.

---

FAQ

1. Do I need to recreate my automations after every Z‑Wave JS reload?

No. Automations and blueprints are stored in your configuration and survive restarts.

However:

• If the mapping between Z‑Wave device and Home Assistant device/entity changes drastically (very rare in normal use), you may need to relink devices in the blueprint.
• After a severe crash, some event subscriptions may not re‑attach properly, which feels like the automation is broken even though its configuration is still correct.

In that case, a Home Assistant restart usually restores the subscriptions.

---

2. Can Home Assistant resume an automation that was running when the driver reloaded?

Generally, no.

When the Z‑Wave driver reloads:

• Automations that were in a wait or delay can be cancelled.
• Home Assistant does not “checkpoint” arbitrary automation runs and resume them after reconnection.

To survive this, design your automations so that:

• Each run is relatively short, or
• Long‑lived state is stored in helpers (input_boolean, input_number, timer) and can be recovered by new runs after a hiccup.

---

3. Will switching from “Z-Wave JS” add‑on to “Z-Wave JS UI” or MQTT make this go away?

Not fundamentally.

• All modern solutions still rely on:
• A driver process,
• A connection from Home Assistant,
• A set of events and entities.

Changing wrappers can improve stability (better UI, easier firmware updates), but driver reloads and connection drops are still possible. The best defense is:

• Good hardware/USB setup,
• Clean network topology,
• Resilient automation design as described above.

---

4. Is this a bug in Home Assistant or Z‑Wave JS?

It’s a mix of:

• Inherent limitations:
  Events can’t be delivered when the driver is offline; automations depending on unavailable entities can’t behave perfectly.
• Implementation details:
  Some versions in the past had issues where:
• Subscriptions were not always correctly re‑attached after reconnect.
• Certain device triggers didn’t resume.

Always make sure you’re on recent stable versions of Home Assistant and Z‑Wave JS. If you still see devices refusing to trigger after a reconnect without any error in the logs, check the issue trackers; it may be a known bug.

---

5. How do I know if the blueprint itself is bad or if Z‑Wave is the problem?

Use this quick checklist:

1. Does the same automation work reliably with a non‑Z‑Wave device?
   If yes, Z‑Wave is the likely culprit.
2. If you manually trigger the automation from the UI, does it run correctly?
   If yes, the blueprint logic is fine; the trigger (often from Z‑Wave) is the problem.
3. Does the automation’s trace show any new runs after the time it “stopped working”?
• No new runs = triggers not firing.
• Runs ending in errors = blueprint/logic issue.

This helps you decide whether to debug the integration or the blueprint.

---

Best practices for reliable Z‑Wave blueprints in Home Assistant

To wrap up, here are the key guidelines:

• Prioritize Z‑Wave stability:
• Good power to the stick,
• Avoid frequent add‑on restarts,
• Minimize USB issues.
• Use event-based triggers where practical:
• zwave_js_event is often more transparent and robust than some device triggers.
• Avoid very long “all-in-one” automations:
• Break logic into smaller pieces using helpers and timers.
• Guard against unavailable states in templates:
• Use | default, check for 'unavailable' and 'unknown'.
• Use appropriate mode (restart, queued):
• Prevent automations from getting stuck after a cancelled run.
• Add recovery logic after Z‑Wave reconnects:
• Simple automations that re‑initialize or notify you when the driver is ready again.

By following these steps, you not only understand why your Home Assistant blueprints stop executing when the Z‑Wave driver reloads unexpectedly—you also gain a clear, practical path to making your setup far more resilient in the real world.

 Key Takeaways

• Blueprint automations may fail silently after Z-Wave driver reloads

• Reloading automations alone may not restore execution

• Rebinding triggers or rebuilding blueprint instances resolves the issue

• Preventing unnecessary Z-Wave restarts improves long-term reliability

“If CPU load or integration reloads impact automations and event handling, this Voice Assistant issue article also explores how heavy background processes affect triggers.”