How long can my end device go without polling its parent? What happens after that timeout?
EmberZNet router/coordinator nodes require that their end devices (even non-sleepy ones) poll their parent at least once within the End Device Poll Timeout (as set by EMBER_END_DEVICE_POLL_TIMEOUT or EZSP_CONFIG_END_DEVICE_POLL_TIMEOUT, specified in seconds or minutes and left-shifted by EMBER_END_DEVICE_POLL_TIMEOUT_SHIFT or EZSP_CONFIG_END_DEVICE_POLL_TIMEOUT_SHIFT). Otherwise, these devices will be removed from the child table at the parent, effectively being aged out of the network. This is done to ensure that the child table slot is not permanently reserved for an end device that has been removed from the network ungracefully (no Leave notification was heard from that device); it also ensures that the parent and child remain in sync about which child belongs to which router parent. An example value for these constants are 6 for shift and 5 for timeout, meaning that the effective end device poll timeout is 5 * 2^6 = 5 * 64 = 320 seconds.
The default values can be found in ember-configuration-defaults.h under <zidgbee_stack>/stack/config/..
When a successful poll is processed by the parent node, the timeout is reset on that side, and when the ACK for that poll is received at the child, the child resets the timeout on his side. To accomodate devices on stacks that do not support polling by non-sleepy end devices, the parent node will still reset the timeout on his side whenever the child sends an outgoing message, but the end devices running EmberZNet will not reset the timeout on their side for outgoing messages, so polling should still be done to keep the timeout “alive” on both sides of the connection.Since Zigbee Specification R21 the limits of the timeout mechanism are between 10 seconds and 16384 minutes (approx. 11 days).
The Legacy calculation method:
Regarding the limits of the timeout mechanism, the total timeout value is determined by timeout (T) shifted by shift (S) as T * 2^S, where the total is in seconds. This total is internally translated to a 32-bit number of milliseconds, so the limit on this timeout is the maximum 32-bit unsigned integer of milliseconds. Given this limit, maximum timeout duration can be achieved with Shift (S) = 14 and Timeout (T) = 255, for a total of 255 x (2^14) seconds, or approximately 48 days (4,177,920 seconds = 69,632 minutes = 1160.53 hours = 48.36 days).
If the end device happens to sleep for longer than the total timeout without polling its parent, the parent will forget about the child, and the end device will be required to rejoin (FindAndRejoinNetwork command) before participating in future network communications. Note that the EmberZNet stack will initiate this rejoin automatically if a PollForData action is initiated while the emberNetworkState() result is EMBER_JOINED_NETWORK_NO_PARENT (as would be the case when the child detects that the timeout has expired from its side).
The parent node, if the child has timed out, but didn't rejoin yet, can send a Network Leave Request to the child. This behavior is triggered if either of the following scenarios occur:
In both cases, the child will respond to the Network Leave Request and leave the network.
Also, keep in mind that if you want your device to receive incoming messages and incoming APS ACKs (for its outgoing messages) reliably, you should poll at least once within the EMBER_INDIRECT_TRANSMISSION_TIMEOUT (or EZSP_CONFIG_INDIRECT_TRANSMISSION_TIMEOUT) to check for data at the parent. This state is referred to as “napping” throughout the Ember documentation, while sleeping for intervals outside of this timeout is referred to as 'hibernating'.
In 《docs-05-3474-21-0csg-zigbee-specification》， the max value is 16384 minutes(about 11 days).
#define EMBER_END_DEVICE_POLL_TIMEOUT MINUTES_256
#define EMBER_END_DEVICE_POLL_TIMEOUT_SHIFT 6
So the timeout value is 256*2^6 = 16384 Seconds ?