How often should my end device poll its parent?

How often you poll will depend on your application’s requirements as well as your desired battery life or power constraints.

There are certainly worst-case values for how long your end devices can go without polling, and these are discussed in the FAQ, How long can my end device go without polling its parent? What happens after that timeout?. However, for determining how often the end device should poll, it is important to consider the Indirect Transmission Timeout, which dictates how long a parent will hold onto a packet for relaying to its child before the message is discarded. While this timeout is configurable (via the EMBER_INDIRECT_TRANSMISSION_TIMEOUT or EZSP_CONFIG_INDIRECT_TRANSMISSION_TIMEOUT), ZigBee Pro PICS (the conformance specification) dictates a prescribed value of 7.680 seconds for this timeout and therefore recommends polling at least once per 7.5 seconds to ensure reliable communication, since polling outside of this timeout can result in missed messages or missed APS ACKs.

If you are implementing an application under an official ZigBee application profile, the profile specifications generally contain more guidance about suitable rates of polling.

For example, in Smart Energy (SE), looking at the latest SE spec as of this writing (075356, revision r15), Section 5.2 (concerning stack profile features) says the following about recommended rates of polling:

In their normal operating state, ZigBee end devices shall poll no more frequently
 than once every 7.5 seconds except where this specification indicates otherwise 

for a particular device description, or under the following conditions.


	
• ZigBee end devices may operate with a higher polling rate during 

commissioning, network maintenance, alarm states, and for short periods after 

transmitting a message to allow for acknowledgments and or responses to be 

received quickly, but they must return to the standard rate indicated previously 

during normal operation.

	
• It is recommended that ZigBee end devices poll much less frequently than once 

per 7.5 seconds, especially when the device normally only communicates due to 

user interaction. To further clarify, except for one condition in the Simple 

Metering cluster (refer to DD.3.3), all cluster interactions that read or write 

attributes, or cause command exchanges should limit transactions to once every 

30 seconds.

	

Section 5.3.4 (End Device Parameters) also briefly mentions polling, saying that “an end device that is designed to receive data should poll its parent every 60 seconds”, which seems to contradict the 7.5 seconds, but that same table (Table 5.4) also contains a “Value” field for that parameter, which says “Set by stack profile”, so the Stack Profile section (5.2 as quoted above) takes precedence here.

An informal interpretation of all this would be that your end device should operate in one of a few poll intervals depending on what’s going on:

• If your device never receives data except in response to something (which seems unlikely in the SE profile, where the ESP may send DRLC events asynchronously), it only needs to poll rarely (to stay connected to the network and pick up the occasional network-wide events, like channel/key/PANID changes), except when waiting on ACKs/responses for things it sent.

• If your end device expects to receive occasional asynchronous transmissions (like commands or reports) from other devices, it should poll at least once a minute to increase the likelihood of catching these events (bearing in mind that any poll rate beyond once per 7.68 secs cannot ensure reliable delivery, but if you’re lucky you might catch 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 you’re a sleepy device).

• If your end device needs to participate in a reliable APS transaction with another node, such as during a command/response exchange, commissioning, key establishment or service discovery process or anything where asynchronous transmissions are sent to this end device regularly, it should poll about once per 7.5 seconds to make sure it gets the messages and ACKs them in a timely manner.

• If your end device is undergoing some low-latency or high-bandwidth process, like streaming of data, firmware uploading, joining/rejoining, or the “real time feedback” loop described in Section D.3.3.2, it should probably poll more often (like once every 1-2 seconds) to reduce latency and maximize throughput.

This may be a bit vague and perhaps somewhat confusing, but this is ZigBee SE’s attempt to balance flexibility (and varying battery life requirements) with reliability and standards-based interoperability, so ultimately the application developer has to make his/her own choices about what specific poll rates to use under which circumstances.