Z Wave

Z-Wave

What Works Today

Device Sentinel recognizes Z-Wave JS from the registry: a device whose integration domain is zwave_js proves Z-Wave JS is running. That is the whole of the detection, and it is not new work.

Because everything else is built on the Home Assistant event bus rather than on any radio, almost all of Device Sentinel works identically on Z-Wave. Freeze detection, battery detection, signal detection, the reports, the problem list, the daily brief and the notifications all behave exactly as they do anywhere else. Restarts, MQTT broker outages where a broker is present, and integration reloads are all recorded normally, as described on What Is Recorded About Your House.

Where a controller cannot be read, an intervention is caught by the per-device debounce instead. A device that was unavailable long enough that its return looks more like someone fixing it than like a recovery has its gap set aside rather than learned. That is the same mechanism every house used before any coordinator could be read, and it is described on How Device Sentinel Learns.

What Is Missing, and Why

The controller layer is not read. Four things are absent on a Z-Wave system:

• Inclusion windows recognized.
• Controller outages recorded.
• A second opinion on a freeze verdict.
• A controller sensor.

The reason is simple and not a matter of priority: there is no Z-Wave hardware on the author's fleet. Nothing here ships on the strength of documentation alone, because documentation is where wrong assumptions come from. A capability is built against a capture from a real system, and there is no capture.

What Is Known and Unverified

Documentation suggests that inclusion is observable as an event rather than as a state that can be read back. That is a different shape from Zigbee2MQTT, where the current state is retained and arrives the moment Device Sentinel subscribes, so a reader of events would have to follow the window as it happens rather than ask for it. None of this has been measured.

One rule is already settled and waits only on a way to read it. An operator-driven inclusion is a person's hand on the network, so the silence around it should be discarded rather than learned. A SmartStart automatic rejoin is the network healing itself, so its silence is a real measurement and should be learned. Whether the two can be told apart from what Z-Wave JS publishes is exactly the question nobody has answered.

It is not known whether the controller exposes a readable liveness state. It is not known what marks a device as dead rather than quiet.

What Cannot Yet Be Said

Unlike ZHA, where an out-of-band join is known to be undetectable, no permanent limit has been established for Z-Wave. There may be one. Anything an operator can do that publishes nothing to Home Assistant would be invisible in the same way, but whether that case exists here has not been checked, and this page will not invent it.

The Ask

Adding the controller layer needs raw output from a live system. Not a description of it, and not a link to documentation: documentation is where the unverified claims above came from.

Four captures would settle most of it:

• The events fired when inclusion opens, and when it closes.
• The same for an operator inclusion beside a SmartStart rejoin, so the two can be compared.
• Whatever the controller exposes about its own state, if anything.
• The state and attributes of a node the controller has marked dead, beside one that is merely quiet.

How to Send It

Open an issue on the repository with the raw output attached. Say which controller hardware and which integration version, because both change what is published.

A capture from a live system carries device names and network identifiers. Strip or rename anything you would not put on a public page before attaching it. Where the raw form matters for the structure, say so in the issue and it can be handled privately.

What happens next is that the capture becomes a test fixture, and the behavior it proves is built against that fixture rather than against documentation. The Zigbee2MQTT work was done exactly this way: the captures from the reference fleet are committed to the repository, and the tests replay them.