Zigbee智能家居开发分享

从2013年开始听说Zigbee到2016年，大大小小也做过几个Zigbee的项目，其中也有工业控制类的、智能家居类的、无线透传类的，这里主要和大家分享下我在开发智能家居的开发过程的一些心得。

网络环境、低功耗、协议栈bug、ZigBee白名单

本屌的公司就是做智能家居，摊上了这趟浑水，也算是和Zigbee结下了梁子。下面我要分享的这个样板间已经稳定运行了10个月了，同步语音讲解，语音说到开灯，灯就开了，说道窗帘关闭，窗帘肯定就关上了，分毫不差。上次去看了下，坏了两个灯泡，一个面板（灯泡功率太大了，300多W，直接把单火的保险丝烧了），其余完美。每天来样板间参观置业顾问都会为他们展示智能家居，负荷量其实挺大的。不过本屌的网络依然健壮如日中天。

1.1 复杂的网络环境

洋房样板间，一共36个节点，上图红色的都是节点，大概就记得这些了，各种绕来绕去，弱电箱在入门玄关处，网关就放在这里（很Low的STM32+CC2530），所有控制灯光的都是单火供电的PCB天线（正好这个天线是我们硬件小哥最屎的一个版本，现在的这个版本已经ok了，还是大的倒F好），窗帘电机搞成了路由（220V长供电）剩下的就是各种电池供电的红外转发节点、幕布控制节点、温度、湿度、人体红外分散在120平的房子的各个角落。当时只有网关上的协调器加了功放，整个样板间最后就用了两个路由，一个放在客厅的空调出风口（这个节点是专门拿来控制客厅的中央空调用的），另一个是主卧的红外转发，考虑到窗帘电机虽然是长供电，但是放在墙角加上也是PCB天线，为了样板间稳定性，一上电我就用NLME_PermitJoiningRequest关了join权限。

整个网络大概就是这样了。

1.2 低功耗

由于样板间所有的灯光控制都是单火供电的，面板上面还要带3颗led灯，我的天啊，这其实对节点的功耗要求还是有一点的，所以楼主在PM2模式下深深的感受到了无奈。除了用过烂大街的修改request，也自己到ZDO层和操刀了一些函数，所幸所有的单火面板可以正常运行和控制,最低3W灯泡无压力。更低的我就没尝试了。

除了单火就是电池设备了，让置业顾问去换电池显然不合适，既然低功耗，那就要低功耗到底。目前撸主PM3待机下万用表打了一下（勿嘲讽，没钱买设备），大约0.3uA的样子，跑了定时器就会高一点。总的来说，除了常用的添加POWER_SAVING ,适时的对电源的软件上的控制是很重要的，其实功耗主要靠软件降低。

1.3协议栈的bug

撸主遇到过有的信号不好的节点发送Oprah后就一直发送beacon，协调器开启NLME_PermitJoiningRequest后才可以加入，可是撸主的掉线节点是rejoin啊，后来通过修改ZDO层的函数修复了此bug（感谢TI的工作人员 VV和susan还是挺好的）

撸主的ZigBee转485在一开始的时候总是发不出数据，然后撸主用自己写的串口发送，就OK啦，2.6.1的版本。

1.4 ZigBee白名单

其实白名单是撸主2014年搞出来的一个东西，和大家在ti官方论坛看到的“罗菜鸟”也就是教父的不是一样的，罗总的应该更底层一些，我这个白名单就真是菜鸟了。简而言之，就是为了针对多个协调器存在的情况下的一种入网控制机制，协调器组建网络后，只会运行已经添加的节点MAC地址给协调器的设备入网，包括路由节点，所有的节点都是分布式的管理，受信任的节点可以通过任何一个路由设备加入这个网络而不必担心白名单数据同步的问题。

其实后来发现这个功能应用于智能家居很狗血，操作其实不方便，不过再某些应用场景还是可以作为一种不错的方式用于解决复杂的网络环境。目前撸主已经找到了更合适的方法来解决这种批量的问题了。

总的来说，撸主总结了下，开发过程中遇到问题是小事，遇到问题一定要拿数据说话，抓包，分析一定不能偷懒。问题总能解决。

现在撸主又开始踏上了wifi和 蓝牙等设备的新旅程。

有需求找撸主的也可以加这个群343207451（撸主经济压力很大啊），然后就能找到撸主了（QQ32657514*），大家一起讨论低功耗通信的各种屎。

楼主不简单啊，牛！

好

支持，学习了

楼主你好，我现在在做zigbee的单火开关，现在遇到个问题：当主机断电后，单火开关的控制板电流瞬间最大达到20ma，伴随着灯闪烁，是哪里的问题呢？遇到过吗？谢谢！

这个应该是，孤点请求找不到父节点的原因，然后一直Beacon Request 导致的。

beacon扫描信道导致的电流增加。单火负载能力不够，建议从硬件和软件两个方面进行优化。

哈哈哈哈啊哈哈哈哈哈哈哈

恩恩，已解决！谢谢楼主！

谢谢楼主分享