【ember zigbee】第四章：ug103-02-fundamentals-zigbee 学习笔记(下)

• 索引
  • 【ember zigbee】序章:协议栈相关文档学习笔记
  • 【ember zigbee】第二章：ug103-02-fundamentals-zigbee 学习笔记(上)
  • 【ember zigbee】第三章：ug103-02-fundamentals-zigbee 学习笔记(中)
  • 【ember zigbee】第四章：ug103-02-fundamentals-zigbee 学习笔记(下)

1、Zigbee Cluster Library

1.1 概述

  In the Zigbee Cluster Library (ZCL), a cluster is a set of messages used to send and receive related commands and data over a Zigbee network. For example, a temperature cluster would contain all the necessary OTA messages required to send and receive information about temperature.
  To facilitate learning and management, these clusters are further grouped into functional domains, such as those useful for HVAC, Security, Lighting, and so on. Developers may also define their own clusters, if the pre-defined clusters do not meet their specific application needs.
  The Zigbee common application layer then references which clusters are used within certain applications, and specifies which clusters are supported by different devices–some clusters are mandatory, others optional. In this way, the ZCL simplifies the documentation of a particular application and allows the developer to understand quickly which behaviors devices support.
  A more detailed overview of the ZCL, the format of messages within clusters, and a set of messages that may be used within any cluster are described in the Zigbee Cluster Library Specification document (15-02017-002). Functional domain clusters are described in separate documents, such as the Functional Domain: Generic, Security and Safety document.
  Silicon Labs provides source code to easily assemble and disassemble ZCL messages, whether they are pre-defined by the ZCL or custom messages created by the developer. In addition, Silicon Labs provides a powerful tool called AppBuilder that allows developers to create and configure most of their ZCL-based application. See document UG102: Application Framework Developer Guide, for more information.

• 在Zigbee集群库（Zigbee Cluster Library 简称ZCL）中，cluster是一组用于通过Zigbee网络发送和接收相关命令和数据的消息。例如，温度群集将包含发送和接收温度信息所需的所有必要OTA消息。
• 为了便于学习和管理，这些集群进一步分为功能域，例如对HVAC，安全，照明等有用的功能域。如果预定义的集群不满足其特定的应用程序需求，开发人员也可以定义自己的集群(例如私有的cluster)。
• 然后，Zigbee公共应用程序层引用在某些应用程序中使用的集群，并指定不同设备支持哪些集群 - 某些集群是必需的，其他集群是可选的。通过这种方式，ZCL简化了特定应用程序的文档，并允许开发人员快速了解设备支持的行为。
• Zigbee Cluster Library Specification文档（15-02017-002）中描述了ZCL的更详细概述，集群内消息的格式以及可在任何集群中使用的一组消息。功能域集群在单独的文档中描述，例如功能域：通用，安全性和安全性文档。
• Silicon Labs提供源代码，可以轻松地汇编和反汇编ZCL消息，无论它们是由ZCL预定义还是由开发人员创建的自定义消息。此外，Silicon Labs提供了一个名为AppBuilder的强大工具，允许开发人员创建和配置他们的大多数基于ZCL的应用程序。有关更多信息，请参阅文档UG102：应用程序框架开发人员指南。

1.2 Inside Clusters

1.2.1 客户端和服务端

  Each cluster is divided into two ends, a client end and a server end. The client end of a cluster sends messages that may be received by the server end. The client end may also receive messages that are sent by the server end. In this sense, the client and server ends of a cluster are always complementary. In contrast to many other systems (for example, HTTP), both have the same potential for sending and receiving messages: the “client” designation does not imply a subordinate or response-only status.
  Because all commands have a sender and a receiver, each cluster is described in two parts – a server part and a client part, as shown in the following figure. A device supporting the server half of a cluster will communicate with a device supporting the client half of the same cluster.

  This equality complicates discussions; for clarity, this document always refers to “cluster end” when one of the client or the server end must be used, “cluster ends” when speaking of both client and server ends, and “cluster server” or “cluster client” when a specific end is required (usually examples).

