Need Help reconnecting end devices to Zigbee Coordinator

[Belalshinnawey]

Hi,

I have a zigbee application built on top of the NRF5340 as a coordinator and 52840 as End devices. I am trying to keep end devices connected to coordinators and routers. The coordinators and routers are powered through mains power supplies so I have no power concerns there. The end devices are powered through batteries and long battery life is required. Now End devices by default disconnect after a while if the network is inactive as I understand, I would like to reconnect to the coordinator again after a little time. I thought of restating the network steering after 10 minutes of disconnection, so battery life is not too affected, and the device stays connected. As I understand, the coordinator closes the network after 180 seconds, and no devices are allowed to reconnect. So what I did is I added a thread that reopens the network by calling  bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING) every 200 seconds and starts after the first network formation. My questions are first:

1- Is the approach of keeping the network open on coordinators and routers good? Is there a better way to accomplish this that doesn't involve the users restarting the devices, the devices are meant to never be touched by the users. 

2- Does reopening the network again affects end devices? I have end devices randomly starting the reconnection process without ever firing the disconnect even locally or on the coordinator, and it always happens around the time coordinators reopen the network, so is it happening because of it?

3- On my end device I have a thread that waits for 10 minutes and then calls:

if(!ZB_JOINED()){
            LOG_INF("Device Not Connected, Rejoining");
            user_input_indicate();
        }

Is this the right approach for reconnecting end devices?

Please answer my question purely on theory, Nothing in my application is remarkable enough to change the default behavior of the zigbee library. All I need is the correct logic to keep coordinators always open, and reconnect end devices after X amount of time if they disconnect without having any of them restart the whole application. I couldn't pin point this information in the docs, so your help would be life saving.

Thanks in advance,

Belal

[Edvin]

Hello,

Now End devices by default disconnect after a while if the network is inactive as I understand,

I don't think this is how it works, unless you have implemented something that works this way. 

Please answer my question purely on theory

I think all questions, 1-3 are based on a misconception. Zigbee End Devices (ED) doesn't disconnect from the network. An End Device is just a node that doesn't have any children (unlike a router, which can have children). 

Then you have something called Sleepy End Device (SED), which is a low power device. A light switch is a good example of this, since it doesn't need to react quickly to anything, but it needs to be able to wake up at any point in time to send a message. Please see the description of the sleepy end device behavior in our light switch sample. 

You can also read more about sleepy end device behavior here:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/zigbee/configuring.html#zigbee-ug-sed

Perhaps this is closer to what you are looking for.

Best regards,

Edvin

[Belalshinnawey]

All my end devices are SED devices, As I understand, SED is just an ED that turns its radio off and on based on a timer, sort of like the Target Wake Time in WiFi6, or at least that is the behavior I see from my current example, I am able to send messages, but from my power logging device, the radio is only working during the Polling times, which in my Case is 3 Secs. I opened the part of the docs you linked and I couldn't see any direct conflict with my understanding.

If SED don't disconnect after a while of not active, could you please explain zb_set_ed_timeout() and the timeout feature in Zigbee because that is how I understood it, otherwise I might need to find why would my coordinator disconnect from the End device after a long while. Also Even if the device does not disconnect after a while, I still need a way to keep the coordinator open forever, so devices can join on the go, and I need a good way for end devices to reconnect, which until now, the only way is to reset the entire zigbee stack.

[Edvin]

Belalshinnawey said:

As I understand, SED is just an ED that turns its radio off and on based on a timer, sort of like the Target Wake Time in WiFi6

Yes, that sounds about right. 

Belalshinnawey said:

I couldn't see any direct conflict with my understandin

I was just confused since you talked about disconnecting. The SEDs doesn't disconnect from the network, and if you expected to see disconnect events when the device goes to sleep, you will not see that. 

Belalshinnawey said:

If SED don't disconnect after a while of not active, could you please explain zb_set_ed_timeout()

Ok, so they do in fact disconnect if they don't reappear after a given amount of time. Perhaps I just misunderstood what you were trying to say. 

When a SED is set up, it is set up to have a wakeup interval (like in TWT in WiFi6). Then you have another timer saying how long the device needs to be inactive before it is considered lost from the network. This is not the same timeout value. 

So a SED will not disconnect every wakeup interval, and it doesn't need to rejoin the network on every wakeup. However, if you either way want to be able to pick up new devices without interacting with the coordinator, you need to keep restarting commissioning after it times out. Without having any good sources, I believe there was something about not being able to adjust the 180 second commissioning window. At least not keep it open forever. You should not have to reset the entire zigbee stack. 

If you try:

int ret = bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING);
LOG_INF("bdb_start_top_level_commissioning returned %d", ret);

when you try to reopen the network, without restarting the zigbee stack. What does the log say? What does btb_start_top_level_commissioning() return?

Best regards,

Edvin

[Belalshinnawey]

Thank you for this.

Yes, I do not experience disconnection every wake up time, that's not what I am concerned about. However my goal is to send as little messages as possible so a device staying in the network for days without messages is expected for me, but it needs to stay joined to respond to events from upstream. That, and the joining on the go thing.

So the code snippets you shared works fine for new devices, and I can connect new devices anytime, I just needed to confirm that this shouldn't affect devices that are already connected, or devices that were connected and need rejoining. basically if this approach shouldn't cause any connected end devices to disconnect and doesn't stop any devices that were connected to rejoin, then this approach is fine.

btb_start_top_level_commissioning() returns no errors in the coordinator.

now the end device side, devices that were connected, and are trying to reconnect are not able to reconnect, sometimes they get network steering unsuccessful or multiple network leave signals. Is the

int ret = bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING); on the coordinator enough to enable end devices to reconnect if they attempt so? 

basically if I reset an end device while the coordinator is running, the end device is able to connect, but if I reset the coordinator while an end device is running, that end device is never able to rejoin.

I am running this on my end devices whenever they disconnect, should this work in the default cases? or is my application having another hidden issue.

{

        k_sleep(K_MINUTES(10));

        LOG_INF("Rejoining Network if not connecting");

        if (!ZB_JOINED())

        {

            LOG_INF("Device Not Connected, Rejoining");

            user_input_indicate();

        }

    }

I do reach the user_input_indicate() statement in my application whenever the device disconnects, but still, no reconncetion,

[Edvin]

Belalshinnawey said:

I just needed to confirm that this shouldn't affect devices that are already connected

I see. No, that shouldn't affect already joined devices.

In fact, in the old nRF5 SDK for Thread and Zigbee, we had a light coordinator sample (SDK\examples\zigbee\light_control\light_coordinator), which re-opens the network on a button press using this API. It is using the same Zigbee stack (an older version), so you should see similar API being used. Just for reference.

Belalshinnawey said:

basically if I reset an end device while the coordinator is running, the end device is able to connect, but if I reset the coordinator while an end device is running, that end device is never able to rejoin.

What exactly is your coordinator device? Will all nodes fall out, or only SEDs?

BR,
Edvin

[Belalshinnawey]

I did some experiments, and found out that if I don't update the IC value on the device, I shouldn't do  a full erase of the nvram.  what was happening is I was clearing the nvram on either SED or coordinator (Because of IC changes), and whenever one of them didn't reset it's memory, they were not able to reconnect, that's why new devices could connect but older ones couldn't. I opted to clear the IC manually for each device id instead of fully clearing the memory , and directly updating the IC on the end device instead of clearing and then setting a new IC. Your confirmation about the reopening of the network doesn't interrupt already connected devices helped find the exact issue after combing through each step of the re-connection.