The original Sonoff ZBBridge was built to pair Zigbee devices to eWeLink’s cloud over Wi-Fi. Flash it with Tasmota and it can run instead as a networked Zigbee2MQTT coordinator, with no eWeLink account and no cloud round-trip. This guide covers the original ZBBridge specifically, not the newer ZBBridge Pro, which uses a different Zigbee chipset and a different flashing procedure entirely.
That scope note matters. The two devices share a name and a similar case, and existing coverage doesn’t always separate them cleanly, which shows up as real confusion in the Zigbee2MQTT issue tracker. If a step here doesn’t match what’s on your board, stop and confirm which variant you have.
What you get at the end is a Wi-Fi-connected coordinator that talks to Zigbee2MQTT over TCP rather than a local USB serial port. It’s a legitimate budget option if you already own one. It isn’t equivalent to a proper USB or Ethernet coordinator, and the official documentation is unusually blunt about why.
This article covers the original Sonoff ZBBridge only. The ZBBridge Pro runs a different Zigbee radio and protocol stack, and its flashing steps are out of scope here.
What the Sonoff ZBBridge actually is
Per zigbee.blakadder.com’s device page, the original ZBBridge pairs an Espressif ESP8266/ESP8285 for Wi-Fi with a CoolKit “SM-011 V1.0” radio module built around a Silicon Labs EFR32MG21 for Zigbee. It runs on USB power at 5V 1A, so there’s no mains wiring and no electrical-safety concern from flashing it, unlike some of the relay-style Sonoff products.
The EFR32MG21 module supports both Coordinator and Router Zigbee firmware roles, and the same device page lists it as compatible with both ZHA and Tasmota based on community testing. That flexibility is what makes the repurposing project possible at all: the radio hardware isn’t locked to eWeLink’s firmware, it just ships that way from the factory.
| ZBBridge (original) | ZBBridge Pro | |
|---|---|---|
| Zigbee protocol | EZSP | ZNP |
| Zigbee chipset | Silicon Labs EFR32MG21 (CoolKit SM-011 module) | Texas Instruments CC2652P |
| Z2M serial.adapter value | ezsp | Z-Stack/ZNP driver — not covered here |
| Flashing procedure | Covered in this article | Different steps — see Pro-specific guides |
Why repurpose it instead of buying a dedicated coordinator
This site has already covered purpose-built coordinators like the Sonoff ZBDongle-E vs ZBDongle-P and the Ethernet-connected SMLIGHT SLZB-06, and either is the better long-term choice for a serious network. But if a ZBBridge is already sitting in a drawer, or shows up secondhand for a few dollars, turning it into a coordinator is a legitimate way to get off eWeLink’s cloud without spending anything.
It’s the same pattern this site covered for migrating a Tuya Zigbee gateway to Zigbee2MQTT: repurpose a cloud-first gateway you already own rather than adding another vendor account. Readers working through the broader project of getting Sonoff gear off eWeLink will also want the local-LAN options in Sonoff DIY Mode.
What you’ll need
- A ZBBridge confirmed as the original (not Pro) variant
- A USB-to-TTL serial adapter for the initial flash
- A small Phillips screwdriver to open the case
- Basic soldering-adjacent wiring skills, or someone who has them
Getting Tasmota onto the ESP8266 side the first time means opening the case and wiring a USB-to-TTL adapter to internal test points. This isn’t a plug-and-play web flash the way some other Sonoff Wi-Fi devices are. Budget time for it, or skip this project if you’re not comfortable opening the device.
Flashing Tasmota onto the ESP8266 side
The initial flash puts the ESP8266/ESP8285 side into a state where it can accept a standard Tasmota firmware build over serial, following the same general approach as other ESP8266-based Sonoff devices: open the case, connect the UART pins to a USB-to-TTL adapter, put the chip in flash mode, and write the image. Once that completes and the device reboots into Tasmota, it’s reachable over Wi-Fi through Tasmota’s own web console instead of the eWeLink app.
Flashing the Zigbee radio’s coordinator firmware
The ESP8266 running Tasmota and the EFR32MG21 Zigbee radio are two separate chips, and getting Tasmota running doesn’t touch the radio’s firmware. That’s a second, later step. With Tasmota already live, the EFR32MG21 gets an EmberZNet NCP (coordinator) image pushed to it through Tasmota’s own web-based firmware upgrade page, not through the UART wiring from the first step.
Once that’s done, the ZBBridge is running Zigbee coordinator firmware and is ready to be pointed at Zigbee2MQTT. Nothing carries over from the eWeLink side: the new coordinator firmware forms its own Zigbee network, so every device that was paired to the bridge through the app has to be paired again from Zigbee2MQTT.
Connecting Zigbee2MQTT over the network
Because the ZBBridge only exposes its Zigbee radio over Wi-Fi, not a physical USB serial port, Zigbee2MQTT needs to be told to treat it as a remote adapter reachable over TCP rather than a local /dev/tty* device. The official Zigbee2MQTT documentation covers this exact connection method, with the adapter type set to ezsp to match the ZBBridge’s EFR32MG21 protocol.
serial: port: 'tcp://192.168.10.42:8888' adapter: ezsp
Swap the IP for wherever the ZBBridge actually sits on your network, ideally on a dedicated IoT VLAN rather than your main LAN. The port number depends on how the radio firmware exposes its TCP listener; check the firmware’s own documentation if it isn’t 8888 on your build.
That ezsp value deserves a second look, because it isn’t Zigbee2MQTT’s current driver for Silicon Labs radios. The project deprecated ezsp in favour of a newer ember driver, which is now the recommended way to run EFR32 hardware and is a genuine improvement in stability and in backup and restore behaviour. The catch is that ember requires EmberZNet firmware 7.4.x (EZSP 13) or newer, and ezsp was kept precisely so adapters on older firmware keep working. That’s why the ZBBridge instructions still specify it. Check which EmberZNet build your NCP image actually is against the EmberZNet adapter guide before assuming either driver will take it.
Running adapter: ezsp means running a driver Zigbee2MQTT has deprecated and maintains for legacy firmware. It works, and this setup is documented — but it’s another sign that this is a repurposing project on an older platform, not a current-generation coordinator.
The reliability tradeoff
This is the part that shouldn’t get buried under the flashing steps. The official Zigbee2MQTT documentation is direct about it: Wi-Fi-based serial-to-IP bridges are described as not recommended, because the serial protocol underneath doesn’t have enough fault tolerance for the packet loss and latency that a Wi-Fi hop can introduce, and EZSP support over this specific remote-adapter path is currently labeled experimental.
The Zigbee2MQTT project itself describes this connection method as not recommended and experimental. A Wi-Fi TCP bridge is not a drop-in equivalent to a wired USB coordinator, and the project’s own docs say so directly.
That caveat is easy to skim past, because the flashing instructions read like any other Tasmota project. But it describes a structural limit, not a rare edge case, and treating a Wi-Fi hop as interchangeable with a wired serial link is where the failure reports in the next section start.
Common connection failures and what they usually mean
GitHub issue #16947, “Sonoff ZBBridge cannot connect,” describes this device losing its TCP connection to Zigbee2MQTT with repeated “Error while opening socket” errors, and no documented fix in the thread. It was opened in March 2023 and closed as not planned, meaning it went stale rather than getting resolved. If you hit the same error, that thread is worth reading for context, though it won’t hand you a fix.
Separately, GitHub issue #28134, “Can’t connect to Sonoff ZBBridge Pro over TCP anymore,” describes a similar-sounding but distinct failure: the TCP socket connects, then Zigbee2MQTT’s Zigbee layer never finishes starting. That report is about the Pro variant on the ZNP protocol, not the device this article covers, and it’s mentioned here only because it shows how easily the two devices’ problems get conflated in bug reports. ZNP-specific advice aimed at the Pro doesn’t apply to the original ZBBridge.
FAQ
Can you use a Sonoff ZBBridge with Zigbee2MQTT?
Yes, the original ZBBridge, once flashed with Tasmota and a coordinator-role EmberZNet firmware, connects to Zigbee2MQTT as a remote TCP adapter using the ezsp protocol.
Is ezsp still the right adapter setting?
It’s what Zigbee2MQTT’s own ZBBridge page specifies. Project-wide, ezsp is deprecated in favour of the newer ember driver, which needs EmberZNet 7.4.x or newer; ezsp remains supported for adapters running older firmware, which is the situation most ZBBridge builds are in.
Is the Sonoff ZBBridge the same as the ZBBridge Pro?
No. They share a product name but use different Zigbee radios and protocols, EZSP on the original’s Silicon Labs EFR32MG21 versus ZNP on the Pro’s Texas Instruments CC2652P, with separate flashing procedures for each.
Do you need to solder anything to flash a Sonoff ZBBridge?
The initial Tasmota flash requires opening the case and wiring a USB-to-TTL adapter to internal UART pins. It’s not full soldering, but it’s soldering-adjacent and not a plug-and-play web flash.
Is a Wi-Fi Zigbee coordinator reliable for Home Assistant?
The Zigbee2MQTT project’s own documentation describes Wi-Fi-based serial-to-IP bridges as not recommended and calls EZSP support over this path experimental, due to the fault tolerance limits of a Wi-Fi hop compared to a wired serial connection.
Does flashing Tasmota remove eWeLink cloud dependency completely?
Once the ESP8266 side is running Tasmota instead of the stock eWeLink firmware, the device no longer needs an eWeLink account or cloud connection to function. Control moves to Tasmota’s local web interface and, for the Zigbee side, to Zigbee2MQTT directly.
What this article verified, and what to check yourself
No ZBBridge was flashed or bench-tested for this article. The chipset details, power specification, and Coordinator/Router firmware support come from zigbee.blakadder.com’s device database; the connection method, the serial.port/serial.adapter: ezsp configuration, and the “not recommended” and experimental caveats come from the official Zigbee2MQTT remote-adapter documentation; the driver-deprecation detail comes from Zigbee2MQTT’s EmberZNet adapter guide. Both GitHub issues cited above were checked: #16947 is the original ZBBridge report, opened March 2023 and closed as not planned, and #28134 is a ZBBridge Pro report, included here only for disambiguation.
What stays local once this is set up: Zigbee2MQTT talks to the ZBBridge directly over your own network, with no eWeLink account or cloud service in the path. What still depends on outside parties: Zigbee2MQTT’s continued support for this EZSP-over-TCP method, which its own docs flag as experimental, the ezsp driver’s continued life as a deprecated-but-maintained path, and the community-sourced Tasmota and EmberZNet NCP firmware images themselves.
After setup, check three things: that your board is confirmed as the original ZBBridge and not the Pro, that the TCP port in your config matches what your radio firmware build actually exposes, and that you watch the Zigbee2MQTT logs for the same “Error while opening socket” pattern from issue #16947 if the connection drops. The flag most likely to change how confidently this setup can be recommended is whether EZSP-over-TCP graduates out of experimental status — or whether the deprecated ezsp driver is eventually retired, which would end this path rather than improve it.