Switching Zigbee device role with OTA update?

[mytzyiay]

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.

[Jørgen Holmefjord]

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

[mytzyiay]

We want the product to be a ZR, but a while back we switched the builds to ED mode because that helped work around some of the stability issues we were seeing in ZR mode.  The hope is that we can switch back to ZR mode through an OTA update at some point in the future, after the stability issues have all been addressed.

We continue to see the Nordic devices rebooting/asserting randomly, and it is more disruptive to the customer's network if it's a ZR rather than an ED doing this.  The most reproducible example of this is  (Missing Ticket) where a simple match_desc response causes the Nordic device to hang.  We have seen other instances where a flurry of network activity causes a Nordic device configured as a ZR to hang/reset, but there was no instrumentation connected at the time and there isn't currently a repro case.

I can upload the NVRAM from the most recent failure, if that helps...

[Jørgen Holmefjord]

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.

[mytzyiay]

Jørgen Holmefjord said:

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.

Jørgen Holmefjord said:

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.

[Jørgen Holmefjord]

Hi,

As it seems that the stability issues you were experiencing was resolved by the provided fix in your other ticket, I hope you can avoid changing the device role over DFU?

Best regards,
Jørgen

[mytzyiay]

I'm still seeing unexplained rejoins and high packet error rates on the Nordic nodes.  But if it isn't possible to switch the device role, then we can shelve the idea...