• 每个集群分为两端，即客户端和服务器端。 集群的客户端发送可能由服务器端接收的消息。 客户端还可以接收服务器端发送的消息。 从这个意义上说，集群的客户端和服务器端始终是互补的。 与许多其他系统（例如，HTTP）相比，两者都具有发送和接收消息的相同潜力：“客户端”指定并不意味着从属或仅响应状态。
• 由于所有命令都有发送方和接收方，因此每个群集分为两部分 - 服务器部分和客户端部分，如下图所示。 支持服务器一半群集的设备将与支持同一群集的一半客户端的设备通信。
• 这种平等使讨论复杂化; 为清楚起见，当必须使用客户端或服务器端之一时，本文档总是指“cluster end”，当谈到客户端和服务器端时，“cluster ends”，以及“cluster 服务端”或“cluster 客户端”时 需要特定的结束（通常是例子）。

1.2.2 属性

  An attribute is data associated with a cluster end; the server and client ends of a cluster may each possess multiple attributes.
  Each attribute declares a 16-bit identifier, a data type, a read-only or read/write designator, a default value, and an indicator of whether its support by any implementation is mandatory or optional. The following table lists example data types.

• 属性是与cluster 端相关联的数据; 集群的服务器端和客户端可以各自拥有多个属性。
• 每个属性声明一个16位标识符，一个数据类型，一个只读或读/写指示符，一个默认值，以及任何实现的支持是强制还是可选的指示符。 下表列出了示例数据类型。

Data Type	Description
Binary data types	8, 16, 24, or 32 bits in length
Logical data type	Boolean
Bitmap data type	8, 16, 24, or 32 bits in length
Unsigned Integer	8, 16, 24, or 32 bits in length
Signed Integer:	8, 16, 24, or 32 bits in length
Enumeration:	8 or 16 bits in length
Floating Point:	2-byte semi-precision, 4-byte single precision, or 8 byte double precision
String:	binary octet string or character string; first byte is length
Time:	time of day, date
Identifier:	cluster ID, attribute ID
IEEE address type	8-byte unique IEEE address of an 802.15.4 radio

  The attribute identifier is unique only within the specific cluster end: this means that the attribute 0x0002 within the cluster server does not need to be the same as the attribute 0x0002 within the cluster client, even within the same cluster.
  The data types are fully described in the ZCL Specification. The following table is an excerpt from that document.

• 属性标识符仅在特定集群端内是唯一的：这意味着集群服务器中的属性0x0002不需要与集群客户端中的属性0x0002相同，即使在同一集群中也是如此。
• 数据类型在ZCL规范中有完整描述。 下表是该文档的摘录。

Type Class	Data Type ID	Data Type	Length of Data (octets)	Invalid Number	Analog / Discrete
Null	0x00	No data	0	-	-
	0x01 – 0x7	Reserved	-	-
General Data	0x08	8-bit data	1	-	D
	0x09	16-bit data	2	-
	0x0A	24-bit data	3	-
	0x0B	32-bit data	4	-
	0x0C – 0x0F	Reserved	-	-
Logical	0x10	Boolean	1	0xFF	D
	0x11 – 0x17	Reserved	-	-
Bitmap	0x18	8-bit bitmap	1	-	D
	0x19	16-bit bitmap	2	-
	0x1a	24-bit bitmap	3	-
	0x1b	32-bit bitmap	4	-
	0x1C – 0x1F	Reserved	-	-
Unsigned Integer	0x20	Unsigned 8-bit integer	1	0xFF	A
	0x21	Unsigned 16-bit integer	2	0xFFFF
	0x22	Unsigned 24-bit integer	3	0xFFFFFF
	0x23	Unsigned 32-bit integer	4	0xFFFFFFFF
	0x24 – 0x27	Reserved	-	-
Signed Integer	0x28 Signed 8-bit integer	1	0x80	A
	0x29 Signed 16-bit integer	2	0x8000
	0x2A Signed 24-bit integer	3	0x800000
	0x2B Signed 32-bit integer	4	0x80000000
0x2C – 0x2F	Reserved	-	-
Enumeration		0x30	8-bit enumeration	1	0xFF
	0x31	16-bit enumeration	2	0xFFFF
	0x32 – 0x37	Reserved	-	-
Floating Point	0x38	Semi-precision	2	Not a Number	A
	0x39	Single precision	4	Not a Number
	0x3A	Double precision	8	Not a Number
	0x3B – 0x3F	Reserved	-	-
String	0x40	Reserved	-	-	D
	0x41	Octet string	Defined in first octet	0xFF in first octet
	0x42	Character string	Defined in first octet	0xFF in first octet
	0x43 – 0x47	Reserved	-	-
