KuangJunBin：本文是作者根據(jù)TI Z-Stack開發(fā)文檔，ZigBee Specification-2007，《Zigbee Wireless Networking》等英文資料整合和翻譯而成，采用中英雙語對照方便讀者理解，文中翻譯不當之處，望廣大同行不吝賜教。推廣ZigBee技術(shù)，提高國內(nèi)電子行業(yè)的國際影響力，是我們無線通訊工程師的愿景。本文歡迎轉(zhuǎn)載，請保留作者信息和出處，作為支持我繼續(xù)努力前行的動力，謝謝！
ZigBee2006版本中規(guī)定，在全部節(jié)點中實現(xiàn)綁定機制，并將其稱為源綁定。綁定機制允許一個應(yīng)用服務(wù)在不知道目標地址的情況下向?qū)Ψ剑ǖ膽?yīng)用服務(wù)）發(fā)送數(shù)據(jù)包。發(fā)送時使用的目標地址將由應(yīng)用支持子層從綁定表中自動獲得，從而能使消息順利被目標節(jié)點的一個或多個應(yīng)用服務(wù)，乃至分組接收。
Binding Table
綁定表
1. 綁定表存放的位置是內(nèi)存中預(yù)先定義的塊，如果編譯選項NV_RESTORE被激活，也能保存在Flash里。
2. 綁定表放置在源節(jié)點（需要激活編譯選項REFLECTOR）。
3. 綁定表的條目把需要發(fā)送的消息映射到它們的目標地址上。
4. 綁定表中每個條目包括以下內(nèi)容：
5. 綁定表條目結(jié)構(gòu)體的定義
typedef struct
{
uint16 srcIdx; //源地址索引
uint8 srcEP; //源端點
uint8 dstGroupMode; //指定尋址模式
uint16 dstIdx; //目標地址索引或者分組號
uint8 dstEP; //目標端點
uint8 numClusterIds; //在簇標識符表中簇標識符的個數(shù)
uint16 clusterIdList[MAX_BINDING_CLUSTER_IDS]; //簇標識符表
}BindingEntry_t;
Simple Description --- How to bind devices
概述---怎樣綁定節(jié)點
綁定指的是兩個節(jié)點在應(yīng)用層上建立起來的一條邏輯鏈路。在同一個節(jié)點上可以建立多個綁定服務(wù)，分別對應(yīng)不同種類的數(shù)據(jù)包。此外，綁定也允許有多個目標節(jié)點（一對多綁定）。
舉個例子，在一個燈光網(wǎng)絡(luò)中，有多個開關(guān)和燈光設(shè)備，每一個開關(guān)可以控制一個或以上的燈光設(shè)備。在這種情況下，需要在每個開關(guān)中建立綁定服務(wù)。這使得開關(guān)中的應(yīng)用服務(wù)在不知道燈光設(shè)備確切的目標地址時，可以順利地向燈光設(shè)備發(fā)送數(shù)據(jù)包。
一旦在源節(jié)點上建立了綁定，其應(yīng)用服務(wù)即可向目標節(jié)點發(fā)送數(shù)據(jù)，而不需指定目標地址了（調(diào)用zb_SendDataRequest()，目標地址可用一個無效值0xFFFE代替）。這樣，協(xié)議棧將會根據(jù)數(shù)據(jù)包的命令標識符，通過自身的綁定表查找到所對應(yīng)的目標設(shè)備地址。
在綁定表的條目中，有時會有多個目標端點。這使得協(xié)議棧自動地重復(fù)發(fā)送數(shù)據(jù)包到綁定表指定的各個目標地址。同時，如果在編譯目標文件時，編譯選項NV_RESTORE被打開，協(xié)議棧將會把綁定條目保存在非易失性存儲器里。因此當意外重啟（或者節(jié)點電池耗盡需要更換）等突發(fā)情況的發(fā)生時，節(jié)點能自動恢復(fù)到掉電前的工作狀態(tài)，而不需要用戶重新設(shè)置綁定服務(wù)。
配置設(shè)備綁定服務(wù)，有兩種機制可供選擇。如果目標設(shè)備的擴展地址（64位地址）已知，可通過調(diào)用zb_BindDeviceRequest()建立綁定條目。如果目標設(shè)備的擴展地址未知，可實施一個“按鍵”策略實現(xiàn)綁定。這時，目標設(shè)備將首先進入一個允許綁定的狀態(tài)，并通過zb_AllowBindResponse()對配對請求作出響應(yīng)。然后，在源節(jié)點中執(zhí)行zb_BindDeviceRequest()（目標地址設(shè)為無效）可實現(xiàn)綁定。
此外，使用節(jié)點外部的委托工具（通常是協(xié)調(diào)器）也可實現(xiàn)綁定服務(wù)。請注意，綁定服務(wù)只能在“互補”設(shè)備之間建立。那就是，只有分別在兩個節(jié)點的簡單描述結(jié)構(gòu)體（simple descriptor structure）中，同時注冊了相同的命令標識符（command_id）并且方向相反（一個屬于輸出指令“output”，另一個屬于輸入指令“input”），才能成功建立綁定。
There are 4 ways to build a binding table:
建立一個綁定表格有四種方法可供選擇：
第一種方法：自動綁定
使用函數(shù)：ZDP_MatchDescReq()
一、 負責發(fā)送消息的設(shè)備在網(wǎng)絡(luò)上廣播帶有如下參數(shù)的“個人公告”（Personal Advertisement）：
（1） 地址，配置文件標識符，簇集合列表；
（2）描述符匹配請求- ZDP_MatchDescReq()。
二、 匹配的設(shè)備會作出響應(yīng)。
三、 由ZDO處理和驗證響應(yīng)
四、 負責發(fā)送消息的設(shè)備建立綁定表并保存綁定記錄。
五、 這種方法有時也稱“服務(wù)發(fā)現(xiàn)”，“自動找尋”或者“自動匹配”。
第二種方法：輔助綁定
使用函數(shù)：ZDP_BindReq()
ZigBee設(shè)備對象綁定請求-一種告訴目標設(shè)備建立綁定記錄的委托工具，也稱輔助綁定。
任何一個設(shè)備或應(yīng)用服務(wù)，都能通過無線信道向網(wǎng)絡(luò)上的另一個設(shè)備發(fā)送一個ZDO消息，幫助其建立一個綁定記錄。這稱為輔助綁定，在消息發(fā)向的設(shè)備上會建立一個綁定條目。
委托綁定的申請：
任一個應(yīng)用服務(wù)，通過ZDP_BindReq()[defined in ZDProfile.h] 向綁定記錄所需要的應(yīng)用服務(wù)入口提供參數(shù)（地址和端點）以及簇標識號（cluster ID），即可啟動委托綁定的申請。第一個參數(shù)（消息發(fā)送目標地址）是綁定源節(jié)點的短地址（即保存綁定記錄的節(jié)點地址，這是因為ZDP需委托應(yīng)用框架AF輔助實現(xiàn)綁定，如果節(jié)點本身是REFLECTOR，并且希望保存綁定記錄，則此消息發(fā)送的目標地址就是本地的AF，這與目標節(jié)點的地址DestinationAddr of Receiving device不同）。
注意事項：
確保[ZDConfig.h]中ZDO_BIND_UNBIND_REQUEST特性已經(jīng)打開！
你可以通過ZDP_UnbindReq()（使用相同參數(shù)）來移除綁定記錄。
被請求輔助綁定的目標設(shè)備會返回的ZDO申請綁定或者解除綁定的應(yīng)答消息。此ZDO消息會被解析并通過調(diào)用ZDApp_BindRsp()或ZDApp_UnbindRsp()告知ZDApp.c此次請求的結(jié)果。
對于申請綁定的應(yīng)答消息，從協(xié)調(diào)器返回的狀態(tài)可能有ZDP_SUCCESS,ZDP_TABLE_FULL or ZDP_NOT_SUPPORTED。
對于解除綁定的應(yīng)答消息，從協(xié)調(diào)器返回的狀態(tài)可能有ZDP_SUCCESS,ZDP_NO_ENTRY or ZDP_NOT_SUPPORTED。
綁定是由外部的設(shè)備發(fā)起（“外部”的意思是發(fā)起綁定的不是綁定的對象之一）。
外部設(shè)備應(yīng)用程序以兩個應(yīng)用服務(wù)（地址和端點）和簇標識符作為參數(shù)調(diào)用ZDP_BindReq ()發(fā)起綁定。第一個參數(shù)就是綁定記錄保存的設(shè)備地址。
確保編譯選項REFLECTOR已經(jīng)打開！
函數(shù)解析：
ZDP_BindReq()實際上是調(diào)用ZDP_BindUnbindReq()的一個宏。這一調(diào)用會產(chǎn)生并發(fā)送一個綁定的請求，使得ZigBee協(xié)調(diào)器根據(jù)簇標識號clusterID對相應(yīng)的應(yīng)用服務(wù)實施綁定。
函數(shù)原型：
afStatus_t ZDP_BindReq(zAddrType_t*dstAddr,byte*SourceAddr,byte SrcEPIntf,byte ClusterID,byte*DestinationAddr,byte DstEPIntf,byte SecuritySuite);
參數(shù)細節(jié)：
DstAddr-消息發(fā)送地址 （負責綁定的設(shè)備地址）
SourceAddr–源節(jié)點的64位IEEE地址
SrcEPIntf–源節(jié)點應(yīng)用服務(wù)的端點
ClusterID–需要綁定的簇標識符
DestinationAddr–目標節(jié)點的64位IEEE地址
DstEPIntf–目標節(jié)點應(yīng)用服務(wù)的端點
SecuritySuite-安全機制模式
返回值：afStatus_t–此函數(shù)需要借助AF發(fā)送（AF_DataRequest()）生成的消息，因此返回值是AF狀態(tài)值。
第三種方法：集中式綁定
使用函數(shù)：ZDApp_SendEndDeviceBindReq()
ZigBee設(shè)備對象終端節(jié)點綁定請求-兩個設(shè)備可向協(xié)調(diào)器告知他們想建立一個綁定表記錄。協(xié)調(diào)器通過安排配對并分別在這兩個設(shè)備上建立綁定表條目，也稱集中式綁定。
這一機制規(guī)定在指定的時限內(nèi)，通過按鍵或者其他類似動作對指定的設(shè)備實施綁定。在規(guī)定的時限內(nèi)，協(xié)調(diào)器負責收集終端設(shè)備綁定請求消息，然后根據(jù)相同的配置文件標識號和簇標識號建立相應(yīng)的綁定表格條目。默認的終端節(jié)點綁定時限(APS_DEFAULT_MAXBINDING_TIME)是16秒(在nwk_globals.h中定義)，若要修改可在f8wConfig.cfg中新增數(shù)值。
所有例子的應(yīng)用服務(wù)中都有一個響應(yīng)按鍵事件的函數(shù)（例如，TransmitApp.c中的TransmitApp_HandleKeys()）。這一響應(yīng)函數(shù)調(diào)用ZDApp_SendEndDeviceBindReq()[在 ZDApp.c中]收集該應(yīng)用服務(wù)端點的所有信息，然后再調(diào)用ZDP_EndDeviceBindReq()[在ZDProfile.c中]把信息發(fā)送給協(xié)調(diào)器。或者，像SampleLight和SampleSwitch例程中，按鍵后直接調(diào)用ZDP_EndDeviceBindReq()，僅把與開關(guān)燈函數(shù)相關(guān)的簇標識號發(fā)送出去。
這一消息將會被協(xié)調(diào)器接收[ZDP_IncomingData()in ZDProfile.c]和解析[ZDO_ProcessEndDeviceBindReq()in ZDObject.c]，然后讓回調(diào)函數(shù)ZDApp_EndDeviceBindReqCB()[in ZDApp.c]調(diào)用ZDO_MatchEndDeviceBind()[ZDObject.c]處理這一請求。
當協(xié)調(diào)器接收到第一個綁定請求時，他會在一定的時限內(nèi)保留這一請求并等待第二個請求的出現(xiàn)。（默認的最長時間間隔是16秒）。
一旦協(xié)調(diào)器接收到兩個需要匹配的終端設(shè)備綁定請求時，它就會啟動綁定過程，為發(fā)出請求的設(shè)備建立源綁定條目。假設(shè)在ZDO終端設(shè)備綁定請求中找到匹配，協(xié)調(diào)器將采取以下步驟：
1. 協(xié)調(diào)器發(fā)送一個ZDO解除綁定請求給第一個設(shè)備。終端設(shè)備綁定是一個切換過程，所以解除綁定請求需要發(fā)送給第一個設(shè)備，以便移除一個已有的綁定條目。
2. 等待ZDO解除綁定的應(yīng)答，如果返回的狀態(tài)是ZDP_NO_ENTRY，協(xié)調(diào)器可以發(fā)送一個ZDO綁定請求，在源設(shè)備（ZDP_EndDeviceBindReq()第一個參數(shù)指定的地址）中建立綁定條目。假如此時返回的狀態(tài)是ZDP_SUCCESS，可繼續(xù)處理第一個設(shè)備的簇標識符（解除綁定指令已經(jīng)移除了綁定條目，即已經(jīng)切換完成）。
3. 等待ZDO綁定應(yīng)答。收到以后，繼續(xù)處理第一個設(shè)備的下一個簇標識符。
4. 等第一個設(shè)備完成了以后，在第二個設(shè)備上實行同樣的過程。
5. 等第二個設(shè)備也完成了，協(xié)調(diào)器向兩個設(shè)備發(fā)送ZDO終端設(shè)備綁定應(yīng)答消息。
注意打開編譯選項：REFLECTOR和ZDO_COORDINATOR
ZDApp_SendEndDeviceBindReq()
優(yōu)點：
1. 綁定信息保存在網(wǎng)絡(luò)反射設(shè)備（例如協(xié)調(diào)器、路由器）中，可以節(jié)省目標設(shè)備的內(nèi)存空間。
2. 網(wǎng)絡(luò)反射設(shè)備總是處于監(jiān)聽網(wǎng)絡(luò)的狀態(tài)。所以，如果其中一個被綁定的節(jié)點廣播網(wǎng)絡(luò)地址改變的消息，網(wǎng)絡(luò)反射設(shè)備就可以馬上更新相應(yīng)的綁定表條目。這樣，其他被綁定的節(jié)點即使處于休眠狀態(tài)（沒有收到該節(jié)點網(wǎng)絡(luò)地址改變的消息），隨后向該節(jié)點（網(wǎng)絡(luò)地址已改變）發(fā)送的消息，（在）網(wǎng)絡(luò)反射設(shè)備（協(xié)助下）仍能準確定位。
缺點：
1. 一個與多個設(shè)備綁定的節(jié)點不能只向一個或若干個配對的設(shè)備發(fā)送消息。網(wǎng)絡(luò)反射設(shè)備會向全部已綁定的設(shè)備本別發(fā)送單播消息。
2. 發(fā)送消息的設(shè)備無法收到目標設(shè)備接收情況的通告。（沒有像AF_ACK_REQUEST標志位那樣返回接收情況的功能?。?br style="LINE-HEIGHT: 28px">3. 所有的消息必須經(jīng)過網(wǎng)絡(luò)反射設(shè)備傳輸，降低了網(wǎng)絡(luò)的帶寬。
進一步分析：
與六個設(shè)備綁定的某個設(shè)備，向網(wǎng)絡(luò)反射器發(fā)送一個消息后，會導(dǎo)致反射器發(fā)送六個單播消息。假設(shè)一個網(wǎng)絡(luò)被分成兩個相等的地理區(qū)域A和B，網(wǎng)絡(luò)反射器在兩區(qū)之間的中央。如果發(fā)送消息的設(shè)備在A區(qū)的深處，接收消息的（六個）設(shè)備在B區(qū)的深處，那么每次通過綁定（向反射器）發(fā)送一個消息，A區(qū)的網(wǎng)絡(luò)流量將會是對六個接收設(shè)備分別發(fā)送消息時的六分之一。（這是優(yōu)點?。┑绻l(fā)送和接收的設(shè)備都鄰近在一個區(qū)的深處（假設(shè)離反射器很遠），那么（其中一個設(shè)備通過反射器的綁定功能想其他設(shè)備發(fā)送一個消息）該區(qū)的網(wǎng)絡(luò)流量將會是對六個接收設(shè)備分別發(fā)送單跳消息的許多倍。（這是缺點！）
第四種方法：應(yīng)用API函數(shù)綁定
設(shè)備的應(yīng)用服務(wù)-設(shè)備上的一個應(yīng)用服務(wù)可以建立或者維護一個綁定表。進入設(shè)備上綁定條目的另一種方法是由應(yīng)用服務(wù)本身去管理綁定表。
這意味著應(yīng)用服務(wù)通過調(diào)用以下的綁定表管理函數(shù)，可以在本地進入或者移除綁定表的條目。
管理綁定表使用的API：
bindAddEntry()–綁定表中加條目
bindRemoveEntry()–綁定表中移除條目
bindRemoveClusterIdFromList()–從一個已有的綁定表條目中移除一個簇標識符
bindAddClusterIdToList()–在一個已有的綁定表條目中加入一個簇標識符
bindRemoveDev()–移除某目標地址的所有條目
bindRemoveSrcDev()–移除某源地址的所有條目（協(xié)調(diào)器中）
bindUpdateAddr()–更新條目到新的地址
bindFindExisting()–查找一個綁定條目
bindIsClusterIDinList()–在綁定條目中查找一個已有的簇標識符
bindNumBoundTo()–某一地址（源地址或目標地址）綁定條目的個數(shù)
bindNumOfEntries()–綁定表條目的個數(shù)
bindCapacity()–允許的最大綁定條目數(shù)
BindWriteNV()–在NV中保存新的綁定表
Which Binding Method To Use?
我們應(yīng)該選擇哪一種綁定方式？
Automatic自動綁定的特點：
+no user interaction required無需用戶交互
+no tool cost 沒有工具成本
-development time knowledge開發(fā)時，需要知道詳細應(yīng)用？
-non-configurable 不可靈活配置
Assisted輔助綁定的特點：
+install-time decisions(site-specific knowledge) 安裝時決定（具體現(xiàn)場知識）
+analysis,maintenance,modification,visualization分析，維修，改裝，可視化
can be under installers control可用安裝程序控制
-cost of tool工具成本
Centralized集中綁定的特點：
+allows user to decide允許用戶決定
+cost of tool minimal成本最小的工具
-few,if any,configurable parameters可配置參數(shù)很少
-requires a user interface on each device用戶需要介入每個設(shè)備
Application應(yīng)用API函數(shù)綁定的特點：
+maximum flexibility最大的靈活性
-you must write all the code你必須編寫所有代碼
來自TI E2E社區(qū)的進一步討論：
一、“終端設(shè)備綁定請求”這一命名有誤導(dǎo)的嫌疑。這一請求不僅僅適用于終端設(shè)備，而且適用于對希望在協(xié)調(diào)器上綁定的兩個設(shè)備中匹配的簇實施綁定。一旦這個函數(shù)被調(diào)用，將假設(shè)REFLECTOR這一編譯選項在所有希望使用這一服務(wù)的節(jié)點中都已經(jīng)打開。具體操作如下：
（1） (Bind Req) Device 1 --> Coordinator <--- Device 2 (Bind Req)
協(xié)調(diào)器首先找出包含在綁定請求中的簇，然后對比每一設(shè)備的IEEE地址，如果簇可以匹配，而且這幾個設(shè)備沒有已經(jīng)存在的綁定表，那他將發(fā)送一個綁定應(yīng)答給每一個設(shè)備。
（2） Device 1 <--- NWK Addr Req ------ Coordinator ------- NWK addr Req ----> Device 2
（3） Device 1 ----> NWK Addr Rsp ---> Coordinator <---- NWK addr Rsp <--- Device 2
（4） Device 1 <----- Bind Rsp <----- Coordinator -----> Bind Rsp ----> Device 2
二、“描述符匹配”為源設(shè)備的服務(wù)發(fā)現(xiàn)提供了一種靈巧的方法。下面是具體的操作，這一過程并沒有通過協(xié)調(diào)器。
（1） Device 1 ----> Match Descriptor request (broadcast or unicast) Device 2
（2） Device 1 <---- Match Descriptor response (if clusters, application profile id match) that includes src endpoint, src address <---- Device 2
1號設(shè)備需要維護一個端點和地址的記錄。
許多應(yīng)用服務(wù)最終都會使用第二種方法。
3、綁定
綁定是控制信息從一個應(yīng)用層到另一個應(yīng)用層流動的一種機制。在 zigbee06 版本中，綁定機制在所有的設(shè)備中被執(zhí)行。 綁定允許應(yīng)用層發(fā)送信息不需要帶目的地址，APS 層確定目的地址從他的綁定表格中，然后在信息前端加上這個目的地址或組。 注意：在 zigbee1.0 版本中，所有綁定條目存儲在協(xié)調(diào)器中?，F(xiàn)在所有綁定條目存儲在發(fā)送數(shù)據(jù)的設(shè)備中。
3.1 綁定一個綁定表格
有三種方式建立一個綁定表格：
ZDO 綁定請求 -- 一個試運轉(zhuǎn)工具能告訴這個設(shè)備制作一個綁定報告。
ZDO 終端設(shè)備綁定請求 --一 個設(shè)備能告訴協(xié)調(diào)器他們想建立綁定表格報告。該協(xié)調(diào)器將使協(xié)調(diào)并在這兩個設(shè)備上創(chuàng)建綁定表格條目
設(shè)備應(yīng)用 – 在設(shè)備上的應(yīng)用能建立或管理一個綁定表格 。
任何一個設(shè)備或應(yīng)用能在網(wǎng)絡(luò)中發(fā)送一個 ZDO 信息到另一個設(shè)備，用來建立一個綁定報告。這是調(diào)用綁定幫助并且它將建立一個綁定條目為發(fā)送設(shè)備。
3.1.1 ZDO 綁定請求
通過調(diào)用函數(shù) ZDP_BindReq()（在ZDProfile.h）發(fā)送一個綁定請求。第一個參數(shù)（dstAddr）是綁定的源地址的短地址。 這之前應(yīng)該確定允許綁定，在 ZDConfig.h 文件中有參數(shù)[ZDO_BIND_UNBIND_REQUEST]允許綁定。 能用同樣的參數(shù)調(diào)用函數(shù) ZDP_UnbindReq()移除綁定。 目標設(shè)備將調(diào)用函數(shù) ZDApp_BindRsp()或 ZDApp_UnbindRsp()，反饋綁定或移除綁定的響應(yīng)，返回其操作狀態(tài)為 ZDP_SUCCESS, ZDP_TABLE_FULL 或 ZDP_NOT_SUPPORTED.
3.1.2 ZDO 終端設(shè)備綁定請求
該機制是用一個按鈕按下或其他類似的動作來選擇設(shè)備在指定時間內(nèi)被綁定。在規(guī)定時間內(nèi)，該終端設(shè)備綁定請求信息被收集到協(xié)調(diào)器，并創(chuàng)建一個基于模式（profile） ID 和串（cluster） ID 的規(guī)定的綁定表格條目。默認的終端設(shè)備綁定超時時間（APS_DEFAULT_MAXBINDING_TIME）為 16000（定義在 ZGlobals.h中），但是能被改變
發(fā)送綁定請求
在所有的應(yīng)用例子中有一個處理鍵盤事件的函數(shù)[例如在 TransmitApp.c 文件中的 TransmitApp_HandleKeys()函數(shù)]。在該函數(shù)中，調(diào)用了函數(shù) ZDApp_SendEndDeviceBindReq()[在 ZDApp.c 中]，它將收集應(yīng)用的終端設(shè)備的所有信息并調(diào)用函數(shù) ZDP_EndDeviceBindReq() [ZDProfile.c]，發(fā)送一個綁定信息到協(xié)調(diào)器?；蛘?，在 SampleLight 和 SampleSwitch 例子中，直接調(diào)用 ZDP_EndDeviceBindReq()函數(shù)就實現(xiàn)點亮/關(guān)閉燈的功能。 （嚴重注意：我在協(xié)議里面搜索TransmitApp_HandleKeys函數(shù)，根本搜索不到？，協(xié)議棧似乎沒有包含TransmitApp.c函數(shù)進來）
接收綁定請求
協(xié)調(diào)器將接收[ZDP_IncomingData() 在 ZDProfile.c]這些信息并分析處理[ZDO_ProcessEndDeviceBindReq() 在 ZDObject.c]這些信息并調(diào)用函數(shù) ZDApp_EndDeviceBindReqCB() [in ZDApp.c]，它將調(diào)用ZDO_MatchEndDeviceBind() [ZDObject.c]處理這個請求, 當協(xié)調(diào)器接收到 2 個匹配終端色后備的綁定請求時，它將啟動在綁定設(shè)備上創(chuàng)建源綁定條目的處理過程。該協(xié)調(diào)器有如下處理過程：
解除綁定
1. 發(fā)送一個 ZDO 解除綁定請求到第一個設(shè)備。終端設(shè)備綁定切換處理，所以解除綁定首先被發(fā)送到移除一個存在的綁定條目。
2. 等待 ZDO 解除綁定響應(yīng)，如果響應(yīng)狀態(tài)為 ZDP_NO_ENTRY, 發(fā)送一個 ZDO 綁定請求，在源設(shè)備上制作一個綁定條目。如果該響應(yīng)為 ZDP_SUCCESS, 為第一個設(shè)備繼續(xù)到 move on to the cluster ID for the first device (the unbind removed the entry – toggle)。
3. 等待 ZDO 綁定響應(yīng). When received, move on to the next cluster IDfor the first device。
4. 當?shù)谝粋€設(shè)備完成時，對第二個設(shè)備做同樣的處理。
5. 當?shù)诙€設(shè)備完成時，發(fā)送 ZDO 終端設(shè)備綁定響應(yīng)信息到第一個和第二個設(shè)備
3.1.3 設(shè)備應(yīng)用綁定管理
在設(shè)備上其他進入綁定條目的方式是應(yīng)用層管理綁定表格。 意思是說，應(yīng)用層將調(diào)用下列函數(shù)進入和移除綁定表格條目：
bindAddEntry() ——增加綁定表格條目
bindRemoveEntry() —— 從綁定表格中移除條目
bindRemoveClusterIdFromList() —— 從一個存在的綁定表格項目中移除一個串 ID 。
bindAddClusterIdToList()——向一個已經(jīng)存在的綁定記錄中增加一個群ID
bindRemoveDev()——刪除所有地址引用的記錄
bindRemoveSrcDev()——刪除所有源地址引用的記錄
bindUpdateAddr()——將記錄更新為另一個地址
bindFindExisting()——查找一個綁定表記錄
bindIsClusterIdInList()——在表記錄中檢查一個已經(jīng)存在的群ID
bindNumBoundTo()——擁有相同地址(源或者目的)的記錄的個數(shù)
bindNumEntries()——表中記錄的個數(shù)
bindCapacity()——最多允許的記錄個數(shù)
bindWriteNV()——在NV中更新表
3.2 配置源綁定
允許綁定源的編譯選項 REFLECTOR 在 f8wConfig.cfg 文件中。在文件f8wConfig.cfg,中查看這兩個綁定配置參數(shù)（DNWK_MAX_BINDING_ENTRIES & DMAX_BINDING_CLUSTER_IDS)。DNWK_MAX_BINDING_ENTRIES 綁定表格中最大的綁定實體數(shù)量參數(shù)；DMAX_BINDING_CLUSTER_IDS 是在每個綁定實體中最大的串ID 數(shù)量。 綁定表在靜態(tài)RAM 中(未分配)，因此綁定表中記錄的個數(shù)，每條記錄中群ID的個數(shù)都實際影響著使用 RAM 的數(shù)量。每一條綁定記錄是 8 字節(jié)多(MAX_BINDING_CLUSTER_IDS * 2 字節(jié))。除了綁定表使用的靜態(tài) RAM 的數(shù)量，綁定配置項目也影響地址管理器中的記錄的個數(shù)。
