If you already own a Xiaomi Multimode Gateway or an Aqara Hub E1, you’re sitting on hardware most coordinator buying guides never mention. The Zigbee radio inside both is an EFR32 chip from Silicon Labs, the same EZSP-based family that shows up in dedicated Zigbee2MQTT and ZHA coordinators. Reflash that chip’s firmware and, in theory, the gateway stops being a Xiaomi- or Aqara-branded appliance and starts acting as your Home Assistant Zigbee coordinator instead.
The technique isn’t secret, but it is thinly documented. Where it’s written down is the AlexxIT/XiaomiGateway3 project on GitHub and a couple of its forks, aimed at people who already know what a coordinator is. Zigbee2MQTT’s supported-adapters page is no help either: it’s organised by chipset family and never names Xiaomi or Aqara gateway hardware.
That absence is easy to mistake for silence, and it isn’t. Once the chip is flashed, Home Assistant doesn’t reach it over USB. It reaches it over your network, on a TCP port. Zigbee2MQTT documents that arrangement separately, as a remote adapter, and there it has a clear verdict: Wi-Fi-based serial-to-IP bridges are not recommended for Zigbee coordinators, because the serial protocol underneath has no fault tolerance for the packet loss and latency a Wi-Fi hop introduces. The docs call out Silicon Labs EZSP adapters specifically. Their suggested alternative is a remote adapter on wired Ethernet, and neither of these gateways has an Ethernet port.
This path assumes the AlexxIT/XiaomiGateway3 custom component is already installed and running on the gateway’s original firmware, in its normal LAN-integration mode. Flashing the Zigbee chip is a separate, deliberate action taken from inside that component.
What flashing actually changes
The custom component exposes a flash-custom-firmware action that replaces the Zigbee chip’s firmware independently of the rest of the gateway. It doesn’t touch the main OS or the Wi-Fi/Bluetooth radios. It only rewrites what the EFR32 chip runs, and it gives you a choice of two destinations: ZHA mode or Zigbee2MQTT mode.
Both destinations do the same thing to your existing setup. Every Zigbee device that was paired to the gateway through Mi Home stops working there the moment the flash completes.
What survives is worth knowing: Bluetooth and Mesh sub-devices, the BLE-based Xiaomi/Mijia sensors many gateways proxy into Mi Home, keep working in both Mi Home and Home Assistant regardless of which Zigbee mode is active. You lose the gateway’s own Zigbee radio and everything paired to it through that radio. You don’t lose the BLE fleet sitting on the same piece of hardware.
Support reality check: experimental, and not recommended
Neither destination is a first-class target for this chip, but they aren’t equally untested either.
Two independent sources agree on the Zigbee2MQTT side. The AlexxIT project’s README states that this gateway’s EFR32 EZSP chip is supported in Zigbee2MQTT in experimental mode. Zigbee2MQTT’s own remote-adapter documentation separately labels EZSP support over that connection path experimental, on top of the not-recommended verdict on Wi-Fi bridges above.
ZHA isn’t officially blessed either. ZHA’s developers advise against EZSP radios on Wi-Fi-based bridges, citing possible stability problems. But the same README notes that a range of users run the gateway in ZHA mode without issues, and describes ZHA as the more commonly working of the two modes. Our own Multimode Gateway local-control guide reached the same conclusion from Chinese community reports: on this specific chip, ZHA holds up better in day-to-day operation.
So it isn’t a wash. Both modes are unsupported in the sense that no project will promise you they work, but the weight of reporting leans ZHA on this hardware. If you already have a preference from other coordinators, ZHA vs Zigbee2MQTT for Aqara devices covers that general decision.
| Mode | Official status on this chip | What the sources say |
|---|---|---|
| Zigbee2MQTT | Experimental, over a connection path the project doesn’t recommend | AlexxIT README: supported in experimental mode. Zigbee2MQTT docs: EZSP over a remote adapter is experimental, and Wi-Fi serial-to-IP bridges are not recommended for coordinators |
| ZHA | Advised against, more commonly reported working | ZHA developers advise against EZSP on Wi-Fi bridges; the README reports a range of users running this mode without issues, and our own gateway guide finds ZHA steadier on this chip |
What can go wrong, and what “reversible” really means
The clearest documented failure is a closed GitHub issue (#862, last activity 2022-11-15) reporting that the mode-switch step failed outright on a gateway running the project’s recommended custom firmware build. The configuration flow returned an error along the lines of “Can’t update zigbee firmware” and stopped there. No maintainer resolution is recorded in that thread as it stands, so I’m treating it as evidence the mode-switch flow can fail, not as a solved or fully understood failure mode.
That’s consistent with how the source project frames the whole procedure: at your own risk. The change is described as reversible in principle. Reflashing the gateway’s default firmware restores Mi Home’s Zigbee mode. But reverting isn’t automatic. It’s a second deliberate flash you have to perform.
Treat this as a one-way door until you’ve reflashed back and confirmed Mi Home sees your original Zigbee devices again. A documented case exists of the mode-switch step failing mid-flow with no recorded fix. Don’t attempt this on a gateway you can’t afford to have stuck in an unclear state.
One documented working configuration
If you do go ahead with Zigbee2MQTT mode, the Zhenia-l/XMG2 project documents the ember-driver TCP settings used to connect to the flashed radio: a network adapter address on port 8888, the ember adapter type, and a 115200 baud rate. That project describes this as tested and stable, but only against one specific NCP firmware version, 8.0.2. Treat it as one documented working configuration rather than a guarantee across every gateway hardware revision or firmware version you might be running.
serial: port: tcp://192.168.10.50:8888 adapter: ember baudrate: 115200
The adapter value deserves a second look. ember is Zigbee2MQTT’s current driver for Silicon Labs radios, and it requires EmberZNet 7.4.x (EZSP 13) or newer; the older ezsp driver is deprecated but deliberately kept alive for adapters still on earlier firmware. An NCP build in the 8.x line clears that bar, which is why ember is the right value here. Flash an older NCP image and ezsp is the one that will talk to it. Our Sonoff ZBBridge guide walks through the same choice on the same chip family, over the same kind of network connection.
Where this makes sense, and where a dongle is the saner call
This is worth doing if most of the following are true for you.
- You already own the Multimode Gateway or Aqara Hub E1, and buying a second radio feels wasteful
- You’re already comfortable installing HACS custom components and don’t need the process to be officially blessed
- You’re not relying on the Mi Home app’s Zigbee pairing for anything you can’t rebuild in Home Assistant
- You accept “experimental” plus an explicit not-recommended verdict from the Zigbee2MQTT project as acceptable support levels for a coordinator you’ll depend on daily
A dedicated USB coordinator, something like a SLZB-06 or a Sonoff ZBDongle-P/E, is the better call if any of the following apply.
- You want a coordinator whose Zigbee support is the project’s primary target rather than an experimental add-on
- You’d rather the radio sat on a wired connection, which is what Zigbee2MQTT recommends when it can’t be plugged into the host directly
- You’d rather not risk your gateway getting stuck mid-flash
- You’re not currently running the AlexxIT component and don’t want to add it just for this
Sonoff ZBDongle-E vs ZBDongle-P is the comparison to read if you go that route.
I think buying a dedicated dongle is the better default for most readers, even though reusing hardware you already paid for is the more appealing option on paper. What settles it isn’t the experimental label. It’s that the project you’d be depending on has published a specific reason to avoid this topology, and the mitigation it suggests (wired Ethernet) isn’t available on either gateway. A coordinator is the one piece of a Zigbee network you don’t want fighting you.
How this differs from this site’s other gateway guides
The Multimode Gateway guide and the Aqara Hub E1 guide both cover the stock, LAN-integration mode: the gateway keeps its original firmware, and the AlexxIT component talks to it locally over your network instead of through Xiaomi’s or Aqara’s cloud. Nothing about the gateway’s Zigbee radio changes in that setup. Read those first if what you actually want is your existing devices working locally, with the least risk.
One thing to square before you start. Our Hub E1 guide answers “can I use the E1 with Zigbee2MQTT” with a flat no, and that answer is still right for the question it asks: a stock E1 is a Zigbee coordinator, and a coordinator can’t join another coordinator’s network. This article is about replacing what that coordinator runs, which is a different operation with a different answer.
Check your exact model before assuming the flash action is available to you. The component is built for these gateways on their default firmware over LAN, and its supported list covers the Multimode Gateway (ZNDMWG03LM and ZNDMWG02LM, the unit the community and the component both call Gateway 3), the Multimode Gateway 2, and the Aqara Hub E1 in CN (ZHWG16LM) and EU (HE1-G01) forms. Custom-firmware support is tracked separately from LAN support and doesn’t move in lockstep with it, so the README’s own list is the authoritative source rather than any summary of it, including this one.
This site’s decision piece on reaching Aqara hub entities over telnet covers a different local-API approach on the Aqara hub family: hub-level entities over telnet, not replacing the Zigbee chip’s firmware. It’s a different mechanism solving a different problem, and the risk profile isn’t the same.
FAQ
Can I use my Xiaomi Gateway 3 as a Zigbee2MQTT coordinator instead of buying a USB dongle?
Yes, technically, through the AlexxIT/XiaomiGateway3 custom component’s flash action. The chip’s Zigbee2MQTT support is labelled experimental, and because the flashed radio is reached over Wi-Fi rather than USB, it lands in a category Zigbee2MQTT’s own documentation says it doesn’t recommend for coordinators.
Does flashing coordinator firmware onto an Aqara Hub E1 break Mi Home entirely?
No. It breaks Mi Home’s control of Zigbee devices that were paired through the gateway’s own radio. BLE and Mesh sub-devices keep working in Mi Home and in Home Assistant either way.
Is ZHA or Zigbee2MQTT better supported on this hardware?
Neither is officially recommended, but they aren’t equal. Zigbee2MQTT calls its support experimental and advises against Wi-Fi serial-to-IP bridges generally. ZHA’s developers advise against EZSP on Wi-Fi bridges too, yet the AlexxIT README reports ZHA as the more commonly working mode, and our own gateway guide reaches the same conclusion from community reports.
Can I go back to stock Mi Home firmware after flashing a coordinator firmware?
Yes, by reflashing the default firmware, but that’s a separate, deliberate step, and at least one documented case shows the mode-switch flow itself can fail without a recorded fix.
What this piece verified, and what it didn’t
The two-mode behaviour, the BLE/Mesh survival detail, the “at your own risk” framing and the experimental label on the Zigbee2MQTT side all come from the AlexxIT/XiaomiGateway3 project’s own README, cross-referenced against GitHub issue #862 for the failure case. The not-recommended verdict on Wi-Fi serial-to-IP bridges, the EZSP-specific caveat and the wired-Ethernet alternative come from Zigbee2MQTT’s remote-adapter documentation, which is where this connection method is covered rather than on the supported-adapters index. The ember TCP settings come from a separate, smaller project (Zhenia-l/XMG2) and are scoped to one tested firmware version, not treated as universal.
No flashing was performed for this piece, on this site’s hardware or otherwise. Nothing here should be read as a tested, step-by-step procedure.