Routers device rejoining process doubts

Do you enable NV_RESTORE on your ZR and ZC? If you enable it, ZR won't try to rejoin Zigbee network. I don't understand why your another two routers can switch channel after power recycle. In general, ZC has to notify all nodes in network that it would switch channel and switch it after ZC gets responses.

I'm facing the same problem and it seems that Zigbee doesn't play well with this type of case.

''Router are supposed to be ALWAYS ON Devices''

Therefore there are no provisions for the corner case specified in the current post...

Well, the case where 1  or many router could go offline while the rest of the network is still powered on is something I absolutly have to deal with...

Worst case scenario for me is exactly what is requested in this post...  or possibly that a router and its parent go off line while the rest of the network is still going strong... 

Let says that, for some reason, a router is power down by the end user and during the power down time, the user also request a change of channel. 

Now all the powered ON device will change channel just fine as they are running when coordinator send the request to change channel. 

All the end device will do what they must to find the network on the new channel whenever they are power back on...

Once it is power back on, our poor little router will end up alone on the former channel...  To my knowledge, there is no way to get a indication that we are standed.   Looking closely at the code in ZDApp or ZObject, a router is not entitled to run a orphan scan... 

Is this per design or simply because zigbee doesn't require it?

Here's what I've tried and it's working pretty good although there might be solution that are much more elegant...

At start up I start a applicative timer and I'll make sure that, If I'm to be connected to a knowed network, that I have received at least a couple transmissions otherwise,  ( I use nwkTotalTransmissions to asses the communication status...)

You could also send a command, read or write an attribute from the coordinator or simply make sure that the link to our parent is sound.  I though of doing so with the APS layer acknowledge to make sure that we have a link to the coordinator if you really want to be safe...

In any case, when the application realized that it is no longer able to communicate, you'll need to scan the channels to find your former network.  At this point, you should make sure to rejoin with the extPanID because the PanId may have changed if it was already taken on the new channel!

Hope this helps.

I'm also open to comment and suggestions!

This behavior is out of definition in Zigbee spec. If ZC decides to switch channel and any of ZR doesn't listen to it, you will be in trouble. In general, you have to do factory reset to make ZR retry to join original Zigbee network.

Thanks for your input Yikai!

This was my understanding as well...

The factory reset might be an option for some, but I doubt that this is the case for most...  This is espacially true for network that have a permit join enabled only upon user request...  This leaves the standed device no chance to get back in the network without user action.

I'd like to hear your thoughs on possible solutions to this problem...

In order to resolve this, we need to do a few things...

1) make sure to clean our neibour table because network has been living without our presence and we don't want to come back in assuming that any of our former child is still our own...

2) Find a way to know if the network we want to connect to is still on the same channel.  

- Any way to do this cleanly within the zigbee spec?  Query to the DeviceInfo or commissionning cluster?

3)  Perform a scan if our coordinator or parent can't be found... 

- The way I implemented my scan is actually quite simple and it is based on what the router actually do when a channel change is requested.

- I also though about changing the device type to end device in order to perform a orphan scan but I felt it was possibly confussing and reverting to the router type afterward could prove to be even more...

point 2 and 3 are closely related and could be dealt with differently depending on the system behavior...

Maybe this is why zigbee commity steared away from implementing a router rejoin mechanism! ;-)

Anyways, thanks again for your time Yikai!

According to my understanding to Zigbee spec, there is no what you said do this cleanly within the spec. I would suggest you to avoid changing channel. If you have to, I can only suggest you to let unnotified ZR factory reset to rejoin original network.