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

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

17 使用Ember AppBuilder设计应用程序

AppBuilder是一个用于生成zigbee兼容的应用程序的工具。AppBuilder由两部分组成: Zigbee应用程序框架和用于配置所包含的源代码的图形工具。Ember AppBuilder图形化工具既是一个独立的应用程序，也是一个Simplicity Studio插件。AppBuilder为您提供了一个用于打开或关闭嵌入式Cluster的接口，以及编译成最终应用程序的代码中的特性。

AppBuilder旨在满足以下目标:

• 为Silicon Labs无线平台快速创建zigbee兼容的应用程序。
• 通过提供标准的SE和HA应用程序，支持快速开发并缩短客户上市时间。

17.1 ZCL概念

17.1.1 定义

ZigBee Application Profiles
ZigBee application profiles为应用程序组中的所有设备指定通用设置(例如安全性、连接参数和轮询率)。应用程序配置文件还精确地指定必须为应用程序组中的每个设备支持哪些Cluster(protocols)。

AppBuilder目前支持6个Zigbee应用程序配置文件:

• Zigbee 3.0
• Home Automation (HA)
• Smart Energy (SE，前AMI或自动化抄表基础设施)
• Commercial Building Automation (CBA)
• ZigBee Light Link (ZLL)
• Health Care (HC)

Clusters
每个ZigBee Cluster定义一个应用程序级协议。这些协议(或cluster)定义了特定ZigBee设备的功能。任何具有网络背景的人都可以将cluster看作是在ZigBee规范中封装的应用程序协议。

ZigBee Cluster Library (ZCL)是一个指定ZigBee设备使用的cluster的文档。原始ZCL文档有30个clusters，其中大多数cluster被至少一个设备在ZigBee HA应用程序配置文件中指定为必需或可选。SE应用程序配置文件使用了ZCL中指定的一些cluster，但也指定了SE独有的新cluster。

Devices
ZigBee设备可以看作是cluster的集合。例如，一个开/关灯开关和一个开/关灯是HA配置文件中31个设备中的两个。一个配置文件中的所有设备都必须使用相同的安全性。有关于轮询率、启动参数、应该实现哪种类型的ZDO消息等方面的建议，其思想是这些设备必须在同一网络上互操作。如果设备具有不同的安全设置，则它们不能连接在一起。如果用户从公司a购买一个HA设备，并从公司B购买一个HA设备，因为他们使用相同的应用程序配置文件，其中一个设备应该能够加入另一个设备。

如果两个ZigBee设备在一个经过认证的ZigBee stack上，它们可以互相路由。换句话说，它们可以在应用程序级别交换消息。在使用应用程序配置文件之前，不能保证应用程序级别的互操作性。这些标准的应用程序配置文件使AppBuilder能够生成兼容的ZigBee应用程序。

HA on/off灯有以下实现:

• Identify server (required by all)
• Groups server
• Scenes server
• On/Off server

HA on/off灯开关有以下实现:

• Identify client
• Groups client
• Scenes client
• On/Off client

开/关灯开关可以发送开/关或切换信息，说明开/关灯需要理解和遵守。

17.1.2 关于集群和属性的更多信息

Cluster指定两件事:属性和命令。属性是定义良好的数据片段，存储在设备上，可以由外部设备读取(有时是写入)。命令指定交换的空中消息。ZCL定义的每个命令都是单向的，因为它是由一方(客户机或服务器)发送并由另一方接收的。一个设备只能实现cluster的一端，或者它可以实现cluster的两端。

例如，“HA on/off Light”实现“on/off” Cluster的服务器端，而“HA on/off Light Switch”实现“on/off” Cluster的客户端。这定义了灯开关发送“开”、“关”和“切换”命令，灯可以接收(和理解)。它还定义了一个名为“on/off”的布尔属性，表示设备的当前状态。

注意:ZigBee经常使用术语“in-cluster-list”和“out-cluster-list”来代替服务器和客户端。“in-cluster-list”是受支持的服务器Cluster的列表，而“out-cluster-list”是受支持的客户机Cluster的列表。

在大多数情况下，Cluster的服务器端包含所有属性，而客户端是发起空中交换的端。在大多数情况下，客户端发送一条消息，而服务器应答该消息。

17.1.2.1 Identify Cluster示例

由ZCL定义的客户机/服务器交互在图9所示的Identify示例中进行了说明。

图9 Cluster 示例: Identify
与许多Cluster一样，Identify Cluster是一个相当简单的Cluster。右下角显示单个属性，标识时间。
Identify cluster 用例
一个用户在一个房间里准备了一个12盏灯的网络，并且必须将其中的6盏灯连接到一个单独的开关上。每个灯的MAC地址用于将其与开关相关联。所有12个灯的MAC地址可以通过使用供应工具和低功率广播或使用每个灯指示房间或位置的令牌(在安装时设置)来发现。“Identify”功能可以用来确定哪6个MAC地址对应于用户想要绑定到开关上的6个物理灯。使用Identify cluster，用户可以分别告诉每一盏灯“识别”自己(例如，闪烁，让它可以被看到)。
Identify cluster定义了设备如何进入和退出Identify模式的协议。在上面的例子中，供应工具实现了identify集群的客户端，而需要识别的light或设备实现了服务器端。

