Coordinator replacement - EFR32MG21 to EFR32MG24

[stickpin]

Hi,

Has anyone already tried migrating from one EFR32 USB coordinator to another without repairing the whole network?
I want to migrate from SkyConnect (EFR32MG21) to the newer SMLight SLZB-07Mg24 (EFR32MG24).

It seems like ember-zli with backup and restore functionality might do the trick.

Does anyone know if regular Stack backup and Restore will be enough?

Thanks a lot in advance!

[Nerivec]

Regular backup and restore from z2m itself will not write the EUI64/IEEE of the adapter (for now).
If you do a backup/restore tokens from ember-zli it will restore all (best when you migrate like that). Otherwise, you can write the EUI64 with ember-zli, then let z2m restore the network.

[stickpin]

@Nerivec Thanks a lot for the info!
I will try to do tokens backup/restore once I get a new dongle somewhere next week.

[stickpin]

@Nerivec Migrated without any issues. Magic! 🪄 Thanks a lot! 😊
Now theoretically I have two "identical" coordinators.
What will be the best way to remove it from the network and replace the EUI64/IEEE?

I guess, I will need to do "Reset NVM3 tokens" first and then "Write EUI64 NVM3 token" with some random value change in the existing EUI64.

[Nerivec]

Perfect!

Yes, that should do it. Make sure to write a value that won't clash with any device around (hard to do, but you know, luck... 😛). Should be easy enough to just change the last 2-3 characters from the original value (that will also keep the original manufacturer tag, the first 6 after 0x, though it doesn't matter much).

[nanostra]

Hello @Nerivec and thanks for your work. I have the same kind of task to perform as @stickpin, but I probably have less experience. I also want to migrate my ZBDONGLE-E EFR32MG21 to an SLZB-07 EFR32MG24. I understand that I need to do a Backup NVM3 tokens from the ZBDONGLE-E and then Restore NVM3 Tokens on the SLZB-07 MG24.

Q: If I understand correctly, the restore will also copy the EUI64, so logically I just need to replace the ZBDONGLE-E with the SLZB-07 MG24 and possibly change the port name in Home Assistant to fully recover my network, right?

However, I don't understand the next step mentioned by @stickpin.

"What will be the best way to remove it from the network and replace the EUI64/IEEE? I guess, I will need to do "Reset NVM3 tokens" first and then "Write EUI64 NVM3 token" with some random value change in the existing EUI64."

Q: If, I want to keep the ZBDONGLE as a backup, do I have anything else to do?
Q: One last question, when entering the Stack option, does the choice between Hardware flow control or Software flow control matter?

[Nerivec]

Q1: Indeed. Backup/Restore tokens basically restores everything ZigBee related, and should put the network exactly as you left it last.
Q2: Indeed, you don't have anything to do, but you also cannot use it in proximity of the restored one at the same time (they will have the same EUI64, which will require them being on separate networks to not conflict).
Q3: Better to get it right, it avoids weird behavior (or things not working at all). ZBDongleE: software.

[nanostra]

Migration completed. Thanks again for your work and these clarifications.

[nanostra]

I have created a guide in English and French, which can be found here: https://github.com/nanostra/Migration-EFR32MG21-vers-EFR32MG24

[Nerivec]

Quick notes:

• You can do all this on plain Windows (either via npm, or using the tarball package), no need for WSL.
• About "keeping the old dongle as backup": as soon as you started up the network again on the new dongle, several tokens would have started changing again (frame counters & such), which means it is no longer synced with the old one. If you ever were to put the old dongle on the network (as emergency I assume), best course of actions would be to restore the latest Z2M coordinator_backup.json onto it (which means leaving the network with Ember ZLI, then starting Z2M, which will trigger the network restore process), otherwise, you might encounter some sync issues (EmberZNet seems pretty resilient in that regard, but still worth mentioning if something were to not work as expected). You could also take regular tokens backup of the new dongle, for extra safety.
• Careful with that last screenshot, as changing rtscts is entirely adapter-dependent.

[Ra72xx]

