Direct answer: A Z-Wave node marked dead or unavailable is usually failing to answer the controller. Check power, controller connectivity, USB interference, and the mesh route before excluding or factory-resetting it.
Symptoms
- The device card is unavailable.
- The Z-Wave node-status sensor reports dead.
- Commands time out or updates arrive intermittently.
Before you start
Do not remove the integration, reset the controller, or factory-reset the device. Preserve your Z-Wave security keys and create a backup before any destructive recovery.
Diagnostic steps
- Confirm the device has power. For battery devices, install a known-good battery and wake the device using its manual.
- Open Settings → Devices & services → Z-Wave and confirm the integration and Z-Wave JS server are connected.
- Open the device and inspect its node status and communication statistics.
- If the adapter is connected directly to USB, move it to a short USB extension cable to reduce RF interference.
- For a mains-powered node, use the Ping button once. Battery devices normally sleep, so pinging them while asleep proves little.
- After correcting power or interference, rebuild routes where the interface offers that action. Allow the mesh time to settle.
- Enable debug logging briefly and reproduce the failure. Download diagnostics before escalating.
Verify the fix
Send one command, confirm the physical device responds, and check that a new state report returns to Home Assistant. Watch the node statistics for repeated failures.
Recovery and rollback
If the device remains dead, consult its manufacturer instructions and the current Z-Wave JS documentation before exclusion or replacement. Exclusion and factory reset can break entity references and automations, so treat them as last-resort steps.
Prevention
Keep the adapter away from USB 3 interference, use stable device paths for external servers, retain security-key backups, and build a healthy mains-powered mesh.
Sources
Last reviewed: September 4, 2026.
Related Troubliq guides
Find your next troubleshooting path
Use the related guide that matches the next confirmed layer of the failure. Avoid changing unrelated systems at the same time.
Detailed evidence checklist for Z-Wave JS node is dead or unavailable in Home Assistant
Before another change, create a short incident record. Include the exact time the symptom appeared, what the system was doing, the last successful action, and every update or network change made during the previous day. Record the Home Assistant release, installation type, integration version, device model, firmware, connection method, current address, and relevant entity IDs. Screenshots are useful for visible states, but copy the exact error text because screenshots may crop the detail needed to search logs.
Compare the failing item with one known-good item that uses the same path. If both fail, move outward toward shared services such as the integration, coordinator, add-on, DNS, router, cloud account, or Home Assistant host. If only one fails, stay close to that device: power, signal, address, credentials, firmware, permissions, and configuration. This comparison prevents a single-device problem from turning into an unnecessary system-wide rebuild.
Network tests that prove the failing layer
Use tests in layers. Confirm the address is current in the router or DHCP server. Confirm the Home Assistant host or container resolves the same name and reaches the intended address. Then test the actual documented service, port, or protocol. A dashboard loading on a phone proves only the phone’s path. A successful ping proves basic reachability, not authentication, WebSocket upgrades, multicast discovery, API encryption, event subscriptions, or application permissions.
For segmented networks, document source VLAN, destination VLAN, direction, protocol, and port before editing a firewall rule. Test the smallest temporary exception and remove it if it did not help. Discovery traffic and control traffic may use different mechanisms. Seeing a device in discovery does not prove Home Assistant can maintain a working session.
Configuration comparison procedure
Export or photograph the current configuration without exposing secrets. Compare it with official documentation field by field: host, port, account, region, project, encryption setting, device identifier, and optional switches. Watch for trailing spaces, uppercase versus lowercase account names, obsolete hostnames, restored encryption keys, or an account belonging to the wrong home or region.
Use Reconfigure or Reauthenticate before deleting an integration. Preserve entity IDs and note every automation, dashboard, script, scene, or helper that refers to them. If replacement becomes necessary, take a backup and map old entities to replacements. That makes rollback controlled rather than leaving broken references.
Power, radio, and timing checks
Do not interpret every unavailable state as software failure. Low-voltage devices may stay partly online while unstable power causes resets. Battery devices sleep and report on their own schedule. Wi-Fi and Bluetooth devices can associate yet fail at the application layer. Zigbee and Z-Wave devices depend on routes, radio conditions, and powered repeaters. Match the test to the technology instead of repeatedly pressing Reload.
Allow enough time after each test. Cloud polling, sleepy devices, retained MQTT messages, mesh repair, Bluetooth advertisements, and DHCP changes do not update instantly. Define the expected interval, then wait through at least two normal cycles. If availability returns briefly, capture the next disconnect in logs instead of declaring success.
Log-reading workflow
Synchronize clocks and reproduce the problem once. Start with the first warning or error at that timestamp; later messages may be consequences. Group errors by layer: name resolution, timeout, refused connection, TLS certificate, unauthorized account, invalid token, missing permission, unsupported capability, malformed payload, device timeout, or rate limit. Each group suggests a different next action.
Turn debug logging off after reproduction. Large files consume storage and bury the event. Redact tokens, passwords, keys, email addresses, public addresses, precise locations, and unnecessary unique identifiers. Keep the unredacted copy private for comparison with later tests.
Safe change order
- Correct time, power, cabling, or an obviously stale address.
- Reload only the affected integration when documentation supports it.
- Use Reconfigure or Reauthenticate without deleting the entry.
- Restart only the affected device or add-on during a safe window.
- Restart Home Assistant when several components share the symptom or a change requires it.
- Update software after reading release notes and preserving rollback.
- Delete, exclude, reset, or rebuild only after safer checks prove it necessary.
Post-repair validation
Verify both directions. Confirm Home Assistant receives a fresh state, send one harmless command, and confirm the physical response. Check the returned state, logbook, history, and automation trace. Restart the affected component and verify automatic reconnection. During a maintenance window, confirm the repair survives a normal Home Assistant restart.
Monitor long enough to cover the original pattern. If failure occurred overnight, after DHCP renewal, deep sleep, or token expiry, a five-minute test is insufficient. Record the confirmed cause and exact corrective change. Remove temporary firewall rules, extra logging, duplicate test integrations, and unused credentials.
When to stop and escalate
Stop if hardware overheats, power is unstable, storage reports errors, a controller backup fails, credentials are rejected across services, or firmware may be damaged. Escalate with versions, timestamps, topology, redacted logs, the first meaningful error, and results of each safe test. Do not repeat destructive steps while waiting for help.
A strong report answers four questions: What still works? What exactly fails? What changed immediately beforehand? Which test most clearly separates the causes? Those answers help maintainers diagnose the correct layer.
Verification checkpoint 1 focuses on power source. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 1: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
For checkpoint 2, inspect wake interval rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 2: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Checkpoint 3 — last-seen time: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 3: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Verification checkpoint 4 focuses on command queue. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 4: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
For checkpoint 5, inspect route statistics rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 5: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Checkpoint 6 — powered repeaters: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 6: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Verification checkpoint 7 focuses on individual heal. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 7: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
For checkpoint 8, inspect security state rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 8: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Checkpoint 9 — failed-node eligibility: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 9: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Verification checkpoint 10 focuses on fresh report. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 10: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
For checkpoint 11, inspect driver restart rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 11: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Determine whether the node is sleeping, unreachable or formally failed
A battery node that is asleep is not automatically dead. Check whether the device is mains powered, listening, frequently listening or sleeping, then compare its last-seen time with its normal wake-up interval. A dead status after one missed exchange should lead to power and route checks, not immediate failed-node removal.
For a battery device, replace or measure the battery and wake it using the manufacturer’s documented sequence while watching Z-Wave JS events. For a mains device, confirm line power and test a nearby repeater. Do not repeatedly ping a sleeping node; it will not respond until awake and the extra commands can fill its queue.
Use route repair at the correct time
Run an individual node heal only after power and physical placement are stable. Healing a powered-off device cannot succeed. Avoid treating a full-network heal as a universal fix, especially on large networks, because it creates substantial traffic and can obscure the original fault. Examine route statistics, failed transmissions and neighboring powered nodes first.
The controller will permit failed-node removal only when the protocol considers the node failed. If exclusion is possible, prefer a normal exclusion so the device clears its network state. Use failed-node removal for a truly missing or broken node, then clean up entity references deliberately. Never remove a node merely because its entities show unavailable for a short period.
Verify recovery beyond one successful ping
- The node reports a fresh value or accepts a harmless command.
- Interview and security state remain complete.
- Transmission failures stop increasing during normal use.
- Battery devices complete at least one expected wake cycle.
- The node reconnects after a routine Z-Wave JS restart.
If the node repeatedly becomes dead in the same location, investigate marginal power, metal enclosures, interference, missing repeaters or an unstable neighbor. Provide the node type, security level, firmware, route statistics, last-seen time and driver logs when escalating. That evidence is more useful than repeated network heals.