当客户端想要告诉设备“开始识别”时，它会发送“Identify”命令并指定一段时间(以秒为单位)来继续识别。当identify time属性(每秒递减)达到0时，或者当设备收到identify time值为0的“identify”命令时，设备停止识别。

图a1中的第一个消息打开了“identify”。当identify被打开时，一个时间段也被包含在消息中。例如，假设identify打开了30秒。第二条消息显示客户端(配置设备)查询服务器(light)，以确定标识过程中还剩多少时间。

因为可以将查询消息发送给组，所以可以将设备设置为它正在标识的模式，然后使用PC或供应工具确定组中的哪个设备正在标识。如果设备支持开始识别的物理线索，这是有用的。然后，可以戳设备(按钮按下，磁铁棒，等等)开始识别，并可以发送一个组消息来将MAC地址映射到物理设备。

17.1.2.2 Temperature Measurement Cluster示例

图10展示了cluster的另一个示例。这个例子显示了温度测量。

图10 Cluster 示例：Temperature measurement

注意，这个集Cluster没有命令——它只有属性。在这种情况下，该设备实现温度测量，例如恒温器。此示例包括测量值、最小测量值和最大测量值。在没有命令的情况下，这个Cluster依赖于ZCL中定义的全局命令。全局命令定义用于读取、写入、发现和报告属性的消息。

注意:14个全局命令读取属性、写入属性、配置属性报告、发现属性和报告属性值。只包含属性的Cluster易于理解和实现，因为全局命令已经实现。

为了读取这个Cluster的属性值，需要使用全局读取属性命令。此消息包含要读取的属性的属性ID。在组合中，集群和属性ID提供惟一标识。在嵌入式方面，这使得将所有属性集中在一个表中成为可能。这些属性的所有代码都是通用的共享代码。

因此，例如，当添加四个温度测量传感Cluster时，对flash的影响是最小的，因为没有额外的命令。对RAM的影响取决于每个Cluster添加的属性数量。

ZigBee Cluster Library提供的应用程序级协议使两家公司可以单独开发产品，并让它们一起工作，而不必一起进行测试。

17.2 Ember AppBuilder和应用程序框架架构

AppBuilder是一个GUI工具，它是Simplicity Studio桌面应用程序的一部分，用于配置Zigbee应用程序框架代码。AppBuilder从已安装的堆栈目录中读取配置数据。位于tool/appbuilder中的.properties和.xml文件告诉appbuilder它需要知道的关于相关堆栈的所有信息。通过解释堆栈中的这些配置文件，AppBuilder能够生成完整的Zigbee应用程序所需的适当配置数据和项目文件。

图11显示了AppBuilder如何与Zigbee应用程序框架一起工作。

图11 AppBuilder和应用程序框架是如何工作的

17.2.1 AppBuilder GUI

GUI不生成任何代码—所有代码都已经存在。代码使用# define进行保护，如图12所示

图12 它是如何工作的?(GUI)

在图12中，Ember AppBuilder GUI显示在左边。GUI的配置输出显示在右边。GUI生成一组# define，称为生成的配置。在构建时，编译后的代码包括由Ember AppBuilder生成的配置文件。通过使用# define，可以打开或关闭嵌入代码的不同特性。

您可以从GUI中选择一个预先定义的设备，该设备指定一组已建立的Cluster，或者您可以选择您自己的自定义设备。stack选项可用于安全性、PAN ID、xPAN和睡眠时间(即nap/hibernate)。HAL选项可用于平台(SoC或EZSP主机)、引导加载程序、调试级别、串口和GPIOs。

例如，睡觉就是#defines之一。如果一个设备是一个休眠设备，您将获得一个休眠设备的所有代码。如果没有，所有用于休眠设备的代码都将从构建中排除。这种方法非常模块化。如果您尝试在没有特定Cluster的情况下构建，那么很容易确定您什么时候离开了模块，而另一段代码期望该Cluster出现。
重要的是要理解您可以选择特定的设备或特定的Cluster。在选择设备时，它指定了为了符合ZigBee规范而应该使用的确切Cluster。这是确保设备符合ZCL规范的简单方法。

睡眠时间包括nap和hibernate时间。nap时间配置使向设备可靠地发送消息成为可能，前提是nap时间小于用于从处于睡眠状态的设备的父设备检索消息的超时时间。hibernate配置允许比间接传输超时时间更长的睡眠间隔。

您可以设置PAN ID、安全级别、扩展PAN，并指定执行连接操作时使用的首选通道。HAL部分指定了平台。例如，如果选择EM357 SoC，则可以选择引导加载程序、调试级别和要使用的串行端口，并指定如何配置GPIOs。