终端不能通过路由入网

6790行，终端D729不能通过路由A68F入网，因为路由A68F一直不给终端发送key。但终端是可以通过其他路由入网的，说明是这个路由的问题。求解

user4381970：

1869行协调器给门锁435D发送开锁指令，通过路由FE98转发。但FE98不转发。

门锁435D的父节点是E6B0。

1873和1896行的link status中查看路由FE98和门锁的父节点路由E6B0都是连接的。

但通信不上。后面还有好几条数据同样如此。除非门锁重新入网，求解路由不转发.zip

user4381970：

6790行终端不能通过路由入网.zip

miffy：

回复 user4381970:

至少我也遇到过通过路由无法入网的问题，最后我不得不将设备放在协调器附近，让其入网，之后再部署到所需位置，不知道其他人有没有遇到。

0xA68F收到Transport key之后似乎并没有给你的目标节点0xD729发送，你的那么多设备怎么都在拼命发data request，我觉得可能是这个导致网络拥塞，才无法入网的。

user4381970：

回复 miffy:

如果是可以移动的终端是可以移动位置来改变父节点来解决。但是像单火开关和门锁，很难改变位置的。终端有时候总是一直加那个加不上的路由父节点。
实际使用中，30-50是很正常的，甚至70多个设备都很普遍的。

Susan Yang：

从ZigBee协议角度来说，节点加入网络选择父设备是随机的。

若是您需要自己修改协议的话，可以下面函数中做修改：

ZDO_beaconNotifyIndCB( NLME_beaconInd_t *pBeacon )

user4381970：

回复 Susan Yang:

路由不转发的问题不只是入网时候，与终端上下行数据，都可能出现。1869行协调器跟门锁发送开锁指令。先发给路由1，但路由1没有转发给路由2.门锁的父节点是路由2.
也碰到过终端汇报数据给协调器，中间结果路由，但路由不转发的情况。使用的都是zcl_sendcommand命令发送的，参数也没有NwkFrameCounter啊，也不存在NwkFrameCounter不变啊，也不是2级路由的问题，1级路由也发生过。

miffy：

回复 user4381970:

虽然不是对题，但对于zigbee技术的探讨，也不算是题外话。

1、目前就我遇到的zigbee控制类问题，也同样类似，协调器下发给被控终端的指令，经过多级router后，有时候莫名其妙的丢失（即控制不到），但有时候又正常。这和当初预想的zigbee可以多级转发效果迥异。我发现默认的协议栈zcl_ota.c里面OTA会不停的一直不定时发出OTA image request请求包，节点多了之后大家都一直在发，可能导致网络拥塞，MAC层溢出丢包了，毕竟MAC层的收发队列是有限的(默认各5个)，短时间内收到大量数据包来不及转发，可能就会导致丢包。

 

#ifndef ZCL_STANDALONE// Register for all OTA End Point, unhandled, ZCL foundation commandszcl_registerForMsgExt( task_id, ZCL_OTA_ENDPOINT );
#endif#if 0// Per section 6.1 of ZigBee Over-the-Air Upgrading Cluster spec, we should// periodically query the server. It does not specify the rate.For example's// sake, here we query the server periodically between 5-10 minutes.uint32 queryImgJitter = ( ( uint32 ) osal_rand() % OTA_NEW_IMAGE_QUERY_RATE ) + ( uint32 ) OTA_NEW_IMAGE_QUERY_RATE;osal_start_reload_timer ( task_id, ZCL_OTA_QUERY_SERVER_EVT, queryImgJitter );// Wake up in 5 seconds and do some service discovery for an OTA ServerqueryImgJitter = ( ( uint32 ) 5000 );osal_start_reload_timer ( task_id, ZCL_OTA_SEND_MATCH_DESCRIPTOR_EVT, queryImgJitter );
#endif// Initiliaze OTA Update End Request Transaction Seq NumberzclOta_OtaUpgradeEndReqTransSeq = 0;#endif // (defined OTA_CLIENT) && (OTA_CLIENT == TRUE)}

 

2、我禁掉了所有router里面的定时器发送OTA image request，改成image notify这种方式升级，这样任何router只要不升级，就不要再发image request不断请求有没有升级包可用，我觉得zigbee规范里面定义这一段就是傻x，改成notify这种方式能死吗？平时谁蛋疼的要一直在那请求升级不成，还浪费"网络带宽"。这样改了之后，网络基本上非常空闲，测试过多次，都能控制到，基本上百发百中。

 

3、虽然这样暂时能解决问题，但是遇到诸如“同频干扰”，比如我测试了在网络附近有同样另外一组协调器网络，同样的11信道，然后那组一直进行OTA升级，即空中包不断有image block request以及image block response发出。这样此时对被控终端进行控制，有时候也会出现控制指令无法到达终端的问题，分析了zigbee linux gateway里面的代码，发现他的机制是每次发送控制指令，都对transcation进行跟踪，一旦发现发送超时了，就立即执行单播route request，这样就相当于执行了路由发现，但是后面他也没再进行重发指令，我觉得如果要改进，必须增加APP层的重发机制，这样之后，比如正常指令到达只需要50ms，但此时经过超时判断显然需要几秒钟才能到达，但总比莫名其妙的丢失强。

 

4、我想即使是MAC ACK和APS ACK这两套机制加起来，也必须你自己的协调器上层APP配合transID和对应的AF_DATA_CONFIRM_CMD以及失败重发机制，才能确保指令100%到达被控终端(看好了，是100%，不是99.999999%，任何偶尔一次的无法打开/关闭空调，都是无法接受的)，不然就一定会出现莫名奇妙控制不到的情况，显然这会严重影响zigbee的实际应用，比如人家要开个空调，结果指令发过去了以为空调已经打开，结果实际没打开，这不严重影响客户对产品的信任。

user4381970：

回复 miffy:

你说的1.2点一般是碰不到的，一般不使用ota功能一般都要十多分钟才可以，也没有多大必要去ota。
第3。4点，我理解zigbee就如同udp一样，是可能丢包的，要达到100%是要有应用层自己做的。但正常zigbee层也不至于丢到不能用，肯定是有问题导致的。
通常通信不上就是路由不转发，这个是可深入调查探讨的。vv提出如果父节点保存的Framecounter比终端发送数据的Framecounter还小的话，如果使能了加密，那么网络层会丢弃这个包。这是我目前知道的路由不转发的唯一解释。但是全局搜索Framecounter。只有在一些初始化的地方有Framecounter清零。不知道这个Framecounter是如何管理的。
如果终端从父节点1掉线了，重连后Framecounter就是0了。是不是这个时候出现了Framecounter小于原来保存值的情况呢

miffy：

回复 user4381970:

不知道ubiqua抓包是否能看到对应的Framecounter，这个你可以试一下。

至于像不像UDP，我觉得如果APS ACK能有正常返回，结合transID让上层APP来判断，应该基本上算是TCP了。
路由不转发只能是表面上的症状，底层不一定是什么问题，只是代码都不开源，也不清楚里面是不是出了bug，不过据我对TI已公开的代码使用测试看，里面还是有很多bug，不是内存泄漏，就是功能异常

user4381970：

回复 miffy:

nwkFrameCounter到底是如果管理的啊

要像你说的ti不用干了黄了算了。有问题还要要针对问题解决的，解决不了就怪不开源有bug也无济于事。我也碰到过小米插座不转发的问题，把插座拔掉，终端重新入网就好了