If you’ve pulled your Aqara or Xiaomi Zigbee devices out of the vendor app and onto Zigbee2MQTT or ZHA, one worry tends to surface a few weeks in. Are these devices still getting firmware updates, or did leaving the cloud also mean leaving updates behind?
The short answer is that the app is out of the loop for already-supported devices, but updates aren’t fully hands-off either. Zigbee2MQTT checks for new firmware on its own and flags when one is available; installing it is a deliberate action you trigger, not something it applies for you in the background. No vendor app, account, or login is involved in that path. A smaller set of newer or less common devices need a one-time manual step that does briefly involve the app. And at least one current device, the Aqara FP300, doesn’t get Zigbee2MQTT OTA support at all, so its firmware has to go through the Aqara app every time.
This piece focuses on the documented Zigbee2MQTT mechanism specifically, since that’s what the sourced material actually covers. ZHA has its own separate OTA-update mechanism and firmware index that these sources don’t get into — worth its own look if you’re on ZHA rather than Zigbee2MQTT. If you haven’t settled on a platform yet, ZHA vs Zigbee2MQTT for Aqara devices covers the broader tradeoffs.
How Zigbee2MQTT handles firmware updates without an app
By default, Zigbee2MQTT pulls firmware images from the Koenkk/zigbee-OTA repository, a community-maintained index of firmware files for supported devices. Devices that support OTA are checked against that index on a schedule set by the update_check_interval setting (once a day, out of the box), and Zigbee2MQTT flags any device that has newer firmware available. What it does not do is install that firmware on its own. By design, when a device asks whether an update exists, Zigbee2MQTT answers NO_IMAGE_AVAILABLE until you explicitly request the update — so an OTA only ever runs when you tell it to, never silently in the background. None of this needs a vendor app, a vendor account, or an Aqara Home or Mi Home login for anything already in that index.
Zigbee2MQTT checks for available firmware on its own once a day by default and flags what it finds — but it never installs an update automatically. The check is hands-off; the install is a deliberate step you trigger. An update showing as “available” is a notification, not something already applied.
To actually apply an update, you trigger it by hand — over MQTT, or from the device’s update entity in Home Assistant. The same manual check is useful when you don’t want to wait for the daily scan, or you’re confirming a device took an update correctly.
Topic: zigbee2mqtt/bridge/request/device/ota_update/check
Payload: {"id": "0x00158d0001a2b3c4"}
Topic: zigbee2mqtt/bridge/request/device/ota_update/update
Payload: {"id": "0x00158d0001a2b3c4"}
Replace the id with your device’s friendly name or IEEE address. An update itself typically takes somewhere between 10 and 100 minutes, with progress published to MQTT roughly every 30 seconds so you can watch it move.
The device reboots at the end of an OTA update to load the new firmware. Depending on that device’s power-on default, the reboot can briefly flip a plug or switch’s output state. Don’t run an update on a load you can’t have blink off for a few seconds.
Devices not yet in the index: what “manual extraction” actually means
Some newer or less common Aqara and Xiaomi Zigbee devices aren’t in the standard OTA index yet. For those, Zigbee2MQTT documents a manual process for obtaining the firmware URL yourself. It involves running a mitmproxy intercept between an Android emulator (with the vendor app installed) and the internet, then triggering a firmware check inside the app so the OTA URL shows up in the intercepted traffic.
This does still require the vendor app, at least temporarily, and only for that specific device. It’s a contributor-facing process built for people comfortable setting up an emulator and a proxy, not a step most readers will ever need to run themselves. In practice, once someone in the community has extracted a given model’s URL and it’s been added to the shared index, everyone else’s Zigbee2MQTT can see and install that device’s updates the normal way from then on — the same check-and-trigger path as any other indexed device. How reliably those one-off extractions actually get contributed back into the shared index — rather than staying as private knowledge on one person’s setup — isn’t something the sources here establish, so treat the “someone will add it eventually” assumption as best-effort community behavior, not a guarantee.
Worth knowing: the Xiaomi/Aqara side of this extraction method is documented as working with devices natively paired to an Aqara gateway and compatible with the Aqara Home app. It isn’t confirmed across every Mi/Mijia ecosystem gateway model, so treat that as a documented limitation of the method rather than a rule about which devices need it.
The FP300 exception: when the app is still required
At least one current Aqara device sits outside this whole system. The Aqara FP300 presence sensor doesn’t support OTA updates through Zigbee2MQTT at all, based on the sources gathered for this piece. Firmware updates for it have to go through the Aqara app, full stop, and that isn’t a one-time step the way the manual extraction process is for other devices. Our FP300 + Home Assistant guide covers the FP300 setup in more detail if you’re running one.
That’s a specific finding about the FP300, not a pattern across the wider FP-series or any other model family. Nothing in the sources here supports extending it further, so don’t assume a sibling sensor behaves the same way without checking.
| Tier | What it means | App needed? |
|---|---|---|
| Already in the OTA index | Zigbee2MQTT checks automatically and flags updates; you trigger the install (one action, no app) | No, never |
| Not yet indexed (mostly newer SKUs) | Firmware URL captured once via the documented mitmproxy/emulator extraction process | Yes, briefly, for that one extraction |
| Aqara FP300 | No Zigbee2MQTT OTA support found in the sources checked | Yes, ongoing, every update |
What actually happens if you skip a firmware update
For devices in the first tier, nothing forces the issue. There’s no vendor push notification nagging you, no cloud dashboard flagging it red, because there’s no cloud account attached to the device at all anymore. Zigbee2MQTT quietly checks once a day and flags what it finds, but it waits for you to press go — so if you never act on the update log, most devices will just keep working on whatever firmware they shipped with.
I think that’s actually the right default for a local-first setup, not a gap. It puts the decision in your hands instead of a vendor’s release calendar, and most of these firmware updates fix minor bugs rather than anything urgent enough to chase.
Practical caveats before you trigger one
A few things are worth knowing before you go update-happy across a mesh full of devices.
- Zigbee2MQTT can’t back up a device’s current firmware version before updating, so there’s no built-in way to revert if something goes wrong.
- Some devices reject downgrading to an older firmware version even though the Zigbee spec technically allows it.
- A post-update re-interview can reset custom reporting intervals back to the device’s defaults, which is easy to miss if you tuned those settings for battery life or responsiveness.
None of these are Aqara/Xiaomi-specific. They’re general Zigbee2MQTT OTA behavior worth knowing about regardless of brand.
FAQ
Do I lose firmware updates if I remove Aqara/Xiaomi devices from the vendor app?
Not for devices already in Zigbee2MQTT’s OTA index. It keeps checking for their firmware and lets you install it with no app involved — you just trigger the update yourself instead of waiting on a vendor’s app to do it. The exceptions are devices not yet indexed (a brief, one-time app step) and the FP300 (ongoing app dependency).
How do I check if a Zigbee2MQTT firmware update is available for my Aqara device?
Send an MQTT request to zigbee2mqtt/bridge/request/device/ota_update/check with the device’s ID, or just wait for the daily automatic check, which flags any device with newer firmware waiting. Either way, a flagged update still needs you to trigger the install.
Does the Aqara FP300 get firmware updates through Zigbee2MQTT?
No, not based on the sources checked for this piece. FP300 firmware updates go through the Aqara app.
Is it safe to update Aqara/Xiaomi Zigbee device firmware through Home Assistant?
The mechanism itself is the same one Zigbee2MQTT uses regardless of front end. The real caveats are practical. There’s no rollback if an update goes wrong, a reboot can briefly change a switch’s output state, and reporting intervals may reset and need re-tuning afterward.
Do I need the Aqara or Mi Home app installed for any reason once I’m on Zigbee2MQTT?
Generally no, for devices Zigbee2MQTT already knows how to update. Does Aqara work without internet? and why Mijia app outages don’t touch local setups both cover the wider pattern of what stays functional without the vendor cloud. The app resurfaces only for not-yet-indexed devices during that one-time extraction, and for the FP300 on an ongoing basis.
What this actually verifies, and what to check on your own setup
This is a research-synthesis piece, built from Zigbee2MQTT’s own OTA documentation, its separate advanced doc on the Tuya/Xiaomi URL-extraction process, and one independent blog specifically documenting the FP300’s app-only requirement. It isn’t a bench test of every Aqara or Xiaomi device against the OTA index.
The no-app path is verified and real: for devices already in the index, Zigbee2MQTT handles the check and the install itself, with no vendor app or account anywhere in the loop — you just have to trigger the install, since it won’t run one on its own. A vendor app is still needed for the one-time extraction process on not-yet-indexed devices, and for every update on the FP300. What stays open is whether ZHA’s OTA handling behaves the same way — its firmware index and update flow are a separate question these sources don’t cover — along with whether manually-extracted device entries reliably make their way into the shared index for everyone else.
The fastest way to check your own setup is to look up your specific device on Zigbee2MQTT’s supported-devices list and see whether OTA is marked as supported. That single line tells you which tier you’re in faster than any general rule of thumb here will.