Skip to main content
Selora Homes Selora Homes

Troubleshooting Z-Wave Devices Showing Unavailable or Unresponsive

Diagnose and fix Z-Wave devices that stop responding, show as dead or unavailable in Home Assistant, or fail to execute commands after previously working.

Z-Wave Troubleshooting Unavailable Unresponsive Dead-Node Z-Wave-Js

Understanding the Problem

Z-Wave devices that were previously working but now show as unavailable or fail to respond to commands are a common issue in Home Assistant. Z-Wave operates differently from Zigbee — it uses a source-routed mesh where the controller maintains a full routing table. When a device becomes unresponsive, the issue is typically related to the routing table, range, the controller itself, or a device firmware hang.

Common Symptoms

  • Device entity shows Unavailable or Dead in Home Assistant.
  • Commands are sent but the device does not respond (lights do not turn on, locks do not engage).
  • The Z-Wave JS UI shows the node as Dead or Asleep (for a device that should not be asleep).
  • Device responds with significant delay (5–30 seconds).
  • Device works locally (physical button press) but not from Home Assistant.

Step 1: Check Node Status in Z-Wave JS

The Z-Wave JS UI provides detailed information about each node’s health and communication status.

  1. Open the Z-Wave JS UI (accessible from the Z-Wave integration page or the Z-Wave JS add-on sidebar entry).
  2. Navigate to the Nodes list and find the problem device.
  3. Check the node’s Status column:
    • Alive: The controller can communicate with the device. The issue is likely in Home Assistant’s entity layer, not Z-Wave.
    • Asleep: Normal for battery devices, but if a mains-powered device shows this status, it has stopped responding.
    • Dead: The controller has given up trying to reach the device after multiple failed communication attempts.
  4. Check the Last Active timestamp to see when the device last communicated.

Step 2: Identify the Root Cause

Work through these causes from most common to least common.

Controller Communication Failure

The most frequent cause of Z-Wave devices going dead is a communication breakdown between the controller (USB stick) and Home Assistant, not between the controller and the device.

Diagnosis:

  • Check the Z-Wave JS add-on logs for errors like “Serial port not found” or “Timeout waiting for response.”
  • If multiple devices went dead simultaneously, the controller itself is likely the issue — not the individual devices.

Fix:

  • Restart the Z-Wave JS add-on. This re-initializes the serial connection to the USB stick.
  • If restarts do not help, check the physical USB connection. Try a different USB port or a powered USB hub. USB power management on some systems can cause the controller to disconnect silently.
  • Use a USB extension cable (at least 1 meter) to move the Z-Wave stick away from the server. USB 3.0 ports and SSDs generate interference on the Z-Wave frequency band (around 908 MHz in North America, 868 MHz in Europe).
  • Supported Z-Wave controllers include the Home Assistant Connect ZWA-2, Aeotec Z-Stick Gen5+, Zooz ZST39 LR, and the Silicon Labs UZB-7.

Dead Node Due to Range

A device marked as dead may simply be out of range of both the controller and any repeating nodes. Unlike Zigbee, Z-Wave does not self-heal routing as aggressively. If a routing node between the controller and the target device is removed or powered off, the dead device may not find an alternative route on its own.

Diagnosis:

  • In the Z-Wave JS UI, check the Route column for the dead node. It shows which intermediate nodes the controller uses to reach the device.
  • If any of the intermediate nodes are themselves dead or have been removed, the route is broken.

Fix:

  • Ping the node: In the Z-Wave JS UI, select the dead node and use the Ping action. If the ping succeeds, the node is not actually dead — the routing table just needs updating.
  • Re-interview the node: Select the node and run Re-interview Node. This forces the controller to rediscover the device and rebuild its routing entry.
  • Heal the network: Run a network-wide heal from the Z-Wave JS UI (Settings → Heal Network). This rebuilds the routing table for all nodes. Run this at night — it can take 30+ minutes for large networks and causes temporary unresponsiveness during the process.

Ghost Nodes

Ghost nodes are entries in the Z-Wave controller’s node list for devices that were physically removed or factory reset without being properly excluded first. They occupy a slot in the routing table and can cause communication errors as the controller tries to route through a device that no longer exists.

Diagnosis:

  • In the Z-Wave JS UI, look for nodes with no manufacturer information or that show a permanent “Unknown” status.
  • Check if any nodes in the routing table correspond to devices you have physically removed.

Fix:

  • Select the ghost node in the Z-Wave JS UI and use Remove Failed Node. The controller will verify that the node is truly unreachable and then remove it from the network.
  • If removal fails, you may need to attempt it multiple times. The controller requires several consecutive communication failures before it allows a node to be removed.
  • After removing ghost nodes, run a network heal to update routes.

S2 Security Key Issues

Devices included with S2 security use encrypted communication. If the security keys become mismatched (for example, after restoring a Z-Wave controller backup from a different date than the device’s inclusion), the device will appear alive at the network layer but fail to execute commands.

Diagnosis:

  • The device shows as Alive in Z-Wave JS but commands do not work.
  • The Z-Wave JS logs show S2 decryption failed or Security CC command failed errors when interacting with the device.

Fix:

  • The only reliable fix is to exclude the device and re-include it. This re-establishes the S2 security handshake and generates fresh keys.
  • During re-inclusion, ensure you complete the S2 key exchange (scanning the DSK code or entering the PIN from the device). An incomplete S2 handshake falls back to no security, which changes the device’s behavior.

Firmware Lock-Up

Some Z-Wave devices (especially older models) can enter a state where their firmware stops responding to Z-Wave commands even though the hardware is powered on. This is more common with devices that have not received firmware updates.

Diagnosis:

  • The device does not respond to pings from the Z-Wave JS UI.
  • The device does not respond to physical button presses (if applicable), or physical operation works but Z-Wave commands do not.

Fix:

  • Power cycle the device. For hardwired devices (switches, dimmers, outlets), turn off the circuit breaker for 30 seconds. For plug-in devices, unplug and re-plug.
  • After power cycling, ping the device in Z-Wave JS. Most devices recover immediately.
  • If the device locks up frequently, check for a firmware update from the manufacturer or consider replacing it.

Step 3: Last Resort — Exclude and Re-Include

If none of the above resolves the issue:

  1. Exclude the device using the Z-Wave JS UI exclusion mode. Put the device into exclusion mode according to its manual (usually a button press sequence).
  2. Factory reset the device if exclusion fails (the device was already dropped from the network).
  3. Remove the failed node from the Z-Wave JS UI if the device cannot be excluded normally.
  4. Re-include the device using inclusion mode. Bring the device close to the controller for inclusion, then move it to its installed location.
  5. After re-inclusion, run a network heal to update all routes.
  6. Update any automations or dashboard cards that referenced the old entity — re-inclusion creates new entity IDs.

Type to search across cities, counties, and installers

↑↓ navigate open
⌘K search