终端不能通过路由入网

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

门锁435D的父节点是E6B0。

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

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

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

虽然不是对题，但对于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 commands
  zcl_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 Server
  queryImgJitter = ( ( uint32 ) 5000 );
  osal_start_reload_timer ( task_id, ZCL_OTA_SEND_MATCH_DESCRIPTOR_EVT, queryImgJitter );
#endif  
  // Initiliaze OTA Update End Request Transaction Seq Number
  zclOta_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的实际应用，比如人家要开个空调，结果指令发过去了以为空调已经打开，结果实际没打开，这不严重影响客户对产品的信任。

nwkFrameCounter到底是如果管理的啊

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