[ZSDK] Coordinator startup from persistent memory in a centralized network

[Jorge Alves]

Hi,

In a centralized network, the coordinator is the only entity able to permit network joining. If the coordinator power cycles, and starts up from persistence, does it maintain its coordinator status?

In my testing setup, when I power cycle the coordinator, it rejoins the network with the correct previous address. However, after requesting the network to permit joining (PermitJoinReq), new devices are not added to the network, when before power cycling it, they would. Does this means that it loses its status as a coordinator? My current guess is that it does and since it belongs to a centralized network, there isn't any other device with the authority to permit joining. However, the PermitJoinReq returns a success status.

What do you think could be happening? 

I don't know what is going on, since I can't be sure of what actually happens when I call the persistent startup function from the ZSDK

[Ouadi]

Hi @Jorge Alves,

In a ZigBee centralized network both coordinator and routers can allow new devices to join the network when the permit join is enabled.

After restarting from persistence, the device is supposed to restore its configuration and takes back its role on the network.

Can you confirm that the association permit flag on the beacon response is set to true when a new device is attempting to join the network ? Could you please share a Wireshark capture ?

Which Wireless binary version you are using ?

Best regards,

Ouadi

[Jorge Alves]

Hi @Ouadi ,

Sorry for the late response, I was and still am waiting on a sniffer. I will get back to you when it arrives.

[Jorge Alves]

So, I finally got around to check this and for some reason the startup from persistence sequence is successful, but it seems to break some functionality. In the St wiki it explicitly says it restores the binding table and report configurations. In my application devices restored from persistence don't, and remaking a new bind request with the same entry doesn't work i just lose the reports and cant configure new ones hardcoded on device. Otherwise, the device works as expected with beacons, route requests, link status etc, but never reports again. The same was happening for performing a permit joining request from to the coordinator restored from persistence - returns as successful, but doesn't do anything. 

It's on version 1.19.1 FFD for zigbee

[Ouadi]

Hi @Jorge Alves,

I can confirm that both reporting config and binding tables are saved into the NVM when the persistence mode is enabled, the reportable attribute should be configured with the flag ZCL_ATTR_FLAG_PERSISTABLE to be persisted. 

Please follow the recommendation described on this AN Persistent data management ZigBee to implement properly this feature. 

Regards,

Ouadi

[Jorge Alves]

Again, thank you for the answer.

I am aware of the attribute flag, but I don't mind losing the attribute's value. I want to keep the report and binding information. Is it bound by that flag as well? It would be okay not to restore it as long as I could keep or configure reporting again.