iot-gateway-lighting-gateway相关问题（偏原理性质）

最近一直在弄这个程序来实现对ZLL灯的控制，之前调不通，现在终于都能弄好了，看了看代码，但是还有些问题一直不太明白。

    1、这个应用用的是2531DONGLE，我看到灯控命令通过客户端程序（比如devlist）生成后通过socket发给server（zbcontroller.c），server接到后进行一些处理和解析后，最后是以一个字符数组的形式写给dongle的，然后不同的命令对应的字符数组不同。我想知道的是，这里的字符数组在进到dongle后，2531还要在解析一遍然后加工成zigbee的帧格式发走么，还是这里的数组不作处理了，只是直接通过zigbee协议栈走天线发出去了？换句话说，我想知道的是这里的字符数组是如何约定的，是符合ZLL某个标准的还是只是一个非标的协定。

    2、DONGLE内才运行zstack，整个协议的实现都在这里，那作为server的beaglebone以及gateway的整个程序是不是可以说与zigbee本身的关系并不大，只是需要满足ZLL最上层的一些控制命令的种类和协定就可以？我想问，是不是不修改2531内的程序，单纯修改这个GATEWAY程序是无法实现控制ZLL灯以外的功能；想要干别的事儿就只能两方一同修改才行？

     3、这个2531上的协议栈和zigbee中关于协调器、组网等有关系吗，对于应用开发者来说，是不是不需要关心这个协调器组网、添加终端之类的事情，协议栈自会实现，我们只需要知道设备地址（就像IP地址一样的东西），利用这个协议栈就能够实现数据收发了？

     4、最后，关于这个灯控标准，是不是其实和ZIGBEE的关系并不是很大，更多的是个灯控的命令协议，也就是说这个命令只是通过zigbee这样的一个通信方式在两个设备之间传递而已；或者我可不可以说，其实这个灯控标准也完全可以用在蓝牙或者其他通信的协议之上？（其实自己现在属于一头雾水，可能问题不专业，还望大神不要鄙视）

这里是一段命令的字符数组的代码

void zbSocSetState(uint8_t state, uint16_t dstAddr, uint8_t endpoint,
uint8_t addrMode)
{
uint8_t cmd[] =
{ 0xFE, 11, /*RPC payload Len */
0x29, /*MT_RPC_CMD_AREQ + MT_RPC_SYS_APP */
0x00, /*MT_APP_MSG */
0x0B, /*Application Endpoint */
(dstAddr & 0x00ff), (dstAddr & 0xff00) >> 8, endpoint, /*Dst EP */
(ZCL_CLUSTER_ID_GEN_ON_OFF & 0x00ff), (ZCL_CLUSTER_ID_GEN_ON_OFF & 0xff00)
>> 8, 0x04, //Data Len
addrMode, 0x01, //0x01 ZCL frame control field. (send to the light cluster only)
transSeqNumber++, (state ? 1 : 0), 0x00 //FCS - fill in later
};

calcFcs(cmd, sizeof(cmd));
zbSocTransportWrite(cmd, sizeof(cmd));
}

Chin Lee1

最近一直在弄这个程序来实现对ZLL灯的控制，之前调不通，现在终于都能弄好了，看了看代码，但是还有些问题一直不太明白。

    1、这个应用用的是2531DONGLE，我看到灯控命令通过客户端程序（比如devlist）生成后通过socket发给server（zbcontroller.c），server接到后进行一些处理和解析后，最后是以一个字符数组的形式写给dongle的，然后不同的命令对应的字符数组不同。我想知道的是，这里的字符数组在进到dongle后，2531还要在解析一遍然后加工成zigbee的帧格式发走么，还是这里的数组不作处理了，只是直接通过zigbee协议栈走天线发出去了？换句话说，我想知道的是这里的字符数组是如何约定的，是符合ZLL某个标准的还是只是一个非标的协定。

主频发送数据给CC2531 Dongle的可是是符合MT格式，你可以参考ZIgBee协议栈安装目录下关于MT的文档。Z-Stack Monitor and Test API.pdf

CC2531收到以后，还要组成符合ZIgBee标准的报文发送出去。

    2、DONGLE内才运行zstack，整个协议的实现都在这里，那作为server的beaglebone以及gateway的整个程序是不是可以说与zigbee本身的关系并不大，只是需要满足ZLL最上层的一些控制命令的种类和协定就可以？我想问，是不是不修改2531内的程序，单纯修改这个GATEWAY程序是无法实现控制ZLL灯以外的功能；想要干别的事儿就只能两方一同修改才行？

对的，是的。一般把所有的接口都留出来的，在网关处改就可以了

     3、这个2531上的协议栈和zigbee中关于协调器、组网等有关系吗，对于应用开发者来说，是不是不需要关心这个协调器组网、添加终端之类的事情，协议栈自会实现，我们只需要知道设备地址（就像IP地址一样的东西），利用这个协议栈就能够实现数据收发了？

这个lighting gateway的话，这个网络内的设备都符合ZLL协议，ZLL协议里面没有协调器这个设备，所以CC2531是一个Router。负责网络的创建和管理。对的组网方面的都是协议栈处理的。用户不需要太关心底层协议栈处理，直接使用上层的应用就可以了。

     4、最后，关于这个灯控标准，是不是其实和ZIGBEE的关系并不是很大，更多的是个灯控的命令协议，也就是说这个命令只是通过zigbee这样的一个通信方式在两个设备之间传递而已；或者我可不可以说，其实这个灯控标准也完全可以用在蓝牙或者其他通信的协议之上？（其实自己现在属于一头雾水，可能问题不专业，还望大神不要鄙视）

ZIgBee协议分为两部分，一部分是核心协议栈，主要完成组网之类的。另外一部分是应用协议栈，主要指针对应用的。所以灯控部分主要是应用部分，也属于ZigBee协议栈。

这里是一段命令的字符数组的代码

void zbSocSetState(uint8_t state, uint16_t dstAddr, uint8_t endpoint,
uint8_t addrMode)
{
uint8_t cmd[] =
{ 0xFE, 11, /*RPC payload Len */
0x29, /*MT_RPC_CMD_AREQ + MT_RPC_SYS_APP */
0x00, /*MT_APP_MSG */
0x0B, /*Application Endpoint */
(dstAddr & 0x00ff), (dstAddr & 0xff00) >> 8, endpoint, /*Dst EP */
(ZCL_CLUSTER_ID_GEN_ON_OFF & 0x00ff), (ZCL_CLUSTER_ID_GEN_ON_OFF & 0xff00)
>> 8, 0x04, //Data Len
addrMode, 0x01, //0x01 ZCL frame control field. (send to the light cluster only)
transSeqNumber++, (state ? 1 : 0), 0x00 //FCS - fill in later
};

calcFcs(cmd, sizeof(cmd));
zbSocTransportWrite(cmd, sizeof(cmd));
}

最后建议你使用我们最新的gateway方案，基本架构和你这个一样，但是稳定性更高。

http://www.ti.com/tool/cc2531em-iot-home-gateway-rd?keyMatch=iot%20gateway%20zigbee&tisearch=Search-EN-Everything