The M3 is Aqara’s first hub with a real local automation engine. The M2 came before it and still gets sold beside it, often at half the price. If you’re weighing the Aqara M2 vs M3 for a privacy-focused setup, the spec sheet comparison misses the point. The question is: what actually breaks when the internet goes down — and what can you run behind a firewall?
This article answers that directly. No padding, no hedging. We’ll cover each hub’s local control story, how they behave in Home Assistant, and what happens when you block their cloud access at the router.
Disclosure: Some links in this article may be affiliate links. We may earn a small commission at no extra cost to you.
Why this comparison matters right now
The Aqara Hub M3 launched globally in late May 2024, positioning itself as an “Edge Hub” — a term Aqara uses to signal on-device automation processing. At the same time, M2 units remain in wide circulation, often available refurbished or on clearance for significantly less.
For most buyers, the comparison starts and ends at price. For privacy-focused buyers, it starts at “what does local control actually mean here?” Those two buyers need different information, and most comparisons give everyone the first kind.
The price delta between M2 and M3 is real. Whether it’s worth it depends entirely on how much you rely on automations during cloud outages and how hard a firewall stance you want to take.
Protocol stack side-by-side
Both hubs run Zigbee 3.0 as their primary device protocol. Both include an IR blaster. That’s where the overlap ends.
| Feature | Hub M2 | Hub M3 |
|---|---|---|
| Zigbee | 3.0 | 3.0 |
| Thread | No | Yes (controller) |
| Matter | No | Yes (controller/bridge) |
| IR blaster | Yes | Yes |
| PoE | No | Yes (802.3af/802.3at — 48V/0.27A ≈13W) |
| Local storage | None | 8 GB eMMC |
| Local automation engine | No | Yes (Edge Hub mode) |
| Ethernet | Yes | Yes |
Thread and Matter on the M3 aren’t just checkboxes. Matter as a controller means the M3 can manage Matter-native devices locally — without routing through any cloud. For Zigbee-only setups, this doesn’t matter yet. As more devices ship with Matter support natively (or via Thread), it starts to matter a lot.
The PoE option on the M3 is worth noting for deployment flexibility — no power brick, mounted high near the ceiling where Zigbee mesh coverage is better. The M3 draws 48V at 0.27A (≈13W), which falls within the 802.3af limit of 15.4W. It’s compatible with both 802.3af and 802.3at switches; a standard 802.3af port is sufficient.
Local control: what the M2 actually does
The M2 is a cloud-assisted hub with local passthrough. That’s the honest description.
What runs locally:
- Zigbee device commands issued from the Aqara app when the phone and hub are on the same LAN
- IR commands triggered from within the app on local network
- HomeKit automations when controlled via a HomeKit home hub (HomePod, Apple TV, iPad always-home)
What requires cloud:
- All Aqara automations (scenes, triggers, schedules) — these are processed server-side
- Third-party integrations (Alexa, Google Home)
- Remote access
- Firmware updates
When your ISP goes down, or Aqara’s servers have an outage, every automation in the Aqara app stops working. Your Zigbee devices remain paired to the hub; you can still control them manually from the app if you’re on the same network. But scheduled lights, motion-triggered automations, thermostat rules — all of it pauses until the cloud comes back.
This isn’t unusual for this class of hub. It’s how most consumer Zigbee hubs worked before local processing became a realistic option. The M2 is a 2020-era design. Calling it cloud-dependent isn’t a criticism — it’s a description.
For Home Assistant users who migrate their Zigbee devices off the Aqara hub entirely (using a dedicated Zigbee coordinator like the SkyConnect or Sonoff Zigbee 3.0 USB Dongle Plus), the M2’s cloud dependency becomes irrelevant. The hub is sidelined. More on this in the Home Assistant section.
Local control: M3’s Edge Hub architecture
The M3’s “Edge Hub” label refers to a specific set of capabilities enabled by its 8 GB eMMC storage and an on-device automation engine. Automations are compiled and executed on the hub itself, not on Aqara’s servers.
What this means in practice:
- Schedules and triggers continue running during internet outages
- Device state is persisted locally — the hub doesn’t need to phone home to know a door sensor is open
- The Aqara app on your local network can still read and write device state without cloud relay
Local automation has been available since the M3’s global launch (May 2024) — it was a core design goal, not a feature added later. To activate it, go to Profile → Settings → Edge Mode in the Aqara app and confirm it’s enabled. Without that toggle on, the hub defaults to cloud-relayed automation even when capable of running locally.
The 8 GB eMMC isn’t just for automation rules. Aqara uses it for local storage of camera footage from compatible cameras, device event logs, and the offline device state database. For a hub with no cameras attached, 8 GB is overkill for automation rules alone — this is clearly designed for a fuller local ecosystem.
What Edge Hub mode doesn’t solve:
- Aqara app remote access still requires cloud relay — if you’re away from home, you need Aqara’s servers
- Firmware OTA updates require cloud connectivity (see “Blocking cloud access” section below)
- Third-party voice assistants (Alexa, Google) still route through cloud
If you’re building a setup where the Aqara app is your primary interface and you just want outage resilience, the M3 delivers that. If you want to block all Aqara cloud access entirely, you trade away remote access and OTA updates — which is a separate calculation.
Home Assistant integration paths
Both hubs integrate with Home Assistant via the HomeKit Controller integration. This uses Apple’s HomeKit Accessory Protocol (HAP) over your local network — no cloud involvement once paired.
HomeKit Controller method:
- 1. In Aqara app, expose the hub as a HomeKit accessory
- 2. In Home Assistant → Settings → Devices & Services → Add Integration → HomeKit Controller
- 3. Enter the pairing code from the Aqara app or hub label
- 4. Devices appear in HA as HomeKit entities
The M3’s HomeKit Controller integration works, but it’s rougher than the M2. Known issues reported across the HA community and Aqara forums: the hub may re-appear as a newly discovered device after every reboot; not all Zigbee child devices are fully exposed (missing sensors such as lux, pressure, or power consumption are common complaints); pairing code entry occasionally fails outright. Workaround that has helped multiple users: pair the M3 to Apple HomeKit first, remove it from HA’s HomeKit integration, restart HA, then re-add it — this often stabilises the connection. Using Matter instead of HomeKit Controller for the M3 is an alternative, though Matter’s entity coverage has its own gaps (IR blaster and some advanced sensor attributes are not exposed via Matter 1.x).
The HomeKit Controller path exposes your Aqara-paired Zigbee devices to Home Assistant as HomeKit entities. The underlying control is local: HA sends HAP commands to the hub, hub talks Zigbee to the device. No cloud.
Limitation: entity types are constrained by what HomeKit exposes. Complex Aqara sensor attributes (some Aqara FP2 presence zone data, for example) may not appear through the HomeKit layer. For full attribute access, you need either a direct Zigbee coordinator or a future native Aqara integration that exposes the local API directly.
Zigbee coordinator method (bypassing the hub):
For users who want maximum control and don’t care about using the Aqara app at all:
- 1. Flash a Zigbee coordinator (SkyConnect, Sonoff Zigbee 3.0 Dongle Plus, ConBee II)
- 2. Use ZHA or Zigbee2MQTT in Home Assistant
- 3. Re-pair your Aqara devices directly to the coordinator, bypassing the hub
This gives you full device attribute access, no Aqara app dependency, and a fully local stack. The hub becomes irrelevant. Most Aqara Zigbee devices pair cleanly to ZHA or Zigbee2MQTT — the Aqara FP2, T1 motion sensors, door/window contacts, and cube controllers all have solid support.
If your goal is a Home Assistant-centric setup with no Aqara app involvement, the Zigbee coordinator path makes the M2 vs M3 comparison mostly moot. You’re not using the hub’s intelligence at all.
The M3 becomes interesting in a HA context when you want to use the hub’s local automation engine alongside HA, or when you’re adding Thread/Matter devices that benefit from the M3 as a Thread Border Router.
For more on building out an Aqara sensor ecosystem in Home Assistant, see our guide on the Aqara FP2 in Home Assistant.
Blocking cloud access: M2 vs M3 behavior
What actually happens when you add *.aqara.com to your router’s blocklist?
M2 with cloud blocked:
- Aqara app: connects locally, can control devices on LAN, but remote access broken
- Automations: stop firing. No error message — they just don’t execute
- HomeKit: continues working normally (HAP is local)
- Home Assistant (HomeKit Controller): continues working normally
- Firmware updates: blocked
M3 with cloud blocked:
- Aqara app: connects locally, can control devices on LAN, remote access broken
- Automations: continue firing (Edge Hub processes locally)
- HomeKit: continues working normally
- Home Assistant (HomeKit Controller): continues working normally
- Matter local: continues working (Matter local network binding doesn’t require cloud)
- Firmware updates: blocked — permanently, until you unblock
The practical difference is in automations. With the M3, you can build your Aqara app scenes and rules, block the cloud, and they still run. The hub is your local automation controller. With the M2, blocking the cloud means blocking your automations.
On OTA updates with the M3: there is no official local firmware flashing path. Blocking *.aqara.com means staying on whatever firmware version is installed until you temporarily lift the block. An unofficial custom firmware project (available on GitHub) enables Telnet access and more, but it voids the warranty and carries bricking risk — not a recommended route for production deployments. The pragmatic approach is to unblock for the duration of an update, then re-block.
One nuance: some users report that prolonged cloud disconnection on certain hub firmware versions triggers a health check loop that causes the Aqara app to show the hub as “offline” even when it’s reachable locally. If you’re running a hard block, test this before committing to it in production.
Migration: moving devices from M2 to M3
Aqara has a migration tool in the app. The flow:
- 1. Open Aqara app → Hub M2 → More → Migrate Hub
- 2. Select the M3 as the target
- 3. The tool migrates paired devices, automations, and scenes
Known limitations and gotchas:
- The migration tool requires internet access during the migration process — you can’t migrate offline
- Device firmware updates may be triggered post-migration; allow time for this
- Some complex automations (especially multi-condition rules built in older app versions) may need to be rebuilt manually
- IR device codes are stored in the app, not the hub — these migrate cleanly as long as you’re using the same Aqara account
- If you’re using the M2 as a Zigbee coordinator through a third-party integration, migration doesn’t apply — you’re re-pairing devices to the new hub from scratch
The migration tool works well enough for straightforward setups. If you have 50+ devices and complex scenes, budget an afternoon and expect to manually verify a few rules.
Price vs. value verdict
Current street prices (as of publish): Hub M3 runs ~$120–$140 USD on Amazon; S$209 in Singapore. Hub M2 runs ~$60 USD; street price in SGD typically S$79–$99 depending on retailer. The M3 is roughly 2× the M2’s price.
Hub M2 — buy it if:
- Budget is the hard constraint
- You’re using Home Assistant with a dedicated Zigbee coordinator (the hub’s local limitations become irrelevant)
- Your automation logic lives in HA, not in the Aqara app
- You don’t have PoE infrastructure and don’t plan Thread/Matter devices
Hub M3 — buy it if:
- You want Aqara app automations to survive internet outages
- You’re building a mixed Zigbee + Thread/Matter device ecosystem
- You want a single hub to act as local automation controller without Home Assistant in the loop
- PoE deployment makes sense for your layout
- You’re comfortable paying the premium for genuine local-first operation
For a privacy-first buyer who relies on the Aqara app as the primary interface, the M3’s Edge Hub mode is the meaningful upgrade. For a Home Assistant user running Zigbee2MQTT or ZHA on dedicated hardware, the M2 is a capable gateway for HomeKit bridging and costs less.
The M3’s “Edge Hub” marketing is accurate — it does what it says. The M2’s local control story is narrower than the marketing implies.
Conclusion
The M2 is a reliable Zigbee hub that needs the cloud to run your automations. The M3 is a hub that can operate independently of the cloud for most daily functions. That’s the core difference, and it’s a meaningful one if outage resilience or network-level cloud blocking is part of your setup.
If you’re on a budget and running Home Assistant with your own Zigbee coordinator, an M2 makes sense. If you want the Aqara ecosystem to function autonomously on your LAN — automations firing, app working, no cloud dependency for core operation — the M3 earns its price.
FAQ
Does the Aqara Hub M3 work without internet?
For local control: yes. Automations run on-device, devices respond to app commands on the local network, and HomeKit control works normally. What stops working: remote access from outside your home, Alexa/Google integrations, and firmware OTA updates.
Can I use the Aqara app locally with either hub?
Yes for both, with caveats. The Aqara app discovers the hub on your local network and communicates directly when you’re on the same subnet. On the M2, app-triggered device control works locally, but automations still require cloud. On the M3, app control and automation management are both local once Edge Mode is active (Profile → Settings → Edge Mode in the Aqara app).
Does Matter on the M3 require cloud?
No. Matter is designed as a local protocol. When you pair a Matter device to the M3, the binding is local — the M3 acts as a Matter controller on your LAN. No cloud relay is involved for local control. Remote access via Matter still requires a Matter controller that has cloud relay capability (like Apple Home or Google Home), but local operation is fully offline.
Should I migrate my M2 to M3?
Only if you actively need what the M3 adds: local automation resilience, Thread/Matter support, or PoE deployment. If your current M2 setup works with Home Assistant via HomeKit Controller and you’re not relying on Aqara automations, the migration adds cost without changing your day-to-day experience.
Can I use the M3 as a Zigbee coordinator in Home Assistant instead of a USB dongle?
Not directly through ZHA or Zigbee2MQTT in the way a USB coordinator works. The M3 doesn’t expose a raw Zigbee serial interface to Home Assistant. You use it via the HomeKit Controller integration (or Matter), which provides local control but through a protocol translation layer. For full Zigbee coordinator functionality — including Zigbee2MQTT with complete device attribute access — a dedicated USB coordinator is still the right tool.
