For the sake of brevity, we will refer to Realistic Use Cases (RUC) as an abbreviation throughout this discussion.
1. Introduction
This page describes how to quickly handle an On/Off Light Device with On/Off Light Switch.
The project generates a Zigbee Light Device acting as a Router and Zigbee Light Switches as End Devices.
It is a good introduction to handle and have a first approach of ST Zigbee mesh solution.
2. Functioning
This example demonstrates STM32WB applications capabilities using the Zigbee network with ST Devices to connect switch and Light bulb in different cases.
From a basic example with one switch is connected to one light bulb, it is possible to connect multi-switch at the same light bulb or to connect one switch to multiple light bulbs and all other combinations to test the ST Zigbee functionalities.
RUC Lighting |
---|
3. Getting started
This project implements a ST Zigbee mesh supporting Coordinator (ZC), Router (ZR) and End Device (ZED) features.
These features are sufficient to set up a first Zigbee network [1].
The ZED are not Sleepy ones but it is a possible extension, for more information please see Application Note [2].
3.1. Hardware requirements
P-NUCLEO-WB55[3] and STM32WB5MM-DK[4] are required to set up the demonstration.
For more information, please visit STM32WB Development ecosystem
P-NUCLEO-WB55 | STM32WB5MM-DK |
---|---|
3.2. Software and system requirements
For more information to build Zigbee application, please visit STM32WB Build Zigbee Project
To check messages from the board, use any convenient terminal software via the UART Interface, please visit Wiki: Zigbee Log via UART
3.3. Install the Zigbee network
To install the RUC example, please follow the HowTo Join a Zigbee Network and HowTo bind devices.
4. Zigbee implementation
This example will use the Zigbee cluster On/Off [5] with the following topology:
- a Gateway as ZC
- Light switches as ZED with client cluster
- Light bulb as ZR with server cluster
So, the basis topology uses 1 ZC, 2 ZR and 4 ZED, both ZR bound to 2 ZED each.
It is possible to extend devices with Zigbee clusters Level control [6], Color control[7]… to add features device.
A crucial point to note is that the server holds the attribute values, i.e., the state of the light in this case. If the client wants to know the light's state, it needs to send a "read the attribute" command to the server. When two devices are bound together, they can set up a link where the server sends the state of some attributes when they are modified. These attributes are called reportable. For instance, in a network with 2 switches and one light, if both switches are bound to the light, Switch 1 can turn the light on, and Switch 2 will be informed of the change in the light's state.
4.1. Light switch
The client command (switch) sends a message (On/Off/Toggle) to the server (light bulb). The implementation is straightforward and high-level, allowing you to choose the messages delivery method: broadcast, group or unicast. In this example, the message has sent in unicast mode, which requires binding the devices together. This approach enables configuring the reporting process and receiving an acknowledge from server.
4.2. Light bulb
After reception of a command from a client, an appropriate callback function is executed by the server.
If attribute modification, the server sends this modification to each client according to the report configuration in the local binding table.
4.3. Binding and Report process
To manage many configurations, attribute reports are used to troubleshoot issues.
So, each time a client binds to a server, a configuration report is created to notify the client of the attribute modification.
For more information please see Wiki: Zigbee Binding
Please find below the Binding process used in this example.
Binding Process |
---|
|
In case of multi-client, the report attribute is using to maintain a coherence between each client when the state of light is changed on the server.
Please find below the Report attribute process for two clients:
Report attribute Process |
---|
4.4. Retry process
When a client sends a command, there are three possible situations:
- The client doesn’t receive any response from server, indicating a communication issue.
- The client receives an acknowledgement from server, but it implies a failure in processing the command.
- Everything works fine, and the client receives successful acknowledgement from server.
To make it more reliable, a “retry” process was created when a Zigbee command from client failed.
As explained before, for all applications, all the command are sent in unicast. Once the command is sent, the server responds with an acknowledgement, if this one includes a failure message, the message will resend to the server.
Please find below the retry process and the flow chart implemented in source code:
Retry process |
---|
Flow chart |
By implementing this mechanism, the number of failed commands has significantly decreased.
5. Possible Extension
From this use case, some extensions are possible:
- Add several Light Bulb (multi-server) to observe when clients send commands and server behavior.
- Add dimmable light and switch.
- Add Color control light and switch.
- Add PIR occupancy sensor to light on/off automatically.
Below, the example shows extension with a PIR sensor and dimmable switch:
RUC Lighting extension |
---|
6. Tests and Results
To stress the system and verify its proper functioning, a series of tests has been conducted.
Test | Passed/Failed |
---|---|
Adding a server (ZR) and getting current service value | Passed |
Adding a client (ZED) and getting current service value | Passed |
Detecting and handling the case of report not received | Passed |
Correcting the issue of report not received by reading service value | Passed |
Same Zigbee cmd from multiple clients at the same time | Passed |
Different Zigbee cmd from multiple clients at the same time | Passed |
Overloading the system with sending Zigbee cmd on time (with PIR) | Passed |
Latency test | Passed |
Distance (3-hops) | Passed |
Endurance time (7 days) | Passed |
Remove Coordinator | Passed |
7. Acronyms and definitions
Term | Definition |
---|---|
ZC | Zigbee Coordinator |
ZR | Zigbee Router |
ZED | Zigbee End Device |
RUC | Realistic Use Case |
PIR | Passive Infra-Red sensor, motion detectors |