zigbee、profile、cluster、 endpoint、

1.引用ZigBee联盟的说法

Profile: a collection of device descriptions, which together form a cooperative

application. （配置文件：共同促成交互式应用的多种设备描写叙述项的集合。

）

ZigBee devices describe themselves using descriptor data structures. The actual data

contained in these descriptors is defined in the individual device descriptions.

There are five descriptors: node, node power, simple, complex and user.（ZigBee

设备以描写叙述项数据结构刻画自己，包括在这些描写叙述项内部的详细数据定义在该设备描写叙述项中。

有5种描写叙述项：节点，节点电源，简化。复杂和用户。）

2.我们的观点

Profile是对逻辑设备及其接口的描写叙述集合，是面向某个应用类别的公约、准则。

Descriptor是为分布式应用提供的描写叙述项，多种描写叙述项共同组成描写叙述集合Profile。

它

依据应用必须处理的数据包和必须运行的操作来描写叙述分布式应用。

总之，配置文件使得ZigBee 设备能够互操作。ZigBee 联盟已经定义了非常多标准的配置

文件，比方远程控制开关配置文件和光传感器配置文件等。不论什么遵循某一标准配置文件的节

点都能够与其它实现同样配置文件的节点进行互操作。

【相关问答】

Guest：

我看协议上说一个温度计节点和一个炉子节点构成一个profile啊！

所以我认为实现一定功

能的几个节点的集合就是一个profile？

ZigBee会友：

几个节点的集合和profile不是在一个层面上说的。

profile是面向某个应用。解决一系列事

务的公约。是对逻辑设备及其接口关系的描写叙述集合。不论什么遵循这一描写叙述集合的节点之间都可

以交互工作（仅仅要两方能够通信）。比如：根据加热应用的条例规定。一个节点上的温度调

节器能够和还有一个节点上的加热炉交互工作。

Guest：

device description、device profile和profile有什么差别啊？！

ZigBee会友：

description 是理论性描写叙述集合profile中的详细事项，device profile是profile对详细

device的有关规定和描写叙述项，眼下profile中有5种描写叙述项。

Guest：

那么对于zigbee的通讯来说。就须要有两个不同类型的endpoint来相互通讯？endpoint的类

型取决于Profile？

ZigBee会友：

Profile规定了接点的类型和接口关系。endpoint当然是取决于详细应用中开发者自己的

配置，仅仅只是要交互工作，必须遵循Profile的相关规定而已。

Guest：

profile是一个更大一点的概念。是不是有人所说的“应用框架”？也就是说在这个框架中

定义设备类型 设备之间的控制管理接口等等？

ZigBee会友：

嗯。仅仅要明白当中的含义，当然也能够用你自己的说法，眼下相关说法还有“側面”、“概

貌”等。

Guest：

endpoint依据cluster进行绑定，进而构成profile？一个网络有多个profile，难道仅仅须要

一个profile identifier？

ZigBee会友：

profile 是“公约”、“准则”、“法律条款”。profile identifier即profileID就是对

应条款的识别序号。就像：民法、刑法、野生动物保护法……

Guest：

这样理解能够吧：profiles 理解为联合国宪章条款。cluster 是伊朗核问题，attribute

就是谈判， cluster是在遵守profile的情况下制定的？

ZigBee会友：

profiles 是面向详细应用的公约准则，cluster 此应用涉及到的事务关系。attribute

就是某事务能够预料的各种情况。

Guest：

请问，在zdo、profile、af之间的各种关怎样？我弄不明确啊？

ZigBee会友：

zdo是ZigBee设备对象，属于特殊的Endpoint（特制自己）；profile面向某个应用的公约或

准则。包含5种描写叙述项。AF是应用层侦。

Guest：

可是我看zdo中定义的功能在device profile中都定义啦，你们分析了microchip的协议了

吧？我认为挺难理解的，各个层次间的文件定义认为非常难……

