在一個終端上，可以有多個端點endpoint，這個概念是很重要的。

一個節點可以有多個端點，0號endpoint是Zigbee device object(ZDO)用的一個端點，255號是用作廣播。我們自己可以定義的是1-240這些端點。每個端點對應一個任務taskid。因此，我們每增加一個端點，就要給它配置一個新任務taskid

舉一個列子： 例子一：一個無線節點(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的時候，這種方式就行不通了

zigbee端口的理解