引言

目前，國內市場上ZigBee產品雖然很多，但大多采用 的都是私有協(xié)議棧，阻礙了不同廠家產品之間的互用和替代， 這也是ZigBee市場規(guī)模無法迅速擴大的一個重要原因，因 此，開發(fā)具有符合標準規(guī)范的ZigBee產品成為當務之急。目 前國內的ZigBee行業(yè)規(guī)范還正在處于形成階段，但國際上的 ZigBee規(guī)范已經建立并受到國際上眾多廠商的追隨，因此， 本文就如何開發(fā)符合ZigBee聯(lián)盟規(guī)定的HA規(guī)范的ZigBee 應用進行了探討。

Z-stack是TI公司推出的ZigBee協(xié)議棧系統(tǒng)，這是一個 通過ZigBee聯(lián)盟認證的符合ZigBee2007規(guī)范的平臺。借由 TI公司ZigBee芯片及SOC產品在國內的廣泛接受，Z-stack 也稱為眾多芯片廠商提供的協(xié)議棧中開發(fā)者接受度比較廣的一 款ZigBee協(xié)議棧。本文探討的ZigBee產品應用開發(fā)是基于 Z-stack協(xié)議棧的。

收稿日期:2013-01-30

ZCL 庫(ZigBee cluster library)111

在ZigBee協(xié)議棧中，簇是一組命令和屬性的集合，這些 命令和屬性組合起來，構成了實現某一功能的實體。

ZCL是由ZigBee聯(lián)盟制定的包含了大量功能簇(cluster) 的大集合。在應用開發(fā)中，以ZCL中已有的簇作為功能單元 來使用，可以增強通用性，避免重復開發(fā)。

ZCL對功能簇進行了分類和描述。每個功能簇都包含有 一個或多個屬性及命令，ZCL對每個屬性都進行了定義和描 述，包括屬性ID、名稱、數據類型、數值范圍、初始值、可 讀寫性以及強制性;同時，也對此簇所包含的命令進行了定義， 包括命令ID、命令名稱、命令數據幀內容和觸發(fā)效果等。

ZCL中的通信是基于Client/Server模型的以簇為單位進 行的。兩個不同功能設備之間的相互通信，是基于某一個或多 個功能簇的。用來儲存這些簇屬性的設備，稱為Server端； 而用來操作這些簇屬性的設備，稱為Client端。針對Client/ Server端口類型的不同，同一個簇也具有不同的屬性和命令。例如，操作屬性的命令，通常由Client端發(fā)送給Server 端；而用針對這些操作命令的回復，通常由Server端發(fā)送給 Client 端。另外，報告類型的命令(report attribute command) 通常由Server端發(fā)送給Client端。以On/Off簇為例，該簇的 作用是實現開關設備的開/關狀態(tài)的控制，體現在設備上，分 為Client端和Server端兩種角色的設備，比如開關是Client端, 而某個具有ZigBee模塊的燈節(jié)點則代表了相應的Server端。 Server端作為命令的接收者，必須能夠識別開/關/切換這幾 個來自Client端的命令(在ZCL中，已經規(guī)定好這些命令對 應的ID,如0x00代表關,0x01代表開,0x02代表切換)，同時, 由于命令操作的是屬性，因此，該Server端必須保存有開關 狀態(tài)這一屬性。

另外，ZCL制定了基于cluster的各類命令幀的格式(包 括讀、寫、報告等)；定義了用于尋址的各指示參數(包括規(guī) 范ID、設備ID、簇ID、屬性ID和命令ID)；規(guī)定了用于各 屬性和命令中各類數據的數據類型；還規(guī)定了在通信中可能 會出現的所有狀態(tài)的枚舉數組。

HA(home automation)規(guī)范[2]

HA規(guī)范是由ZigBee聯(lián)盟(ZigBee alliance)制定的對用 于住宅環(huán)境的各類常見應用的設備描述和操作規(guī)范。通過這 一規(guī)范，為不同廠商的ZigBee HA設備提供了標準的接口和 定義，確保其相互之間能夠相互通信并協(xié)同工作。

HA規(guī)范的范圍主要集中在對家用設備進行的實時操 作，該規(guī)范可以構筑在ZigBee2007的兩個子規(guī)范(ZigBee、 ZigBee pro)之上。