What are the advantages of moving to MG24? SMLight themselves are pretty pessimistic about any advantage of the newer chip (see the table on https://smlight.tech/ - indeed I did never ever see a producer make their own new product look so completely unnecessary?!?).
@Nerivec , however, on several occasions sees advantages in difficult Zigbee networks. As I seem to have one of those, and my SkyConnect seems overwhelmed by my 70-something devices (delays, lost transmission, dropped devices), I have hopes that updating to MG24 will help me.

[Nerivec]

As I mentioned in previous posts, these chips offer higher specs, newer tech (SMLight table doesn't show the Zigbee-side specs, also were just previews, no doubt it will be updated in the near future, since more of the models are being released).
Here's an example (these links are available for each in Z2M docs):

• SLZB07MG24: https://www.silabs.com/wireless/zigbee/efr32mg24-series-2-socs/device.efr32mg24a020f1024im40?tab=specs
• SLZB07: https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-socs/device.efr32mg21a020f768im32?tab=specs

Note that despite the better specs, a poorly designed network will still cause issues, nothing much the adapter can do about that (be it from bad devices, too much interference, etc.). Unfortunately, in some cases it is also not possible to improve the situation much (if the interference comes from neighbors for example)...
A well designed network, with decent devices, can already reach 100+ on MG21 without much troubles. But in comparison, MG24 have been tested to 250+ (with the MGM24 from TubesZB). Highest reached was around 320 devices (composed of mostly Inovelli & Phillips) on an optimized network (after that, stability takes a hit no matter how optimized it is, many parameters in firmware are tied to uint8_t -255 max-).
Of course, that's only to show capabilities, you are much better off with 2x150 rather than 1x300 with Zigbee.
The mesh design has many advantages, but it is also very affected by bad devices (routers), which can drag down entire parts of the networks (because they "kind of work", they remain on the network as a viable option, and because they are bad, they keep affecting other devices, from slow downs, to dropped messages...).

Since you now have two adapters, try running a few tests with Ember ZLI (channel scan, network scan, etc.), to see if there are areas where you can improve things (can test in various locations around the house if you do it on a laptop). I've had more than one report of users surprised by how many other 2.4GHz networks are around them.
You can also put your logs through https://nerivec.github.io/z2m-ember-helper/ to see if patterns emerge, and investigate involved devices in more details.

[Ra72xx]

@Nerivec: Thanks for your support and work on this driver. The SMZB-07MG24 (with fw 7.4.2 - why so old? - and bl 2.04.02) has arrived and I'm playing around with it. I have a few questions:

• On MG21 SkyConnect, hardware flow control was to be disabled, AFAIK. With MG24 it can be enabled again safely?
• ember-zli ony connects with 115200 baud, not at any higher speed, otherwise the "ASH starting" step fails after a few retries. Is this normal?
• Which fw do you recommend? 7.4.5 from darkxst oder 8.0.2 from your builds? EDIT: OK, the proposed firmware is 8.0.2, so that answers my question.
• Is the bootloader updated with a firmware update or how to do that? EDIT: In the docs I read that I simply can flash a bootloader gbl file.
• Should I start with a fresh network or is it save to restore the keys from the old stick?

Thanks!

[Nerivec]

1. Hardware flow control is still causing an error, but ZHA & Z2M both should have proper retry mechanisms in place to bypass it now (you'll see a few more Waiting for RSTACK lines when that happens).
2. Baudrate must match between what is used by the firmware, and what is configured in the application. i.e. if you flashed 115200, you must always use 115200 in the application (same applies for ZLI or Z2M).
3. 8.0.2 from darkxst or me only have minor differences.
4. 😉
5. You can backup/restore the NVM3 tokens with Ember ZLI with ease, start with that. You can always start from scratch later if something doesn't agree with you 😉

[Ra72xx]

1. Hardware flow control is still causing an error, but ZHA & Z2M both should have proper retry mechanisms in place to bypass it now (you'll see a few more Waiting for RSTACK lines when that happens).

But generally speaking, hw flow control is the better option nevertheless, I assume.

2. Baudrate must match between what is used by the firmware, and what is configured in the application. i.e. if you flashed 115200, you must always use 115200 in the application (same applies for ZLI or Z2M).

Your firmware builds only include 115200 so I assume that is enough. If changing the baud rate, does that mean that both bootloader and firmware have to have the some baud rate, or is this independent?

4. 😉

Any reason not to upgrade the bootloader? I'm a bit worried because my brand-new Zigbee dongle seems to run rather old software versions.

[Nerivec]

It is, but benefits are also usage-specific.
From darkxst's experiments, higher than 115200 doesn't provide any noticeable benefits, and 115200 is by far the most used/tested one (it's what silabs uses in all their code too).
Bootloader uses separate serial values (though in this case, baudrate is also 115200, per silabs recommendations).

Factory firmware are always pretty old. Sonoff still has 6.10.3 floating around with 1.x bootloader... 7.4.2 is not very old compared to it (April) 😉
darkxst supplies the firmware that SMLight uses in their flasher, so, should be pretty much the same version-to-version.
Unless a version has specifically identified issues, updating has minor risks nowadays (built-in checks/cancel/retry), so, better to keep up-to-date (whenever possible...). You can always ask SMLight for more details.
Also note that bootloader updates, despite incrementing in version (because silabs increments all versions with each release), usually contain very few changes, compared to firmware.
https://docs.silabs.com/mcu-bootloader/3.0.0/gecko-bootloader-start/