|
Coming soon |
1. Introduction
Binding in ZigBee allows an endpoint/cluster identifier pair on one node to be connected to one or more endpoints on others nodes. Instead of sending multiple unicast requests, application only sends one single request to Zigbee stack. Binding mechanism is provided by the APS layer, so that the application can set up bindings using binding tables.
Binding is a one way action. Each device has its own binding table.
The binding table maps a source address and source endpoint/cluster identifier pair to one or more destination addresses and endpoints.
The BDB provides Find and Bind method to automate the creation of bindings.
| Binding Table Format |
|---|
2. How to configure Binding?
Bindings are pre-configured source-to-destination addresses. They can be configured either locally or remotely. Local binding is typically to be used for client cluster commands. Remote binding is to be typically used for attribute reporting.
2.1. Local configuration
Bindings must be configured in the binding table using the ZbApsmeBindReq().
ZbApsmeBindReq parameter shall be set as follow:
- srcExtAddr: local client Extended Address
- dst.extAddr: remote server Extended Address
The prototype of the API is :
void ZbApsmeBindReq(struct ZigBeeT *zb, ZbApsmeBindReqT *bindReqPtr, ZbApsmeBindConfT *bindConfPtr);
Parameters:
- zb : Zigbee stack structure
- bindReqPtr : APSME-BIND.request
- bindConfPtr : APSME-BIND.confirm
Here is a code example that utilizes the ZbApsmeBindReq API.
struct ZbApsmeBindReqT bindreq;
struct ZbApsmeBindConfT bindconf;
bindreq.srcExtAddr = xx;
bindreq.srcEndpt = yy;
bindreq.clusterId = cluster_id;
bindreq.dst.mode = ZB_APSDE_ADDRMODE_EXT;
bindreq.dst.endpoint = endpoint;
bindreq.dst.extAddr = zz;
ZbApsmeBindReq(zb,&bindreq,&bindconf);
if(bindconf.status != ZB_WPAN_STATUS_SUCCESS)
{
APP_DBG("Local Bind failed .\n");
}
APP_DBG("Binding the client with ext_addr = %#08llx dest endpoint: %d.\n", bindreq.dst.extAddr, bindreq.dst.endpoint);
2.2. Remote configuration
Bindings may also be configured from a remote node using the ZbZdoBindReq().
ZbZdoBindReq parameter shall be set as follow:
- srcExtAddr: remote server Extended Address
- dst.extAddr: client Extended Address
- target: remote server Short Address
3. Find and Bind
Finding and binding mechanism is a semi-automated method to create bindings. It can be triggered automatically if the bdbCommissioningMode is set to BDB_COMMISSION_MODE_FIND_BIND. However, Finding and binding can be started manually from the application by calling ZbStartupFindBindStart() on all endpoints, or calling ZbStartupFindBindStartEndpoint() from a specific endpoint.
Remote binding is only performed for below clusters:
- Alarm
- SE Messaging
- Poll Control
The Find and Bind is based on Identify cluster. The picture below describes how an initiator (normally client) can create binding with one or more targets (normally server) using Find and Bind method.
| Find and Bind method |
|---|
In the example projects provided with STM32CubeWB MCU Package[1], there is an application that describes how to use the Finding and Binding method. The example uses both ways to start Find and Bind : automatic on Router1 (ZR1), and manual on Router2 (ZR2).
As mentioned before, the remote binding is not applicable for all clusters. In our use case, the Router2 has a Messaging cluster client allocated, and so, after starting the Find and Bind procedure, it will send a ZDO Bind Request to the Coordinator (ZC) for the Messaging cluster. Binding entry will be added the the Coordinator Binding Table.
Local binding is performed for any local client cluster matching remote server cluster located on device in identify mode.
As IAS Warning client cluster and Messaging client are located on Router2, and IAS Warning server cluster and Messaging server are located on the Coordinator, local Binding Table of the Router2 will be updated by adding two entries.
| Find and Bind example |
|---|
According to the application setup, following bindings entries should be created:
Remote Binding
- For Messaging cluster between ZC and ZR2
→ Binding entries will be added in ZC Binding Table.
Local Binding
- For IAS Warning cluster between ZC and ZR2
- For Messaging cluster between ZC and ZR2
→ Local Binding Table entries will be created for above clusters on ZR2 side.
- For OnOff cluster between ZC and ZR1
- For Scenes cluster between ZC and ZR1
→ Local Binding Table entries will be created for above clusters on ZR1 side.
4. Attribute Reporting
The ZCL specification allows attribute reporting which configure a Zigbee device to send reports to the requestor, based on the binding table.
Attribute Reporting is often a combination of periodic & event triggered attribute report.
Attribute Report can be sent in a periodic way if value of monitored attribute does not change during Maximum Reporting Interval or value of monitored attribute does not change above reportable change threshold.
If value of monitored attribute changes above reportable change, Attribute Report will be immediately sent if no other Attribute Report was sent for at least Minimum Reporting Interval.
We can configure attribute reporting on the server in case of default attribute reporting configuration using ZbZclAttrReportConfigDefault, that means, the server will send a default report attribute to all its binding clients with the same configuration. We can also configure the client to ask for a dedicated attribute reporting using ZbZclAttrReportConfigReq, so that the server will not send the default attribute report, and instead sends the requested attribute report.
To understand these scenarios, consider a thermostat that needs to keep tracking temperature values. Instead of sending explicit requests to the sensors, sensors could be configured to send periodically attribute report to update temperature values, or to send attribute report when temperature reaches threshold value.
| Thermostat use case |
|---|
Note that:
- Attribute reporting starts after binding process. The reporting is done from server cluster to client cluster.
- Not all attributes in a cluster are reportable.
5. Acronyms and definitions
| Term | Definition |
|---|---|
| APSME | Application Support Management Entity |