改进的zigbee适配器示意图

zigbee_luo

如图所示，我们的网关都是通过UART和zigbee适配器通信，zigbee适配器把消息转发到设备端。其中蓝色是UART通信，红色是无线通信。这个只是简单的示意图，在zigbee底层还有路由寻址，实际情况更复杂。
网关 主机在对第三方设备控制时，有3个明显的延时。因此我自己的zigbee适配器，对延时做了优化。

延时1：主机发送数据包到zigbee适配器，但是zigbee适配器不会将数据包立即发出去，而是把数据包加载进发送队列buffer中，并通过串口返回Send Ack。主机务必遵照收到Send Ack再发送下一包数据的原则。延时1的时间非常短，zigbee的处理器，以CC2652或者EFR32来说，都有cortex M4甚至cortex M33的内核，在执行内存搬运和内存查找这样简单的任务时，基本上不到1个毫秒就能完成。因此延时1对网关主机的连续控制影响并不大。

串口应答：串口应答只能告诉主机，zigbee适配器有没有把主机发给它的数据包加载到发送队列buffer中。如果主机编辑的数据包格式不正确，或者zigbee适配器没有足够的发送队列Buffer，都会导致串口应答返回“失败”的状态。主机收到这样的消息后，可以等待zigbee适配器的发送队列Buffer有空间了再重试，但是如果是主机编辑的数据包格式不正确的话就检测自己的代码错在哪里。

延时2：数据包从进入zigbee适配器的队列Buffer，到发送出去的延时。这个延时就是一个不可控的。zigbee底层发送数据的逻辑还是比较复杂的，zigbee适配器中通常有很大的路由缓存，zigbee设备发送无线数据包时，会先在路由缓存中寻找目标地址的通信路径。如果路径不存在，则需要通过路由算法来新建路由链路。因此我们经常会看到这个现象，网关第一次控制某个设备时延时2会比较长，但是第一次控制成功后，以后大约1~3分钟内，继续控制这个设备，延时2会变得非常短。 另外在延时2期间，网关可以继续把新的数据包发送到zigbee适配器的发送队列buffer中，而且在发送队列buffer中的数据包，会因为目标寻址方式的不同，对应的延时2也不同，因此实际会出现乱序的现象。比如APP连接网关后，先打开灯A，后打开灯B，但是看到的是B先亮，A后亮。另外如果设备带休眠功能，延时2会很长，通常zigbee适配器的发送队列buffer对一个数据包的保存时间最大7秒钟，如果休眠设备能够在这个时间范围内唤醒一次，就能收到数据包。否则就算数据超时。

发送确认：发送确认并不适合表示数据包发送是否成功，而是用来表示zigbee适配器的发送队列buffer是否被释放掉。如果需要连续发送多个数据包给同一个设备，则需要等待zigbee适配器返回了与该设备相关的发送确认，才继续发送下一包。在我自己做的zigbee模组上，发送确认里面加了目标地址，端口号和帧序列号，通过该信息可以追溯对应的发送的数据包。虽然官方的zigbee适配器（比如TI的ZNP）也提供了发送确认命令，但是没有提供完整的追溯机制，而且并不是所有的控制命令都可以通过发送确认来追溯，比如查询设备端点数和Cluster表，这两条命令就没有发送确认，在多设备同时识别时会比较吃亏。另外发送确认机制，在网关发数据包给休眠设备非常有用。网关给一个休眠设备连续发多个控制命令，但是休眠设备不唤醒，那么这些数据包就一直堵在zigbee适配器的发送队列Buffer中，造成“占着茅坑不拉屎”的现象。

延时3：这个延时取决于第三方设备内部处理，如果第三方设备不存在，根本连数据包都不会返回（发送确认会返回异常消息）。另外不同的第三方设备，延时3都不同。甚至同一个设备上不同应用，延时3也不同。如果目标设备是带RTOS的，可以运行多任务，还会出现zigbee Response乱序。因此我在Send Request上加了帧序号，而第三方设备返回的Receive Response也会带上相同的帧序号。一旦主机收到乱序的Receive Response，可以根据帧序号来追溯对应的Send Request数据包。

firewater

感谢分享