新人报道，十年zigbee经验交流

zigbee_luo · 发表于 2021-3-18 00:12:04

本帖最后由 27hh 于 2021-4-16 02:07 编辑

十年zigbee经验，但是对mqtt一窍不通，相互学习。

zigbee_luo · 发表于 2021-3-18 00:46:55

简单分享一些主流的zigbee设备端的信息

当前的zigbee设备，应用层都采用了ZCL协议，ZCL更像是USB中的设备枚举。

每个zigbee设备，在固件层就要定义一个或者多个endpoint，最早我也不明白为什么这么做。其实endpoint就是单片机上跑的一个应用，对应一个有应该功能的设备。比如开关，灯，窗帘。一个zigbee单片机可以支持多个endpoint，相同功能和不同功能的组合在一起。但是逻辑上他们是独立控制，互不影响。

每个endpoint中必须有个device ID，来表示这个应用对应的是灯，开关，窗帘（这种多个应用设备组合成一个设备的zigbee设备很常见）。我之前一个项目中，考虑到一个zigbee单片机有一个64bit的IEEE地址，一个endpoint有8bit的ID。组合在一起，一个单片机上的一个应用就可以用72bit的SN号（IEEE地址+endpoint ID）来表示。比如一个有开关，窗帘，灯组合在一起的设备，加入网关后，网关识别出来3个SN号，对应3种应用设备。但是这3个应用设备共用一个zigbee短地址，共用一个IEEE地址。同样，16bit的短地址+8bit的endpoint ID，又构成一个24bit的应用设备地址。采用这种思路去控制设备。

每个endpoint下还有若干个cluster，区分成in cluster和out cluster。每个cluster代表这个应用设备支持的功能，比如灯，开关，窗帘组合的设备有3个endpoint，endpoint_1的in cluster肯定有调光，颜色相关的cluster，endpoint_2的in cluster肯定有开关状态的cluster，而且还可能有电源管理相关的cluster。endpoint_3下肯定有窗帘控制相关的in cluster。具备in cluster的设备在ZCL协议中叫做server，而控制它们的则叫client。一开始我也对server和client的逻辑关系很迷惑，但是按照ZCL的逻辑定义，zigbee网关始终都是一个client，zigbee网关是一个万能的控制者，网关只能控制其它设备，而不能被其它设备控制，只要想清楚这个逻辑关系，就明白server和client了。

每个cluster下，还定义了叫做“属性（Attribute）”和“命令（command）”的两种东西。属性相当于这个应用对应的全局变量，可以被系统的公共接口指令访问，而且属性有定义的数据类型，如uint8型，uint16型，string型……比如一个调光灯，至少应该支持开关状态的cluster和亮度的cluster，开关状态的cluster里面肯定有一个表示当前灯的开关状态的属性（在ZCL协议中该属性为bool型），亮度cluster下必须有有个亮度状态的属性（ZCL协议中为uint8型），每个cluster下还会有其它扩展的属性，比如亮度cluster下可以设置一个开灯默认亮度的属性。属性都是公开的访问接口，可以定义为只读，读写，主动上报三种形式。但是在自己做一个zigbee设备时，千万不要采用写属性的方式去控制开关灯，电机转动等操作（危险性类似给全局变量直接赋值，某大公司做的zigbee灯出过事）。主动上报可以设置属性的值发生改变后自动上报给网关。

说了这些，再继续讲讲怎么识别zigbee设备。zigbee设备加入网关后，网关会获取到设备的IEEE地址，短地址。然后照着短地址，先读取设备的endpoint列表，然后根据endpoint列表再逐个读取endpoint的信息，包括这个endpoint的device ID是啥，有哪些cluster。完成了这一步基本上就知道入网的设备到底是个啥了。实际环境中，经常会有多个zigbee设备挤在一起入网，如果网关要挨个读取endpoint信息，数据交互量很大。这里可以采用类似并行流水线的方式来读取设备的endpoint信息，因此我对ZNP也是深恶痛绝，ZNP没有把zigbee无线通信产生的data confirm消息上报给主机，如果主机能够得到data confirm，可以极大提高并发读取endpoint信息的效率。我自己做了一个类似ZNP的固件，但是串口命令不兼容，也希望找到志同道合的朋友把我的固件一直到zigbee2Mqtt上。