Z-Wave JS / Troubleshooting
Z-Wave JS Node Is Dead but the Controller Is Online
Use the exact Z-Wave JS node status to separate Dead from Asleep/Awake, then check communication evidence, power, and mesh path without removing the node or rebuilding the network.
Z-Wave JS defines distinct node states. Nodes that support Wake Up CC use Asleep/Awake states, while nodes that do not support Wake Up CC are marked Dead after failing to respond and Alive while responding.[1]
That exact status boundary matters: a temporarily sleeping node is not the same diagnosis as a Dead non-WakeUp node, and an online controller does not prove the individual node's power or mesh path.[1][3]
Applicability
Symptoms
Quick diagnosis
Gate on the exact Z-Wave JS node status, then preserve network state while checking Wake Up CC semantics, power, and mesh evidence.
Confirm the exact Z-Wave JS node status
Read the node status before touching the mesh. Continue only for Dead; Asleep/Awake belongs to a sleeping-node path.[1]
Confirm the controller/driver remains online
A controller outage or USB adapter problem can make many nodes unavailable and is outside this single-node Dead diagnosis.[3][1]
Capture communication, route, and physical evidence
Use available last-communication, retry, route/neighbor, power, and placement evidence to distinguish a node problem without Remove Failed Node, exclusion, or reset operations.[1][3]
Interactive troubleshooter
Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.
Guided check / step 1
Safe diagnostic guidanceIs the controller online with one specific node unavailable?
This page is for a single-node problem with an otherwise online controller.[3][1]
Read the complete diagnostic tree without using the controls
- Is the controller online with one specific node unavailable?
This page is for a single-node problem with an otherwise online controller.[3][1]
- Yes — controller is online → What is the exact Z-Wave JS node status?
- No — controller or wider network is affected → Use a controller or wider-network diagnosis
- What is the exact Z-Wave JS node status?
Z-Wave JS defines Unknown, Asleep, Awake, Dead, and Alive as distinct states.[1]
- Dead → Does the node support Wake Up CC?
- Asleep or Awake → Use a sleeping-node diagnosis
- Unknown or Alive → The node is not in the Dead state
- Does the node support Wake Up CC?
Dead/Alive states are used for nodes that do not support Wake Up CC; WakeUp nodes use Asleep/Awake semantics.[1]
- No — non-WakeUp node → Is the device physically powered and still in its expected location/range?
- Yes — status/capability evidence conflicts → The status/capability evidence conflicts with this Dead-node path
- Is the device physically powered and still in its expected location/range?
A non-WakeUp node that stops responding can be marked Dead; physical power is supporting evidence.[1]
- Yes — power and placement look normal → What does communication and mesh-path evidence show?
- No — power/placement issue is proven → Physical power or placement is the first failing layer
- What does communication and mesh-path evidence show?
Use available communication, retry, and route/neighbor evidence before mutating the network.[1][3]
- Evidence points to a path problem → Mesh communication evidence points to the path
- Path looks healthy but node still does not respond → The Dead-node cause is not yet isolated
- Evidence is inconclusive → The Dead-node cause is not yet isolated
- Use a controller or wider-network diagnosis
A controller outage or multi-node failure is outside this single Dead-node page.[3]
- Use a sleeping-node diagnosis
Asleep/Awake follows Wake Up CC semantics and is not the Dead-node path.[1]
- The node is not in the Dead state
Unknown or Alive requires a different observation and should not be forced through Dead-node troubleshooting.[1]
- The status/capability evidence conflicts with this Dead-node path
Preserve the exact state and capability evidence for a separate investigation instead of assuming physical power type.[1]
- Physical power or placement is the first failing layer
Restore the normal power/placement condition before any network removal or reset.[1]
- Mesh communication evidence points to the path
Keep the node enrolled and investigate the proven communication path rather than removing it.[1][3]
- The Dead-node cause is not yet isolated
Preserve the node and collect controller, communication, and topology evidence before any destructive network action.[1][3]
Detailed diagnosis
1. Gate on the exact node status
Continue only when the node is Dead. Asleep/Awake, Unknown, or Alive must leave this diagnosis rather than being forced through Dead-node logic.[1]
2. Check the Wake Up CC boundary
Z-Wave JS uses Wake Up CC support, not a simple battery-versus-mains label, to distinguish sleeping-node states from the Dead/Alive model.[1]
3. Check physical power and obvious range changes
A non-WakeUp node that no longer responds may simply be unpowered or no longer reachable from the mesh. Confirm power and recent physical changes before mutating network state.[1]
4. Inspect communication and route/neighbor evidence
Use available communication, retry, and route/neighbor evidence before deciding that the Z-Wave path is the failing layer.[1][3]
5. Preserve network state if the cause is not proven
Do not use Remove Failed Node, exclusion/re-inclusion, factory reset, NVM restore, or a whole-network heal as a probe for temporary unreachability.[1][3]
Supported scenarios
These observations narrow the Dead-node path; they do not justify removing or re-including the node.
The Dead node is not powered or no longer physically reachable
Z-Wave JS uses Dead for a non-WakeUp node that fails to respond; a powered-off plug is an example in the documented state semantics.[1]
How to check: Verify physical power and obvious placement/range changes before network mutation.[1]
The node is powered but its Z-Wave communication path is failing
When the node remains powered, communication history and route/neighbor evidence can narrow whether the mesh path is the failing layer.[1][3]
How to check: Use controller evidence rather than repeatedly removing or re-including the node.[1][3]
Next actions and procedure boundaries
Restore normal power when loss of power is proven
If the device is simply unplugged or its normal power source is off, restore normal power and wait for the node to respond before considering any Z-Wave network mutation.[1]
Mesh evidence points to the path: preserve the node and investigate that path
Keep the node in the network and use the observed communication/route evidence for the next mesh investigation. Do not remove or replace the node merely to test a hypothesis.[1][3]
If power and mesh evidence are inconclusive, stop before removal
Preserve logs, node status, last communication, controller version, and topology evidence. A temporary Dead status does not justify deleting network state.[1][3]
Warnings and boundaries
Sources
Links were reviewed on 2026-09-09. Reachability and automated validation do not replace editorial verification of each claim.
- Z-Wave JS Node API
Z-Wave JS project · Tier A · accessed 2026-09-09 - Z-Wave JS releases
Z-Wave JS project · Tier B · accessed 2026-09-09 - Z-Wave integration
Open Home Foundation · Tier A · accessed 2026-09-09