Switching Zigbee device role with OTA update?

If a manufacturer ships a large number of nRF52840 based devices that are configured as Zigbee end devices, and then later decides to switch them to Zigbee routers through an OTA firmware update, will that work?

Or is there data stored in the ZBOSS NVRAM that could potentially confuse the stack after such a change?

Obviously, the effects of the OTA update would need to be transparent to end users -- i.e. they shouldn't be forced to manually re-pair or factory-reset all of the devices that got the update.

Parents
  • Hi,

    Yes, information about the device role is stored in ZBOSS NVRAM. The update from an End Device to a Router without factory reset is not possible.
    What are you trying to achieve with this approach?
    Best regards,
    Jørgen
  • Not sure I understand the logic behind switching the device role instead of trying to fix the underlaying reliability issues.

    Do the device not need the router role to serve its intended purpose? If not, why do you want to switch the role back to router? If you explain your requirements, we may help you find an alternative solution.

    I'm informed by our Zigbee developers that changing the device role without factory reset/recommissioning is not permitted by the Zigbee specifications.

  • Not sure I understand the logic behind switching the device role instead of trying to fix the underlaying reliability issues.

    If we can ship it as an ED and upgrade later with an OTA, that prevents the ZR-related stability issues from holding up the product schedule.

    Do the device not need the router role to serve its intended purpose?

    As a mains-powered device, ZR would be preferable.

    I've also noticed that when configured as an ED, these Nordic nodes tend to disconnect/rejoin at random.  Haven't seen the same behavior in ZR mode.  I filed another (private) ticket about this.

    I'm not sure whether this is normal behavior for a Zigbee ED and I'm not sure if it's a potential source of latency / UX issues.  My intuition tells me that an ED "leaf node" that only maintains a connection to a single parent node might be less robust than a ZR that's constantly talking to several peers.

Reply
  • Not sure I understand the logic behind switching the device role instead of trying to fix the underlaying reliability issues.

    If we can ship it as an ED and upgrade later with an OTA, that prevents the ZR-related stability issues from holding up the product schedule.

    Do the device not need the router role to serve its intended purpose?

    As a mains-powered device, ZR would be preferable.

    I've also noticed that when configured as an ED, these Nordic nodes tend to disconnect/rejoin at random.  Haven't seen the same behavior in ZR mode.  I filed another (private) ticket about this.

    I'm not sure whether this is normal behavior for a Zigbee ED and I'm not sure if it's a potential source of latency / UX issues.  My intuition tells me that an ED "leaf node" that only maintains a connection to a single parent node might be less robust than a ZR that's constantly talking to several peers.

Children
No Data
Related