Zigbee中无线节点和端点的解释

在Zigbee中，端点EndPoint的概念尤为重要，然而Zstack目前提供的例子并不清晰。虽然看看Zigbee的书也会提及这个问题，但是并没有多大篇幅，也表述的不是很清楚。那本葵花宝典描述的很清楚，但是很多人貌似没有耐着性子去研究那本书，杯具。今天闲暇，我就藉此地说一下自己的看法和认识，希望对新手同学有一定帮助。
1、Zigbee节点(Radio unit)
    Zigbee本身其实只是一种协议规范，落实到具体目标上无非就是一个具有2.4G射频发射接收功能和单片机功能的一块电路板(TI的2530、2430，意法半导体的STM32W108处理器都在一块芯片上集成了这两个部分，Ember和飞思卡尔也有集成的，也有一些非集成的方案)，在这块电路板上去运行Zigbee的协议，并且按照协议规范的射频频段和无线数据封包格式来在多个这样的电路板之间实现无线通信。这就引出了节点的概念(英文大致叫做Device，我这里称之为Radio unit吧)，理解起来就是这块能够实现无线通信的电路了。如果不是zigbee，而是之前的那些诸如nrf905这样的射频芯片，如果其没有协议栈支持，这个节点就是通信的全部了。
2、zigbee的EndPoint
     Endpoint这个概念在Zigbee中绝对是非常重要的。因为所有的Zigbee无线数据包都必须有一个Endpoint为目标。那么什么是Endpoint呢？从理解的层面上来说，Endpoint是一个radio unit上的真正的数据目标。按照协议规范，0号endpoint是Zigbee device object(ZDO)用的一个端点，255号是用作广播用途，我们可以自己设定的是1～240号，其余的保留。在一个Radio unit上可以实现多个EndPoint。当进行无线数据收发的时候，数据包里面就必须包含radio unit信息(设备的短地址），端点信息(destination endpoint number)。也就是说一个radio unit在接收到一个数据包后，会在协议栈的底层进行解析，比对应该把这个数据包发给哪个endpoint，如果找不到，这个包将被丢弃。
3、例子
   下面我举两个例子来解释一下endpoint的问题
   例子一：一个无线节点(radio unit)A上有一个温湿度传感器，有一个空调控制系统；另外一个无线节点B则负责接收A发回的温度数据，并通过一定的算法来控制空调系统。我们不管B如何实现，只研究A如何实现。这种情况的一个很规范的实现方式是：温湿度传感器设置一个endpoint，比如为10号；空调控制系统设置一个endpoint，比如为20号。还要说明的是：还应该为每一个endpoint建立一个任务，这样在注册端点描述符的时候(调用afRegister函数)，就会向协议栈底层说明处理这个端点数据的任务是谁。这样：当B想要获取温湿度的时候，他将会发出一个包含A的短地址和10号端点的信息，这个信息到了A，协议栈会将这个消息转给10号端点所对应的task去处理，管理空调的20号端点根本就看不到这个消息；类似地，如果B想要控制空调，他发出的数据包将包含A的短地址和20号端点信息，A收到消息后会发给20号端点的task去处理。（需要注意的是：在网络层面经常会有发给ZDO的消息，这时候信息包的端点号就将是0号)。这种将不同功能分配到不同endpoint上的方法非常有利于任务的划分，是一种很正规的方法。
   例子二、一个无线节点(radio uint)A上有4个LED需要被控制，另外一个无线节点B则有4个开关用来控制这4个LED。这种情形的规范实现方式还是要为每一个LED设置一个endpoint(允许的范围内你任意指定，只要不重复),并为每个endpoint建立一个task。这样处理之后，B可以用同样的命令来控制4个LED，而不是每一个led 用不同的命令，这种情况在public profile实际上是必须这么做的。

    上面两个例子可能很多同学认为太麻烦，完全可以变通。变通的想法就是我所有的被控对象都落在一个endpoint上，但是我发的数据包内容不同，接收端这个endpoint通过解析数据包的内容来判断具体该做什么，这种方式实际上完全可以实现，不过需要你自己规定一下数据包的格式，即第几个字节表示什么。。。。。
虽然这可以实现要求，但是我很不赞成这样，一方面实际上是增加了你程序设计的复杂度，另一方面完全没有了互联的可能，尤其是当你用ZCL的时候，这种方式就行不通了。
    这是今天闲暇对设备和端点的一点儿理解，可能用处不大，全当我练习打字了。呵呵。

毛毛老师解释得很形象，我的理解是这样的：
1、在zigbee网络中，Zigbee节点(Radio unit)是由网络地址(short addr)来区分的；
2、在zigbee设备内部，协议栈虚拟出一些“接收端点”，是由端点号(endpoint)来区分的。
由于1是具体的硬件，一目了然，很容易理解；而2是抽象地把一个设备又划分成了不同的“单元”去做不同的事情，相对难理解些。但使用zigbee，往往这些抽象地概念更重要。

1.无线节点对应一个无线收发器,对应一个网络地址和MAC地址.类似主机系统的一块网卡.
2.一个节点中可以运行不同的程序,每个程序由唯一的端点(endpoint)标识.类似TCP/IP中的端口号.
3.网络地址或MAC地址确定一台具体的设备,端点确定某台设备中的哪个应用程序.
4.网络地址的作用范围是整个网络,端点有意义的范围是某台设备.

顶毛毛老师

毛毛的讲解通俗易懂

"还要说明的是：还应该为每一个endpoint建立一个任务，这样在注册端点描述符的时候(调用afRegister函数)，就会向协议栈底层说明处理这个端点数据的任务是谁。"

请问，此句话的是否可以理解为使用一个ep则定义一个用户任务，使用n个ep则定义n个用户任务，多个ep不能在同一个task中进行登记，每个用户应用严格对应唯一的ep？是否与qq和浏览器这两程序必须对应pc的两个不同的端口原理一致呢？
另外，不同device，只要profile、cluster同，而ep不同，也是可以进行绑定等操作的，对不对？

多个EP可以在同一个任务注册，但是来消息的时候这个任务会收到对应他所注册的所有EP的消息，你在程序处理上需要提取出来EP信息才行，否则你也不知道是发给哪个EP的。绑定的时候，是按照ＥＰ来的，可以进行绑定。在ｐｕｂｌｉｃ　ｐｒｏｆｉｌｅ的处理中，比如你一个节点有４个ＬＥＤ需要管理，这４个led 的控制命令是完全相同的，你只能用ＥＰ来区分，在这种情况下最好是为每个ＥＰ建立一个任务。

谢谢，已经试验，多个ep注册在一个task下是可行的，目前demo规模较小，还是采取了这种模式。
另有一个问题，ep255保留用作广播，是否和应用端口1-240一样，需要注册？

受教了，谢谢

回复 8# NangelQ


    广播那个不需要自己注册的。ZDO的那个0 EP也不需要自己注册，协议栈已经处理了。集中精力管理好1～240就好