ZIGBEE中Profile、Cluster和Attribute关系

    在zigbee规范中，引入了profile, cluster的概念。具体说来，假设规范一个profile(可以理解成一套规定)，这个profile用来规范智能家居领域的相关产品都要满足那些要求，那么home automation public profile就规定了智能家居都要做什么。当然了，你可以自己规范一个自己的profile，称为private profile，而zigbee联盟则已经规范了一些profile，比如home automation，smart energy，building automation等，一个public profile也规定了profile 的ID，比如智能家居就规定是0x104。协议栈本身也有一个profile，就是Zigbee Device Profile，也就是ZDP了，这里规范了一个zigbee节点都要具备那些功能，比如路由能力啊，网络发现能力啊，各个协议层都要做什么啊，如此。

   在一个profile的规范下，又提出了cluster的概念，这个cluster要理解成一个大方向下的一个特定对象，比如智能家居下的一个调光器，操作这个调光器就需要一些命令，比如变亮，变暗，关灯，开灯这些，另外，这个调光器也会有一个attribute，也就属性，比如当前的亮度啊，由亮变暗的过程经历多长时间啊(一下子变亮视觉感觉没有渐变效果好喔)。对于home automation 的public profile已经规定了调光器应该有哪些cluster，如：Color Control Cluster，Ballast Configuration Cluster 等。然后，profile也规范了color control cluster 的ID，这个就是clusterID了。

     如果学过面向对象编程的思想，那就更好理解了：其实profile就相当于面向对象编程中的类，而cluster就是面向对象编程中的对象，至于command你可以理解为每个类中的方法，而attribute则是每个对象的属性。比如你定义了一个智能家居的类（profile=0x104)，那你是不是需要包括很多设备呀？比如具体的灯，开关什么的呀？所以你在类的基础上你又会去实例化一个对象调光器。这个调光器是不是需要一些方法呢？比如去控制灯开关什么的，这个就相当于command。而每个设备对象本身都应该有一些自己的属性来描述这个设备所以需要一个attribute。

在这个cluster下面，要有以下命令：
#define COMMAND_LIGHTING_MOVE_TO_HUE 0x00
#define COMMAND_LIGHTING_MOVE_HUE   0x01
#define COMMAND_LIGHTING_STEP_HUE   0x02
#define COMMAND_LIGHTING_MOVE_TO_SATURATION  0x03
#define COMMAND_LIGHTING_MOVE_SATURATION    0x04
#define COMMAND_LIGHTING_STEP_SATURATION   0x05
#define COMMAND_LIGHTING_MOVE_TO_HUE_AND_SATURATION   0x06
#define COMMAND_LIGHTING_MOVE_TO_COLOR          0x07
#define COMMAND_LIGHTING_MOVE_COLOR            0x08
#define COMMAND_LIGHTING_STEP_COLOR            0x09
#define COMMAND_LIGHTING_MOVE_TO_COLOR_TEMPERATURE    0x0a

Ballast Configuration Cluster 下面则没有定义命令。

除了命令之外，每一个cluster还会定义一些属性，比如colorcontrol cluster下有：
#defineATTRID_LIGHTING_COLOR_CONTROL_CURRENT_HUE              0x0000
#define ATTRID_LIGHTING_COLOR_CONTROL_CURRENT_SATURATION          0x0001
#define ATTRID_LIGHTING_COLOR_CONTROL_REMAINING_TIME            0x0002
#define ATTRID_LIGHTING_COLOR_CONTROL_CURRENT_X               0x0003
#define ATTRID_LIGHTING_COLOR_CONTROL_CURRENT_Y               0x0004
#define ATTRID_LIGHTING_COLOR_CONTROL_DRIFT_COMPENSATION          0x0005
#define ATTRID_LIGHTING_COLOR_CONTROL_COMPENSATION_TEXT           0x0006
#define ATTRID_LIGHTING_COLOR_CONTROL_COLOR_TEMPERATURE           0x0007
#define ATTRID_LIGHTING_COLOR_CONTROL_COLOR_MODE               0x0008
...........................
这样的属性。
而Ballast Configuration Cluster 则有：
  // Ballast Information attribute set
#defineATTRID_LIGHTING_BALLAST_CONFIG_PHYSICAL_MIN_LEVEL               0x0000
#define ATTRID_LIGHTING_BALLAST_CONFIG_PHYSICAL_MAX_LEVEL               0x0001
#define ATTRID_LIGHTING_BALLAST_BALLAST_STATUS                     0x0002
等属性。
这些属性反映了这个cluster下设备的状态，可以通过读写这些属性来改变其值。

    总结说来，Profile规范了应该包括哪些cluster，一个cluster会有一个ID，在一个cluster下又会有很多command，也会有很多attibute；在一个cluster下面command 和attribute的ID要唯一，不同的cluster下可以重复，不同的profile下clusterID也可以重复。

    再延伸一点儿，zigbee联盟在协议栈之外又增加了一部分操作cluster的函数，那就是zigbee cluster library (ZCL)，这里边已经以源代码的形式提供了操作联盟规范的那些public profile下的函数，主要功能包括一些command的transmit，response，indicate以及confirm等，还有读写attribute的一些操作函数。所以在理解了ZCL的工作机制基础上，通过调用ZCL的函数实际上会让应用程序设计变得简单（但是学习ZCL倒是很麻烦）。
    假设我们要控制一个LED，有一个远程节点（发命令控制led ），一个本地节点（接受命令并真正的让led亮起来)，那么如果引入ZCL的概念，你可以设置这个操作led的事情是一个cluster，其下包含三个命令，一个open，一个close，一个read attribute，灯还有一个attribute，那就是当前的status，远程节点可以用ZCL的函数发open和close命令，也可以随时发一个read attibute命令读取本地节点led 的状态。这么做的好处是不需要再自己设计一个规定（比如：一个数据包的第几个字节表示什么。。。），而是直接调用ZCL即可实现，这对于command和attribute数量很少的应用不见得有多大好处，但是当command和attribute数量很多的时候，引入ZCL会让事情变得简单。