写作初衷
写这篇文章是因为最近碰到几家客户公司，都自己使用了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节点设备，客户可免去产品端研发投入，直接做云端协议对接即可复用