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

    source_routing: true
      tx_power: 12
      ikea_provider: true                        # Auto update Trådfri devices
      ledvance_provider: true                    # Auto update LEDVANCE/OSRAM devices
      salus_provider: true                       # Auto update SALUS/Computime devices
      otau_directory: /config/ota_ha

I believe as long as you are on the latest firmware, what you need is the tx_power under znp_config entity.
I didnt notice any difference though so I am not sure if this really works

Later ZHA works around this limitation so it should be a non-issue if using latest ZHA.

That works when using as a Zigbee Coodinator. Changing power on a Zigbee Router is only possible with ZBDongle-P as routers.

1 Like

Oooh… was not aware of that. Any idea what they are doing?

Sorry yes I misread, dongle p has it as an entity if a router. Weirdly dongle E shows up as a light in zha if acting as a router

Thank you, Hedda, for your directions. Appreciated.

As I already have met most of the requirements

  • Zigbee channel 15

  • Wi-Fi channels 2.4G : 11 - low power / 5G :48 - medium power

  • 2.0 USB HUB with USB 2.0 extension cable, ZBDongle P ~ 5 meters outside home lab middle of
    the three floor house where no Wi-Fi AP is present

  • most devices are router integrated devices, distance between devices ~ 2-3 meters

Am I missing the obvious due to my blind spots?

Current topology:

I do not remember exactly but believe it was something puddly added to the bellows radio library for zigpy → GitHub - zigpy/bellows: A Python 3 project to implement EZSP for EmberZNet devices

OK so just to test and since I am still in the return window, I flashed the Sonoff E into coordinator again using the latest from Firmware Flasher Darkxst

Migrated the radio from the P dongle. Looks good, had to repair some mains powered devices but seem to be good now.

However I flashed the P dongle to act as a router and unable to be added. Anyone else encountered anything similar? Flashed the router firmware multiple times now and started the pairing process before connedting the P dongle, still no dice

If you migrated the E dongle from the P dongle, they now both have the same IEEE-address. You will need to give the P-dongle a new IEEE-address.

Damn I didnt take note of the new coordinator IEEE address. Is this something I can generate?

I had the same problem, I just changed the last 4 digits of the existing IEEE-address.

1 Like

Thanks that worked brilliantly.

Will report after a few days on how things are different or same :smiley:

1 Like

Just an update after the migration from P to E.

Mesh seems responsive and faster. I had to repair about 4 routers (out of 60) as they dropped off within 1-2 days but was straight forward.

Signal strength seems to be much better but I am not sure if this is just the way SL calculates it vs TI.

One thing I noticed however is there are more warning in my logs, mostly timeouts but also a topology scan fail. Not sure what that means, tried searching online with little progress.


Logger: zigpy.topology
Source: /usr/local/lib/python3.11/site-packages/zigpy/
First occurred: September 26, 2023 at 4:58:12 PM (4 occurrences)
Last logged: 5:44:24 AM
Topology scan failed

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/zigpy/", line 78, in _scan_loop
    await self.scan()
  File "/usr/local/lib/python3.11/site-packages/zigpy/", line 96, in scan
    await self._scan_task
  File "/usr/local/lib/python3.11/site-packages/zigpy/", line 221, in _scan
    await self._find_unknown_devices(neighbors=self.neighbors, routes=self.routes)
  File "/usr/local/lib/python3.11/site-packages/zigpy/", line 253, in _find_unknown_devices
    await self._app._discover_unknown_device(nwk)
  File "/usr/local/lib/python3.11/site-packages/zigpy/", line 940, in _discover_unknown_device
    return await zigpy.zdo.broadcast(
  File "/usr/local/lib/python3.11/site-packages/zigpy/", line 519, in broadcast
    return await app.broadcast(
  File "/usr/local/lib/python3.11/site-packages/zigpy/", line 916, in broadcast
    await self.send_packet(
  File "/usr/local/lib/python3.11/site-packages/bellows/zigbee/", line 854, in send_packet
    raise zigpy.exceptions.DeliveryError(
zigpy.exceptions.DeliveryError: Failed to enqueue message after 3 attempts: <EmberStatus.NETWORK_BUSY: 161>

Funilly enough I am getting this

Zigbee channel 11 utilization is 94.48%!

Even though I have no wifi channels from 1 to 5. Dont remember seeing this in Dongle P

Responses do seem faster but the same 4 routers dropped again today. I deleted them and readded instead of just repairing. So let’s see what happens.

Last resort will be to rebuild the entire network, arghhhh

Note that the frequency range for Wi-Fi channel numbering does not match Zigbee channel numbering

1 Like

Thanks @Hedda I knew that, I did say I didnt have any wifi channels in 1 to 5 :slight_smile: which would be in the zigbee 11 channel zone.

I actually went back to the Sonoff P dongle. The E dongle although showing good signal strength, I constantly had the above warnings and constant drop outs after a few days :frowning:

I deleted everything and repaired everything again but it didnt help. Still kept getting topology scan warnings and the same few devices kept falling off.

Finally decided to go back to dongle P, removed zha again and repaired everything. ZHA auto selected channel 11 as it should. So far seem to be okay, less warnings and errors in logs.

I have a fairly large network with 145 devices, 60 routers and the rest end devices.


The IEEE address gets written to OTP (on-time programmable, aka eFuse) memory, however with the latest firmware (i.e 7.3.x) the IEEE address can now be stored as a token in NVMEM, which can be rewritten/updated. ZHA has implemented this, not sure about Z2M.

Now which is the most stable firmware for zigbee2mqtt? Some of my devices are not responding after 1-2 hours (WXKG01LM, RTCGQ01LM) Server: rpi3, HA, Coordinator: dongle-e, FW6.10.3.0 build 297, ezsp v8

1 Like

Updated to FW:
I’ll be back with the news.

News (31/10/23): Since the firmware update, the sensors are stably connected.:slight_smile:


Check out the latest related development discussion here → [WIP]: EFR32 EZSP adapter implementation and test · Issue #319 · Koenkk/zigbee-herdsman · GitHub (currently most look to recommend either 6.10.x.x or 7.3.x.x versions as most stable but not the versions in between those). Also check out relatef firmware discussions and issues in this other firmware builder repository → darkxst/silabs-firmware-builder · Discussions · GitHub

1 Like

Because the topic has a lot of messages, wich dongle its better to buy for home assistant the
Zbdongle-p or zbdongle-e;
I see that model e is newest

1 Like