Smartmi Humidifier 2 in Home Assistant: Local, No Cloud
The Smartmi/Xiaomi humidifier line is one of the few devices in this cluster that isn’t Zigbee at all. It’s a Wi-Fi device speaking Xiaomi’s miIO protocol directly, which changes what “local” even means here. There’s no hub, no Zigbee2MQTT, no pairing dance with a coordinator. Just the humidifier, your LAN, and a 32-character token that the Mi Home app never shows you.
Which humidifier do you actually have
Xiaomi and Smartmi have shipped several generations under names that all sound similar, and the model identifier is what actually matters for setup, not the box art:
- zhimi.humidifier.ca1 — the CN-market Smartmi Humidifier 2
- zhimi.humidifier.cb1 — the same generation, EU-market variant
- zhimi.humidifier.ca4 — the Evaporative Humidifier 2 (different tank/wick mechanism, different entity set)
- zhimi.humidifier.ca6 — the newer Evaporative Humidifier 3, which needed dedicated community work to get supported at all
That last point is worth sitting with. The Evaporative Humidifier 3 wasn’t automatically covered when it launched. It can be misdetected as an older model, or configured manually as a ca4, but several of its modes and features don’t map cleanly that way. Working support arrived through community effort instead — a development branch of the underlying python-miio library, and the third-party hass-xiaomi-miot integration — rather than landing in Home Assistant’s built-in xiaomi_miio on day one. The takeaway: the model ID genuinely determines what works, and a new Xiaomi/Smartmi humidifier SKU isn’t guaranteed built-in support just because older ones in the same line already work.
If you’re not sure which model you have, check the label on the base or the device entry in the Mi Home app before you do anything else. Guessing the model ID during setup is a common way to end up with an integration that half-works.
What “local” means for this device
Home Assistant’s built-in xiaomi_miio integration lists its IoT class as Local Polling. In practice that means Home Assistant talks to the humidifier directly over your LAN on a schedule, reading and writing state without a round trip through Xiaomi’s servers once it’s configured. That’s a meaningfully different privacy posture than Xiaomi’s supposedly “local” Zigbee gateways, where what “local” actually delivers is more complicated.
It’s also distinct from where your automations run. Whether a Mi Home rule executes on-device or in the cloud is a separate question from whether Home Assistant can poll the device locally — we cover that split in Mi Home local execution vs cloud execution. For the humidifier under xiaomi_miio, the catch isn’t ongoing cloud dependence. It’s the one-time bootstrapping step, which is where most people get stuck.
Getting the device token
To add the humidifier to Home Assistant, xiaomi_miio needs two things beyond the model ID: the device’s LAN IP address and a 32-character hex token generated when the device is provisioned.
The token is where most people get stuck, and it’s a real, documented gotcha rather than a hypothetical one. The Mi Home app never shows the token in any settings screen, and recent app versions no longer keep it in a readable local database the way older ones did. The reliable way to retrieve it is the community “Xiaomi cloud tokens extractor” tool, which logs into your Mi account and lists the tokens for every device attached to it. That means the humidifier does need to be added to your Mi account first — the token lives server-side, tied to your account, not only on the device.
One snag worth flagging: on the newest Mi Home app versions, the extractor’s login can stall on the two-factor step. That’s a known, separately-documented problem with its own workarounds, not a sign you did anything wrong — so if you hit it, treat it as a login-flow issue to solve rather than a dead end.
Worth knowing: this isn’t unique to Xiaomi’s humidifiers. It’s the same pattern across most of Xiaomi’s miIO device family, one more reason to treat “get the token” as step one, not an afterthought, whenever you bring a new Xiaomi Wi-Fi device into a local-first setup.
Setting it up in Home Assistant
Once you have the IP and token, adding the device is a standard integration flow: Settings, Devices & Services, Add Integration, search for Xiaomi Miio, and enter the host and token when prompted. Home Assistant uses the model ID to determine which entities and services to expose, which is why getting that ID right matters.
The built-in integration is configured entirely through this UI flow rather than YAML. If it doesn’t detect your model automatically — or detects it as a different variant — you can supply the model manually in the same flow. If the core integration still won’t drive your specific unit correctly, that’s the point where people move to the community component covered below, which is YAML-configured and tracks a wider list of model quirks.
What you actually get: entities, and the water-level quirk
Once connected, you get the entities you’d expect from a humidifier integration: on/off, mode, and target humidity. Where it gets messy is water level.
Not every model in this family exposes a clean water-level percentage. Some report a raw depth attribute instead, which isn’t directly usable in a dashboard or automation without conversion. Home Assistant Community members have worked around this by building template sensors that translate the raw depth value into something resembling a percentage, but the exact conversion isn’t standardized across models — a template that works for one variant won’t necessarily match another.
If you’re setting a low-water automation (a notification when it’s time to refill), don’t assume the entity you get is already a percentage. Check what the integration actually surfaced for your specific model first.
When the built-in integration isn’t enough
For humidifier and purifier models the built-in xiaomi_miio integration doesn’t fully cover, the community-maintained xiaomi_airpurifier custom component is the fallback most people land on. It’s a separate HACS-installable integration purpose-built for filling gaps the core integration hasn’t caught up to yet, which matters most for newer or less common model variants.
The custom-firmware route, and why it’s a bigger step
There’s also a more invasive option: replacing the device’s stock firmware to cut the cloud dependency at the hardware level, instead of working around it from Home Assistant’s side. In practice this means reflashing the humidifier’s ESP8266 Wi-Fi module with ESPHome — there are community projects written specifically for the ca1, and the approach was documented in some detail in a round of late-2025 write-ups. It’s a meaningfully different commitment: it typically means opening the unit, soldering to the chip’s UART pads, voiding the warranty, and accepting real risk if a flash goes wrong.
I think that trade is rarely worth it for most readers here. The whole reason the token-based xiaomi_miio path works is that Xiaomi already built local polling into the device. Custom firmware solves a cloud-dependency problem you’ve already solved once the token’s extracted. It makes more sense if your goal is removing Xiaomi’s firmware entirely on principle, not if your goal is just keeping this device off the cloud.
FAQ
Does the Smartmi Humidifier 2 work with Home Assistant without the Mi Home app?
Mi Home (or the pairing process it triggers) is how the device gets its Wi-Fi credentials and how its token ends up tied to your account in the first place. After that one-time setup, ongoing control from Home Assistant doesn’t need the app or Xiaomi’s cloud.
How do I get the token if I already added the device to Mi Home?
That’s actually the normal case, not a problem. The token isn’t shown in the app, but the community cloud tokens extractor tool retrieves it from your Mi account after the device is paired. On the latest app versions, watch for the login stalling at the two-factor step — a known snag with its own workarounds.
What’s the difference between ca1, cb1, ca4, and ca6?
ca1 and cb1 are the same Smartmi Humidifier 2 generation, split by region (CN vs EU). ca4 is the Evaporative Humidifier 2, a different mechanism with a different entity set. ca6 is the newer Evaporative Humidifier 3, which needed separate community work to support.
Why doesn’t my humidifier’s water level show correctly in Home Assistant?
Some models expose a raw depth value instead of a ready-to-use percentage. You may need a template sensor to convert it, and the conversion isn’t identical across every model.
Is custom firmware worth it to remove Xiaomi’s cloud dependency entirely?
Only if you want the device itself running non-Xiaomi firmware, not just kept off the cloud in daily use. The standard xiaomi_miio path already gets you local control without that added risk.
Model variant confusion isn’t going away on its own
Xiaomi and Smartmi keep shipping new humidifier generations under names close enough to cause exactly the ca1/ca4/ca6 mix-ups covered here, and each new model ID is a fresh round of “is this one supported yet” for the Home Assistant community to work through. If you’re buying new rather than working with a unit you already own, checking the model ID’s current integration status before purchase will save more time than anything covered in this guide.