ZHA

ZHA

What Works Today

Device Sentinel recognizes ZHA from the registry: a device whose integration domain is zha proves ZHA 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 ZHA. 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 coordinator 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 coordinator layer is not read. Four things are absent on a ZHA system:

• Pairing windows recognized.
• Coordinator outages recorded.
• A second opinion on a freeze verdict.
• A coordinator sensor.

The reason is simple and not a matter of priority: there is no ZHA 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 pairing is observable through the zha.permit service call, which fires when a join is opened from the Home Assistant interface. That is the common path, and it is the design that would be built. It has never been measured, so treat it as a plausible starting point rather than a fact.

It is not known whether ZHA exposes anything equivalent to a coordinator liveness state. It is not known how ZHA reports a device's availability, or what a device looks like when it is unreachable as against merely quiet.

A Permanent Limit

A join opened out of band, by pressing a button on a router or by Touchlink, calls no service at all. Device Sentinel cannot see it, and no amount of work will change that.

This is a property of how ZHA works rather than a gap waiting to be closed, and it is stated here so it is not discovered later as a disappointment. Those recoveries fall to the per-device debounce, which is what catches them today.

The Ask

Adding the coordinator 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.

Three captures would settle most of it:

• The events fired when a join window opens from the interface, and when it closes.
• Whatever entity or attribute reports the coordinator's own state, if one exists at all.
• The state and attributes of a device when it is unreachable, beside the same device when it is merely quiet.

How to Send It

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

A capture from a live system carries device names and addresses. 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 a real system are committed to the repository, and the tests replay them.