Xiaomi Home HA Integration: Cloud vs Local — What Data Does It Send?

If you run Home Assistant and own Xiaomi or Aqara devices, you’ve probably noticed that Xiaomi’s official integration — ha_xiaomi_home — landed in December 2024 and rapidly became the recommended path, replacing the long-running community alternative hass-xiaomi-miot for many users. The setup flow is clean, the state updates are fast, and Xiaomi’s official involvement feels reassuring after years of unofficial API scraping.

Before committing to it, though, it’s worth understanding exactly what you’re agreeing to. The integration works. But “works” and “works locally” are not the same thing, and the gap between them matters if you’re running Home Assistant specifically to get your smart home off vendor clouds.

I’ve been through the documentation, the official README, and the Chinese-language community discussions (少数派 (Sspai), V2EX, and 知乎 (Zhihu)) where the first-mover users have already surfaced the edge cases. Here’s what the integration actually does with your data.

What the official Xiaomi Home integration actually is

ha_xiaomi_home is the integration Xiaomi open-sourced in December 2024. It connects Home Assistant to your Xiaomi and Aqara devices via an OAuth 2.0 login — you authenticate with your Xiaomi account directly in HA’s UI, and the integration takes it from there. Xiaomi documents the behavior in the integration’s official README, which is worth reading alongside this article.

The OAuth flow is cleaner than what hass-xiaomi-miot required. You’re not fishing for tokens manually or reverse-engineering API calls. Xiaomi’s own team maintains the code, which means it keeps pace with their device ecosystem without waiting for community updates.

That said, “official” doesn’t mean “local-first.” This is where the confusion starts.

Cloud control is the default — for most users, it’s the only mode

For the majority of users running ha_xiaomi_home, every device control command follows this path: Home Assistant → Xiaomi’s 米家云 (MiHome cloud) → device. You’re not routing locally. HA is a cloud-control interface.

This catches people off guard because the integration runs on their local HA instance. The software is local. The data path is not.

The cloud dependency goes further than just commands. The integration maintains a persistent MQTT subscription to Xiaomi’s cloud — not a polling connection that fires every 30 seconds, but an open, continuous channel. Chinese community users on Sspai noted this as the integration’s key technical improvement over hass-xiaomi-miot: motion triggers and state changes arrive nearly instantly because Xiaomi pushes them to HA over that MQTT subscription in real time. What that also means: Xiaomi receives all device state events continuously, not only when you issue a command. The connection is always open.

If you’re blocking Xiaomi’s cloud endpoints at the firewall to reduce telemetry, you lose device control entirely in the default configuration.

Bluetooth Mesh (蓝牙Mesh) and Zigbee devices without a hub are cloud-only. There’s no local path for them regardless of what other settings you configure. Bluetooth, infrared, and virtual device categories also have no local support option.

The bulk import: you bring in everything

On first setup, the integration queries all device properties from Xiaomi’s cloud and imports every device in your selected household. There’s no per-device selection at this stage — it’s all or nothing.

For most users this is convenient. If you have a mixed household though — say, smart home devices you care about alongside some Xiaomi appliances you don’t want managed through HA — you’re importing all of them. The integration doesn’t give you a device checklist during setup.

This also means your full device inventory gets enumerated and pulled from Xiaomi’s cloud in one shot during configuration. Not a disaster, but worth knowing if you were hoping to limit the integration’s visibility into your household.

The plaintext token problem

After OAuth login, the integration stores user information — device details, certificates, and your OAuth tokens — in Home Assistant’s configuration file in plaintext (明文存储, plaintext storage).

Xiaomi’s own README is explicit about this risk: it warns that if your Home Assistant configuration file is exposed, someone else can log in with your identity. That’s not me editorializing — Xiaomi’s own documentation flags the issue.

In practice, this means a few things to think through. If your HA instance is accessible from outside your local network — even behind a VPN, but especially if you’re using Nabu Casa or port-forwarding — the risk profile of a compromised account expands. Anyone who can read your HA config directory can extract a working token for your Xiaomi account. And your Xiaomi account likely has more attached to it than just your smart home devices.

If you suspect a token has been compromised, revocation is available through the Xiaomi account management interface: Xiaomi Home App → Profile → Apps → Xiaomi Home → Remove. That kills the OAuth session. You’ll need to re-authenticate in HA afterward.

Token revocation being possible is good. The plaintext storage situation requiring you to think about it in the first place is less good.

LAN control mode — partial local, not true local

The integration does have a LAN control mode (局域网控制, LAN control). It controls Wi-Fi and Ethernet-connected IP devices on the same network segment as your HA instance without routing through Xiaomi’s cloud. For those devices, it’s a genuine improvement.