HA規(guī)范可以簡單分成圍繞網絡特性的參數設置和圍繞 功能實現的設備描述分類(包括相應設備的簇以及特性和功 能)這兩大部分的內容。

2.1參數設置

HA規(guī)范對涉及到協(xié)議棧各功能方面的一些參數進行 了明確的規(guī)定，例如用于設備啟動時的啟動參數集(startup attribute sets),要求每個設備都必須內置這些參數，例如將 PAN ID設置成0xffff等。還有比如用于網絡重連接的時間間 隔、安全中心連接秘鑰等等參數。

在安全參數的設置方面，HA規(guī)范中規(guī)定，設備的初始 網絡安全秘鑰(network key)是空的，即每個設備的網絡安全 秘鑰必須由安全中心來統(tǒng)一分配；而安全中心連接秘鑰(trust center link key)是每個設備都預置好的。

2.2設備描述

HA規(guī)范對可能會用到的設備進行了劃分并設置了相應的 ID,在HA網絡中的每個終端都必須符合至少一項該分類圖 中給出的設備描述分類(如果同時符合多個設備描述的話，需 要在自己的設備描述中枚舉這些設備類型)。

在HA規(guī)范中，每個設備描述都詳細規(guī)定了其所支持的 簇，以及所支持的特性和功能。以通用設備中的開關(On/Off Switch)設備為例。其所支持的簇如表1所列。

也就是說，如果某個設備是開關的Client端節(jié)點，則必 須具有On/Off簇，用以發(fā)出控制On/Off屬性的命令。

針對每一類設備，HA規(guī)范都通過特性和功能描述對其 進行行為上的描述，而通過其所包含的cluster來對其進行程 序層面上功能域與接口的界定。從整體上來講，HA規(guī)范中為 一個設備應該實現什么以及如何實現進行了明確的說明。

Z-stack中的ZCL庫及使用

Z-stack協(xié)議棧中包含有針對ZigBee聯(lián)盟的ZCL規(guī)范進 行編寫的ZCL庫，用以在自己的協(xié)議棧中支持ZCL的實現叫 ZCL層API封裝了大量針對ZCL的包括幀格式、命令ID等 細節(jié)，而只是向開發(fā)者提供了簡單明了的命令函數，通過引入 ZCL層API,可以大大簡化標準化應用的開發(fā)。在Z-stack中， 利用ZCL層API開發(fā)符合HA規(guī)范的應用的步驟如下叫 3.1 ZCL層的注冊及初始化

首先，必須將ZCL層初始化并注冊到任務列表中 去。ZCL的初始化是在osalInitTasks函數中添加zcl_Init( taskID++ )語句，用來給ZCL層的事件分配一個任務ID ；注 冊即是在OSAL的任務列表tasksArr[]中，添加zcl_event_ loop, zcl_event_loop是在zcl.c里定義的用來處理ZCL層事 件的一個任務循環(huán)函數。

ZCL層的注冊和初始化必須放在應用層之前。

3.2應用層的注冊和初始化

用ZCL來構建基于HA規(guī)范的應用層，與ZCL層的注 冊和初始化相類似，也必須在任務列表里添加應用層的任務 循環(huán)，并在初始化函數中進行初始化。

應用層的初始化主要包括以下幾個方面。

3.2.1終端節(jié)點的注冊

通過zclHA_Init函數對終端節(jié)點進行注冊，表明該節(jié)點 是HA規(guī)范中的一個節(jié)點，該注冊過程同時也包括了該節(jié)點相 應功能簇的注冊。

3.2.2 ZCL回調函數集的注冊

ZCL中每一類設備都會包含一系列與其實現功能相關的命令（包括自身發(fā)出的和來自其他設備的），ZCL回調函數集 用以接收并處理這些來自其他設備發(fā)出的命令。

HA規(guī)范中每個功能域都有不同的回調函數集，用以接收 不同種類的命令。以HA規(guī)范中的General功能域為例，其所 包含的回調函數類型如下：

typedef struct