Array	0x48 – 0x4F	Reserved	-	-	-
List	0x50 – 0x57	Reserved	-	-	-
Reserved	0x58 – 0xDF	-	-	-	-
Time	0xE0	Time of day	4	0xFFFFFFFF	A
	0xE1	Date	4	0xFFFFFFFF
	0xE2 – 0xE7	Reserved	-	-
Identifier	0xE8	Cluster ID	2	0xFFFF	D
	0xE9	Attribute ID	2	0xFFFF
	0xEA	BACnet OID	4	0xFFFFFFFF
	0xEB – 0xEF	Reserved	-	-
Miscellaneous	0xF0	IEEE address	8	0xFFFFFFFFFFFFFFFF	D
	0xF1 – 0xEF	Reserved	-	-	-
Unknown	0xFF	Unknown	0	-	-

  Attributes may be accessed over the air by use of the attribute commands described later in this document.
  Global attributes were introduced in revision 6 of the ZCL. These attributes are defined for every cluster instance on a device and function as normal ZCL attributes. Cluster Revision (attribute ID 0xFFFD) is one example of a global attribute. This attribute is a way to version each of the individual cluster specifications, to improve backwards compatibility, and allow for testing of specific versioned cluster behavior. One device may read the Cluster Revision attribute on another device to determine how to communicate certain cluster behavior to them over the air. This Cluster Revision attribute is incremented for every major change to each cluster’s specification.

• 可以通过使用本文档后面描述的属性命令来无线访问属性。
• 全球属性在ZCL的第6版中引入。 这些属性是为设备上的每个集群实例定义的，并且作为普通的ZCL属性运行。 Cluster Revision（属性ID 0xFFFD）是全局属性的一个示例。 此属性是对每个单独的群集规范进行版本化，以提高向后兼容性以及允许测试特定版本化群集行为的方法。 一个设备可以读取另一个设备上的Cluster Revision属性，以确定如何通过无线方式向他们传达某些群集行为。 对于每个群集的规范的每个主要更改，此群集修订属性都会递增。

1.2.3 命令

  A command is composed of an 8-bit command-identifier and a payload format. Like attributes, the 8-bit identifier is unique only within the specific cluster end. The payload format is arbitrary to the command type, conforming only to the general packet format guidelines as described in the ZCL Specification.
  Commands are divided into two types: global and cluster-specific. Global commands are defined in the ZCL Specification and are not specific to any cluster. These global commands were originally referred to as Profile-Wide, but have changed name to fall in line with the Zigbee 3.0 common application layer. Cluster-specific commands are defined inside the cluster definitions in the ZCL functional domain documents, and are unique to the cluster in which they are defined.
Global Commands
  Global commands are not unique to a specific cluster; they are defined in the ZCL General Command Frame (see ZCL Specification 075123r02, Chapter 7). The following table lists example profile-wide commands:

• 命令由8位命令标识符和有效载荷格式组成。与属性类似，8位标识符仅在特定群集端内是唯一的。有效载荷格式对于命令类型是任意的，仅符合ZCL规范中描述的通用分组格式指南。
• 命令分为两种类型：全局和特定于群集。全局命令在ZCL规范中定义，并不特定于任何群集。这些全局命令最初称为Profile-Wide，但已更改名称以符合Zigbee 3.0常见应用程序层。特定于群集的命令在ZCL功能域文档中的群集定义内定义，并且对于定义它们的群集是唯一的。
• 全局命令
  • 全局命令不是特定群集的唯一命令;它们在ZCL通用命令框架中定义（参见ZCL规范075123r02，第7章）。下表列出了示例配置文件范围的命令：

Messages Sent to the Cluster End Supporting the Attribute	Messages Sent From the Cluster End Supporting the Attribute
Read Attributes	Read Attributes Response
Write Attributes	Write Attributes Response/No Response
Write Attributes Undivided	Write Attributes Response/No Response
Configure Reporting	Configure Reporting Response
Read Reporting Configuration	Read Reporting Configuration Response
Discover Attributes	Discover Attributes Response
Report Attributes	Report Attributes
Default Response	Default Response

