14. Zigbee应用程序框架开发指南

1 Zigbee应用程序框架开发指南 - 概述

2 Zigbee应用程序框架开发指南 - 应用程序框架结构

3 Zigbee应用程序框架开发指南 - 应用程序框架目录结构

4 Zigbee应用程序框架开发指南 - 生成应用程序配置文件

5 Zigbee应用程序框架开发指南 - 应用程序框架API

6 Zigbee应用程序框架开发指南 - 应用程序框架Callback接口

7 Zigbee应用程序框架开发指南 - 时间处理

8 Zigbee应用程序框架开发指南 - 事件

9 Zigbee应用程序框架开发指南 - 属性管理

10 Zigbee应用程序框架开发指南 - 命令处理和生成

11 Zigbee应用程序框架开发指南 - 命令行接口（CLI）

12 Zigbee应用程序框架开发指南 - 调试打印接口

13 Zigbee应用程序框架开发指南 - 多网络支持

14 Zigbee应用程序框架开发指南 - 睡眠设备

15 Zigbee应用程序框架开发指南 - 应用程序框架插件

16 Zigbee应用程序框架开发指南 - 扩展ZigBee Cluster Library (ZCL)

17 Zigbee应用程序框架开发指南 - 使用Ember AppBuilder设计应用程序

18 Zigbee应用程序框架开发指南 - 应用框架V6

14 睡眠设备

14.1 介绍

Zigbee应用程序框架包含对休眠终端设备的支持。休眠终端设备是ZigBee网络中的一个设备,大部分时间都处于休眠状态, 并且仅在需要执行某些特定操作如GPIO中断或轮询其父是否有任何消息在网络上等待它时才唤醒。

14.2 轮询

休眠终端设备不直接从网络上的其他设备接收数据。相反，它们必须轮询父进程以获取数据，并从父进程接收数据。父设备充当睡眠设备的代理，在孩子睡觉时保持清醒并缓冲消息。因此，休眠终端设备的睡眠/唤醒周期由ZigBee网络上的两个重要超时控制:APS重试超时(7.8秒)和终端设备轮询超时(由父设备默认为5分钟定义)。这两个超时对应于休眠终端设备上的两个轮询间隔:SHORT_POLL和LONG_POLL间隔。这些时间间隔有时分别被称为“nap duration”和“hibernation duration”。因此，当设备处于在SHORT_POLL时间间隔内不断发送轮询的状态时，它就被认为是在“napping”，因为它在很短的时间内就会不断醒来进行轮询。当设备在LONG_POLL时间间隔上发出轮询时，它被称为“hibernating”，因为它的睡眠时间间隔更长。

当设备需要响应从网络发送给它的消息时，它将进入一种状态，在此状态中，它将在SHORT_POLL间隔(napping)上轮询其父设备。这将确保它的父设备收到的任何消息都将立即被休眠的终端设备检索并处理。当设备在网络上不再需要响应时，它将返回到LONG_POLL interval (hibernating)上轮询父设备的状态，这将确保子设备在父设备的子表中保持活动状态，但不会响应网络。

在此期间，根据SHORT_POLL间隔，休眠端设备以增加的速率进行轮询，称为“Short Poll Mode”、“Fast Poll Mode”或简称为“Napping”。所有这些术语的意思都是一样的。休眠设备轮询其父设备的速度比终端设备的父设备保留终端设备的消息所需的7.68秒要快。通常，SHORT_POLL间隔将小于1秒，以确保以有序的方式发送给父级的所有消息，因为父级只需要保持一条消息。如果从父级检索消息的速度不够快，则可能会被同一子级或其他子级的其他传入消息覆盖。有关快速轮询的更多信息，请参见14.2. Forcing “Fast Polling”的部分。

14.2.1 SHORT_POLL间隔

