ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” (model "ZBDongle-E") based on Silicon Labs EFR32MG21 +20dBm radio SoC/MCU

For z2m, get the “P” and don’t look back. The TI chipset is what the primary z2m dev uses and will likely always be first among peers for z2m.

For ZHA, the opposite is true. The SI Labs chip used in the “E” is the same chip Nabu Casa chose for the Yellow and upcoming Skyconnect USB stick. It will likely be first for ZHA and HA Thread developments.

The Yellow/Skyconnect status should help bring parity between the two to z2m, but I wouldn’t wait.

I don’t think either chip has a clear advantage looking at the spec sheets.

1 Like

I took the advice of @Hedda and bought one of each so that I can set up Z2M with the “P” version and also start some testing with the “E” version and contribute with testing and feedback.

1 Like

I purchased a -E last week and had nothing but issues with pairing using z2m. Purchased a -P a few days ago and it’s working perfectly.

FYI, the upcoming 2022.9 version of Home Assistant will feature a new UI and backend/core functions for backup and restore/recover in Home Assistant’s native ZHA integration to export/save or import/restore Zigbee network ZHA backup images from within Home Assistant’s UI (in the GUI for the ZHA integration) to make migration to a new adapter easy in ZHA.

It should even make migrations to or from ZHA and Zigbee2MQTT or vice versa between them relatively easy compared to how it has been in the past since both ZHA and Z2M now use support the same “Open ZigBee Coordinator Backup Format” standard that was developed in collaboration between ZHA/zigpy and Zigbee2MQTT developers.

I am however now sure if and how well Zigbee2MQTT itself handle migrations (backup and restore) between different radio adapters such as zstack/znp and ezsp when they are not of the same type to “upgrade” adapter in Z2M without migrating to ZHA.

Anyway, see Zigbee2MQTT discussion → https://github.com/Koenkk/zigbee2mqtt/discussions/13373

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?

@rockets

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:

1 Like

And once again I’ve misread the question :flushed:

So still an unknown for Z2M at the moment?

Thank you for taking the time and elaborateing on the zigbee-topics @Hedda :pray:

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

https://github.com/Koenkk/zigbee2mqtt/commits/master

https://github.com/Koenkk/zigbee2mqtt/releases