• Read Attributes: Requests one or more attributes to be returned by the recipient; replies with Read Attributes Response.
• Write Attributes: Provides new values for one or more attributes on the recipient; the reply will contain a Write Attributes Response portion indicating which attributes were successfully updated, and/or a Write Attributes No Response portion for attributes that were not successfully updated.
• Write Attributes Undivided: Updates all attributes and replies with Write Attributes Response; if any single attribute cannot be updated, no attributes are updated and this command replies with Write Attributes No Response.
• Configure Reporting: Configures a reporting interval, trigger events, and a destination for indicated attributes. Replies with Configure Reporting Response.
• Read Reporting Configuration: Generates a Read Reporting Configuration Response containing the current reporting configuration sent in reply.
• Discover Attributes: Requests all supported attributes to be sent; replies with a Discover Attributes Response.
• Report Attributes: A report of attribute values configured by Configure Reporting command.
• Default Response: A response sent when no more specific response is available (and the default response is not disabled by the incoming message).

• 读取属性：请求制定地址的zigbee设备返回一个或多个属性;回复阅读属性响应。
• 写入属性：为制定地址的zigbee设备写入一个或多个属性值;回复将包含写入属性响应部分，指示哪些属性已成功更新，和/或未成功更新的属性的写入属性无响应部分。
• 不可分割的写属性：使用写属性响应更新所有属性和回复;如果无法更新任何单个属性，则不会更新任何属性，并且此命令将回复“写入属性无响应”。
• 配置报告：配置报告间隔，触发事件和指定属性的目标。回复配置报告响应。
• 读取报告配置：生成读取报告配置响应，其中包含作为回复发送的当前报告配置。
• 发现属性：请求发送所有支持的属性;回复发现属性响应。
• 报告属性：“配置报告”命令配置的属性值报告。
• 默认应答：当没有更多特定响应可用时发送的响应（并且传入消息未禁用默认响应）。

  Since attributes are always tied to a cluster, the commands affecting attributes specify which cluster and which attributes are to be accessed or modified. Additionally, each cluster defines which attributes support which commands – for example, an attributes may be declared READ ONLY, in which case it will not support the Write Attributes command. Thus, while the command format is not clusterspecific, the attributes it describes and its result on the receiving system are both cluster-specific.
  Readers interested in more detail about the format or specific behaviors of these messages should review the ZCL Specification (075123r02)

• 由于属性始终绑定到群集，因此影响属性的命令指定要访问或修改的群集和属性。 此外，每个集群定义哪些属性支持哪些命令 - 例如，属性可以被声明为READ ONLY，在这种情况下，它将不支持Write Attributes命令。 因此，虽然命令格式不是特定于群集的，但它描述的属性及其在接收系统上的结果都是特定于群集的。
• 有兴趣了解这些消息的格式或特定行为的更多细节的读者应该查看ZCL规范（075123r02）

Cluster-Specific Commands
  The payload format, support requirements (mandatory, optional), and behavior on receipt of a cluster-specific command are all defined in the cluster definition. Typically, these commands affect the state of the receiving device and may alter the attributes of the cluster as a side-effect.
  For example, the ZCL defines three commands (OFF, ON, and TOGGLE) that are received by the On/Off cluster server. It further declares that each of these commands is mandatory and the payload format for each command (in this case, none of them have payloads). The ZCL defines that the On/Off cluster client is responsible for generating the commands received by the server.

• 有效负载格式，支持要求（强制，可选）以及接收特定于集群的命令时的行为都在集群定义中定义。 通常，这些命令会影响接收设备的状态。
• 例如，ZCL定义了On / Off群集服务器接收的三个命令（OFF，ON和TOGGLE）。 它进一步声明这些命令中的每一个都是必需的，并且每个命令的有效载荷格式（在这种情况下，它们都没有有效载荷）。 ZCL定义On / Off群集客户端负责生成服务器接收的命令。

1.3 举例：温度传感器的 Cluster

  As an example, consider a portion of the Temperature Measurement Sensor cluster that is fully described in Chapter 4 of the Zigbee Cluster Library Specification (15-02017-002).
  The following table lists some of the attributes from the ZCL specification.

• 考虑温度测量传感器集群的一部分，该部分在Zigbee集群库规范（15-02017-002）的第4章中有详细描述。
• 下表列出了ZCL规范中的一些属性。

