z-stack3.0 路由器断电恢复网络问题

你好可以私信把你的抓包文件发给我么。

1，如果直接使用z-stack 3.0的原始的例程做测试，会有问题吗?

2, Transport key应该是协调器发出来的。

VV你好，第一个问题，我做了很多调试发现，第1种情况：先打开协调器允许设备加入，设备加入网络后，作为路由器，不管什么时候断电上电都会恢复为路由器。第2种情况：先触发设备开始寻网，再打开协调器允许加入，设备可以进入网络，但是断电再上电，无法恢复为路由器，而是变为了一个新节点，按键触发后，一直发送beacon request。只有调用bdb_resetLocalAction();  复位后，按照第一种情况加网，设备才可以实现断电恢复。这两者不同的操作顺序为什么结果不一样。

我路由器初始化调用的是bdb_StartCommissioning( 0 ); 然后按键触发 调用bdb_StartCommissioning(  BDB_COMMISSIONING_MODE_NWK_STEERING  ); 

我测试的时候使用了一个协调器+8个路由器，打开协调器，8个路由器同时触发开始入网，有时候会出现有个别设备无法加入，一直在连接，无transport key，把已经入网的路由器断电2-3个后，就能顺利加入

另外，zstack3.0中，想要增加install code key，设备端和协调器端需要调用哪个API，能指点下具体操作流程么

谢谢！

1：两种情况，只是顺序不一样，代码都是一样的，不知道3.0的协议栈是否本身就对不同操作顺序有区别，还是我调用的函数参数有问题

2：这个问题，好像是协调器那边的问题，同时加入的设备多了，会出现个别设备没有收到key

3：设备端增加API接口是哪个啊，install code key可以自定义吧

VV你好：

1：我用zstack3.0做路由器，初始化调用bdb_StartCommissioning( 0 )，然后再BDB回调函数中 case BDB_COMMISSIONING_NWK_STEERING:  中else调用bdb_StartCommissioning( BDB_COMMISSIONING_MODE_NWK_STEERING );这样新设备上电后，一直发送beacon requeset，设备打开了看门狗。但是出现一个问题，设备经常出现复位，软件debug，发现没有跑到软件复位，怀疑是看门狗复位，看门狗初始化为WatchDogEnable( WDTIMX );，在

for(;;) // Forever Loop
#endif
{
osal_run_system();
WD_KICK();

喂狗。

我想知道发送beacon request 为什么会导致复位