private@homelab: ~/latest
local-first guides · privacy-aware · no noisy tracking
lightdark
private@homelab:~$ cat guides/article.md
·
·
7–11 minutes
read

Sonoff ZBDongle-E vs ZBDongle-P for Zigbee2MQTT: Which to Buy

Both dongles run Zigbee2MQTT, but the ZBDongle-E's Ember adapter still isn't stable-tier while the ZBDongle-P works out of the box. Which to buy.

Sonoff ZBDongle-E vs ZBDongle-P for Zigbee2MQTT: Which to Buy

Sonoff sells the ZBDongle-E and ZBDongle-P under nearly the same name, “Zigbee 3.0 USB Dongle Plus,” and most spec-sheet comparisons treat them as interchangeable options that differ mainly in price and range. For a ZHA install, that’s roughly true. For Zigbee2MQTT, it isn’t, and the gap comes down to driver maturity rather than raw hardware capability.

The short answer

Buy the ZBDongle-P if you’re running Zigbee2MQTT and don’t have a specific reason to pick the other one. It uses Texas Instruments’ CC2652P radio, ships with Z-Stack coordinator firmware already flashed, and works with Z2M the moment you plug it in.

Buy the ZBDongle-E only if you already know why. That means you want Silicon Labs radio hardware for some other reason, you’re comfortable with a one-time firmware flash, and you accept that its Z2M driver — while improved and now the recommended path for this hardware — still hasn’t reached the maturity tier of the Z-Stack driver the P uses.

Chipset and firmware differences

The ZBDongle-P is built around the CC2652P, part of TI’s long-running CC26xx Zigbee/Thread/BLE SoC family that’s been the default recommendation in the Zigbee2MQTT and Home Assistant communities for years. It ships pre-flashed with Z-Stack 3.x.0 coordinator firmware, connects over USB through a CP2102N UART bridge, and needs no setup beyond plugging it in and pointing Z2M at the serial port.

The ZBDongle-E uses a different chip entirely. It’s built around Silicon Labs’ EFR32MG21, an ARM Cortex-M33 radio SoC. It ships with EmberZNet firmware, which Zigbee2MQTT talks to through its ember driver — but many units arrive on an EmberZNet build older than the ember driver requires. The current driver expects EmberZNet 7.4.x (EZSP 13) or newer, so getting reliable behavior usually means running Sonoff’s official browser-based flasher once, before first use, to bring the firmware up to a compatible release.

That’s a five-minute step, not a real barrier on its own. But it’s a step the P doesn’t require, and it’s the first sign that these two dongles aren’t sitting at the same level of Zigbee2MQTT support.

The one thing most comparisons miss

Here’s the part that dedicated ZBDongle-P-vs-E comparisons tend to skip entirely. In Zigbee2MQTT, Silicon Labs’ EFR32/EmberZNet coordinators — the ZBDongle-E, the SkyConnect/Connect ZBT-1, the SLZB-07 line — have sat in an experimental development tier and have never been declared stable in the traditional sense. That’s a different footing from the Z-Stack adapter the CC2652P runs on, which is the path Zigbee2MQTT’s own team has spent the most years hardening.

The situation has moved, though, and it’s worth being precise about how. The older ezsp driver that first supported these adapters is now deprecated. Its replacement, the ember driver, is the recommended way to run EFR32 hardware today and is a genuine improvement — better stability, more reliable backup and restore. What hasn’t happened is a formal graduation to “stable.” So the accurate framing isn’t “the E is broken” or “the E is fine now”; it’s that the E’s driver is still catching up to the maturity the P’s driver already has.

That distinction is the single fact that should change your buying decision if you’re specifically choosing a coordinator for Zigbee2MQTT rather than ZHA or some other stack. Most of the comparison sites I looked at run through range, price, and antenna specs and conclude the two dongles are roughly equivalent. None of them lead with the fact that the underlying driver for the E carries a different support tier in the platform you’re actually about to run.

I think that’s a meaningful omission, not a nitpick. A reader choosing between a coordinator that works out of the box with a first-class driver and one that works after a flash on a driver that’s still short of stable is making a different decision than one choosing between two dongles with equivalent TX power. Zigbee2MQTT’s own EmberZNet adapter guide documents the driver requirements and caveats if you want to read the primary source.

What the support tier actually means in practice

Worth knowing: a driver that hasn’t reached “stable” in Zigbee2MQTT’s terminology doesn’t mean broken. Plenty of people run the ZBDongle-E with Z2M’s ember driver successfully and report stable networks. It means the Ember path hasn’t accumulated the same years of hardening as the Z-Stack adapter the CC2652P uses — the one most troubleshooting guides, forum answers, and issue triage assume you’re running.

Practically, that shows up as a smaller pool of precedent when something goes wrong. If you hit an edge case with a Z-Stack coordinator, there’s a large body of prior GitHub issues and forum threads to search. If you hit an edge case with the Ember driver, you’re more likely to be one of the earlier reports rather than finding your exact situation already resolved.

If you choose the E anyway: the one-time firmware flash

If you have a reason to prefer the E (Silicon Labs hardware, an existing preference, a specific compatibility need), the setup path is quick but not skippable. Sonoff provides an official web-based flasher that updates the dongle’s EmberZNet firmware to the 7.4.x release the current ember driver expects. You do this once, before pairing any devices, over USB from a browser that supports WebSerial.

