01 / THE ROLE
In this lab.
The documented setup uses Zigbee2MQTT with a network-connected Zigbee coordinator and the MQTT broker. The coordinator, bridge and broker are separate dependencies. Their private identities, device list and locations are omitted from the public architecture.
02 / THE CONNECTIONS
Follow the flow.
- STEP 01Zigbee device
- STEP 02Coordinator & bridge
- STEP 03MQTT broker
- STEP 04Automation application
03 / How it works
How it works.
The bridge translates device messages into MQTT-facing information and commands in the other direction. Its interface helps manage the integration, but an available web page is not proof of radio connectivity, message delivery or application response.
04 / Persistent data & recovery
Persistent data & recovery.
Bridge configuration and network/device state may be needed to recover without re-pairing or changing device relationships. Preserve the deployment-specific recovery procedure privately. Do not assume replacing the container recreates the Zigbee network.
05 / How to check it
How to check it.
Check the coordinator connection, broker connection and a controlled device-to-application path. The documented history includes a coordinator dependency affecting startup, illustrating why a restart loop should be investigated rather than repeatedly restarted.
06 / Decisions & limits
Decisions & limits.
This is a chain of components rather than a single service with one health flag. A useful diagram makes the handoffs clear while keeping device identities and operational details private.