ZigBee会友：

profile是法律条款。zdo是逻辑工作实体（自己）；profile中的多种描写叙述项是条例、是图

纸。zdo是详细实现。

Guest：

我想问问，配置文件究竟是什么？协议中好像说是设备描写叙述符和簇描写叙述符和服务类型

（KVP或MSG）。

难道profile是设备描写叙述符和簇描写叙述符和服务类型（KVP或MSG）的集合？

ZigBee会友：

Profile也能够翻译成配置文件，实质上大家公认的在某个方面应用的公共准则（对逻

辑设备及其接口的描写叙述集合）。

Guest：

那Profile是怎样划分的, 依据实际location 还是app的相关性分得？

ZigBee会友：

依据应用相关性。

cluster是不是指一个应用？事务是service 是吗 。比方 KVP service 类型, 是吧？

ZigBee会友：

cluster是“事务”，是特性的集合（或者说属性的集合）；Attribute是“事务”的具

体情况，比方节点的开或关。

Guest：

啊, 好像明确一点，原来总是把它和 multicast 往一起混，就乱了。谢谢！

ZigBee会友：

总之profile是面向应用的公约或准则；详细包含多种事务关系。每种事务关系又分多

种情况。

ENDPOINT

非常多资料将其翻译为“端点”，我们不如也这么叫。只是问题的关键不是它怎样称呼。而是怎样认识它。

我们来研究这样一个事实：outman在看我的帖子的同一时候他又使用QQ和别人聊天。如果他的电脑IP地址为192.168.1.2。那么当他的QQ好友向他发送了一句话的时候，这个信息里面包括了目的IP地址，所以通过TCP/TP协议能够到达outman的电脑。

可是问题随之而来。

当outman电脑上的操作系统接收到此条信息时。它将把这个信息交给浏览器（我们刚才说了，他在看帖子，所以肯定开着浏览器）呢，还是交给QQ？操作系统通过怎么样的方法作出裁决呢？显然，仅仅通过IP地址是没有办法决定的，所以这条消息除了包括IP地址以外，还要告诉目的机，这条消息应该交由哪个应用程序来处理。

于是port（Port）的概念产生了。操作系统为应用程序提供了非常多port，消息由IP地址到达操作系统。再由port找到处理消息的应用程序。

相同的道理，在ZigBee的应用程序框架里（结构图请看《深入浅出Z-Stack
2006 OSAL多任务资源分配机制》）包括了最多240个应用程序对象，每一个应用程序对象在OSAL中相应了一个任务，当网络层接收到信息以后怎样决定将此信息传递给哪个任务呢？ENDPOINT决定了传递方向，于是我们能够说ENDPOINT的作用与TCP/IP协议中的port的作用是一样的。

【综述】

1.引用ZigBee联盟的说法

Cluster: is a container for one or more attributes. (一个或很多其它属性的集合)

Attribute: a data entity which represents a physical quantity or state.（反映物

理特性或状态的一个数据实体）

2.我们的观点

Cluster是逻辑设备之间的事务关系，Attribute则是某种事务关系的详细特例；也就是说

Cluster定性，Attribute定量。

【相关问答】

Guest：

请问，attribute这个词怎么理解？ 温度 等等？

ZigBee会友：

在温度这个cluster里面，attribute就是详细的温度值。“属性”attribute是“事务”

cluster里面分的详细情况。就像C语言的swich ，case 语句里的使用方法。

Guest：

请问“事务”又是个什么概念？是不是就是一个事件？我理解cluster是属性的集合？

ZigBee会友：

cluster的确是属性的集合，和一般提到的事件不一样，在网络理解为事务关系更贴切。

Endpoint之间根据“事务关系”（cluster）通讯。

Guest：

一个endpoint相应一个application？比方一个switch相应“开关”这个application？

ZigBee会友：

你的这样的提法不规范，一个endpoint是一个逻辑设备。能够包括多个Cluster。每一个