Skipping this step is the most common reason people report the ZBDongle-E as broken with Zigbee2MQTT when it first arrives. It’s not a compatibility failure. It’s an unflashed dongle running firmware that predates the current Ember-driver support.

ZHA users: this decision flips

If you’re choosing between these two dongles for ZHA rather than Zigbee2MQTT, the calculus is different. Silicon Labs’ EmberZNet coordinators are a first-class, well-supported path in ZHA, not a second-tier one. Our ZHA vs Zigbee2MQTT comparison covers the platform-level tradeoffs in more depth, but the short version for this comparison is that a ZHA user landing on this page after searching for a P-vs-E comparison shouldn’t necessarily conclude the E is worth avoiding. For ZHA specifically, the E is a solid, mainstream choice. The maturity caveat in this article is about Zigbee2MQTT’s Ember driver, not about the EFR32MG21 chip or Silicon Labs firmware in general.

Range, capacity, and price: the minor differentiators

A few specs get more attention in other comparisons than they deserve.

Both dongles support up to +20 dBm TX power (some ZBDongle-P batches ship configured to +5 dBm by default, adjustable). Despite how often this gets framed as a differentiator, it isn’t one in practice. Real-world Zigbee range depends far more on router placement and mesh topology than on a coordinator’s transmit power alone. A dongle with more TX power sitting in a closet behind two walls won’t out-perform a lower-power one with good router coverage.

Coordinator capacity is a more useful number if you’re planning a large network. Sonoff documents the ZBDongle-P as supporting up to 50 directly-joined child devices and roughly 200 total devices once mains-powered routers are relaying. Sonoff’s figure for the ZBDongle-E is lower on the directly-joined count — around 30 children joined straight to the coordinator — with total network size, as with any coordinator, expanding well past that once routers relay for it. Sonoff doesn’t publish a clean E-vs-P “total device” number to line up against the P’s ~200, and effective capacity on the Ember stack depends on firmware and configuration, so treat the direct-child figures as the more meaningful comparison: 50 for the P, ~30 for the E. If you’re anticipating a lot of end devices joined directly to the coordinator, that gap is worth planning against. For anything approaching either ceiling, it’s also worth comparing a USB dongle against a networked coordinator like the SMLIGHT SLZB-06, which sidesteps USB-cable placement constraints entirely.

Price varies by retailer and bundle, and it moves often enough that a specific number here would be stale within weeks. As a general pattern, the ZBDongle-E tends to run somewhat cheaper than the P. If price is the deciding factor and you’re on Zigbee2MQTT, that discount is coming with a less-mature driver attached to it. Decide whether that tradeoff is worth it for your setup rather than assuming the cheaper option is automatically the better deal.

Buying recommendation matrix

  • Running Zigbee2MQTT with no strong preference either way. Get the ZBDongle-P.
  • Running Zigbee2MQTT but want to try Ember/EFR32 hardware anyway. Get the ZBDongle-E and budget five minutes for the firmware flash before first pairing.
  • Running ZHA. Either dongle is well supported. The P still avoids a firmware-flash step, and the E is a legitimate first-class choice here too.
  • Planning a large network (100+ devices) with few routers. Check each dongle’s documented direct-child ceiling against your plan, or look at a networked coordinator instead.
  • Price is the only factor. That’s fine, but the E’s discount comes attached to a less-hardened Zigbee2MQTT driver. Weigh that tradeoff deliberately rather than assuming cheaper always wins.

This exact question — which of the two to buy for Zigbee2MQTT — recurs on Home Assistant and Zigbee community forums without a clear consensus answer, usually because the answers focus on hardware specs rather than driver support. That’s the whole reason this comparison is worth writing carefully rather than as a spec-sheet table.

FAQ

Is ZBDongle-E or ZBDongle-P better for Zigbee2MQTT?
For Zigbee2MQTT specifically, the P is the safer default because it uses the Z-Stack driver Z2M has supported longest and in most depth. The E works well through Z2M’s ember driver, but that driver — while now the recommended path for EFR32 hardware — still hasn’t reached the same stable tier.

Does ZBDongle-E work with Zigbee2MQTT?
Yes, after a one-time firmware flash to bring its EmberZNet firmware to a version the ember driver supports (7.4.x or newer). It’s not plug-and-play the way the P is.

Do I need to flash the Sonoff ZBDongle-E before using it?
Usually, for Zigbee2MQTT. Many units ship with older EmberZNet firmware that predates the current ember driver’s requirements. Sonoff’s browser-based flasher handles the update in a few minutes.

What’s the difference between ZBDongle-P and ZBDongle-E?
Different radio chips (TI CC2652P vs Silicon Labs EFR32MG21) and different firmware stacks (Z-Stack vs EmberZNet, the latter driven through Z2M’s ember driver). The P works immediately with a first-class driver. The E needs a flash and runs on a driver that’s improved but still short of stable-tier in Zigbee2MQTT.

Which Sonoff dongle should I buy for ZHA vs Zigbee2MQTT?
For ZHA, both are solid choices since EmberZNet coordinators are mainstream there. For Zigbee2MQTT, the P is the default recommendation unless you have a specific reason to accept the E’s less-mature driver path.

Whether Zigbee2MQTT’s Ember driver formally graduates to stable is worth watching. If that happens, this comparison gets a lot simpler, and it’ll be time to revisit this article.

local-firstHome Assistantno-cloud