Zigbee2MQTT

Zigbee2MQTT

Zigbee2MQTT is the stack this project was developed under. It is not better supported because it is a better protocol. It is supported because it is the one running on the author's fleet. The other stacks lack features because they cannot be tested until Device Sentinel is installed on a system that uses them.

How Zigbee2MQTT Is Recognized

Not by the mqtt integration domain, which every MQTT device shares. Device Sentinel looks for the bridge device itself, which Zigbee2MQTT publishes through MQTT discovery.

The stack is recognized by a name ending in "Zigbee2MQTT Bridge", or by a model of "Bridge" under the manufacturer "Zigbee2MQTT". If the bridge device is present, Zigbee2MQTT is present.

Four Retained MQTT Topics

• zigbee2mqtt/bridge/state: whether the bridge is online or offline.
• zigbee2mqtt/bridge/info: carries permit_join and permit_join_end, plus the availability settings described below.
• zigbee2mqtt/bridge/devices: the roll of what actually exists, carrying each device's IEEE address, friendly name, and power source.
• zigbee2mqtt/+/availability: what Zigbee2MQTT itself says about each device, online or offline.

What the Bridge State Buys

Reading the bridge state makes two kinds of detection possible.

Pairing windows. When a device goes quiet and comes back, a recovery during an open pairing window was almost certainly a person re-pairing it by hand. The silence before it is set aside rather than learned as the device's rhythm. The episode report marks it no (pairing).

Bridge outages. A coordinator going down and coming back is recorded as two system events with the outage duration. Every silence spanning it is set aside as no (bridge down), because the gap measures the outage rather than the device.

Both are covered in more detail on The Bridge and Broker Sensors.

Reachability, and Why It Is Weaker Than It Sounds

Zigbee2MQTT publishes its own opinion of every device's availability. Device Sentinel reads it and shows it beside its own freeze verdict as confirmation, not as a verdict of its own.

The two timeouts are read from your own bridge. Zigbee2MQTT allows a mains device 10 minutes of silence before calling it offline. A battery-powered sensor spends most of its life asleep, so it judges those on a silence window of 25 hours.

On the author's reference system, 55 of 74 devices were battery end devices. For three quarters of them the "online" reading was true of a device that stopped reporting hours previous, and Device Sentinel's own learned windows were deemed more accurate.

The value of watching Zigbee2MQTT's availability topic is to confirm an offline device that is already determined by Device Sentinel to be offline, and not as a verdict of its own.

What a Zigbee2MQTT User Gets That Others Do Not

This is the answer to why other stacks are not fully supported. A Zigbee2MQTT user gets:

• Pairing windows recognized, so a hand re-pair does not teach a false rhythm.
• Bridge outages recorded and named, and the silences they caused set aside.
• A second opinion on every freeze verdict.
• A Bridge: Zigbee2MQTT sensor.

Everything else Device Sentinel does works identically on every stack, because it is built on the Home Assistant event bus rather than on any radio.