This post contains affiliate links. If you buy through them, I earn a small commission at no extra cost to you.
Aqara Hub M2 vs M3 for Home Assistant: Which to Buy
Every vendor comparison page I’ve seen frames this as “M3 is newer, therefore better.” That framing is wrong for Home Assistant users.
The M2 and M3 don’t just differ in specs. They use different integration paths in HA. Different paths mean different entities exposed, different VLAN requirements, different known bugs, and a different setup experience. The M3 is not a straightforward upgrade if your priority is local control in Home Assistant — it is a different integration with different tradeoffs.
This guide covers those tradeoffs in enough detail to actually make the call.
How Each Hub Talks to Home Assistant
This is the thing vendor pages skip over, and it’s the most important part of the comparison for HA users.
M2: HomeKit Controller (recommended), Matter bridge (limited)
The M2 was designed in the pre-Matter era. Its primary HA integration path is via the HomeKit Controller integration. You add the M2 as a HomeKit accessory, HA discovers it through mDNS, and your Aqara Zigbee devices appear as HomeKit entities within HA.
From firmware 4.0.0 onward, the M2 also supports Matter bridge mode. But the entity coverage through Matter is noticeably thinner than through HomeKit Controller — several device types that work fine via HomeKit Controller don’t appear at all via Matter. For M2 users, HomeKit Controller remains the recommended path. The Aqara Hub M2 HomeKit Controller setup guide walks through that path step by step.
M3: Matter (primary) + HomeKit Controller (secondary) — dual-stack recommended
The M3 ships with Matter as its flagship integration. In theory, you commission the M3 into HA via the Matter integration, and your downstream Zigbee and Thread devices appear through the Matter bridge.
In practice, Matter-only gives you thin coverage. The M3 hub itself shows up as a single identify entity. Smart locks appear correctly. But a significant portion of device types — sensors, switches, many actuators — don’t surface through Matter alone.
The workaround that the HA community has converged on is dual-stack: run both the Matter integration and the HomeKit Controller integration simultaneously on the same M3 hub. The two integrations cover different device types, and together they give you close to complete coverage. It works, but the setup is more involved than the single-path M2 experience.
For the M3 in detail, see the Aqara Hub M3 Matter bridge guide for Home Assistant.
Entity Coverage: What Each Integration Exposes
The table below summarizes what you get from each path. This is based on documented community experience, not vendor claims.
| Device type | M2 via HomeKit Controller | M3 via Matter only | M3 dual-stack |
|---|---|---|---|
| Motion sensors | Full | Partial | Full |
| Door/window sensors | Full | Partial | Full |
| Temperature/humidity sensors | Full | Partial | Full |
| Smart locks | Full | Present | Full |
| Smart plugs (on/off + power) | Full | Partial | Full |
| Wall switches | Full | Partial | Full |
| Presence sensor (FP2) | Via separate HomeKit Controller pairing | Not applicable | Not applicable |
| IR blaster | Not exposed | Not exposed | Not exposed |
| Hub identify entity | Present | Present | Present |
| Button multi-press events | Present | Missing | Partial (HomeKit side) |
The IR blaster gap applies to both hubs equally: there is no integration path — HomeKit Controller or Matter — that exposes IR control to HA. This has been the case since the M2 launched, and there’s no indication Aqara plans to change it. If IR control from HA matters to you, neither hub solves it.
The M3 Matter-only button multi-press gap is more frustrating because it’s specific to the Matter integration. Single presses come through, but double-press and hold events are not exposed via Matter. The HomeKit Controller side of the dual-stack does carry these events, so dual-stack resolves it — at the cost of the added setup complexity.
VLAN and mDNS Requirements
A common question is whether one hub is easier to configure in a network-segmented setup. The answer is: not meaningfully.
Both integration paths rely on mDNS (UDP port 5353) for discovery. The HomeKit Controller integration, used by both hubs, requires mDNS to traverse the boundary between your main HA network and your IoT VLAN. If you’ve already set up mDNS reflection — via Avahi on OpenWrt, or using the mDNS setting in pfSense/OPNsense — it works for both hubs equally.
Where the M3 adds complexity is Thread. Thread uses link-local IPv6 and does not cross VLAN boundaries by design. If you’re running your HA instance on a different Layer 2 segment from the M3, Thread device communication will not reach HA without explicit border router forwarding configuration. Practically, this means the M3 is somewhat easier to operate when HA and the hub are on the same network segment. If you’re running a strict IoT VLAN with no Layer 2 adjacency to HA, the Thread stack on the M3 requires more network configuration to use correctly than the M2 does. Our Aqara and Xiaomi IoT VLAN guide for Home Assistant covers the firewall rule specifics if you need them.
Neither hub is “simpler” for segmented network users. They require different configuration, with the M3’s Thread stack adding a step that M2 users don’t face.
Hardware Differences That Matter for HA Users
Both hubs support Zigbee 3.0 and Wi-Fi 2.4GHz. Beyond that, the hardware diverges in ways that are relevant depending on your setup.
Ethernet (M2) vs PoE (M3). The M2 has an RJ45 Ethernet port for a wired connection, but it draws power separately over its own power port — Ethernet carries data only. The M3 supports Power over Ethernet: a single PoE cable provides both power and network. If you’re installing the hub in a location without a nearby power outlet but near a PoE switch, the M3’s PoE is a meaningful quality-of-life advantage. If you’re placing it near both a switch and a power outlet, it’s irrelevant.
Thread Border Router (M3 only). The M3 can act as a Thread Border Router, which is useful if you have or plan to have Thread-native devices. Aqara’s own Thread-native devices can communicate directly without going through a Zigbee coordinator. In a Home Assistant setup, Thread support means those devices can commission into the HA Matter integration more directly. If your device inventory is all Zigbee and you have no Thread devices, this feature is irrelevant to your decision.
CPU and RAM (M3 faster). The M3 has a faster processor and more RAM than the M2. For small to medium device counts — say, under 50 devices — this doesn’t make a practical difference in HA. For larger installations (80+ devices, complex local automations running on the hub), the M3’s headroom matters. Most home setups will never push the M2 to its limits, but it’s worth knowing if you’re planning to scale.
Protocol support summary:
| Feature | M2 | M3 |
|---|---|---|
| Zigbee 3.0 | Yes (up to 128 devices) | Yes (up to 127 Zigbee/Thread devices) |
| Wi-Fi | 2.4GHz | 2.4GHz + 5GHz |
| Ethernet | RJ45 (separate power) | PoE |
| Thread | No | Yes (Border Router) |
| Matter | Bridge (fw 4.0.0+, limited) | Yes (primary integration) |
| IR blaster | Yes (not HA-accessible) | Yes (not HA-accessible) |
Known Bugs and Limitations
M3: HA reboot triggers Matter device rediscovery
This is the most impactful active issue for M3 users. When the M3 hub or Home Assistant restarts, devices paired through the Matter integration go through a rediscovery process and the hub reappears as a newly discovered accessory. During this process — which can take several minutes — affected devices are unavailable in HA. The behavior is tracked in HA core as issue #128105 and was not resolved as of the last information available to me.
For automations that need to survive HA restarts cleanly, this is a real operational problem. HomeKit Controller devices (the other half of the dual-stack) are not affected — they reconnect quickly after a restart. So in dual-stack mode, your Matter-paired devices have this gap while your HomeKit Controller-paired devices don’t.
M2: IR blaster inaccessible from HA
As noted above, the IR blaster is completely invisible to Home Assistant via any integration path. If you bought an M2 partly for IR control and expected to drive it from HA, that’s not possible today.
Both hubs: initial cloud provisioning required
Both hubs require a one-time cloud setup through the Aqara Home app before local control paths become available. You need to create an Aqara account, connect the hub to your Wi-Fi, and let it provision. After that initial step, HomeKit Controller and Matter operate locally and you can firewall off Aqara’s cloud endpoints if you choose. Our explainer on whether Aqara works without internet covers exactly what persists as a cloud dependency after setup.
This is a minor but worth-knowing limitation for anyone expecting a fully cloud-free out-of-box experience.
Price and Availability
The M2 is the older model and typically sells for less — around USD 30–35, occasionally lower on AliExpress. The M3 is newer and priced roughly USD 55–65 depending on region.
Pricing varies by region. AU and UK pricing follows a similar ratio. Check current prices at time of purchase — the gap between models fluctuates.
Decision Matrix
Choose the M2 if:
- You want the most tested, least-complex integration path in Home Assistant (HomeKit Controller)
- Your device count is under 80 and you don’t need Thread
- You have no PoE switch and prefer a simple Ethernet-plus-power setup
- You’re comfortable with a single integration rather than dual-stack complexity
- Budget matters and the M3 premium isn’t justified by your specific needs
Choose the M3 if:
- You have or plan to have Thread-native devices and want a Thread Border Router
- You’re in a location where PoE is convenient and a power outlet isn’t nearby
- You have a large device inventory and want the extra CPU/RAM headroom
- You’re comfortable running dual-stack (Matter + HomeKit Controller) and willing to accept the HA reboot rediscovery issue until it’s fixed upstream
- You want to future-proof against Matter becoming the dominant protocol
Choose neither — go USB Zigbee coordinator instead:
If your priority is purely local control of Aqara/Xiaomi Zigbee devices in HA, and you don’t need the hub’s HomeKit or Matter bridge functionality, a USB Zigbee coordinator (a Sonoff Zigbee 3.0 USB Dongle Plus is the most commonly recommended option) paired with Zigbee2MQTT gives you more direct control with no hub dependency. Your HA instance talks directly to the coordinator. No cloud provisioning, no mDNS discovery, no integration path complexity.
The tradeoff: you lose the hub’s Zigbee mesh extension (hubs extend the mesh as routers), and you can’t use Aqara’s proprietary features like the M3’s Zigbee-to-Thread bridging for Aqara Thread devices. But for a typical Aqara sensor and switch setup, the USB coordinator path is often cleaner. Our guide to running Aqara Zigbee devices in Home Assistant without a hub covers it end to end.
Verdict
If you’re setting up a Home Assistant instance today and you want the most reliable, least-surprising integration experience, the M2 via HomeKit Controller is the more mature choice. The integration path is well-understood, entity coverage is solid, and there are no active bugs that affect day-to-day reliability in the way the M3’s Matter rediscovery issue does.
The M3 is the right call if you have a concrete reason to need it: Thread devices in your inventory, PoE deployment, or a large enough device count that the hardware headroom matters. Going M3 without one of those reasons means taking on dual-stack complexity and the reboot rediscovery issue for no tangible benefit in a typical HA setup.
If you’re upgrading from an M2 you already have, the upgrade case for M3 is weak unless you’re specifically adding Thread devices. The HomeKit Controller path on the M2 is stable, and “newer hardware” isn’t a reason to re-pair 50+ devices and rebuild your dual-stack configuration.
For readers who decide against both hubs, the USB coordinator path in our hub-free Aqara Zigbee guide is worth reading before you commit.
Frequently Asked Questions
Can I use the Aqara Hub M2 or M3 with Home Assistant without the cloud after initial setup?
Yes, for both hubs. Initial provisioning requires the Aqara Home app and a cloud connection. After that, HomeKit Controller (M2 and M3) and Matter (M3) operate locally. You can block Aqara’s cloud endpoints in your firewall after setup completes — the local integration paths continue to function. Some features like OTA firmware updates still require cloud access.
What’s the difference between Matter and HomeKit Controller integration in Home Assistant?
HomeKit Controller is an older, well-established HA integration. Matter is newer and still maturing. For Aqara hubs, HomeKit Controller consistently exposes more entity types than Matter alone. Matter adds some device types (particularly smart locks) that HomeKit Controller handles differently. Running both simultaneously on the M3 (dual-stack) gives the widest coverage.
Does the M3’s Thread Border Router capability help me in a Home Assistant setup?
Only if you have Thread-native devices. Aqara is releasing Thread-native devices (like the FP300), and Thread devices from other vendors can commission through the M3’s border router. If your entire inventory is Zigbee, the Thread Border Router does nothing for your current setup.
Should I use Matter or HomeKit Controller for Aqara in Home Assistant?
For the M2: HomeKit Controller only. The Matter bridge on the M2 exposes fewer entities. For the M3: dual-stack (both Matter and HomeKit Controller) gives the widest coverage. Matter-only on the M3 leaves significant entity gaps.
If I already have an M2, is it worth upgrading to M3 specifically for Home Assistant?
Probably not, unless you have a concrete need for Thread, PoE, or are hitting performance limits with a very large device count. The M2’s HomeKit Controller integration is stable and has no known reliability bugs comparable to the M3’s Matter reboot issue. The M3 is not a strict upgrade for HA users — it’s a different integration with different tradeoffs.