Cluster包括不同的属性（开、关是“灯控制” Cluster相应不同情况的attribute）。

Guest：

这样理解能够吧：profiles 理解为联合国宪章条款，cluster 是伊朗核问题，attribute

就是谈判， cluster是在遵守profile的情况下制定的？

ZigBee会友：

profiles 是面向详细应用的公约准则。cluster 此应用涉及到的事务关系，attribute

就是某事务能够预料的各种情况。

Guest：

问一个问题：规定240个endpoint是指一个node上还是整个cluster呢，也就是说一个

cluster最多同意有240个endpoint还是240*240个endpoint呢？

ZigBee会友：

协议中的说法指一个node。

endpoint、node、cluster是三个概念 ：node是物理设备，

endpoint是逻辑工作端，cluster是大家通讯的事务关系（属性的集合）。另外，网络拓扑

结构中提到的cluster是集群树，包含家长（parent）及其子女(child)。

Guest：

我想问问，配置文件究竟是什么？协议中好像说是设备描写叙述符和簇描写叙述符和服务类型

（KVP或MSG）。难道profile是设备描写叙述符和簇描写叙述符和服务类型（KVP或MSG）的集合？

ZigBee会友：

Profile也能够翻译成配置文件，实质上大家公认的在某个方面应用的公共准则（对逻

辑设备及其接口的描写叙述集合）。

Guest：

那Profile是怎样划分的, 依据实际location 还是app的相关性分得？

ZigBee会友：

依据应用相关性。

Guest：

cluster是不是指一个应用？事务是service 是吗 ，比方 KVP service 类型, 是吧？

把它和 multicast 往一起混，就乱了。谢谢。

ZigBee会友：

总之profile是面向应用的公约或准则；详细包含多种事务关系。每种事务关系又分多

种情况。

Guest：

协议上的nwk_addr_req（） 标注是cluser ID0x00,后面还有如clusterID 0x01的。

clusterID不是应该是不固定吗？！

ZigBee会友：

clusterID和cluster一一相应。不同的cluster当然用不同的clusterID 。

Guest：

哦。可能我对cluster的理解有问题。我认为cluster就是在绑定时产生的。所以

clusterID应该是随机的。为什么协议里primitive也会有clusterID呢？！

并且不同的

primitive有不同的 固定的clusterID呢？。

ZigBee会友：

primitive是一个广泛意义上的名次，泛指行为和操作，primitive和clusterID没有必

然的相应关系。

Guest：

ClusterID＝0x21 Bind_req(SrcAddress,SrcenEp,clusterID,DstAddress,DstenEp )

那ClusterID＝0x21什么意思！？

ZigBee会友：

就是约定好的某事务相应的事务号。两方以此建立相应关系（邦定关系）。

比方端设备

一的开关控制端设备三的灯，五个參数相应关系：（端设备一SrcAddress,开关SrcenEp,灯

控制clusterID, 端设备三DstAddress,灯DstenEp）。

如今理解吗？

Guest：

这我理解！

那个cluserID＝0x21，我不清楚！

为什么是固定的！

ZigBee会友：

cluserID＝0x21表示“灯控制”灯控制这个cluser

cluserID＝0x20表示“电流”这个cluser

Guest：

我对cluser的理解正确吗！？就是在绑定的时候。产生的！？ 那难道每一个primitive都

有一个clusterID？

ZigBee会友：

当然了每一个邦定都环绕着一个cluser ，邦定三个要素：source、cluser、dest

Guest：

我就是不明确，为什么把primitive跟cluster扯上关系？

ZigBee会友：

primitive就是“原语”。和cluster没有必定的联系，就是某种行为的说法，描写叙述逻辑

设备之间的操作和行为时偶然和某个cluster扯上关系，在描写叙述设备内部工作实机构之间的合作

当没有工作和行为。

版权声明：本文博客原创文章，博客，未经同意，不得转载。