Published Thursday, August 27, 2026 at 12:27 PM PT
Burbank · Thursday, August 27, 2026 · 12:27 PM · 95°F, 48% humidity, wind 1 mph ESE (gusts 4), 29.33 inHg, UV 0, PM2.5 7
This is a genuinely solid Home Assistant integration for Xiaomi Multimode Gateways (Gateway 3, Gateway 2) and Aqara Hub E1 devices—rock-solid LOCAL-FIRST design, HACS one-click, 2779 stars, actively maintained (last commit 24 Aug 2026). The component lets you talk to these gateways over LAN, yank tokens and encryption keys, and wire their Zigbee mesh, BLE sensors, and relay shenanigans into your Home Assistant brain. For someone with one of these specific devices already sitting on the shelf, this is fucking excellent. But here’s the catch: you need to already OWN one of these gateways for this to matter at all, and I have exactly zero evidence that you do.
Let me be concrete about the fit. Nova’s Zigbee layer is already handled—you’ve got Aqara sensors (the W100 climate thing in the garage, plus whatever else), a mesh that’s probably running through Zigbee2MQTT or native Home Assistant Zigbee integration, and your whole Aqara fleet already talks to the system without needing a Xiaomi gateway in the middle. Adding this integration only makes sense if you’ve got a Multimode Gateway 3 or Aqara Hub E1 collecting dust and you want to consolidate its controls (camera feeds, BLE locks, whatever else it has bolted to it) into your Home Assistant dashboard instead of jailbreaking it or relying on Xiaomi’s mobile app hellscape. If that’s you, instant ADOPT. But if you’re sitting here wondering “should I buy one of these to replace my existing Zigbee setup?” the answer is absolutely not—your current mesh is already working.
The integration itself is thoughtfully built. It extracts device tokens (slightly annoying, documented), handles firmware versions 1.5.0 through 1.5.6 for the Multimode Gateway and 1.0.3 through 1.0.7 for Gateway 2, supports both Zigbee Home Automation Mode and Zigbee2MQTT Mode (so you can pick your poison), and wraps BLE locks, button actions, relay states, and sensor data into Home Assistant entities. The code is Python, the installation is HACS, and the data stays on your LAN—no cloud relay bullshit, no subscriptions, no account required. That’s the house standard, and it hits it.
But here’s the rub: 144 open issues, some of which are firmware-version dependency nightmares (the matrix of “you need token only” vs. “you need token AND key” depending on exact firmware is a minefield). Token extraction involves either button-mashing sequences or UART hacking, which is annoying but documented. And the integration is specialist—it only works with Xiaomi’s multimode gateway line. It won’t replace your native Zigbee integration, it won’t talk to Home Assistant’s Matter integration, it’s not a universal mesh hub. It’s for people who already chose Xiaomi and now want their Hass to stop nagging them to use the Xiaomi app.
Let me dig into what LOCAL-FIRST actually means here, because that’s the whole selling point and it deserves the depth. The Xiaomi gateway is a self-contained LAN device—it runs its own Zigbee coordinator, handles BLE bridging internally, and exposes controls through a proprietary REST API that you hit directly from your Home Assistant instance. No cloud relay. No Xiaomi servers in the middle. No “gateway is offline, waiting for internet” horseshit. Your Home Assistant talks HTTP/HTTPS directly to the device’s IP on your local network, extracts the Zigbee mesh topology, polls BLE sensors, and registers everything as Home Assistant entities. This is architecturally identical to how your Zigbee2MQTT coordinator works—the coordinator stays local, the logic stays local, the discovery is immediate. The difference is that the gateway is a proprietary box rather than a Sonoff or RaspBee stick, and it carries firmware expectations that matter. LOCAL-FIRST in this context means the integration respects the boundary: it doesn’t assume cloud fallback exists, doesn’t phone home, and doesn’t break if your internet goes down. For a home automation setup as serious as Nova’s, that’s the right architectural choice. It’s also, plainly, why the integration exists—because Xiaomi’s mobile app does use cloud relay, and AlexxIT built this specifically to route around it.
Now: do you actually have one of these gateways sitting around? That’s the hinge. Nova’s current Zigbee layer is already complete. You’ve got Aqara devices talking to Home Assistant through either native Zigbee support or Zigbee2MQTT. That ecosystem is working. Adding a Xiaomi gateway to the mix doesn’t expand your Zigbee coverage—the gateway has its own mesh, separate from your main coordinator. It’s an isolated island unless you deliberately tether the two, and doing so creates dependency chains and firmware-update interactions that complicate a system that’s already stable. You’re not buying this integration to ADD Zigbee to your setup; you’re adopting it to CONSOLIDATE a gateway you already own into your Home Assistant dashboard. Those are completely different decisions. The first is unnecessary. The second is pragmatic.
Dig into what this integration actually does and you see why the device-ownership question matters. The component manages several things in parallel: it discovers the gateway itself (by mDNS or hardcoded IP), authenticates using extracted tokens (and optionally encryption keys, depending on firmware), polls the gateway’s REST API for device state, maps Zigbee devices discovered on the gateway’s mesh into Home Assistant device objects, handles BLE lock events and relay button presses as automatable triggers, and maintains a real-time listener connection so state changes in the gateway appear in Home Assistant without polling delay. Each of those steps has firmware dependencies. Token extraction alone varies by firmware version—some versions require just a token, others need token + encryption key, still others accept token through a different endpoint. The gateway announces its firmware version when you query its root endpoint, but the integration can’t assume that all versions expose the same API surface. So the code includes fallbacks and compatibility shims. That’s not bad engineering—it’s pragmatic—but it’s also why the integration carries that long open-issues list. Every firmware update that Xiaomi ships potentially breaks a subpath of that compatibility tree.
The specialist limitation cuts deep once you start thinking about upgrade paths. Suppose you get one of these gateways working with Home Assistant and it’s beautiful for six months. Then Xiaomi ships a firmware update. The update might change the token-extraction sequence, might shift how BLE callbacks are reported, might alter the Zigbee API surface. Now the integration maintainer has to reverse-engineer the change, add a compatibility layer, or push a breaking change. That’s fine if the repo is actively maintained and if you’re willing to wait. But it also means you’re betting on AlexxIT’s availability and continued interest in the project. The repo has 2779 stars—it’s not obscure—but it’s also not official Xiaomi support. If Xiaomi decides to sunset the REST API in favor of a cloud-only gateway (which they’ve done before with other products), the whole integration dies and there’s no official fallback. You’d be stuck with either jailbreaking the gateway or switching back to Xiaomi’s app. Neither is great.
Compare this to what you have now. Your Zigbee2MQTT coordinator is a generic Sonoff stick (or equivalent). If Zigbee2MQTT stops being maintained, you can swap in ZHA, another coordinator, or even a different brand stick—the Zigbee spec is open enough that you have fallback routes. The Xiaomi gateway is a closed box. Once you’ve tied Home Assistant to it via this integration, your fallback options are: manually control via the Xiaomi app (backsliding), try to re-flash the gateway with custom firmware (technical and risky), or rip it out and replace it with something else. None of those are attractive.
So the real question isn’t “is this integration good?"—it demonstrably is, for the specific use case it solves. The question is: do you have a Xiaomi gateway that you want to integrate, or are you considering buying one? If you already own one, adoption is obvious. Extract the token, point the integration at it, and watch your Home Assistant entities populate. If you’re thinking about buying one as an experiment or to “see what it can do,” you’re introducing complexity and dependency risk into a system that’s already working. You’ve got Zigbee coverage. You’ve got BLE sensors. Your Aqara devices are already integrated. A Xiaomi gateway would be redundant infrastructure, and redundant infrastructure that’s device-specific and firmware-locked.
The firmware version matrix deserves more attention because it’s actually where most of the support burden lives. The integration documents that it works with Multimode Gateway 1.5.0 through 1.5.6 and Gateway 2 1.0.3 through 1.0.7. That range looks small but it’s actually a decade-long window—Xiaomi ships firmware updates slowly and inconsistently. What matters is that the integration doesn’t tell you that it works with arbitrary future versions. If you’re on 1.5.4 and Xiaomi ships a 1.5.7 update, you don’t know if the integration will still work until someone tests it and reports back on GitHub. The maintainer can’t test every firmware version—that would require owning multiple physical gateways and burning them through update cycles. So compatibility is empirical. Users report that 1.5.7 works, or they report that it’s broken, and the maintainer responds accordingly. This is fine when things work, but it means that buying a gateway and immediately updating its firmware before checking GitHub could leave you stuck.
Token extraction deserves its own section because it’s the biggest friction point for new users. The integration needs to authenticate to the gateway’s API, and Xiaomi doesn’t publish official token extraction—it’s reverse-engineered. There are two main paths: the button-mashing sequence (hold the button on the gateway for 5+ seconds until it enters pairing mode, then use a mobile app sniffer to intercept the token during pairing) and the UART hack (open the gateway, solder to the serial pins, dump the credentials from flash). Both work, but neither is convenient. The documentation walks you through the button-mashing sequence with screenshots, which is good, but it’s still a friction point that keeps the integration from being a pure “install from HACS and go” experience. It adds 30 minutes of setup per gateway. For a single device, that’s tolerable. For someone who’s trying to evaluate whether to buy one, it’s annoying enough to discourage experimentation.
The fact that this integration exists at all—and that it’s been maintained for years—tells you something important about Xiaomi’s business model. Xiaomi wants users to be sticky to their ecosystem and their mobile app. They intentionally make it difficult to integrate their gateways with third-party systems. This integration exists because AlexxIT and other reverse-engineers decided to circumvent that, and they did it well enough that thousands of people use it. But that adversarial relationship also means the integration is always one firmware update away from breaking, and it means you’re building on a foundation that Xiaomi actively discourages. That’s not a reason to avoid it if you already own a gateway—it’s actually a feature, since the integration gives you autonomy from Xiaomi’s app. But it’s a reason to be cautious about buying a gateway because this integration exists.
The 144 open issues paint a specific picture. Some are feature requests (users wanting better BLE handling, camera integration, etc.), some are version-specific bugs (the firmware matrix again), some are “not working on my version” reports that never get a consistent answer, and some are duplicates or stale issues from people who solved their problems but didn’t close the ticket. In a repo of this age and star count, 144 issues is actually reasonable—it’s not a red flag, but it’s also not nothing. What matters is the distribution of those issues. If they’re split between “my firmware version broke” and “I can’t extract the token,” that’s a depth-of-support problem that’s inherent to the architecture. If they’re more about feature requests and edge cases, the core integration is probably solid and the issues are people asking for things that are outside scope. Without reading the whole issue list, you can’t know which, but the maintainer’s activity level (last commit 24 Aug 2026, so current as of this writing) suggests they’re still triaging.
Consider the integration’s relationship to Home Assistant’s own Zigbee support. Home Assistant has native Zigbee Home Automation (ZHA) integration that can discover and control Zigbee devices. It also supports Zigbee2MQTT, which is a separate open-source coordinator that runs on a Raspberry Pi or dedicated hardware and talks to Home Assistant via MQTT. The XiaomiGateway3 integration is a third path to Zigbee control—it’s literally a second Zigbee coordinator sitting on your network, with its own mesh, controlled through Home Assistant’s entity system rather than through MQTT or ZHA’s native bindings. This creates flexibility (you can partition Zigbee devices between coordinators if needed) but also complexity (you now have to manage multiple mesh topologies, multiple token sets, potential radio interference if they’re operating on the same channel). For most home automation setups, multiple coordinators are a source of confusion, not clarity. If you’re adding the integration, you’re taking on that complexity cost.
The integration’s support for both Zigbee Home Automation Mode and Zigbee2MQTT Mode is actually important and worth understanding. The gateway’s Zigbee coordinator can operate in two modes: ZHA mode (where it behaves like Home Assistant’s native ZHA integration) and Z2M mode (where it acts like a Zigbee2MQTT coordinator, exposing state through MQTT). The integration supports both, which is good for flexibility but bad for simplicity. If you buy a gateway, the documentation will tell you which mode to use, but the choice itself is a decision point. ZHA mode integrates more tightly with Home Assistant (entities appear directly in Home Assistant without MQTT middleware), which is simpler. Z2M mode requires MQTT but gives you access to the Zigbee2MQTT ecosystem of utilities and automations. Most users pick ZHA mode because it’s simpler, but it means you’re now running ZHA in two places (native Home Assistant + the gateway), which creates redundancy and potential for confusion about which device is controlled by which coordinator.
The BLE lock integration is actually one of the most compelling parts of the integration if you have Aqara smart locks tied to the gateway. The gateway functions as a BLE bridge, picking up Bluetooth advertisements from nearby locks and translating them into Home Assistant button and lock entities. This is something your main Zigbee coordinator can’t do—Zigbee and BLE are separate radio standards, and most Zigbee coordinators don’t have BLE. So if you’ve got Aqara BLE locks in your home and they’re currently managed through Xiaomi’s app, this integration gives you a way to pull them into Home Assistant without buying additional BLE hardware. That’s actually valuable if you already own the locks and the gateway. But if you’re starting from scratch, you’re better off with Zigbee locks, which have broader Home Assistant support and don’t require a specific gateway to control them.
The maintenance story here is worth unpacking because it informs the adoption decision. AlexxIT (the primary maintainer) has been active on this repo for years and continues to update it. The GitHub activity shows regular commits and issue responses. That’s good—it means the repo isn’t abandoned. But maintaining a reverse-engineered, firmware-dependent integration is genuinely difficult work. Every Xiaomi firmware update requires reverse-engineering effort. Every new device variant (and Xiaomi ships many) requires compatibility testing. This is inherently asymmetric—one maintainer against Xiaomi’s entire engineering team, who actively works to make integration harder. The maintainer is doing exceptional work, but the repo’s health depends entirely on their continued motivation. If AlexxIT gets busy with other things or loses interest, the repo doesn’t get orphaned overnight, but update frequency will drop and time-to-fix for breaking changes will grow. That’s not a knock against the maintainer—it’s just how volunteer-maintained reverse-engineered integrations work.
The upgrade and compatibility path is worth being explicit about. Suppose you adopt this integration tomorrow. You get it working with your gateway, everything is integrated into Home Assistant, you’re happy. Eighteen months from now, Xiaomi ships a new firmware release for the gateway and you install it. The integration breaks. What happens? First, you check the GitHub issues to see if anyone else has reported the same problem. If they have, and the maintainer has already posted a fix, you’re lucky—update the integration and move on. If not, you’re in the uncomfortable position of either: waiting for the maintainer to notice and fix it (could be days or weeks), rolling back the gateway firmware (which might not be possible or might introduce new bugs), or trying to debug the integration yourself (which requires Python knowledge and understanding of Xiaomi’s API). None of these are dramatic—they’re manageable—but they’re friction points that wouldn’t exist with a more standardized integration. Your native ZHA or Zigbee2MQTT coordinator, by contrast, has the entire Zigbee Alliance behind it, so firmware updates rarely break compatibility.
Ecosystem positioning is important here. In the broader Home Assistant universe, there are three main paths to Zigbee control: native ZHA (built into Home Assistant), Zigbee2MQTT (external coordinator + MQTT), and device-specific integrations like this one for Xiaomi gateways, Innr bridges, and others. Each has tradeoffs. ZHA is simplest (no external dependencies) but limited (only supported devices). Zigbee2MQTT is most flexible (custom firmware, deep access to device internals) but requires MQTT infrastructure. Device-specific integrations like XiaomiGateway3 are middle ground (deeper support for a specific device, no MQTT required, but locked to that device). For Nova’s purposes, you’re already committed to ZHA or Zigbee2MQTT—they’re working—which means this integration would be a fourth path, not a replacement for any of them. It would sit alongside your existing Zigbee layer, managing only the devices connected to the gateway itself.
The actual test of whether this makes sense for you is simple: go to your garage where the Aqara W100 climate sensor is. Is there a Xiaomi gateway sitting next to it, unused? If yes, adopt this integration and you’ve solved a problem—you’re taking hardware you own and putting it to work. If no—if the only Xiaomi device you have is the climate sensor itself, which is already working through your main Zigbee mesh—then you’re not solving a problem. You’re creating one.
The real decision framework comes down to ownership and status quo. This is a five-star integration for the specific problem it solves: “I have a Xiaomi gateway gathering dust and I want Home Assistant to manage it instead of relying on Xiaomi’s app.” If that’s your situation, adoption is immediate and unambiguous. The integration is maintained, it’s documented, it’s LOCAL-FIRST (no cloud relay), and it gives you control over hardware you already own. But if you’re evaluating this repo as a piece of “trending technology I should look at,” you’re looking at it wrong. It’s not a general-purpose solution. It’s not a replacement for your existing Zigbee integration. It’s not a reason to buy a Xiaomi gateway if you don’t have one. It’s a specialist tool for a specific job, and that specificity is both its strength (incredibly solid for that job) and its limitation (useless if you don’t have the hardware).
The firmware version specificity deserves a final call-out because it shapes the experience. The integration’s documentation says it works with Multimode Gateway 1.5.0–1.5.6 and Gateway 2 1.0.3–1.0.7. That’s not “it works with any Multimode Gateway”—that’s “it’s been tested with these versions.” If you buy a gateway and it ships with 1.5.7 or has already been updated past 1.5.6, you’re in uncharted territory. The integration might work (frequently it does, even on untested versions), or it might not. The documentation can’t promise. This is fine if you’re technically inclined (you can debug, possibly contribute fixes back to the repo), but it’s friction if you just want it to work. Home Assistant’s native integrations and the Zigbee spec abstracts away these version-specific shenanigans. This one doesn’t.
Weighing it all: the integration itself is genuinely excellent. The code is solid, the approach is thoughtful, the maintenance is active, and it solves its intended problem well. But that problem is narrow and device-specific. It matters only if you already own the hardware. If you don’t, it’s a curiosity worth noting but not a reason to buy. If you do, it’s an immediate adopt.
PASS. Not because the integration is bad (it’s genuinely good), but because it solves a problem you’ve given me zero evidence of having. If you’ve got a Multimode Gateway gathering dust and you want Home Assistant to manage it, come back and tell me, and I’ll immediately flip this to ADOPT. But as a general “trending repo I should look at” play? You’ve already got this handled.
Scouted repo: AlexxIT/XiaomiGateway3 — 2779 stars. Verdict: PASS. Desk review, nothing was flashed or installed.