寫作初衷

寫這篇文章是因為最近碰到幾家客戶公司，都自己使用了Zigbee技術做了相關產品，有的是協議棧自己開發的，有的是用的第三方提供的模組，但是在專案大規模應用時出現了各種各樣頭疼的問題，無從下手。帶著這樣的問題來諮詢希望從我們這個得到解決方法，我們也感同身受，因為曾經的我們也是這樣的小白鼠，滿滿的苦……

 

適用前提

本文所有問題是僅針對TI的 CC2530F256晶片，以及TI所提供的半開源Zstack協議棧、ZHA協議棧。

其他Zigbee晶片及協議棧方案，我們沒有大規模應用，所以不做評述。

 

給大家先上眼藥

首先明明白白的告訴大家，協議棧在真實專案應用中，是純在很多問題的，這些問題都是需要通過優化協議棧的邏輯來解決的。

如果你們只是做了應用層的功能開發，就想上專案應用，那麼很不幸，你會為此付出遠超預期的代價。要做Zigbee產品開發，請一定有一顆敬畏之心，深度理解協議棧的運轉原理，修改運轉機制，以符合各自的專案需要。

 

給大家一個安慰

上述所說協議棧的問題並不是真的說協議棧有嚴重的BUG，而是協議棧的設計之初，官方是有官方的設計邏輯的，並不是針對我們的專案，拿來即用的。很多業務邏輯跟我們的真實專案是有區別的，所以我們是一定要修改這些業務邏輯的。

 

來一個忠告

協議棧的優化開發非短時間可以考慮全面的，很多時候，實驗室內是不出問題的。一定要準備好打長期的硬仗，千萬不要急於求成，兵家大忌！！

 

正文

好了廢話不多說，今天針對Zigbee技術，我們只講乾貨，不講理論，希望這篇文章能夠為大家稍稍解答一些疑惑，以過來人身份，來為同行們指明一下開發方向。

 

坑一：Zigbee硬體模組選型

1、無線模組如果是自研的，那麼一定要做好天線部分的效能測試。天線設計的好壞，對專案影響巨大。

2、如果是選用第三方模組，儘量選擇通過認證的模組，以通過FCC認證為佳，其次能夠提供模組天線測試報告（發射的波形圖）。目前市場上，zigbee模組很多，但是能真正做好的也不多，3~5家而已，這裡就不打廣告了。

 

坑二：Zigbee網路抓包工具的使用

Ti 提供的Zigbee抓包工具是Packet Sniffer的使用還是太弱了，不夠人性化。

這裡推薦一下比較強大的抓包工具 ubiqua。

我們開發過程中碰到所有問題一定要抓取資料包，通過資料包來解釋現象，單純的猜測很多時候解決不了問題。

下載連結：https://www.ubilogix.com/ubiqua/

 

坑三：Zigbee的2.4G同頻干擾問題

Zigbee使用的是2.4Ghz頻段，與wifi的2.4G是屬於同一個頻段，那麼自然是會存在一定的干擾。

1、解決這個問題我們可以通過對Zigbee的16個頻道、和wifi的頻道做一下對比，儘量避開主要的干擾頻道，選擇幾個可用通道即可。

推薦文章：http://blog.sina.com.cn/s/blog_595296f50102vkmf.html

 

2、解決同一個通道的Zigbee網路之間也會存在同頻干擾的問題

專案安裝時，需要在實施過程中，儘量避免同通道網路裝置安裝距離太近，以避免資料頻繁的碰撞。關注每臺閘道器內的“協調器”所建立的網路的Channel，業務機制上要注意“協調器通道搜尋及網路建立的機制”

 

坑四：Zigbee節點裝置掉線問題

Zigbee掉線問題是有多種不同的現象的，大家一定要注意區別分析。

1、Zigbee節點掉線，一段時間無法通訊，後又自動恢復了連線