{

zclGCB_BasicReset_t pfnBasicReset; // Basic Reset zclGCB_Identify _t pfnIdentify; // Identify Response zclGCB_IdentifyQueryRsp_t pfnIdentifyQueryRsp; // Identify Query Rsp

zclGCB_OnOff_t pfnOnOff; // On/Off cluster zclGCB_LevelControlMoveToLevel_t pfnLevelControlMoveTbLevel; // MoveToLevel

zclGCB_LevelControlMove_t pfnLevelControlMove; // Move

zclGCB_LevelControlStep_t pfnLevelControlStep; // Step zclGCB_LevelControlStop_t pfnLevelControlStop; // Stop zclGCB_GroupRsp_t pfnGroupRsp; // Group Response zclGCB_SceneStoreReq_t pfnSceneStoreReq; // Scene Store Request

zclGCB_SceneRecallReq_t pfnSceneRecallReq; // Scene Recall Request

zclGCB_SceneRsp_t pfnSceneRsp; // Scene Response zclGCB_Alarm_t pfnAlarm; // Alarm Req & Rsp zclGCB_Location_t pfnLocation; // RSSI Location zclGCB_LocationRsp_t pfnLocationRsp; // RSSI Location Rsp

} zclGeneral_AppCallbacks_t;

每個節(jié)點根據功能域的劃分來選擇對應的回調函數集的 類型（例如節(jié)點用到的是General功能域下的某些功能簇，則 使用zclGeneral_AppCallbacks_t類型來構建回調函數集），并 根據實際功能的需要來裁剪和自定義自己的回調函數集。

在完成回調函數集的構建之后，通過調用相應功能 域的注冊函數來注冊該功能域的回調函數集（如要注冊 zclGeneral_AppCallbacks_t類型的回調函數集，則需要使用 相應的 zclGeneral_RegisterCmdCallbacks 函數）。

3.2.3 ZCL屬性的注冊

每個簇都有相應的一個或者多個屬性，在Z-stack中, 簇屬性由zclAttribute_t類型來表征。具體結構如下所示：

typedef struct

{

uintl6 attrId; // Attribute ID

uint8 dataType; // Data Type - defined in AF.h

uint8 accessControl; // Read/write - bit field

void *dataPtr; // Pointer to data field

} zclAttribute_t;

由于每個簇可能有多個屬性，并且每個節(jié)點可以有多個功 能簇，因此，通過屬性列表zclAttrRec_t類型來表征一個節(jié) 點所具有的屬性集合。

typedef struct

{

uint16 clusterID; // Cluster ID

zclAttribute_t attr; // Attribute record

} zclAttrRec_t;

開發(fā)人員在構建了該應用節(jié)點的屬性列表之后，通過zcl_ registerAttrList函數完成這些屬性的注冊。

3.2.4 ZCL層消息的注冊

由于ZCL是一個中間層，其負責接收并初步處理的一些 消息需要上傳至應用層來處理。為了實現這一功能，需要調用 zcl_registerForMsg函數來在應用層進行注冊，確保經ZCL層 預加工的消息能夠傳達到應用層。

3.2.5其他注冊

其他注冊包括一般應用都需要的按鍵事件的注冊、ZDO 層消息的注冊［5］以及一些非HA規(guī)范節(jié)點的注冊等。

3.3應用層邏輯的實現

應用層邏輯的開發(fā)與一般應用開發(fā)的區(qū)別，主要就是 使用ZCL層API來進行命令的發(fā)送，比如當觸發(fā)開關按 鍵時，使用ZCL庫的API來發(fā)送相應的命令zclGeneral_ SendOnOff_CmdOn,可以看到，在應用層只需寫入這種標準 命令函數，協(xié)議棧會自動調用下層的函數庫來進行相應的操作 并實現命令的發(fā)送。

另外還需要注意的一點是，在應用層的節(jié)點行為以及網 絡層的參數設置上，也必須符合HA規(guī)范給出的限定，例如 PAN ID的設置、安全相關的一些秘鑰的初始值設置以及終端 設備向父節(jié)點輪詢的時間間隔等參數和行為的設定。

4結語

可以看到，通過在協(xié)議棧中引入ZCL層，可以大大簡化 符合HA標準的ZigBee應用的開發(fā):來自應用層的數據通過 ZCL層的封裝處理后，實現了數據和命令格式的標準化;同樣, 來自其他設備或節(jié)點的消息通過ZCL層的分析和提取，能夠 將應用層敏感的命令和相關數據直接呈現給應用層，從而保 證應用層只需關注于其節(jié)點自身功能的實現，而將繁瑣的標準 化通信任務交給下層來處理。

20211020_61702baf2afa0__基于Z