短轮询间隔是在发送或接收消息的过程中，终端设备在轮询其父设备之前可能等待的时间。此间隔必须小于间接传输超时(ZigBee PRO networks的标准为7.68秒)。这是因为在发送设备决定重新发送消息之前，终端设备必须向发送设备发送一个APS ACK。最终的结果是,为了让休眠终端设备可靠地与网络上的其他设备通信,他们必须知道什么时候发送或接收消息的过程中,必须唤醒和调查父母中的数据轮询间隔短,直到事务完成的消息。

编译时设置
短轮询间隔在框架中由EMBER_AF_SHORT_POLL_INTERVAL以四分之一秒定义。Ember AppBuilder接口没有允许用户操作这个值的GUI小部件。它默认为一个单位，等于1 / 4秒。如果您希望更改默认的EMBER_AF_SHORT_POLL_INTERVAL，您可以在应用程序配置的“include”选项卡的宏部分为它添加一个定义。

运行时设置
在应用程序框架中，EMBER_AF_SHORT_POLL_INTERVAL被分配给一个名为emberAfNapDuration的全局变量，该变量可以在运行时使用EMBER_AF_SET_NAP_DURATION (int32u duration)宏进行修改。

注意，在stack release
4.7中，变量emberAfNapDuration已经被弃用，并被回调emberAfGetShortPollIntervalQsCallback()所取代。同样，函数EMBER_AF_SET_NAP_DURATION也被弃用，并被函数emberAfSetShortPollIntervalQsCallback(int16u shortPollIntervalQs)所取代。

14.2.2 LONG_POLL间隔

长轮询间隔是终端设备在轮询其父设备之前等待的时间量，否则它是不活动的。这个间隔应该(但不是必须)比“End Device Poll Timeout”短，后者是一个Ember父设备在从子设备表中删除它之前等待它的子设备发出消息的时间。对于Ember设备，默认的结束设备轮询超时时间为320秒或5分钟多一点。

注意:ZigBee协议没有提供超时子表中条目的标准方法。取而代之的是，存在几种启发式机制来对子表中的条目进行老化。例如，如果父进程听到一个它认为是它的子进程与另一个父进程交互或由另一个父进程表示的设备，它可能会从它的子进程表中删除这个条目。Silicon
Labs已经开发出一种更确定的机制来应对孩子的老化，称为“终端设备轮询超时”(End Device Poll
Timeout)。一个Ember父节点期望子节点在终端设备轮询超时期间“检入”它们的父节点。如果不这样做，则假定它们已经消失，并将它们从子表中删除。终端设备轮询超时在stack/include/ember-configuration-default
.h中定义

终端设备不能在其父设备上配置终端设备轮询超时，而且在父设备和子设备之间通信终端设备轮询超时值方面也没有一致的协议。取而代之的是，Silicon Labs在父设备和子设备上都配置了一个假定的端设备轮询超时。这个值在stack/include/ember-configuration-default .h中定义。

根据它的睡眠特征、电池寿命考虑，子设备可能希望睡眠超过假定的终端设备轮询超时。这样做是自由的。但是，如果它这样做，它必须在再次与网络交互之前修复与其父节点的网络连接。通常，有可能这样做的设备在发送数据之前应该检查网络的状态，看看是否需要进行任何修复。一个休眠的设备永远不应该唤醒并假设它的父设备仍然在那里，除非它确切地知道它的父设备配置了一个它所服从的、双方都同意的终端设备轮询超时。有关终端设备轮询超时的更多信息，请参见位于stack/include/ember-configuration-default .h的配置头文件。

编译时设置
长轮询间隔在框架中由EMBER_AF_LONG_POLL_INTERVAL以四分之一秒定义。可以在stack configuration选项卡中操作长轮询间隔。EMBER_AF_LONG_POLL_INTERVAL也可以在stack选项卡的“include”部分定义。

运行时设置
在应用程序框架中，EMBER_AF_LONG_POLL_INTERVAL被分配给一个名为emberAfHibernateDuration的全局变量，该变量可以在运行时使用EMBER_AF_SET_HIBERNATE_DURATION(int32u duration)宏修改。