Identifier	Names	Types	Range	Access	Default	Mandatory/Optional
0x0000	MeasuredValue	Signed 16-bit Integer	MinMeasuredValue to MaxMeasuredValue	Read only	0	M
0x0001	MinMeasuredValue	Signed 16-bit Integer	0x954B – 0x7FFE	Read only	-	M
0x0002	MaxMeasuredValue	Signed 16-bit Integer	0x954C – 0x7FFF	Read only	-	M
0x0003	Tolerance	Unsigned 16- bit Integer	0x0000 – 0x0800	Read only	-	O
0xFFFD	ClusterRevision	Unsigned 16- bit Integer	0x0001 – 0xFFFE	Read only	0x0001	M

  1. Overview of Attributes: The cluster server supports at least those five attributes, four of which must be supported by any implementation (MeasuredValue, MinMeasuredValue, MaxMeasuredValue, and ClusterRevision), and one of which may be optionally supported (Tolerance). All of these attributes are read-only, indicating that any write attempts to them will fail. Note the ClusterRevision global attribute functions as a regular attribute.
  2. Implications for Cluster Server, Cluster Client: Clearly, the cluster server should be implemented by the device that contains the temperature sensor. Meanwhile the cluster client should be implemented by any device that wishes to receive temperature sensor information, either actively (through a read attributes command) or passively (through first a configure report attributes command and then from report attributes).
  3. Further Information: The cluster description also provides useful information about the actual format of the data (for example, the range of the signed 16-bit integer for MaxMeasuredValue) and the mandatory supported operations – not all attributes support all basic commands. For example, MaxMeasuredValue is a read-only command and cannot be written.

Note: While the incoming write attribute commands are supported, in this case MaxMeasuredValue always generates a Write Attributes No Response reply.
  4. Commands: No custom commands are supported by this cluster (either the server or the client). For an example of a cluster containing custom commands, see the Thermostat Cluster in the ZCL (15-02017-002).

• 1.属性概述：这个cluster服务端至少支持这五个属性，其中四个必须实现（MeasuredValue，MinMeasuredValue，MaxMeasuredValue和ClusterRevision）支持，其中一个可以选择支持（Tolerance）。所有这些属性都是只读的，表明对它们的任何写入尝试都将失败。请注意，ClusterRevision全局属性用作常规属性。
• 2.Cluster Server，Cluster Client的含义：显然，集群服务器应该由包含温度传感器的设备实现。同时，集群客户端应由希望接收温度传感器信息的任何设备实现，主动（通过读属性命令）或被动（通过首先配置报告属性命令，然后从报告属性）。
• 3.更多信息 : 集群描述还提供有关数据实际格式的有用信息（例如，MaxMeasuredValue的带符号16位整数的范围）和强制支持的操作 - 并非所有属性都支持所有基本命令。例如，MaxMeasuredValue是只读命令，无法写入。
• 注意：虽然支持传入的写入属性命令，但在这种情况下，MaxMeasuredValue始终生成“写入属性无响应”回复。
• 4.命令：此群集（服务器或客户端）不支持自定义命令。有关包含自定义命令的群集的示例，请参阅ZCL中的恒温器群集（15-02017-002）。

1.4 Functional Domains

  As of this writing, the Zigbee Cluster Library defines the following functional domains:

• General
• HVAC
• Lighting
• Measurement & Sensing
• Security & Safety
• Smart Energy
• Over-the-Air Upgrading
• Telecommunications
• Commissioning

  Each domain defines a number of clusters that are then used by the Zigbee Application Layer to describe the OTA behavior of devices (see the following figure).

1.5 制造商相关扩展

  The ZCL allows extension of the existing library in two ways: users may add manufacturer specific commands or attributes to existing clusters, or they may define entirely new clusters that are manufacturer specific.
  Manufacturer-specific commands are identified by setting a special bit in the ZCL header and including the manufacturer code (received from the Zigbee Alliance) in the ZCL header. This guarantees that manufacturer-specific extensions do not interfere with other manufacturer-specific extensions or existing ZCL clusters, commands, or attributes.
  Manufacturer-specific clusters must use the cluster ID range of 0xFC00-0xFFFE.

• ZCL允许以两种方式扩展现有库：用户可以向现有集群添加制造商特定的命令或属性，或者他们可以定义制造商特定的全新集群。
• 通过在ZCL标头中设置特殊位并在ZCL标头中包含制造商代码（从Zigbee联盟授权）来识别特定于制造商的命令。 这可以保证特定于制造商的扩展不会干扰其他特定于制造商的扩展或现有的ZCL集群，命令或属性。
• 特定于制造商的群集必须使用群集ID范围0xFC00-0xFFFE。