The scope is narrower than it sounds. Zigbee devices and Bluetooth Mesh devices are excluded from LAN control regardless — they can only be reached via cloud or a hub. And Xiaomi’s own documentation describes LAN mode as unstable and advises against relying on it for production setups. That caution comes from the integration’s own README, not from third-party testing.

So LAN control exists, it works for a subset of devices, and Xiaomi itself isn’t confident enough in it to recommend it. That’s a complicated endorsement.

True local mode — China-only hardware required

True local control — where commands don’t touch Xiaomi’s cloud at all — requires a 小米中枢网关 (Xiaomi Central Hub Gateway) running firmware version 3.3.0_0023 or above, or a device with a built-in hub function on software version 0.8.9 or later.

The Xiaomi Central Hub Gateway is only officially available in mainland China (仅在中国大陆地区可用). If you’re not in China, you cannot buy this device through normal channels.

There’s a complication for the subset of readers who imported one. A discussion on GitHub Issues has confirmed that the Central Hub Gateway can achieve local control when deployed outside mainland China — but the gateway itself still connects to Xiaomi’s mainland China cloud servers for initial setup and device synchronization. You get local control for ongoing operation, but setup requires the cloud handshake, and that handshake goes to Chinese servers regardless of your geographic location.

For anyone outside mainland China who doesn’t have this hardware, true local mode through ha_xiaomi_home is not currently achievable. If you want the full picture on what local control does and doesn’t get you abroad, our explainer on Xiaomi Home Assistant local control outside China goes deeper.

Regional cloud data isolation

The integration supports six regional cloud endpoints: mainland China, Europe, India, Russia, Singapore, and the USA. Devices registered in one region’s endpoint cannot be controlled from another region’s endpoint in HA.

This matters practically for users who bought Chinese-market Xiaomi or Aqara devices and are now based outside China. The devices were registered to the mainland China cloud. When they try to configure HA with a Singapore or Europe endpoint, their devices don’t appear. The fix requires re-registering devices to a different regional account, which isn’t always clean.

知乎 (Zhihu) users surfaced this as a recurring pain point, particularly for SE Asia-based users with China-sourced hardware.

How this compares to the alternatives

The natural comparison for ha_xiaomi_home is hass-xiaomi-miot, the community integration it largely replaced. On privacy, they’re at the same baseline: both use Xiaomi’s MIoT API, both require cloud connectivity for non-hub setups. The main difference is technical — ha_xiaomi_home uses MQTT push for state updates, hass-xiaomi-miot uses polling. Privacy exposure is comparable.

The more meaningful alternatives for users who want genuine local control:

Zigbee2MQTT or ZHA with an Aqara hub removes Xiaomi’s cloud from the equation for Zigbee devices entirely. Aqara hubs paired directly with Zigbee2MQTT don’t send device state to any cloud — traffic is local. This is the path I’d recommend for anyone whose device fleet is primarily Zigbee. Our Aqara Hub M2 local-control guide walks through that setup without any Xiaomi cloud dependency.

The XiaomiGateway3 component achieves local control for Multimode Gateway users via LAN access. It’s not officially sanctioned by Xiaomi but has a solid track record, covered in our Xiaomi Multimode Gateway local integration guide.

Neither of these paths serves users with Wi-Fi-only Xiaomi devices (smart plugs, vacuums, etc.). For those, the cloud dependency is harder to avoid without alternative firmware.

Who should actually install it

The integration is genuinely good at what it does. The question is whether what it does is what you want.

It makes sense for you if:

• You’re in mainland China and have or plan to get the Xiaomi Central Hub Gateway. True local mode is accessible, and the integration is well-maintained.
• You’re a convenience-first user with Xiaomi Wi-Fi devices who accepts cloud dependency and wants reliable, fast automations.
• You’re using it for appliances or device categories where there’s no realistic local alternative anyway.

It’s a harder fit if:

• You’re running HA specifically to reduce cloud exposure. The default mode is cloud-dependent, and the LAN mode Xiaomi itself calls unstable.
• Your HA config file is exposed to any external network. The plaintext token storage is a real risk in that scenario.
• Your device fleet is mainly Zigbee sensors and switches. Zigbee2MQTT with a local hub is the cleaner path.

The middle path that some users in the Chinese community have landed on: create a dedicated secondary Xiaomi account for HA integration only. This limits the blast radius if the token is ever exposed — the secondary account holds only the devices you want in HA, not your primary Xiaomi account with its full device history and account details. It also makes revocation cleaner. It’s not a privacy solution, but it’s a risk-reduction step.

If you’re primarily concerned about Zigbee devices and local control, the Aqara M2 or M3 hub paired with Home Assistant’s Aqara integration — without ha_xiaomi_home — gets you there without any of the cloud dependencies described here.