1.2.1 Z-Stack
Z-Stack[6，7]是TI公司開發的開源ZigBee協議棧，Stack協議棧中提供了一個名為操作係統抽象層OSAL的協議棧調度程序， Z-Stack協議棧操作的具體實現細節都被封裝在庫代碼中，開發者直接調用API，無需知道協議棧的實現過程。Z-Stack采用分層的軟件結構定義了通信硬件和軟件在每個分層裏怎樣協調工作，協議棧的各層相對獨立，每一層都提供相應的服務，設計者隻關心與他的工作直接相關的那些層的協議，為設計帶來極大的方便，協議棧的每個工程都包含用戶應用層、硬件抽樣層、物理層、網絡層、操作係統抽樣層和設備對象層等目錄文件。
任務的執行通過係統消息進行調用，在初始化函數osalInitTasks中對任務進行初始化，為每一個任務分配一個ID號，任務保存在tasksArr[]數組，通過循環查詢獲取相應的ID號進入對應的任務處理程序，本課題研究采用的是SampleApp_ProcessEvent這個任務。
1.2.2 Z-Stack協調器、終端和路由器的聯網過程
首先，ZigBee協調器上電以後，周期發送空的數據包，在允許通道內搜索其他ZigBee協調器，並基於每個允許通道中所檢測到的通道能量及網絡號，選擇惟一的16位PAN ID，建立自己的網絡[4]。一旦一個新網絡被建立，ZigBee路由器與終端設備就可以加入到網絡中了。而終端設備上電以後，重複發送信標請求，要求加入到最近的網絡中。當協調器發現終端設備發出的信標請求，則響應一個超幀結構，用於設備間的同步，一旦同步成功。
2 硬件設計
為了使用Z-Stack無線通信協議，本研究的硬件模塊用CC2530實現，TI公司已經在CC2530集成了ZigBee係統，CC2530設備使用8051CPU內核[8]。它有三個不同的存儲器訪問總線（SFR、DATA和CODE/XDATA），以單周期訪問SFR、DATA和主SRAM。它還包括一個調試接口和一個18輸入輸出的擴展中斷單元，CC2530提供了一2.4 GHz的IEEE802.15.4兼容無線收發器。RF內核控製模擬無線模塊。
DHT11數據通信是單總線協議，隻要一根數據線就可以完成數據通信，接法簡單，除去兩個電源接口後，將其數據接口接入CC2530的一個GPIO口，本設計將數據接口接入CC2530的P1_0。
3 軟件設計
結合ZigBee的協議，將軟件設計分成節點數據采集模塊、節點監測模塊、協調器網絡通信模塊，數據采集模塊主要完成DHT11的溫濕度采集；節點監測模塊負責將節點數據發送到協調器；協調器的網絡模塊設計負責將收集的數據發送到雲終端服務器。
3.1 節點數據采集模塊設計
采集濕度和溫度DHT11與CC2530之間能采用簡單的單總線進行通信[8]，僅僅需要一個口數據格式采用單總線格式，即單個數據引腳端口完成輸入輸出雙向傳輸，其數據包由5個字節組成，數據分小數部分和整數部分，一次完整的數據傳輸為40位，具體的數據格式為： 8位濕度整數數據+8位濕度小數數據+8位溫度整數數據+8位溫度小數數據+8位校驗和，校驗和數據等於“8 b濕度整數數據+8 b濕度小數數據+8 b溫度整數數據+8 b溫度小數數據”等於結果的末8位。
根據0時序和1時序圖可知，其區別在於總線拉低50 μs後，自動拉高，這時候延時大約30 μs，判斷是否高電平，如果總線拉低了，則表示為數字0；如果總線還是高電平，則表示數字1。
數據由5個字節組成，數據分小數部分和整數部分，根據0和1時序圖，每個字節有8位組成，即每次循環讀取8位，共讀5次。
（1）拉低總線，通過設計連接的IO口將其拉低；（2）延時18 ms，拉高總線；（3）延時40 us，等待總線拉低，如果總線拉低，說明DHT11有響應信號；（4）將總線拉高，開始輸出數據；（5）讀取濕度整數部分；（6）讀取濕度小數部分；（7）讀取溫度整數部分；（8）讀取溫度小數部分；（9）讀取校驗位；（10）數據讀取後，拉高總線。
DHT11的數據接口設計後，通過調用DHT11_read接口，把溫度和濕度值讀取出來。