2、 Zigbee 规范

• PS ： 这章就当科普就好了。

  Zigbee compliance is based on a building block of compliance testing used to ensure that each layer is tested.
  Products that meet all compliance requirements may be branded “Zigbee Compliant” and can display the Zigbee logo.

  The Zigbee radio and MAC are required to have passed the applicable parts of IEEE 802.15.4 certification testing. Parts of the MAC not required for Zigbee operation are not required for this testing.

• Zigbee合规性基于合规性测试的构建块，用于确保每个层都经过测试。
• 符合所有合规要求的产品可以标记为“符合Zigbee标准”，并可以显示Zigbee徽标。
• Zigbee无线电和MAC必须通过IEEE 802.15.4认证测试的适用部分。 此测试不需要Zigbee操作不需要的部分MAC。

  Zigbee stacks are required to be built on certified IEEE 802.15.4 platforms. Zigbee stack providers are required to have the stack tested against a standard Zigbee test plan known as Zigbee Compliant Platform Testing. This testing validates the basic network, security, and Zigbee Device Object (ZDO) operations for the stack.
  Zigbee products are required to be built on a Zigbee Compliant Platform. The developer can choose to build a public or manufacturerspecific application. Those applications which are manufacturer-specific are tested against a specific set of tests to validate basic operation. Products based on the common Zigbee application layer are more extensively tested using a standard Zigbee test for the application layer commands. Testing scrutiny has been heavily increased in Zigbee 3.0; there are now many negative test cases that products must pass in order to pass certification.
  The Zigbee Test Harness is new in Zigbee 3.0. The Zigbee Test Harness is provided to Zigbee members for testing their products and also is used for the final compliance testing for a Zigbee 3.0 product. The Zigbee Test Harness involves both a test harness Zigbee software stack running on a compliant IEEE 802.15.4 platform and a desktop application offering a friendly user interface to the tester.
  Each shipping product has to be certified and substantive changes to the product after certification can require recertification. Silicon Labs sends all chips and stack releases through compliance testing.
  All of the Zigbee test plans are developed and tested using at least three members’ products to ensure interoperability between different implementations.
  Companies are required to become members of the Zigbee alliance to ship product containing the Zigbee stack. There are specific rules for use of the Zigbee logo on product that are detailed on the Zigbee web site (www.zigbee.org).

• Zigbee协议栈需要在经过认证的IEEE 802.15.4平台上构建。 Zigbee堆栈提供商需要根据称为Zigbee兼容平台测试的标准Zigbee测试计划对堆栈进行测试。此测试验证堆栈的基本网络，安全性和Zigbee设备对象（ZDO）操作。
• Zigbee产品需要在符合Zigbee标准的平台上构建。开发人员可以选择构建公共或制造商特定的应用程序。针对特定制造商的那些应用程序针对特定测试集进行测试以验证基本操作。基于通用Zigbee应用层的产品使用标准Zigbee测试进行更广泛的测试，用于应用层命令。在Zigbee 3.0中，测试审查大大增加;现在有很多负面测试用例，产品必须通过才能通过认证。
• Zigbee Test Harness是Zigbee 3.0中的新功能。 Zigbee测试工具提供给Zigbee成员用于测试他们的产品，并且还用于Zigbee 3.0产品的最终合规性测试。 Zigbee测试工具包括在兼容的IEEE 802.15.4平台上运行的测试工具Zigbee软件堆栈和为测试人员提供友好用户界面的桌面应用程序。
• 每个产品必须经过认证，并且在认证后对产品进行实质性更改可能需要重新认证。 Silicon Labs通过合规性测试发放所有芯片和zigbee协议栈。
• 所有Zigbee测试计划均使用至少三个成员的产品进行开发和测试，以确保不同实现之间的互操作性。
• 公司必须成为Zigbee联盟的成员才能运送包含Zigbee堆栈的产品。 Zigbee网站（www.zigbee.org）上详细介绍了在产品上使用Zigbee徽标的具体规则。

