ZigBee的 四種綁定方法簡介

綁定是Zigbee中非常重要的一個概念，想必大家都看了很多文章，其中以“Zigbee四種綁定方式在TI_Z-Stack協議棧中的應用”最為典型，此文我也讀過幾遍，收貨頗豐。此外飛比(Feibit)論壇上也有帖子講解了EndDeviceBinding蛋疼的傳來傳去機理，分析的也相當透徹。我這里不在想解釋具體的各種綁定方式的代碼實現和機制，而是簡單說明一下各種綁定機制的特點，希望大家能夠從應用層面上概念性地理解和認識綁定，然后針對各種機制的應用場景加以舉例。
一、綁定方式再解釋
Zigbee綁定的四種方式：
1、        兩個節點分別通過按鍵機制調用ZDP_EndDeviceBindReq函數
即：在一定時間內兩個節點都通過按鍵(其他方式也可以)觸發調用這個函數
特點：這個函數的調用將會向協調器發出綁定請求(具體如何調用及參數設置請看協議棧相關代碼)，如果在16S(協議棧默認)時間內兩個節點都執行了這個函數，協調器就會幫忙實現綁定，這個過程的代碼很復雜，我不想說。綁定表應該是存在OutCluster那邊，即這兩個節點應該是一個輸出控制命令，一個接收控制命令，綁定表存在輸出控制命令這邊，至於如何實現，有興趣同學可以繼續研究代碼。
注意：這種方式一定需要協調器，否則不行；但是一旦綁定成功，不再需要協調器，協調器只是幫忙綁定的一個第三方；雖然叫做EndDeviceBind，但是不局限於End Device，路由器也一樣用；重復上述操作會解綁定，也就是說這是一個乒乓方式。
2、        Match方式
即：一個節點可以通過調用afSetMatch函數允許或禁止本節點被Match(協議棧默認允許，可以手工關閉)，然后另外一個節點在一定的時間內發起ZDP_MatchDescReq請求，允許被Match的節點會響應這個Req，發起的節點在接收到RSP的時候就會自動處理綁定。
特點：不需要別人幫忙，只要在網絡中的節點互相之間就可以實現，但是前提是他們一定要Match，即一方的outcluster至少有一個是另外一方的incluster，這種方式在很多時候用起來比較方便。
注意：如果同時有多個節點(一個節點上的多個端點也一樣)處於允許Match狀態，那么req的這個節點可能會收到一大票滿足Match條件的rsp，那么你發起req的節點要在這個處理上多下功夫了。
3、        ZDP_BindReq和ZDP_UnbindReq方式
即：應用程序通過調用這兩個函數實現綁定和解綁定，這種方式很有趣。具體說來是為了讓A和B綁定到一起，還需要一個節點C。例如：你想A控制B，那么這種方式是由C發出bind或unbind命令給A(發給誰誰就處理綁定、並負責存儲綁定表)，A在接收到req的時候直接處理綁定，也就是添加綁定表項，並且這個過程B並不知道。但是A知道綁定表里面有了關於控制B的記錄，並且這種方式可以實現一個節點綁定到一個Group上去。
注意：這種方式需要知道A和B的長地址，具體協議棧拿長地址做什么用，有興趣的就去挖代碼好了。
4、        手工管理綁定表
即：通過應用程序調用諸如bindAddEntry(函數在BindingTable.h文件中定義，具體實現被封包了)來實現手工綁定表管理，這種方式自由度很大，也不需要別的節點參與，但是應用程序要做的工作多一些，整個綁定表都是你說了算。
注意：這種方式你需要事先知道被綁定的節點信息，諸如短地址，端點號，incluster和outcluster這些信息，否則你沒辦法把那些函數的參數填進去。

二、應用場合舉例
1、第一種方式(enddevicebind)
例：網絡中有協調器存在，另外有兩個節點A和B，這兩個節點具有互補特性(即A節點的incluster是B節點的outcluster)，A和B結點都有按鈕可以通過程序來觸發EndDeviceBind的調用。在這種情況下，你只要在規定的時間內分別按A和B上的某個按鈕，綁定就會在協調器的幫助下自動完成。這適合於節點很方便操作，沒有被裝牆里或者無法接觸的地方；綁定完成后，具有outcluster性質的B節點即可以通過綁定方式給具有incluster性質的A節點發消息，但是不能指望反過來由A發消息給B，因為A節點根本就沒有關於B的信息，綁定表是存在B中的。
2、第二種方式(Match)
例：網絡中不一定有協調器存在，但是有A、B、C、D等多個節點，A性質是Outcluster，B、C、D的性質是Incluster，你可以通過按鍵策略來在一定時間內允許B、C、D中的任何一個開啟被Match的功能，同時A發起Match請求(廣播的)，那么被允許Match的節點就會在收到請求后將自己的信息返給A，A在得到rsp的時候來處理綁定，如果你還想讓A綁到其它節點上，可以依次這么做。這種方式其實同第一種操作過程類似，只不過不需要協調器的參與。
3、第三種方式(Bindreq,Unbindreq)
例：假設你有一個主控(可能是ARM板子，可能是PC……)，並且有一個Zigbee節點A通過串口或者U口等方式連在了主控上，主控可以給A發命令(什么命令你要自己定義、自己實現了)；你還有一個B節點是開關，還有一個C節點是燈。你想讓在B上建立綁定表，以用來控制C。那么你可以通過主機命令A向另外的節點B發起BindReq要求，主機發給A的命令中會帶着C的一些信息(主機如何有C的信息？這種場合下，主機應該了解整個網絡的細節，至於如何了解。。。。，以后再說)。這樣，A就可以向B發起BindReq請求，這個請求的參數中包含了必要的C的信息，B在收到請求后就會建立起關於控制C的綁定表，以后B可以通過開關控制C了，也不再需要A的參與。這種方式適合那種集中管理的網絡。
4、第四種方式(手工)
例：你還是有一個主機，主機上有Zigbee節點A能夠串口或者U口通信。你想由主機來深入地管理整個網絡上的綁定情況，你就可以通過主機給A發命令，告訴A給某一個節點發命令，讓它去建立、刪除、追加。。。。綁定表。這種方式實際上最靈活，但是需要用戶(也就是你,寫程序的)的工作最多，用戶也需要很清晰的思路去管理綁定表，要是不小心管理錯了，就杯具了。

還要補充說明的是：為什么要用綁定？尤其是3，4兩種，都知道了被綁定節點的具體信息了？綁定有必要嗎？實際上，在每一個節點入網的時候，都會向網絡自動發出DeviceAnnce報告（這里面包含了節點的IEEE地址和新得到的短地址)，告訴大家自己來了，在看到這個DeviceAnnce的時候，每個節點都會根據IEEE地址信息更新自己的綁定表的，這樣你就不怕短地址變化啦。還有的時候你可能根本就不知道某些節點的具體信息，尤其是EP信息，在這種情況下，如果你沒有主機來統一管理，再不用綁定，兩個節點想通信是不可能的。