This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ZigBee End Devices Leaving nRF52840 Coordinator

We have had our nRF52840 based Zigbee Coordinator in production since September of 2020 with great customer feedback.  Unfortunately, we have recently had several instances of third party ZigBee end devices leaving the network and requiring repairing by our customers which is a headache when the user isn't close to our device.

Most of the sensors that have this issue seem to be ZigBee 3.0 devices.  I have the following questions:

  1. Is there a method to determine why a sensor left the network from the ZBOSS stack?
    1. Is there method to determine if the coordinator caused the device to leave or if the device did it?
  2. Is there a defines process for handling ZigBee 30 devices leaving the coordinator?
    1. I noticed in the new nRF Connect SDK there where a lot of flow charts for handling the ZigBee signals including rejoining.
  3. Is there any other methods for diagnosing these kinds of lost connection issues?

This project is using nRF SDK for Thread and ZigBee v4.0.0.

Thanks,

Parents
  • Hi Darren

    I have forwarded some of your questions to our Zigbee devs, as I'm not aware of a way to determine why sensors have left a network specifically, and what the correct methods to handle rejoining are. Hopefully I'll hear back from them by tomorrow.

    In the meantime, is this specific to a specific set of Zigbee 3.0 sensors, or does any kinds of end nodes leave the network? One lmitation to the Zigbee SDK (v4.0.0) is that time-critical processes (like leaving and rejoining can occur at the same time as migration processes, but this should only occur if mass NVRAM operations are in intersection with mass radio operations. (like if a parent device is joining 20+ devices one-by-one without delays. Likelihood of happening is low though.

    Have you enabled the zb_secur_set_tc_rejoin_enabled in your coordinator application to allow TC rejoin?

    Best regards,

    Simon

Reply
  • Hi Darren

    I have forwarded some of your questions to our Zigbee devs, as I'm not aware of a way to determine why sensors have left a network specifically, and what the correct methods to handle rejoining are. Hopefully I'll hear back from them by tomorrow.

    In the meantime, is this specific to a specific set of Zigbee 3.0 sensors, or does any kinds of end nodes leave the network? One lmitation to the Zigbee SDK (v4.0.0) is that time-critical processes (like leaving and rejoining can occur at the same time as migration processes, but this should only occur if mass NVRAM operations are in intersection with mass radio operations. (like if a parent device is joining 20+ devices one-by-one without delays. Likelihood of happening is low though.

    Have you enabled the zb_secur_set_tc_rejoin_enabled in your coordinator application to allow TC rejoin?

    Best regards,

    Simon

Children