3、 Zigbee 3.0

  Zigbee 3.0 marks the beginning of a new chapter in the Zigbee Alliance. Zigbee 3.0 unites all of the different application profiles into one common application layer. Furthermore, it introduces greater test coverage for product certification, ensuring better interoperability for Zigbee devices in the field. The Zigbee 3.0 document suite contains both revised and completely new material for the Zigbee application specification.
  The Base Device Behavior Specification (BDB) is perhaps the most important new document in the Zigbee 3.0 document suite. It specifies mandatory and optional application layer behavior for any Zigbee product. These behaviors include, but are not limited to:

• Network commissioning
• Network security
• ZDO command handling
• Reporting
• MAC data polling
• Persistent data

• Zigbee 3.0标志着Zigbee联盟新篇章的开始。 Zigbee 3.0将所有不同的应用程序配置文件组合到一个通用的应用程序层中。 此外，它还为产品认证引入了更大的测试覆盖率，确保了Zigbee设备在现场的更好互操作性。 Zigbee 3.0文档套件包含Zigbee应用程序规范的修订版和全新材料。
• 基本设备行为规范（BDB）可能是Zigbee 3.0文档套件中最重要的新文档。 它为任何Zigbee产品指定强制和可选的应用程序层行为。 这些行为包括但不限于：
  • 网络调试
  • 网络安全
  • ZDO命令处理
  • 报告
  • MAC数据轮询
  • 持久数据

  See document 13-0402 for more specific information on these items. Because there is now one specification for all Zigbee applications,two different Zigbee 3.0-compliant products in different application domains can interoperate on the same network (for example, a light switch and a garage door opener can perform separate functions on the same network).
  At the heart of the BDB are the commissioning methods that a Zigbee 3.0 device can use. The methods follow an order of execution, but they are all optional for a device. For example, it may only makes sense for a Zigbee End Device switch application to performing touchlink commissioning, classical joining, and then finding and binding. On the other hand, a Zigbee Coordinator gateway application may only wish to form a network. Lastly, maybe a Zigbee Router light application could perform classical joining, and then fall back to classical network formation if it does not find any networks to join. The commissioning methods, and order, are as follows.

• Touchlink commissioning
• Classical network joining
• Classical network formation
• Finding and binding

• 有关这些项目的更多具体信息，请参见文档13-0402。由于现在所有Zigbee应用程序都有一个规范，因此在不同应用程序域中的两个不同的Zigbee 3.0兼容产品可以在同一网络上进行互操作（例如，灯开关和车库门开启器可以在同一网络上执行单独的功能）。
• BDB的核心是Zigbee 3.0设备可以使用的调试方法。这些方法遵循执行顺序，但它们对于设备都是可选的。例如，Zigbee终端设备切换应用程序执行touchlink调试，经典连接，然后查找和绑定可能才有意义。另一方面，Zigbee协调器网关应用程序可能只希望形成网络。最后，也许Zigbee路由器光应用程序可以执行经典连接，然后如果没有找到任何要加入的网络则回退到经典网络形成。调试方法和顺序如下。
  • Touchlink调试
  • 网络加入
  • 网络的形成
  • 查找和绑定

  Touchlink commissioning is the first step in the Zigbee 3.0 network commissioning process. A device may choose to perform the touchlink process for an initiator to try and find a touchlink target. A typical example of this interaction may be a switch and a light. Theswitch may perform touchlink commissioning to establish itself on the same network as the light. See 13-0402 for a more in-depth description of touchlink commissioning.
  The next step in the BDB defined process is classical joining. This means finding open networks and joining one using the original Zigbee joining process. Finding a network involves performing IEEE 802.15.4 active scans on a product-defined set of channels. Once a device has found a network that it wishes to join, it may join that network using an install code derived link key, a default link key for a centralized security network, and a default link key for a distributed security network. For more information on the security mechanisms involved in the Zigbee 3.0 application layer, see UG103.5: Security Fundamentals.

