协调器断电或重新下载程序能否还能和之前组建的网络通信？

问题背景：网络中有一个协调器和多个路由器，均没有使能NV_RESTORE，先开协调器，再开路由器都可以相互正常通信；另外，协调器重新上电，遇到和自身panID相同的网络会自动+1，这块代码已经被我改动了，不自动+1，即保持原来的panID，确保协调器上电前后均为同一panID网络

问题来源：实际运行中协调器可能意外断电或直接坏掉，需要再重新上电或更换其他新的协调器（程序都一样），模仿这样的情况实验，发现协调器就没法和其他路由器广播或点播通信了，但路由却可以和协调器点播通信。

解决办法：尝试使能协调器的NV_RESTORE，发现协调器重新上电导致无法通信的问题解决了；但是更换新的协调器导致无法通信的问题依旧。

个人理解：加NV_RESTORE,协调器会记住与之关联的设备，所以重新上电可以继续和之前的设备通信。

疑问：既然都在同一个网络，为什么更换新的协调器广播，其他设备会接收不到呢？如何解决这个问题呢？

有没有人帮忙解答一下？

疑问：既然都在同一个网络，为什么更换新的协调器广播，其他设备会接收不到呢？

对于这个疑问是否是因为新的协调器重新组建网络时更换了信道导致的（虽然panID没变）？

在使能NV_RESTORE的情况，协调器断电重新上电以后，和网络里面其他的设备再次通信是完全没有问题的。

如果对协调器重新下载了程序，或者更换了新的协调器，还要和原来的网络通信的话，那么新上电的协调器就需要把之前的网络参数都恢复出来，比方说channel，panid，ExtendPANID，security key等等。这些信息应该是从原先的协调器上获得的，保存下来的。

测试条件：一个协调器，一个路由，一个终端pm2模式

协调器断电，终端父节点变成路由。

协调器重新上电后，不能给终端设备发送数据了，但终端可以给协调器汇报数据。此问题是怎么回事呢？

原因是因为协调器并不知道终端设备rejoin到其他父设备了，仍然认为子设备还在。

如果终端设备通过新的父设备发送数据出来，被旧的父设备收到的话，这个时候旧的父设备也会把这个子设备信息删除。

如果终端设备不发数据的话，那么旧的父设备也无法知道了。

针对这个问题，你可以加上parent Announce 的功能。 

详细可以参考Z-Stack Home 1.2.2a里面，关于ZDApp_SendParentAnnce

非常感谢，我先研究下parent Announce功能，从来没有听说了。

话说协调器或者网关断电重启的话，很容易再现这个问题的，必须要解决掉。

我测试的飞比的网关是存在这个问题的。但小米的网关不存在这个问题，我抓包看了小米的协调器上电后发送了很多NWK _addr_req，目的地址是那个终端，然后路由应答了，跟这个有关系吗，这是协调器通过ieee查询短地址还是网关查询的呢？什么作用呢

飞比网关重启后没有任何数据，控制时候也没有任务数据，协调器就没有发出来。存在这个bug。小米的不存在，麻烦查看小米网关重启抓包

38行，终端父节点是协调器，控制有效

120行，网关重启，终端父节点更换为路由

349行，网关启动，发出nwk addr req

421行，app控制终端，通过路由转发，控制成功

半年没有在研究ZigBee了，我记得当时我开启了数据加密功能，导致了协调器重新下程序后无法和原网络通信；当时关闭加密，就没有发现这个问题了，也没有开启nv_restore，感觉挺蹊跷的。以至于现在远程监控都是裸数据，安全性没有保障。你说网络地址请求这个应该是从协调器广播发出，但是必须知道被请求设备的IEEE地址，网络中与IEEE地址匹配的设备收到该请求后会向协调器返回自己的网络地址，协调器收到网络地址后就可以与该设备进行通信了，相当于重新进行了一次路由发现。因此这里的关键是在服务器端要记录网络中所有设备的IEEE地址。

至于这个问题为何和加密有关联，当时时间紧，就没有在深入进去。现在既然又提出了这个问题，希望能够一起讨论一下，找到解决方案。

你看抓包数据了吗，网关都是会保存设备的信息的这个没有问题，不知道小米那么做是不是为了解决这个问题。另外协调器通过ieee地址查询短地址的确是广播，但是不是设备回复的，是设备的父节点应答的。但是如何网络中终端类型特别多，那么广播查询要很复杂了，这样好吗？

刚才@VV回答了问题新版协议栈ZDApp_SendParentAnnce功能，我查看了，这个在功能会在路由设备入网后执行。判断条件就是zgChildAgingEnable是否使能。

不知道这个功能还影响其他，默认是关闭的。

如果协调器要点播，获取设备的网络地址是必须的，这个过程也只能用广播IEEE地址（广播也分几种，广播给路由设备和广播给所有设备包括睡眠的终端设备）来询问，虽然所有设备都会收到，但只有IEEE匹配的会回应（睡眠的终端节点，其父节点会在其醒后询问），因此回应只有一个帧数据包，不会造成网络的拥塞，这个过程只是为了获取网络地址。真正进行通信轮询时，可采用点播方式，也并没有很复杂，我记得最多做过一个协调器管理100个左右的设备。 至于parent annce功能，我也是头一回听说，我现在手头也没有开发板做实验了，这个函数主要执行了什么？路由入网后执行，那么更换协调器后，路由一直工作的话应该不会重新再入网吧，和新的协调器还有关联吗？如果按照小米的方式，新的协调器会重新请求短地址，是靠这种方式将新的协调器和原网络设备关联起来吗？ 你做实验是否开启了加密？如果开启了，试试小米的方式，看是否有效？

核心问题是协调器断电重启后不能与终端通信的问题。楼上@VV解释是协调器不知道这个终端的存在。我抓包小米网关重新上电是查询短地址的，我不确定NWK addr req过程是否协调器就获得了终端的信息。再有网关根本没有必要每次都去查询。一般情况下协调器把各个终端信息都会汇报给网关，网关是会保存下来的，为什么要每次都查询，太没有必要了。

都是zha标准的都是加密的，但是都能相互加入，另外小米是nxp的5169不是ti的。

协调器网关重新上电是常有的情况，这个bug属于zigbee部分的问题，何苦要网关查询来解决这个问题