关于AssociatedDevList 表的疑问

xiaohui bu 说：

最近在研究终端节点和路由节点断线重连时，发现有时候能够连上有时候连不上。查了相关资料说可能与AssociatedDevList 表有关。于是针对AssociatedDevList 表查了相关资料及自己对终端节点作单步调试。对AssociatedDevList 表有一些疑问，想向TI的FAE们请教一下。自己使用的协议栈是Z-stack2.5.1A

1、每个节点都有AssociatedDevList[NWK_MAX_DEVICES]，这个表的作用具体是什么？自己的理解，与本节点有父子/子父关系(或者曾经有过)。都会在本节点的AssociatedDevList里存着。除非自己应用层去做逻辑维护，协议栈是不会自己来维护这个表的？

你的理解是正确的，但是协议栈会维护这个表格，比方说子设备leave了，或者加到别的父设备了。

2、如果本节点的AssociatedDevList表满了之后，会导致本节点入网不成功？因为AssociatedDevList表不能保存本节点的父节点的信息了？这也是自己的理解。

AssociateDevList是保存在父设备的地方，不是保存在子设备上面的。

3、AssociatedDevList表没有任何信息(或者是新节点之前没有加入过任何设备)时，AssociatedDevList表里面的默认值是0xFF？还是0x00？

0xFF

4、自己做过的测试，NV保存都打开。协调器A、路由器B、C、D、终端节点E。终端节点E通过B接入到ZIgbee网络中。我把路由B断电，终端E通过C接入。再把B上电。再把C下电，终端E通过B接入。每次终端E的网络短地址不变。这样十几次后，终端节点接入不了网络。我想问的是，引起这样问题的可能原因是什么？终端E的父节点再B和C之间变化。那么E中的AssociatedDevList表它占用了2个？还是更多？

出现这个问题的原因肯定不是AssociateDevList，你说终端接入不了网络，终端有没有在搜索网络，路由设备有没有在回复beacon，是节点收到beacon以后没有发起rejoin 对吧，所以你要为什么没有发起rejoin？

你看下 _tmpRejoinState这个变量。

非常感谢，VV！

第4个问题，由于我们是终端设备，必须要考虑省电模式。在节点成为“孤儿”之后，不能让其一直DIScover和Beacon Request。所以想了一个办法，就是在成为孤儿后，通过应用层的控制，隔一会儿发现（调用...start），再隔一会儿停止（.....stop）。有一次抓包发现，出现了 rejoin respone后。又有beacon request 发出。自己的理解就是应用层的start和stop没有控制好，从而破坏ZDO层的控制逻辑。VV有什么好的建议？