流程如下:
1、网络中有ZLL Bridge、ZLL Remote、ZLL Light各一个,都处于FN状态;先将Bridge与Light Touchlink,成功;
2、通过电脑给Bridge发送open的开网命令,接着给Remote发送传统加网命令;
3、现象:网络中不断出现Bridge与Remote的数据交换,从Remote的Pan可以看出应该与Bridge处于同一个网络中,即加网成功,但是如果想用Remote与Light进行Touchlink则不成功,无法控制Light。抓包如附件。
如何解决该问题?先谢过!
Zoutao Wen:
经过一天的尝试后,发现:
1、Bridge与Remote的数据交换不是造成问题的主要原因,因为即便把数据交换间隔调成5秒也无济于事(DPOLL_RATE 5000);
2、通过抓包,确定传统加网后的Remote PAN ID 的确与Bridge的相同后,对Light进行TL,发现在zll_Initiator.c的zllInitiator_event_loop内,在ZLL_CFG_TARGET_EVT这个簇的判断中,无法进入注册TL灯的函数段,检查程序发现,原来程序需要判断!zllJoinedHANetwork || ( _NIB.nwkPanId == selectedTarget.scanRsp.PANID)这两个条件,但恰好传统加网后的Remote 首先zllJoinedHANetwork为1,其次其PanId不一定与灯一样,因此无法与灯TL。
3、知道原因后,将这整个判断舍弃之后,传统加网的Remote可以TL并控制灯,但是竟然可以做到Bridge和Remote同时控制一个灯,抓包如附件,不知道会不会对协议栈本身造成进一步的影响。
4、目前发现,只要是陌生灯,需要先跟Remote相连再跟Bridge相连才能做到同时控制同一个灯的效果;但是,如果先用Bridge连接,用Remote再连的时候,即便TL成功,但Remote还是不能控制灯。原因未知
VV:
回复 Zoutao Wen:
非常认真,赞一个。
3,没有任何影响。但是一般都是用Remote和Bridge通过TL,使得Remote加网。这样做的目的在于双方会把地址段分好,也就是说如果有一个新的灯来的,跟Bridge TL和跟Remote TL ,分配的短地址是不是冲突的。但是你现在的做法可能会冲突。
4,Remote有没有事先加到网络里面呢?
建议将Network key改成fixed,这样我这边看数据包,解密就会方便点。