How is that really going to work?
The linked spec appears to only be for the low level stick network data.
I see moving stick to stick within a platforn, but how is all the off-stick data stored in each db’s translated?
Sorry if I was unclear, I did not mean to imply that the application level data would be migrated between the different applications or that the Zigbee network backups contain data about what you named your devices in the application layers of Home Assistant or Zigbee2MQTT. This type of Zigbee network backup will only backups and restores the “Zigbee network” (Zigbee network layer), meaning the Zigbee devices already joined/paired to your Zigbee Coordinator, so you should at least not need to go around your house in order to re-join/re-pair all your Zigbee devices with the Zigbee Coordinator, but the ZHA backup files using this “Open Zigbee Coordinator Backup Format” so it does not contain any data about application layers which technically have nothing to do with the Zigbee networking parts.
Read the primary use case here → https://github.com/zigpy/open-coordinator-backup#rationale
Zigbee2MQTT and vice versa will only be able to restore the backup of the Zigbee level, not a backup at the application level. To clarify; this new backup feature in Home Assistant’s ZHA integration will obviously never be specifically made to be a “ZHA to Zigbee2MQTT migration tool” nor a “Zigbee2MQTT or ZHA migration tool”. It is only that ZHA and Zigbee2MQTT both support saving the Zigbee network part of their backups using the same “Open ZigBee Coordinator Backup Format” standard which makes their “Zigbee network backups” compatible with each other for restoring/recovering the “Zigbee network” without having to re-join/re-pair all Zigbee devices.
The fact remains that this will still make migration between ZHA to Zigbee2MQTT or vice versa much easier than before since you do not need to re-join/re-pair all your Zigbee devices, which is not something that would usually take a very long time if have many devices and you have to first reset them all to factory default and then re-join/re-pair them one by one.
I don’t see how you get out of re-pairing or the functional equivalent if moving between ZHA/Z2M.
Seems like you’d have a functional mesh during transition, but at some point the devices would need to be interviewed to know what they are. Maybe an interview could be triggered as devices check in?
I guess we’ll see soon enough.
FYI, HA 2022.9 has now been released and release notes on news blog mention the new ZHA feature:
https://www.home-assistant.io/blog/2022/09/07/release-20229/#zigbee-backup-and-restore–migration
They have however updated text a little removing the mentioning of Z2M since the version was in beta, but Everything Smart Home took a screenshot of the beta release notes which as seen did mention it:
https://youtu.be/wmYocYd0wts?t=309
Yes the application will re-interview the device and that should be done automatically. That process would be the same if restoring a backup file “Open ZigBee Coordinator Backup Format” in ZHA or Zigbee2MQTT or any other Zigbee implementation supporting the same backup format.
Already joined/paired devices with properly coded Zigbee firmware should usually connect and be “re-interviewed” automatically within 24 hours but some devices, especially battery-powered devices may have to be manually woken up so that they will connect in order to send a state update, so if you for example have door/window sensors then you need to open the doors/windows and a button/remote device may need to have one of its button pressed in order to initiate a state change.
Some troublesome battery-powered devices with poorly written Zigbee firmware are however still known to need to have their battery removed and put back in in order to initiate a connection to the Zigbee Coordinator.
Still, the main point and purpose with these different applications using the same “Open ZigBee Coordinator Backup Format” standard is thjat that you should not have run around your house to factory reset any devices or go through the whole joining/pairing process with each and every one of your Zigbee devices when migrating from another playform that uses the same backup format standard if you restore from a valid backup made by either ZHA or Zigbee2MQTT, no matter if that backup was not generated in the same Zigbee implementation. So I think this compatibility will definitely be welcomed by many people with 100+ Zigbee devices wanting to migrate from Zigbee2MQTT to ZHA or vice versa.
Again, if you migrate from Zigbee2MQTT ot ZHA or vice versa then your automations and scripts will not automagically be updated and it does not restore the application layer which contains your device names and entities names, so you would still have a to manually fix your automations and scripts to use the newly given names or rename all your device names and entities names to match your old names.
The built-in restore of a backup file to migrate will as such not be automagic “next next finish” process.
From other posts, it looks like they come back with default auto generated names.
We will still be running around the house figuring out what sensor is where.
It’s a great feature and improvement.
Docs should be edited to set expectations. Folks with existing nets are still effectively down for extended periods.
There are no docs about this feature/function as of yet, please feel free to contribute info about this:
HA is on my no-coding (or PR) list. It’s a crude method, but only way to manage my time.
Not completely opposed to tweaking some docs, but I can’t document what I haven’t personally tested.
I had been looking at the rc docs and had not realized they removed the line from the release docs.
Will wait and see what the powers that be officially bless.
Hi all,
Reading this, I see some people have flashed ZBDongle-E. Have anyone flash it for router in Zigbee2MQTT?. Is it working well?
Sorry no. I only have the dongle-p. As far as I can tell there isn’t really any benefit choosing the e over the p other than the configurable power level. P dongles are well supported and I can’t see any reason for anyone to change their coordinator out.
He is specifically asking about using ZBDongle-E as Zigbee Router, not as a Zigbee Coordinator (NCP).
https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/Router
vs.
https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/NCP
I flashed it with Zigbee Router firmware to repurpose it as a Zigbee signal repeater / Zigbee range extender device in ZHA but not Zigbee2MQTT, however, on paper it should be great for it. Ask here:
https://github.com/Koenkk/zigbee2mqtt/discussions/13373
EFR32MG2x (and EFR32xG1) chip adapters like these then it will have the newer Gecko Bootloader (GBL) that has the ability to enter bootloader mode automatically via software (also known as Auto-BSL) without the need to press holding physical BTL/reset button or short circuit any GPIO/soldering-pads. Silicon Labs can also be flashed over USB/UART by manually putting them in bootloader / BSL mode (also known as boot mode or firmware recovery mode.
For flashing Silabs EFR32MGxx chips checkout these different methods:
- Elelabs Firmware Update Utility (multi platform Python based command line tool)
- agners silabs-flasher - Silicon Labs Firmware flashing utility (multi platform Python based command line tool)
- walthowd husbzb-firmware script (community maintained multi platform bash script)
- Manual Xmodem sending commands over a terminal console (note that any terminal application with “Xmodem(N)” send can be used)
- Silicon Labs Simplicity Studio included “Flash Programmer” (instructions) (can’t find your device? read below!)
1 Like
And once again I’ve misread the question 
So still an unknown for Z2M at the moment?
Thank you for taking the time and elaborateing on the zigbee-topics @Hedda 
I have a [“ZBDongle-E” (“Sonoff Zigbee 3.0 USB Dongle Plus V2”)
I finally managed to install Python on my win11 laptop, using a USB2 hub and the Elelabs Firmware Update Utility → GitHub - Elelabs/elelabs-zigbee-ezsp-utility: Elelabs Zigbee EZSP Utility to perform firmware update on a range of Elelabs EZSP products as well as other generic EZSP adapters..
With some trail and errors, I manged to get the xmodem and serial connection fuctioning and were able to communicate with the stick, launching the probe command and gtting a readout.
The stick is already in use (having replaced a Conbee II). However I don’t know which firmware to choose.
in the Elelabs repo there are several firmwares in the folders /data/EFR32MG13/
ELE_MG13_ot_rcp_115200_120_211116.gbl
ELE_MG13_ot_rcp_123_220206.gbl
ELE_MG13_zb_ncp_115200_610_211112.gbl
ELX0X3_MG13_6.0.3_ezsp_v6.gbl
ELX0X3_MG13_6.7.0_ezsp_v8.gbl
In the folder /data/EFR32MG21/
ELU0141_MG21_ot_rcp_123_211204.gbl
ELU0141_MG21_zb_ncp_6103_211204.gbl
ELU0143_MG21_ot_rcp_123_211211.gbl
ELU0143_MG21_zb_ncp_6103_211211.gbl
Wich one of these sould I flash the Dongle-E V2 with? It will be the only coordninator on a rpi with latest home assistant version, running zha connected through a usb2 hub.
Shoud I use one of rhese or preferabli one on the meny other firmwarws available on different gits?
As I have spent quite some time getting Python for win and the Elelabs tool to work, I hope to use this tool for flashing.
Thanks!
Yes unknown for know and Z2M usually need a converter for zigbee-herdsman for each new device → GitHub - Koenkk/zigbee-herdsman-converters: Collection of device converters to be used with zigbee-herdsman
That tool is good to use but none of those includee firmware images are for ZBDongle-E as those included images are only for Elelabs own adapters. Instead get firmware image from the links in my original post above, so either the one from ITead’s GitHub or from community developers if feeling brave.
ZBDongle-E Router support should be in the dev branch (HA “Edge” Add-On) now, it was added last week.
1 Like
Ah so it was, so it looks like converter support for “ZBDongle-E” with Zigbee Router device firmware has been added to zigbee-herdsman-converters 7-days ago, so likely Zigbee2MQTT ”Edge” (dev branch) will support it now but not in the master branch (mainline) or any stable releases as yet, see:
If you want to track it further to see check when it will get added to Z2M stable release then also see:
https://github.com/Koenkk/zigbee-herdsman-converters/tags
https://github.com/Koenkk/zigbee2mqtt/commits/dev
I have some serious issues flashing this Sonoff ZB-Dongle-E with the official firmware. I’m using EzspFwUtility to flash the firmware. I tried to flash the Router Firmware, it succeeds but as soon as it wants to restart the NCP it got me stuck in the bootloader with a green blinking light the first time around, now no blinking green light.
However even though stuck in the bootloader I couldn’t flash it again, I had to find out that by pressing boot + reset I could get back in a mode I would be able to flash again, I tried to flash it with the original NCP firmware but again no dice. After restarting it gets stuck in that same bootloader.
I tried a unsigned firmware from the community, and that flashed without any issues. However this firmware isn’t really supported by anything so pretty useless. (zigbeeFirmware/firmware/Zigbee3.0_Dongle-NoSigned/EZSP at master · xsp1989/zigbeeFirmware · GitHub)
Flashing the NCP will give me this:
python3 Elelabs_EzspFwUtility.py flash -f ncp-uart-sw_EZNet6.10.3_V1.0.1.gbl -p com3
2022/09/16 22:39:30 Elelabs_EzspFwUtility: EZSP adapter in bootloader mode detected:
2022/09/16 22:39:30 Elelabs_EzspFwUtility: Gecko Bootloader v1.12.00
2022/09/16 22:39:30 Elelabs_EzspFwUtility: Allready in bootloader mode. No need to restart
2022/09/16 22:39:31 Elelabs_EzspFwUtility: Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
.....
.....
.....
.....
2022/09/16 22:40:06 Elelabs_EzspFwUtility: Firmware upload complete
2022/09/16 22:40:06 Elelabs_EzspFwUtility: Rebooting NCP...
2022/09/16 22:40:21 Elelabs_EzspFwUtility: Couldn't communicate with the adapter in Zigbee (EZSP) mode, Thread (Spinel) mode or bootloader mode
Flashing the Router will give me this:
python3 Elelabs_EzspFwUtility.py flash -f Z3RouterUSBDonlge_EZNet6.10.3_V1.0.0.gbl -p com3
2022/09/16 22:52:19 Elelabs_EzspFwUtility: EZSP adapter in bootloader mode detected:
2022/09/16 22:52:19 Elelabs_EzspFwUtility: Gecko Bootloader v1.12.00
2022/09/16 22:52:19 Elelabs_EzspFwUtility: Allready in bootloader mode. No need to restart
2022/09/16 22:52:20 Elelabs_EzspFwUtility: Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
.....
.....
.....
2022/09/16 22:53:02 Elelabs_EzspFwUtility: Firmware upload complete
2022/09/16 22:53:02 Elelabs_EzspFwUtility: Rebooting NCP...
2022/09/16 22:53:15 Elelabs_EzspFwUtility: EZSP adapter in bootloader mode detected:
2022/09/16 22:53:15 Elelabs_EzspFwUtility: [ASSERT:C:/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.2/platform/base/hal/micro/cortexm3/efm32/token.c:211]
Additional Error Log:
[ASSERT:C:/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.2/platform/base/hal/micro/cortexm3/efm32/token.c:211]
Reset info: 0x07 (CRS)
Extended Reset info: 0x0701 (AST)
Thread mode using main stack (20002460 to 20002DC0), SP = 20002CF0
680 bytes used (28%) in main stack (out of 2400 bytes total)
No interrupts active
Reset cause: Assert C:/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.2/platform/base/hal/micro/cortexm3/efm32/token.c:211
R0 = 0004421A, R1 = 000000D3, R2 = 2000302C, R3 = 00000001
R4 = 00000000, R5 = 00000000, R6 = 0000000E, R7 = 00000031
R8 = 200033D4, R9 = 00041900, R10 = 000417D8, R11 = 200033D4
R12 = 00000001, R13(LR) = FFFFFFF9, MSP = 20002CF0, PSP = 20002DC0
PC = 00008314, xPSR = 69100000, MSP used = 000002A8, PSP used = 00000000
CSTACK bottom = 20002460, ICSR = 00000806, SHCSR = 00070008, INT_ACTIVE0 = 00000000
INT_ACTIVE1 = 00000000, CFSR = 00010000, HFSR = 00000000, DFSR = 00000000
MMAR/BFAR = E000ED34, AFSR = 00000000, Ret0 = 00013A95, Ret1 = 0000833B
Ret2 = 0000958B, Ret3 = 00024263, Ret4 = 0002CA0B, Ret5 = 00015199
Dat0 = 0004421A, Dat1 = 000000D3
Out put of flashing with custom firmware that succeeds:
python3 Elelabs_EzspFwUtility.py flash -f ncp-uart-sw_7.0.2.0_115200.gbl -p com3
2022/09/16 23:22:11 Elelabs_EzspFwUtility: EZSP adapter in bootloader mode detected:
2022/09/16 23:22:11 Elelabs_EzspFwUtility: Gecko Bootloader v1.12.00
2022/09/16 23:22:11 Elelabs_EzspFwUtility: Allready in bootloader mode. No need to restart
2022/09/16 23:22:12 Elelabs_EzspFwUtility: Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
.....
.....
2022/09/16 23:22:52 Elelabs_EzspFwUtility: Firmware upload complete
2022/09/16 23:22:52 Elelabs_EzspFwUtility: Rebooting NCP...
2022/09/16 23:22:59 Elelabs_EzspFwUtility: Generic Zigbee EZSP adapter detected:
2022/09/16 23:22:59 Elelabs_EzspFwUtility: Firmware: 7.0.2-150
2022/09/16 23:22:59 Elelabs_EzspFwUtility: EZSP v8
Honestly I have no idea what to do at this point. I tried to flash both under Linux as Windows but with the same results. Trying to boot in normale mode through the EzspFwUtility also doesn’t work.
Anyone has an idea?
1 Like
Thanks!
My coordinatior was shupped with quite up-to-date firmware:
Generic Zigbee EZSP.
Firmware: 6.10.3-41
EZSP: v8
I think it is the same as Itead has on their git now.
Any good reason to look for some of the community firmware. The criteria is:
- Stability
- Compatibility
- No of devises it van handle.
PS. I still have my previous ConbeeII-stick. I did not back up and transered to new coordinatior.
Some how it seems to have includetet all det devices. However some times it does no keep proper track on light beeing on or off.
Especially when it were turned on on my HASS-dashboard and off on a remote. It will still show as turned on.
I am assuming the devices and eteties are stored in the zigbee.db and that it why it works out oft the box. But shoudld I make a backup of the ConbeeII and transfer it to the Sonoff - or does it allready have all the devices ‘on-board’?
Any update?
No, it looks like I’m stuck on ncp-uart-sw_7.1.1.0_115200.gbl (community firmware). I have not been able to downgrade back to the original firmware, any 6x firmware or the router firmware.
I’ve tested the adapter with the adapter with the ncp-uart-sw_7.1.1.0_115200.gbl firmware in the developer build of Zigbee2MQTT and can confirm it’s working so the device is not bricked but I haven’t been succesful getting the device to work on any other firmware lower than this firmware afterwards.
Most of the time i’m greeted with this message after succesful flashing the firmware and restarting the NCP
Couldn't communicate with the adapter in Zigbee (EZSP) mode, Thread (Spinel) mode or bootloader mode
or bootloop:
[ASSERT:D:/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.2/platform/base/hal/micro/cortexm3/efm32/token.c:211]
At this point I’m so fed up with this adapter that I’ve it stopped for now. If I find the motivation I might try to connect with different baud-rate after flashing. Maybe for some reasons it defaulted to a different baudsize (in the serial connection). I did read that some EZSP sticks use 57600 bauds instead of 115200. that didn’t work