智能家居之我见（四）——智能家居技术、解决方案

　　新年新气象!从今天起，Dr.Bee将少谈些概念，多讲点技术。智能家居技术、解决方案也是魔蜂的看家本领。

　　每一篇我们都尝试就一个问题展开讨论，希望对技术感兴趣的朋友们可以固定每周一进来逛逛，并有所收获。

　　在开始聊技术前，我们暂且做个假设——我们未来所使用的智能家居系统是由很多传感器、开关装置和中央监控系统组成的，这些器件互相之间协作完成对家居“智能化”的支持。

　　在现阶段，我们所开发和使用的echo系统已经加入了IFTTT的一些做法，但是应该说，我们还处在“家居自动化”发展阶段。我们目前所努力做的一个重要方面，还是在不断完善人机交互的控制与反馈以及build-up connection。当越来越多connected home系统能够稳定运行时，智能化的实现才会真正到来。

　　言归正传，今天我们就先来谈一下connection的问题。

　　connection是一个比较偏通信方面的问题，不过这个问题在产品开发和谋划未来市场时都应该被考虑到。目前用于家居系统的通信协议很多，ZigBee、Z-Wave、WiFi、Bluetooth、6LoWPAN，当然也有很多其他自有协议。毋庸置疑，这些协议都有其各自的生存空间和适合其的应用场景。相关详尽的介绍或针对这些技术进行比较的文章，网上比比皆是，在这里我们就不一一赘述了。按照目前的发展，Dr.Bee认为，ZigBee技术会在一段时间内占据比较大的优势，并在家居自动化领域得到较广泛的应用。

　　ZigBee的低功耗和支持多节点等性质使其成为目前传感器网络中的佼佼者，虽然它所支持的数据率不高，传输距离上也有限，但是被用作以数据采集和监控为目的的传感器网络已经足够了。当然使用ISM2.4G有利有弊，不过就目前发展看，人们暂时还没有把它的“弊”放在首要考虑位置，同时ZigBee也支持gigahertz。

　　要形成一个ZigBee网络，我们必须有一个Coordinator(协调器)。它的主要功能是形成一个网络并且允许其他ZigBee节点加入网络、分配网络地址、调节地址冲突、协助其他加入设备进行cluster进配对等。在目前的家居系统中，这个协调器通常被放在Gateway(或者Universal Hub)中，这样用户或者Gateway的控制者可以远程通过web api或者本地方式(使用按钮)形成网络、监控网络等。我们之前提到过德国电信Qivicon Hub就是这种形式，用户可以通过登陆web应用形成家居系统并控制和使用系统内的各种传感设备、报警设备和开关设备等。

　　在形成网络前，Coordinator通常会先扫描信道(2.4G channel11-26)，目前为减少和WiFi之间的信道干扰，ZigBee推荐的家居自动化使用信道为(11，14，15，19，20，24，25)。在扫描时，Coordinator会记录下被扫信道的噪声情况并选择扫描时噪声最小的信道，并在上面形成网络。

　　在网络形成时，Coordinator会进行一系列的本地操作，比如确定PANID、Extended PANID等，其中很重要的是security设定，也就是我们通常所说的网络密钥。在ZigBee家居自动化协议中规定了固定密码，这也就意味着所有经过认证的产品都应该可以使用这一密码加入一个ZigBee Home Automation(ZHA)网络。这一密码在1.0-1.2.1 协议中未曾变过。当然由于很多原因，一些未经过认证的产品也通过某种渠道获得这一密码，那么其产品也可以加入到ZHA网络中。

　　在网络形成后，Coordinator通常需要打开网络，在早期的ZigBee家居自动化中，Coordinator不可以永久性打开网络，一般只可以开网60秒;而在修订后的现行规范中，Coordinator在形成网络后可以发送可加网命令广播并打开网络至少3分钟。网络打开后，用户便可以尝试把新的部件加入到网络中了。

　　目前我们比较常见的ZigBee based传感器在加网时也是通过发送beacon request对信道进行扫描，收集beacon，比较link cost，然后尝试加入link cost在接受范围内的网络(PAN)。这里就会出现一个问题：如果在一栋大厦里，刚好两个Coordinator同时开启了允许入网模式，如何能确保要加入的传感器能够准确加入自己的网络?

　　在这个问题上，很多传感器的设计者会选择加入收到beacon能量比较强的的网络，但如果一家用的是强功率天线，另外一家用的是一般天线，那岂不是两个传感器都会加入强功率天线的网络?

　　Dr.Bee曾经考虑过ZigBee Light Link的做法，感觉touch link虽好，但实际上应用场景也有限，不适于较大规模的组网，更何况，如果考虑sleep end device 和child node的管理问题(之后我们会讨论这个问题)情况会更复杂。

　　目前Dr.Bee认为，我们能做的还是在Coordinator端下功夫，当然使用非公共密钥会是一种解决方案，但是未必最佳，因为会影响设备的通用性，目前协议HA1.3版本中有能看到使用install code的想法，但是终究这会不会是解决方案，尚是未知数，因为如果引入install code的使用，ZHA有助于提高安全性和加网时的异网识别率，但是这将改变一直以来，ZHA简单的密钥交换方式。如果想保证向后兼容，实施难度暂且不谈，成本肯定会提高，不利于ZHA发展，当然，目前再说ZHA有点落伍，ZigBee3.0才是其真名。

　　不考虑密钥使用，那么只能在Coordinator段的应用层加入一定的判定机制，通过Coordinator本地属性和加网设备属性判定是否可以允许加入设备继续停留在网上，否则应该使用网络leave request强行驱逐加入设备。至于哪些属性我们可以用来比较，Dr.Bee曾参与设计过几种适合不同系统的机制，这些机制根据系统安全级别、网络中节点构成、各节点间通信频繁程度会略有不同，但是宗旨都是：使Coordinator能够起到网络管理员作用，时时监管网络。