Mi Home Local Execution vs Cloud Execution Explained

Pull the WAN cable on your router and watch what happens to your Mi Home automations. Some keep firing like nothing happened. Others just stop, with no error and no notification. If you’ve noticed this and assumed it was random, it isn’t. Every automation in Mi Home runs in one of two modes, and which one it gets is decided by a fairly specific set of rules that the app never shows you.

I went looking for this after a scene of mine quietly failed during an outage last year — one I’d built assuming it would work offline, because the devices involved were all local-capable Zigbee sensors. It didn’t, and figuring out why meant digging through Mi Home power-user discussion rather than anything in the app’s own help text. Here’s what I found, and how to check your own scenes against it.

What “execution mode” actually means

Xiaomi calls this 执行方式 (execution method), and it describes the path a command takes between the device that triggers an automation and the device that carries it out. If that signal has to leave your home and round-trip through Xiaomi’s servers, that’s 云端执行 (cloud execution). If it never leaves your gateway or LAN, that’s 本地执行 (local execution).

The distinction matters because it’s per-scene, not per-device. Two automations using the exact same sensor and the exact same gateway can end up in different modes, because the rules apply to the whole chain, not any single link in it.

What quietly forces cloud execution

Four conditions account for most silent fallbacks to cloud mode. Any one of them is enough on its own.

A gateway that can’t run local logic

Local execution is compute-heavy on the hub side, and only specific gateway hardware is capable of it. Xiaomi names two: the 中枢网关 (Central Hub Gateway, the current-generation Mi Home hub) and the 多模网关2 (Multi-mode Gateway 2). Cheaper bundled gateways, including the one built into a Xiao AI speaker and sold as a bonus with it, don’t have the processing headroom for local execution. A scene running through one of these falls back to cloud mode regardless of what else is in it.

One unsupported device anywhere in the chain

Every device involved in an automation — sensor, gateway, and executor — has to individually support local execution for the whole scene to qualify. Mix in a single device or gateway that doesn’t, and the entire automation drops to cloud mode. There’s no partial credit. This is the part that trips people up most, because it’s easy to assume a scene is safe just because most of its components are modern and local-capable.

Any condition that needs an internet lookup

Weather conditions are the clearest example. “If it’s raining, don’t open the curtains” always forces cloud execution, because there’s no local weather source in the home. The moment a scene needs a fact that only exists online, cloud mode is unavoidable, no matter how capable the rest of the hardware is.

This turned out to be exactly what killed my scene. The trigger sensor and the curtain motor were both fine for local execution on their own. The rain condition wasn’t, and it silently pulled the whole automation into cloud mode without telling me.

Voice triggers, always

Anything you kick off by talking to 小爱同学 (Xiao AI) runs through the cloud, full stop, even on a Central Hub Gateway with every other device in the chain qualifying for local execution. Voice recognition itself needs an internet round-trip to Xiaomi’s speech service before the command ever reaches your devices. There’s no local speech model doing this on-device.

Two more that are easy to miss

Beyond the big four, a couple of quieter triggers can push a scene to the cloud even when everything above looks fine. Wi-Fi-based devices in a scene often run through the cloud rather than the local mesh. And a scene that gets enabled or disabled by another automation typically flips to cloud mode after that first cross-scene control, even if it started life as a local scene. The English-side reference on all of this — mi-home.pro’s LAN-vs-cloud writeup — documents both, and they’re easy to overlook because nothing in the app announces the switch.

Which gateways can actually do this

If offline resilience matters to you, the gateway is the first thing to check, since it gates everything downstream:

• Supports local execution: Central Hub Gateway (中枢网关), Multi-mode Gateway 2 (多模网关2)
• Does not support it: bundled/entry-level gateways, including the one packaged with Xiao AI speakers

Xiaomi has never published a single authoritative list of which individual sensors and actuators count as local-execution-capable beyond the gateway tier, so there’s no lookup table to check a specific model against. In practice that leaves per-scene testing — covered below — as the only reliable way to confirm a given chain qualifies.

One more current-as-of-2026 check: community discussion around Xiaomi’s January 2026 Central Hub Gateway firmware update kept referencing the same local-versus-cloud distinction described here — a reasonable signal the underlying behavior hasn’t quietly changed under newer firmware.

I think Xiaomi’s decision to auto-select execution mode per scene, with no visible toggle or indicator showing which mode a saved automation is actually running in, is the wrong tradeoff for something this consequential. A one-line status next to each scene would cost them almost nothing, and would have saved me the outage surprise entirely.

Auditing your own scenes for offline resilience

Mi Home won’t tell you which mode a scene is in, and it can silently flip a previously-local scene to cloud mode later if a condition changes, so a periodic check is worth building into habit rather than doing once. For each scene you actually care about surviving an outage:

• Confirm every device in the chain, including the gateway, is on the supported list above
• Remove or isolate any condition that requires an online lookup, weather being the obvious one
• Don’t build critical offline scenes around Xiao AI voice triggers
• Keep Wi-Fi devices and cross-scene toggles out of anything meant to survive an outage
• Recheck after adding or swapping any device in an existing scene, since one substitution can silently change the mode

If you’re not sure how your gateway tier and its sub-gateways fit together, our breakdown of Mi Home’s gateway, sub-gateway, and blind-gateway roles maps out which hubs sit where in the local-automation chain.

If you’re comparing this against how Home Assistant handles the same problem, the short version is that HA doesn’t have this cloud/local split at all for locally-integrated devices, because there’s no Xiaomi cloud round-trip to begin with. We watched exactly that play out during a real Mijia cloud outage, and whether Aqara’s ecosystem behaves the same way offline is worth a look if you’re weighing brands rather than staying on stock Mi Home.

Xiaomi hasn’t said anything about adding a visible mode indicator, and there’s no roadmap signal either way. Until that changes, the only reliable check is auditing your scenes by hand against the rules above — and doing it again any time you touch a scene’s devices or conditions.