关于zigbee PANID + 1 的问题

项目应用中要求一个zigbee网络的 PANID 能配置为一个固定的值，   测试发现终端或路由用-DZDAPP_CONFIG_PAN_ID 指定后就只能加入到指定的PANID网络。

但是协调器则不是，如果下面有路由，重启协调器PANID会加1，导致通信不了。 查资料说加入NV_RESTOE 后能解决这个问题，加入NV_RESTOE后重启协调器确实不会加1。   但是还有一个问题就是发现NV_RESTOE对协调器来说只有有一个设备加入了才起作用！，           这样就出现了一个问题，

比如我要更换原来网络中的协调器硬件（这个在网关里面，升级网关项目中会有），重新烧了程序放在原来的网络中，PANID还是会加1，唯一的解决办法就是把这个协调器先远离原来的网络，让一个设备先加入。再拿回原来的网络，这样PANID就不会变了，这时NV_RESTOE才起作用。   --------这个办法觉得不是一个好办法呀

大家做工程的时候有没有遇到过这样的问题？     求大神出来指点！  

我用的协议栈是   ZStack-CC2530-2.3.0-1.4.0    pro

uint16 ZDApp_CoordStartPANIDConflictCB( uint16 panid )
{
return ( panid + 1 );
}

如果检测到冲突只 还是return panid  可以解决PANID+1 吗？

求TI的大神们指点一下   thanks ！

感觉还是不行，会循环在这里

ti的zigbee在线服务解答一下呀，都两天了，效率！，不管怎样给个说法呀。

你的理解和找到的相关的代码都是正确。 

如果你说的协调器需要升级的话，如果升级以后的协议器需要和原先网络里面的设备一起工作的话，需要把原先网络的相关信息保存到新的协调器上去，不仅仅是PANID，extend PANID 还有NWK Key，等等。不是你说的仅仅改个PANID就可以了

谢谢 W的解答，那么还有以下疑问

1：用什么方法可以把原来协调器的信息保存到新的协调器中？

2：我现在的做法就是烧同样的协调器代码，发现也能与原来的网络通信，这样做有没有什么隐患或不合适的吗？

3：现在最大的问题就是烧了新程序的协调器必须先远离原来的网络，让一个设备加入后再拿回来，这样才能与原来的网络通信，这个

       有没有解决的方法？ 这个肯定能解决，请W 大神指点一下，不甚感激！

4：我现在是协调器开启了NV_RESTORE下面的其他节点没有使用，发现系统整个重启后节点的短地址会变化，我担心协调器会不会保存之前的网络信息，比如说

      他的子节点网络短地址，这样时间长了，系统重启次数多了协调器ROM会不会用完？这个担心有必要吗？

再次期待W大神的解答，谢谢了！

我也遇到了你的这个问题，就是协调器坏了要更换新的，但是却没法和原来的网络连接了，网络中都是路由器，都没开NV_RESTORE。

你说的，唯一的解决办法就是把这个协调器先远离原来的网络，让一个设备先加入。再拿回原来的网络，这样PANID就不会变了，这时NV_RESTOE才起作用。

让一个设备先加入，是指随便的设备还是原先网络中的设备，我发现随便用一个路由设备加入之后，还是没法跟原来的网络通信。

你能交流一下具体的方法，或者有什么更好的方法吗？谢谢

问题已经解决，我发现我之前用的是GenericApp写的程序，协调器器重新下程序后，没法再和原网络中的路由器通讯了；今天尝试把程序移植到SampleApp的协议栈中，发现没有问题了，不管是协调器断电还是重新下载程序，都可以继续和原网络中的路由器通信。

当然，两次实验的前提是，协调器的panid不自动加1，更改了return （panid + 1）；协调器和路由器都不加NV_RESTORE,这样网络是动态的

uint16 ZDApp_CoordStartPANIDConflictCB( uint16 panid )
{
  return ( panid ); //panid + 1 协调器搜索到已经存在网络，发生网络冲突时，panid不再自动加一，使得协调器复位后能够重新加入原来的网络。
}

所以，我想问一下TI 协议栈里面的SampleApp,GenericApp,SimpleApp都有什么区别，是否确实会影响到组网通信，希望有人继续讨论

不好意思，进入了误区，我发现跟SampleApp,GenericApp,SimpleApp没有什么关系，之前问题根本原因是我的程序之前开启了加密算法-DSECURE=1，后来的程序没有开启加密，所以造成了这样的误解。而且开启加密算法之后，并非没法通信，而是需要尝试与之通信才能最终进入网络，大概需要几分钟，应该是加密算法的缘故。为什么会这样呢，而不是直接进入网络，这些等待的时间在做什么呢，希望TI的大神指点，能否缩短这些等待时间？

你只修改return （panid + 1）；为return （panid ）就可以了？

我用的也是GenericApp，路由与协调器都没用NV_RESTORE,    发现如果协调器断电重启就入不了网，也建立不了网，你遇到有这种情况吗？

自己顶一下，帖子不要沉了，TI 的大神看到请解答一下，也可以帮到更多的人。

说实在的感觉ZSTACK的功能是强大，但感觉配套的文档真的不全，工程应用真的不够。遇到问题只能自个摸索，效率低。

是的，这样做协调器的panid就没有再改变了；

我关闭加密后（-DSECURE=0），GenericApp的程序也可以实现协调器断电或重新下载程序，上电后都可以继续和原来的路由网络通信；

你所说的重启协调器建立不了网，是指什么？把其他路由设备关闭，再开启一个路由，也加入不了重启协调器的网络嘛？