• Touchlink调试是Zigbee 3.0网络调试过程的第一步。设备可以选择执行触摸连接过程以使发起者尝试找到触摸连接目标。这种交互的典型示例可以是开关和灯。该开关可以执行触摸连接调试以在与相同的网络上建立自己。有关touchlink调试的更深入说明，请参见13-0402。
• BDB定义过程的下一步是经典连接。这意味着找到开放的网络并使用原始的Zigbee加入流程加入一个网络。查找网络涉及在产品定义的通道集上执行IEEE 802.15.4主动扫描。一旦设备找到了它希望加入的网络，它就可以使用安装代码派生链接密钥，集中安全网络的默认链接密钥和分布式安全网络的默认链接密钥加入该网络。有关Zigbee 3.0应用程序层中涉及的安全机制的更多信息，请参阅UG103.5：安全基础知识。

  A Zigbee 3.0 application may then choose to form a classical Zigbee network. A product may form a centralized security network as a trust center or form a distributed security network as a router. This is different from many legacy application profiles where only a Zigbee coordinator could form a network. A light may wish to form a network as a router so that it can act as a touchlink target, whereas it makes more sense for a gateway to form a centralized network as a trust center. Trust centers may choose to only allow only certain devices on the network by using install code derived link keys for joining. Again, see UG103.5: Security Fundamentals for a thorough discussion of Zigbee 3.0 security.
  Once devices are on a network, they can perform finding and binding, where devices create bindings to establish application layer links. For example, an On/Off switch may perform finding and binding to create a binding to an On/Off Light. Again, as all commissioning steps, this step is optional.

• 然后，Zigbee 3.0应用程序可以选择形成经典的Zigbee网络。产品可以形成作为信任中心的集中安全网络，或者形成作为路由器的分布式安全网络。这与许多只有Zigbee协调器可以组成网络的遗留应用程序配置文件不同。灯可能希望将网络形成为路由器，以便它可以充当触摸连接目标，而对于网关形成集中式网络作为信任中心更有意义。信任中心可以选择仅允许网络上的某些设备使用安装代码派生的链接密钥进行加入。再次，请参阅UG103.5：安全基础知识，以全面讨论Zigbee 3.0安全性。
• 一旦设备在网络上，他们就可以执行查找和绑定，其中设备创建绑定以建立应用层链接。例如，On / Off开关可以执行查找和绑定以创建对开/关灯的绑定。同样，作为所有调试步骤，此步骤是可选的。

  As mentioned previously, Zigbee 3.0 also introduces more stringent testing on products. This means products will go through more negative test cases and specific cluster functionality tests before they are allowed on the market. Included in the Zigbee 3.0 document suite are the new Cluster Test Specifications. These documents contain test cases for Zigbee products implementing certain clusters. For a product using a certain cluster to be Zigbee 3.0 certified, it must pass the test cases contained within this document for that specific cluster. There is an individual Zigbee document for each cluster test spec. For an example, see document 15-0310, the On/Off Cluster test specification.
  Zigbee 3.0 also mandates that devices should support proxy functionality for Green Power, a networking and application-level specification designed for energy-harvesting end devices. Essentially, this means that every Zigbee 3.0 device will be able to process and forward Green Power messages to other devices with more application-layer Green Power functionality. The Green Power Basic specification and test specification are included in the Zigbee 3.0 document suite.
  It is worth mentioning that the 6th revision of the Zigbee Cluster Library (document 15-02017) is also included in the Zigbee 3.0 document suite. See section 6. Zigbee Cluster Library for more information about this specification.

• 如前所述，Zigbee 3.0还对产品进行了更严格的测试。这意味着产品在被允许进入市场之前将经历更多负面的测试用例和特定的集群功能测试。 Zigbee 3.0文档套件中包含新的Cluster Test Specifications。这些文档包含实现某些集群的Zigbee产品的测试用例。对于使用某个群集进行Zigbee 3.0认证的产品，它必须通过该文档中包含的针对该特定群集的测试用例。每个集群测试规范都有一个单独的Zigbee文档。有关示例，请参阅文档15-0310，开/关群集测试规范。
• Zigbee 3.0还要求设备应支持Green Power的代理功能，Green Power是专为能量收集终端设备设计的网络和应用级规范。从本质上讲，这意味着每个Zigbee 3.0设备都能够处理绿色电源消息并将其转发到具有更多应用层绿色电源功能的其他设备。 Green Power Basic规范和测试规范包含在Zigbee 3.0文档套件中。
• 值得一提的是，Zigbee Cluster Library的第6版（文档15-02017）也包含在Zigbee 3.0文档套件中。有关此规范的更多信息，请参见6. Zigbee集群库。

4、 Applying Zigbee

  A set of design decisions must be made in any Zigbee implementation. For more information, see UG103.3: Software Design Fundamentals.

• 必须在任何Zigbee实现中做出一组设计决策。 有关更多信息，请参阅UG103.3：软件设计基础知识。