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

I had the same issue with RCP firmware, silabs addon & Z2M, a whole lot of failed commands; unusable. I switched back to NCP (7.3.1), got rid of silabs addon, reverted Z2M config, and somehow Z2M kept all my devices (contrary to switching from factory NCP to RCP where I had to re-pair everything, as expected). It works just fine now… it’s as stable as the factory firmware (6.10.3) I used before (i.e. never crashed, no failed command, 30+ devices on it; been using it for over a month now, no complaint).

port: >-
adapter: ezsp
Zigbee2MQTT version 1.34.0
Coordinator type EZSP v12
Coordinator revision build 176

I also have a router-flashed (Sonoff 6.10.3) dongle that works just fine with the coordinator flashed with 7.3.1; not that it shouldn’t, but just in case anyone was wondering.

PS: for anyone having issues with the download links:

Latest Coordinator firmware (NCP) from Sonoff (6.10.3):

Latest Router firmware from Sonoff (6.10.3):

Oh, and, do yourself a favor, use darkxst’s Chrome-based flasher (thanks for that one!).


hey there,
i am just setting up my HA. Bought two Sonoff-E Dongles. Wanted to make the upgrade to Multiprotocol before anything else.

On Windows 10 (both on desktop and laptop) the web-based Flasher on can`t make a connection to both Sonoffs. (Edge and Chrome tested)

If i press connect, i can choose the sonoff off the given list - The circle just stops halfway through.

Driver are installed, shows up in device manager as:
USB-Enhanced-SERIAL CH9102 (COM3) - which should be fine

So two Sonoffs on two different computers (both WIN10) no update possible.

which way to go from here?

Might be a bug in sl-web-tools or its dependecies so suggest that you first try flashing with other methods/tools to rule it out before reporting the issue to the developer(s) of the tool that there is still a problem with it:

Maybe try following ITead/Sonoff guide but using other firmware image file if you wish to rule that out too:

Perhaps also reinstall the CH9102/CH34 (USB-to-UART bridge/converter) device driver and reboot the operating system to be sure:

I have flashed my 2nd dongle E with the router firmware, restarted and added it to the zigbee devices, do I have to do something else to let this router act as repeater in HA or will the rest function automatically between the two USB dongles?

Once you paired/joined a Zigbee Router device the routing function will work automagically, (each device will evaluate its best connection options and if needed automatically move around once every 24-hours to the best Zigbee Router devices), see → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage


ZHA configuration UI has a tab to view visualized device links in your Zigbee network topology, but you do not have to do anything →

1 Like

Thanks a lot …
i didn´t have luck with any of the methods - did try to build python an my WIN10 PRO - in the ende there were cryptic error messages about not being able to build the “wheel”)

So i gave up for the moment - My SONOFF-E (Ver 1.0) is working “as delivered” - only ZigBee … build 297

:question:Does anyone have a SONOFF-E with higher hardware versions than 1.0?

will try the web-flasher again in some weeks

You can try the web-flasher again now. See Web flasher broken due to missing dependency · Issue #11 · NabuCasa/sl-web-tools · GitHub fix should be included in → Release 0.10.1 · NabuCasa/sl-web-tools · GitHub and looks like Home Assistant webpage been updated Fix connection issue with web flasher by puddly · Pull Request #93 · home-assistant/ · GitHubHome Assistant SkyConnect and also looks like darkxst updated his sl-test webpage GitHub - darkxst/sl-test at gh-pages so check out again at Silabs Firmware Flasher | Web based flasher for ZB-GW04 and ZBDongle-E. MultiPAN RCP firmware enables these devices to be used with Silabs Multiprotocol Addon in Home Assistant. Allow Zigbee and Thread to co-exist on the same dongle. Get ahead of the tech an experiment with Matter!

What would be a reason to advise me to switch from firmware build 297 to the new firmware I have never done any updates, and if I can I avoid it, even if since yesterday a Tuya socket has disappeared from zigbee2mqtt I don’t think it depends on the dongle And for this problem

The old preconception that firmware updates are “risky” doesn’t apply (as much) on recent/decent hardware. Many connected devices will even auto-update firmware by default when a new one is available.
The one thing you should avoid is connected devices that don’t allow you to update firmware. 3-5 years down the road (if not sooner), you might as well hang a sign “Entry Here”. Always check on that before buying!

For “lesser” devices (i.e. stuff without much support…) such as the dongle here, you should check the stability of the flashing procedure (quick net search); if you see a myriad of issues, bricked devices, then only update if there is a good reason for it (security issue, not working properly, etc.). On the other end, if the flashing is easy, then definitely go for it, especially if the current firmware is getting old.

As for the dongle specifically, 6.10.3 is 2 years old and there were about 20 updates since. I don’t think there’s much hope for “official” Sonoff updates at this point. But to know exactly what the updates would bring to the table, you’d have to go through the release notes. On devices like this, that define a communication protocol, you also have to consider the “other side”, ZHA/Z2M, and what they support/recommend; new versions may break compatibility with older ones.

Personally, I flashed two dongles, half a dozen times, including router and coordinator firmware. I used Sonoff’s recommended procedure the first couple of times, then darkxst’s tool recently. I didn’t have a single issue (darkxst definitely easier). And like I said, 7.3.1 has been working with Z2M for over a month without problem.

For Zigbee2MQTT you are best off posting issues and discussions to their community:

Note that it is recommend to instead use TI CC2652P based “Sonoff ZBDongle-P” instead of Silabs EFR32MG21 based “Sonoff ZBDongle-E” for Zigbee2MQTT.

Reason is that the ezsp adapter code in the zigbee-herdsman library which Zigbee2MQTT does not quite yet have feature-parity with its zstack adapter code, and most notable the ezsp adapter code is missing full backup and restore support → Koenkk/zigbee-herdsman#319 preventing restoring backups and migration → FAQ | Zigbee2MQTT

FYI, check out this thread for unofficial method on how to migrate from ZBDongle-E to ZBDongle-P for thoee using Zigbee2MQTT → Koenkk/zigbee2mqtt#16478

Tip is then to reflash the ZBDongle-E with Zigbee Router firmware to repurpose it as a dedicated Zigbee repeater/extender by powering it via a USB-charger in order to make it into a stand-alone product →

Note! Regardless of Zigbee gateway solution I highly recommend to read and follow all the tips here → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage

PS: If where to use Home Assistant’s ZHA integration then would instead recommend Silicon Labs over Texas Instruments based Zigbee Coordinator → Zigbee Home Automation - Home Assistant however that is primarly just because Home Assistant SkyConnect is based on Silabs EFR32MG21 → Quantity Connection Home Assistant Notes
SONOFF Zigbee 3.0 USB Dongle Plus-E 1 USB Zigbee2MQTT Used to control all Zigbee smart bulbs and Blinds. ZHA was becoming un-reliable for me so switched to Zigbee2MQTT


I just wanted to drop a note on this thread in order to be self informed (via email notifications on this thread) of progress about EZSP firmware from time to time.

Here is my setup:

  1. Zigbee network with 79 devices, of which, 51 are routers and 28 are end devices. All end devices are less than 4m away from routers. There is no more than 5m between routers.
  2. Home Assistant, always updated to latest version running on a Raspberry-Pi 4
  3. Zigbee2Mqtt (and the Mosquito broker) in a separate hosts (2 separate virtual machines, they both run in the same hardware with Proxmox)

Last week, I’d a deconz Raspbee Zigbee controller in a dedicated Raspberry-Pi 4 (different from the one running HA) but I decided to migrate to Zigbee2Mqtt because of lack of information about what’s going on in the zigbee network with the deconz hardware/software, lack of support for HTTPS in their web app “Phoscon” (my iPhone refused to connect to their web application without HTTPS, limited capacity to rename devices in the zigbee network as that functionality was removed from their desktop application and some other issues, so I migrated to a SonOFF-E Zigbee 3.0 USB Dongle Plus dongle.

My dongle is running EZSP v8 version build 297. I’m having some issues when disconnecting devices from the network as they re-appear immediately after they are deleted from the net. I’d to repeat the delete process several times to success. Also the touchlink is not supported (lack of support in the firmware). But I like that the serial connection is 115200 bauds because in theory, this can handle more devices and messages. I also suffer from some end devices and routers that don’t like each other in the network (I decided to replace OSRAM bulbs with IKEA ones and SonOFF mini with equivalent Aqara on/off devices…)

I’ve also purchased a second SonOff Zigbee 3.0 USB Dongle Plus (like the one I already have) in order to test new firmware versions with the possibility to go back to the current firmware just switching them.

So, I’m definitively interested to know more and monitor the progress of the EZSP firmware in order to see if I can stabilise my zigbee network.

Re-pairing 79 devices is not an easy task. I’d to review all existing scenes and automations in HA because of the changes in device names…

In the end, a wall switch and a bubble physically connected to the AC is far more reliable than all this stuff :slight_smile: I love technology in general and in my mind I know that there is more potential in this mesh networks than in the old physical wires but it has to prove it can be reliable too.

For z2m, I’d also get a ZBDongle-P to test with. Load it up in a second instance for testing.

Many use EZSP with z2m, but it is still missing key backup/restore functionality.

It’s all anecdotal, and I think heavily dependent on device mix, but I see more weirdness with EZSP than I do with the zstack.

1 Like

With that many, you can easily change all names/IDs with vscode addon, and a simple search/replace & then config reload. Once you’re in Z2M though, as long as you name your devices consistently, even if you re-pair after a full reset of Z2M, it will pop back up in HA without issue (did for me anyway). If you re-pair without the aforementioned reset, it’ll all just come back on its own, in Z2M (remembers previous devices, names and all) and HA .

Check this for an easier time with device changes

The one thing you want to avoid in HA is using the action/trigger Device, that uses device_id and won’t port if you change a device (even if named the same); use the services of the corresponding domain instead, or State/Numeric state for a trigger.

For an action, do this

service: switch.turn_on
  entity_id: switch.air_purifier_power
data: {}

instead of this

type: turn_on
device_id: abcdef1234567890abcdef1234567890
entity_id: 1234567890abcdef1234567890abcdef
domain: switch

And for a trigger, do this

platform: numeric_state
  - sensor.basement_t_h_temperature
above: 10

instead of this

type: temperature
platform: device
device_id: 1234567890abcdef1234567890abcdef
entity_id: abcdef1234567890abcdef1234567890
domain: sensor
above: 10

If you keep that rule in all your automations/scripts/etc, you can re-pair or entirely replace a device, as long as you keep the same name in Z2M (and thus the same entity_id generated in HA), it should keep working everywhere.
Of course, sometimes the logic behind the entity_id automatic generation changes; that might force you to make a couple of changes, but that should be far less frequent.

Despite an issue or two in over two years my house has been running on Zigbee, I wouldn’t go back. I’ve forgotten what wall switches feel like (except when I have to step back and flip one when I’m not at home… :sweat_smile:). Not to mention the massive power savings (heat air/water, solar panels optimization, etc)…

The Dongle-E has far better range than my previous hub (Echo 4), and allowed me to save on batteries too; I’d estimate about 3 or 4 times less battery changes on farther devices!


I’m planing to update Sonoff Zigbee 3.0 USB Dongle from to a new version but I’ve some doubts. I already purchased a second dongle in order to be able to flash the new firmware in the new device and just switch dongles for testing.

Here are the questions:

  1. I’m having difficulties to find the firmware to flash. I can find documentation about the new releases of the SDK from Silabs but that is not ready to be flashed to the dongle.
  2. I’ve read that the current firmware ( provides a complete NCP at the coordinator level. This is what I want, there are some pages suggesting to install an RCP firmware but I’m afraid that would require to also to update Zigbee2mqtt side or even switch to ZHA and this is not desired at this moment. I think I just want to keep using an NCP firmware.
  3. I want to be able to use touchlink capabilities and firmware does not support them. I’m not sure if new firmware versions have added support for it. As stated in point 1, I can’t find sources for unofficial firmwares so I can’t read their release notes.

Can someone provide more information?


  1. The two most commonly referred repos are GitHub - darkxst/silabs-firmware-builder: Silicon Labs firmware builder and GitHub - xsp1989/zigbeeFirmware

  2. Only install rcp firmware if you want to install the multiprotocol addon and share the dongle with Thread. Multiprotocol works with z2m or ZHA.

  3. Not sure about touchlink.

I’m not sure how easy that is with the ZBDongle-E if you are expecting plug and play switching between sticks. Z2M doesn’t support full backup/restore for EZSP. I think you should be able to use the zigpy toolchain to backup/restore outside of z2m.

The other possible issue is historically resetting the MAC on EZSP chips was a one time, irreversible action. The HA devs overcame that for SkyConnect, but I am unclear if the SkyConnect updates have made it into other firmware/flashing tool builds.

Thank you! you are right

I’ve successfully flashed ncp-uart-hw-v7.3.2.0-zbdonglee-none-115200.gbl to the new dongle but I’m unable to execute universal-silabs-flasher --device /dev/tty.usbserial-202305080921111 --probe-method ezsp write-ieee --ieee e0798dfffe77c2f0 on the new dongle to write the same address I’ve on the old dongle.

This means my only option will be to just flash the old dongle with new firmware version and forget to just switch dongles.

I’m not sure what functionality is included/required in the Z2M backup/restore for EZSP. I just assumed the change in the dongle with same address and different firmware version would ‘just work’. I consider the dongle was as a pure hardware device without a memory that requires to be permanent between boots (except for the ieee address)

Touchlink should be supported with 7.3.x firmware, according to this with darkxst’s firmware, and this in Z2m, but I don’t have any to test.

Like darkxst says in the github issue, the only way to know the differences, is to read Silabs SDK release notes… and ensure the adapter also supports new features, if it’s hardware-dependent ones.

That is only partially the case when using as RCP (Radio Co-Processor) with the Silicon Labs EmberZNet Zigbee deamon (i.e. the multiprotocol addon with Silabs zigbeed), though not really true then either as it with RCP just offloads most but not all runtime parts of the Zigbee stack to the host computer when used as RCP. However it really is not the case when using as NCP (Network Co-Processor) as then the whole Zigbee stack is stored and runs onboard the Zigbee Coordinator microcontroller chip hardware on the dongle adapter, including all the Zigbee network information and security keys for your paired/joined devices. More details in Silabs docs if want to know how those two architectures work →

For tips on workaround backup and restore method/process for full NVRAM backups needed for Zigbee radio adapter migrations if using Zigbee2MQTT see this discussion in their community (which explain how to migrate between different radio types for Z2M regardless of manufacturer and Zigbee stack used) →

Did I just make a terrible choice in purchasing the Plus-E vs just the Plus? Should I cancel my order and wait the extra day to get the non-E version?

I decided not to take the chance as I was able to cancel the order and just order a Plus, and it’s supposedly pre-flashed with Z-Stack.