Reports and direct actions

Two kinds of message

A sensor tells someone how things are. A switch tells a light what to do. Zigbee carries both, and they do not take the same road. The first goes to whoever asked for it. The second can go from device to device without a controller anywhere near it.

Reports are configured

A temperature sensor does not announce every attribute on its own. A controller configures reporting: send MeasuredValue when it changes by a set amount, or after a set time. Until someone asks, the sensor may say nothing. The report climbs through the routers to the coordinator and is handed to the host, which is where software such as Zigbee2MQTT sits. From there it can leave on MQTT, which is a different network again.

Bindings are stored relations

A binding is a record kept in a device: this client cluster points at that destination. It is not a cable, and nothing runs between the two ends until a press. When the wall switch is pressed with the binding in place, it sends On/Off straight to the light, through forwarding devices if the light is not next door. In this house the light happens to be the switch's parent, so the path is one hop. The coordinator and the host are not on it, and the light still comes on with the host unplugged.

Remove the binding and the same press becomes a report to the controller. The host decides what to do and sends a command down. That works while the host is up and fails quietly when it is not, and it is the price of a controller that can do more than a binding can.

Groups and scenes

A group lets one command address several lights. Each light keeps its own list of the groups it belongs to, so adding light B to the group is a change in light B, not in the switch. A scene is a saved set of attribute values that can be recalled by one command, so a room changes state together.

What to check on a real network

Support varies. A binding needs matching clusters at both ends, which is why lesson 8 matters, and products and controllers differ in how many bindings, groups and scenes they hold. When a bound switch does nothing, read the cluster lists before blaming the radio.

Common mistakes

• Assuming every command goes through the hub. A compatible bound device acts locally, and the hub is not required to start the action.
• Treating a binding as a wire. It is a stored relation in the source device, and it fails when the clusters at the two ends do not match.
• Expecting a sensor to report without being set up. Reporting is configured. An unconfigured attribute stays silent.