For the definition of the sleepy end device and polling mechanism, please refer to ug102 Section 14.
The length of time that the parent will hold on a message for sleepy end devices(SEDs) is determined by the EMBER_INDIRECT_TRANSMISSION_TIMEOUT (~7.68 seconds, should not be changed) which might be much shorter than the expected long poll interval. Therefore, referring to How often should my end device poll its parent?, if the SED needs to receive incoming messages and incoming application support sub-layer acknowledgment (APS ACKs) reliably, the SED should poll at least once within the EMBER_INDIRECT_TRANSMISSION_TIMEOUT (or EZSP_CONFIG_INDIRECT_TRANSMISSION_TIMEOUT) to ensure the data can be retrieved from the parent.
However, it is harmful to the battery life of SED if the SED constantly polls the parent using a long poll interval shorter than 7.68 seconds. Instead, the “Forcing Fast Polling” mechanism can be used to make the SED enter fast poll mode every time the SED needs to initiate a transaction and wait for APS ACKs and stay in normal long poll mode(~300 seconds) if there isn’t any transaction needed (referring to ug102 Section 14). This method only applies to the transactions initiated by the SED. So, what if the occasional initial transaction is sent by the devices other than the SED? According to How often should my end device poll its parent? it should poll at least once a minute to increase the likelihood of catching these initial transaction messages. However, any poll rate beyond once per 7.68 secs cannot ensure reliable delivery but increasing the poll rate will increase the opportunity of successfully catching the incoming event, especially if it’s being retried every 9 seconds or so, which is contingent on APS retries being enabled and the sender knowing the receiver is a sleepy device. This is easy to implement but sacrifices the reliability of the transmission. Therefore, next, this article will introduce a reliable way for SED to receive asynchronous transmissions from other devices without frequent polling.
To better improve the reliability of receiving asynchronous messages for an SED from other devices, we can use the Poll Control Cluster (referring to How does the polling mechanism work? ) in the ZCL.
The main goal of this cluster is to provide a mechanism for the remote management of SED’s polling rate. However, since this cluster can make the SED responsive for a certain period of time which is decided by the controller, it is also useful for reliable transmission between SED and other transmission initiators. For example, a remote device sends a configuration message to an SED by using poll control cluster which makes sure the SED is awake and polling when the message received by SED’s parent.
The general strategy for this type of interaction between SED and other transmission initiators is as follows:
1. The SED which implements the server side of this cluster sends a query to the client on a predetermined interval (Check-inInterval) to see if the client would like to manage the poll period of the end device in question. Before receiving the Check-in Response, the SED will fast poll its parent.
2. The paired Poll Control Cluster Client receives the Check-in command and sends out the Check-in Response with a command indicating that the server should begin fast poll mode if there is some message the client wants to send to SED. We can also send a Check-in Response with a command indicating that the server should not begin fast poll mode if the client doesn’t have anything wants to send to the SED
3. The SED server will enter fast poll mode and polls its parents every ShortPollInterval if the fast poll mode is indicated to be on by the paired client.
4. During the fast poll mode period, the client can send any messages to the SED server and they will all be received by the SED server without dramatic failure if the ShortPollInterval is set correctly.
5. After sending all the messages, the paired server can send a Fast Poll Stop command to SED during Check-in to make it back to the normal long-poll period.
The example below shows how to implement the above strategy using S3Switch, S3Light sample applications and Mesh Wireless Starter Kit under EmberZNet SDK – 188.8.131.52 with toolchain IAR 8.30. Different versions of SDKs and toolchains can be supported and please refer to Gecko SDK Suite Toolchain Support for more information.
1. Create a Z3Light example and use it as the parent of end devices. Optional: name the project as Z3Light_Router.
2. Create a Z3Switch example and use it as the SED which implements the server side of Poll Control cluster. Optional: name the project as Z3Switch_SED. After the creation:
3. Create another Z3Light example and use it as the end device which implements the client side of the Poll Control cluster and control the polling of Z3Switch_SED remotely. Optional: name the project as Z3Light_EndDevice. After the creation:
4. Generate, build and upload the three projects above to 3 different WSTK boards.
5. After using “plugin network-creator-security open-network” CLI command, use CLI command “plugin network-steering start 0” in Z3Light_EndDevice console to make it join the network the Z3Light_Router created. Check whether the PAN ID of Z3Light_EndDevice is the same as Z3Light_Router’s to make sure they are in the same network. If they are not in the same network, use “network leave” command to leave the network and do the network steering again until they are in the same network.
6. Press the button 0 of Z3Light_EndDevice to make it enter Find and Bind target mode. Do the same joining process to the Z3Switch_SED. This time how long the SED slept before waking up will be printed in the console. Besides, note that during the sleep, the SED will not accept any CLI commands.
After the successful join, the Z3Switch_SED should be bonded to the Z3Light_EndDevice. Check it by issuing “option binding-table print” CLI command and clusters 0x3, 0x6, 0x20(poll control cluster) with Z3Light_EndDevice’s node ID should appear in the table. If not, issue “network leave” in the Z3Switch_SED console, Press the button 0 of Z3Light_EndDevice again and make Z3Switch_SED join the network again using network steering.
7. Now the Z3Switch_SED should check in with Z3Light_EndDevice every 20 seconds and the check-in response is 0x00 which means Z3Light_EndDevice don’t want Z3Switch_SED to enter fast poll mode. Then, if we want the Z3Switch_SED to enter fast poll mode, we need to issue “plugin poll-control-client mode 1” CLI command in Z3Light_EndDevice console. After doing this, the check-in response becomes 0x01 in the Z3Switch_SED console which means that the Z3Light_EndDevice is forcing it to poll its parent Z3Light_EndDevice every ShortPollInterval. To leave this fast poll mode, just simply use “plugin poll-control-client mode 0” in Z3Light_EndDevice console.
The fast poll will automatically end in 8 seconds. This is because the value of “Default fast poll time out” under [Z3Switch_SED.isc] -> [Plugins] -> [Home Automation] -> [Poll Control Client Cluster] is set to 32 quarter seconds. “fast poll time out” can be changed on the fly using “plugin poll-control-client timeout <uint_16>” CLI command in Z3Light_EndDevice console. By doing this, the fast poll mode duration in the Z3Switch_SED can be as long as we want.
The code level implementation of this feature can also be achieved using EmberZNet. For more information about this, refer to “poll-control-client.c”, “poll-control-client-cli.c” and “poll-control-server.c”.
If you have any further question, you are welcome to contact Silicon Labs Technical Support.