調查：可分析一下整個zigbee網路構成，協調器、路由器是可以起到網路擴充能力的，那麼掉線的終端裝置 與 父節點裝置之間是否具體過長？

 

2、Zigbee節點掉線，需要開放網路才能重新進入

調查：該情況下是Zigbee節點觸發了異常機制，做了恢復出廠設定處理，屬於協議棧的保護機制，那麼這個機制要針對性的去做修改。

 

坑五：Zigbee節點裝置竄網問題

如果碰到Zigbee節點裝置原先執行在網路A 內，一段時間後突然發現裝置進入了網路B 內。

調查：該問題是多個原因組成的

可能原因1：Zigbee節點裝置恢復了出廠設定（異常狀態）

可能原因2：網路B中存在 持續開放網路的許可權 / 網路重連的許可權

可能原因3：Zigbee網路相關配置引數沒有做Flash儲存，掉電等異常情況會導致丟失

……

 

坑六：Zigbee網路內路由裝置和終端裝置的分配問題

Zigbee網路內三種裝置型別，Zigbee協調器、路由節點、終端節點。很多時間大家無法決斷應該如何來分配節點裝置的型別。

推薦：https://blog.csdn.net/u012912039/article/details/52250253

有一點是沒錯的，路由節點承擔網路內的穩定鏈路的工作，所以當路由節點過多時，會出現網路路徑經常更新的情況，這就是網路最優路徑演算法作怪，會導致資料延遲。

 

我們的建議：

A、強供電並且穩定分佈的裝置可以作為路由節點

B、電池類低功耗裝置必須設計作為終端節點

C、根據網路情況，小範圍大密度佈設時，充分計算節點數量，控制路由節點的量

D、大範圍低密度佈設時，強電類裝置儘可能多的設定為路由節點

 

坑七：測試不嚴謹會隱藏很多問題

注意這幾個Zigbee開發中的測試項（裝置數自然越多越好）

1、實驗室內要測試：單臺閘道器 配 100臺以上節點裝置（路由+終端）的穩定性測試，至少1周

2、實驗室內要測試：同通道下，10臺閘道器，每臺閘道器下配5~10個節點裝置（路由+終端）的穩定性測試，至少1周

3、實驗室內要測試：網路的斷電恢復能力

A、整個網路裝置斷電，重新上電，何時能夠恢復？

B、網路內協調器斷電，重新上電，何時能夠恢復？

C、網路內終端節點斷電，重新上電，何時能夠恢復？

D、網路內路由節點斷電，重新上電，何時能夠恢復？

E、網路內隨機部分路由節點、部分終端節點斷電，重新上電，何時能夠恢復？

4、測試網路內，節點裝置處於臨界通訊點時的異常狀態（db較差的情況，測試難度較高）

 

以上是暫時回憶到的，我們在協議棧開發過程中所碰到的這些問題，都是真實技術研發過程中血的教訓。

如果你們在實驗室內碰到了並解決了，那麼產品才真正能放心的通過一兩個實踐專案來做現場測試。

 

————————————————————————————————————————————————————————

雲隱科技是一家專注物聯網領域，基於無線Wifi、Zigbee技術對外提供智慧硬體產品級解決方案的公司，我們的研發產品目前在酒店、公寓及家居中都有大規模應用，穩定性有保障。

選擇雲隱，選擇的是一份控制專案風險的保障，雲隱人始終堅持不忘初心，努力做好產品，技術不斷的迭代更新，不斷的增強我們的技術優勢。

雲隱Zigbee相關業務合作方式：

一、Zigbee模組銷售（內含我司ZHA韌體），客戶可直接應用於專案中，按訂單採購報價

二、韌體定製服務，可根據客戶產品需求提供韌體定製，並提供生產用韌體，一次性收費

三、Zigbee成品銷售，我司有成熟智慧閘道器及Zigbee節點裝置，客戶可免去產品端研發投入，直接做雲端協議對接即可複用