Do Aqara/Xiaomi Devices Stop Working When Discontinued?

A reader spots a forum thread claiming Aqara’s Opple wireless button is discontinued, or notices a retailer marking the Hub M1S as a final-sale item with no returns or warranty. The unit already on the wall keeps working exactly as before. The question that follows is a fair one. Does that keep being true, or is a clock quietly running out on it?

That question usually bundles three different things together, and untangling them is most of the answer. A manufacturer discontinuing a model is not the same event as a cloud service shutting down, and neither is the same as a firmware update breaking a device that used to work fine. This piece is about the first one: what actually happens to a device already running locally through Zigbee2MQTT or ZHA when Aqara or Xiaomi stops making it.

Three questions that get conflated into one worry

“Does my device stop working” usually means one of three things, and they have different answers.

• The vendor’s cloud/app shuts down or gets restructured. Already covered on this site. Mijia app outages and why local setups don’t care walks through why an outage doesn’t touch a local Zigbee2MQTT setup at all, since the app was never in the control path.
• A firmware update breaks something that used to work. A distinct and real risk. Zigbee2MQTT issue #29175, opened in October 2025, is titled exactly that: an Aqara E1 curtain driver (ZNCLBL01LM) that stopped working after a firmware upgrade. That’s a vendor-firmware problem, not a discontinuation problem, and it can happen to a device that’s still in active production.
• The manufacturer stops making or selling the model. This is what this article is actually about. It’s a supply and support-lifecycle event on the vendor’s side. It says nothing on its own about whether the unit you already own keeps functioning.

Keeping these three separate matters because the mitigations are different. Cloud shutdown risk is solved by running local in the first place. Firmware regression risk is solved by controlling when and whether you update. Discontinuation risk is solved by understanding who actually maintains device support in a local setup, which is the next section.

How Zigbee2MQTT and ZHA device support actually works

Zigbee2MQTT device support is added and maintained through community pull requests to the zigbee-herdsman-converters repository, organized into per-brand device definition files. The documented workflow works like this. Pair the device, let the framework auto-generate a starting definition, refine it against the device’s actual reported clusters and attributes, submit it as a pull request, and it ships in a future release. Nowhere in that workflow does the original manufacturer need to participate, approve, or even be aware the work happened.

Once a device definition is merged and shipped, it isn’t tied to Aqara or Xiaomi continuing to sell that particular model. This site’s own back catalogue is the concrete version of that claim. The Aqara FP1 presence sensor was superseded in Aqara’s lineup by the FP1E. The Xiaomi WXKG01LM wireless switch is a first-generation product Xiaomi no longer sells. The ZNCLDJ11LM curtain motor predates two later Aqara generations. All three still pair and run through Zigbee2MQTT, with the same documented quirks each guide describes and no new ones that trace to the model leaving the catalogue.

What doesn’t exist is a written promise. No published policy from Zigbee2MQTT or zigbee-herdsman-converters commits the project to keeping a device definition forever, and none turned up in the documentation reviewed for this piece. The project has, in a major release, deliberately removed long-deprecated behaviour from specific device definitions, which is covered in the caveat section below. So what follows is observed practice with a clear structural reason behind it, not a guarantee anyone has signed.

Real examples: an Opple switch and a hub marked “final sale”

Two concrete cases show what discontinuation actually looks like in practice, and neither matches the “stops working” fear.

The Aqara Opple 4/6-button wireless scene switch is reported, in a Home Assistant Community thread, as no longer being manufactured. Worth knowing: that report comes from buyers relaying what AliExpress sellers told them, not from an official Aqara discontinuation announcement. Aqara itself doesn’t appear to have said anything public about it. Either way, the switches already paired keep sending button-press events through Zigbee2MQTT exactly as before. What changes is availability. Replacing a broken unit, or buying a second one to match an existing setup, gets harder over time.

The original Aqara Hub M1S tells a cleaner version of the same story. At least one authorized US retailer, The Smartest House, marks it as a final-sale item with no returns or warranty, while Aqara continues actively selling newer hub generations, including the M1S Gen 2, M2, and M3. Aqara’s model naming convention covers how to tell these generations apart from the model number alone. Hub-level discontinuation like this is a routine part of the product lifecycle, and it’s worth separating from a Zigbee sensor or switch’s own support status, which lives in Zigbee2MQTT or ZHA, not in the hub.

The honest caveat: local-first isn’t total immunity

None of this means a Zigbee2MQTT or ZHA setup is invulnerable to every kind of support erosion. It’s just that the actual failure modes are different from “the manufacturer stopped making it.”

That second case is the one worth reading properly, because it is the closest thing to a counterexample to this whole article. The 2.0.0 breaking-changes list is explicit that everything enabled through the device_options.legacy flag was removed, and it names the affected device definitions individually. Nothing lost Zigbee2MQTT support. What changed is the interface: properties and action names that had carried a deprecation notice for years stopped being published, and anything automated against them broke on upgrade. That is a real maintenance cost of running a community-maintained stack, and it has nothing at all to do with whether Aqara is still selling the device.

The first case, the “suddenly unsupported” one, has a clearer documented history, and its most-cited example involves a GLEDOPTO light controller rather than an Aqara or Xiaomi one. Zigbee2MQTT issue #4134, opened in August 2020 under the title “Support was dropped after update of zigbee2mqtt,” is closed; a later report with the same title, issue #24745, was opened in November 2024 against version 1.40.1. Across that family of reports the recurring cause is identification rather than removal. GLEDOPTO hardware has a long history of reporting a model ID that differs from the number printed on the case, or of varying it depending on which mode the controller is in, so a device stops matching the definition it used to match. No verified case of this pattern hitting an Aqara or Xiaomi device turned up in the research for this piece, so it belongs here as a general Zigbee2MQTT-ecosystem risk rather than something documented against this site’s usual device families.

The E1 curtain driver firmware regression mentioned earlier is a third, genuinely separate risk. That one is a vendor firmware update changing device behaviour for the worse, a different mechanism from either a legacy-option removal or a mislabelled device. Checking and controlling firmware updates without the app covers how to stay in charge of that one directly.

What to actually do if you’re worried about a device’s long-term support

A few practical habits cover most of this risk without requiring constant vigilance.

• Before buying a discontinued or hard-to-find unit secondhand, check its Zigbee2MQTT supported-devices page or ZHA quirk status directly rather than relying on age or scarcity as a signal. A device can be years out of production and still fully supported.
• If a device you already own shows up as unrecognized or partially supported, that’s usually a converter gap rather than an unfixable dead end. The “no converter available” fix covers what to actually do about it.
• Read the breaking-changes notes before a major Zigbee2MQTT version jump, not after. Device definitions survive those upgrades; specific property and action names do not always, and the notes name the devices affected.
• Separate hub concerns from device concerns. A hub’s security patch history is its own question, not a proxy for whether the Zigbee sensors paired to it (via Zigbee2MQTT or ZHA, bypassing the hub’s own firmware entirely) still work. The Aqara hub CVE patch investigation covers that side of things separately.
• Control firmware updates deliberately rather than letting an app apply them automatically. A regression is a firmware event, not a discontinuation event, and it’s the one of the two you can actually delay or refuse.

My own view: this distinction gets undersold nearly everywhere, vendors included. Describing local Zigbee control as future-proof is fair as far as it goes, but the durability comes from an open converter project maintained by the people using the devices, not from the brand on the box. Buyers who don’t know that end up crediting the wrong party, and never learn to check the one thing that actually matters before buying an out-of-production unit.

FAQ

Does my Aqara device stop working if Aqara discontinues it?
No. A unit already paired and running through Zigbee2MQTT or ZHA keeps working after Aqara stops selling that model. Discontinuation affects new-unit availability and warranty support, not the local control path.

What happens to Zigbee2MQTT support when a manufacturer stops making a device?
Nothing changes on its own. Support lives in the community-maintained zigbee-herdsman-converters project, added through pull requests that never required manufacturer involvement in the first place.

Is the Aqara Opple wireless switch discontinued?
Buyers report Aqara resellers describing it as no longer manufactured, based on a Home Assistant Community thread. Aqara has not made an official public statement to that effect, as far as this research found.

Can I still buy replacement Aqara Hub M1S units?
At least one authorized US retailer lists it as final sale with no returns or warranty, while Aqara continues to sell newer hub generations (M1S Gen 2, M2, M3). Availability of the original M1S specifically should be expected to keep shrinking.

Does Home Assistant lose support for old Zigbee devices over time?
Not for the device as a whole, and not because a manufacturer stopped selling it. There is one real qualifier: Zigbee2MQTT’s 2.0 release removed legacy properties and actions that had been marked deprecated for years, including on two Aqara wall switches, so automations written against those old names broke on upgrade. That is a breaking change to an interface, not a device losing support. Cases where a device reports as fully unsupported after an upgrade read as fingerprint-matching problems, and they’re uncommon enough that they shouldn’t be the default expectation.

What this piece verified

This article is a synthesis of official Zigbee2MQTT documentation, the project’s 2.0.0 breaking-changes discussion, GitHub issue history, a Home Assistant Community forum thread, an authorized retailer’s product listing, and this site’s own published device guides. No hardware was tested for this piece, and nothing here should be read as bench-verified.

Two claims were checked specifically, because they are the two easiest to get wrong in either direction. First, whether Zigbee2MQTT or zigbee-herdsman-converters publishes a device-support removal policy: no such statement was found, so this article describes observed practice plus one documented, deliberate removal of legacy device behaviour, not a guarantee. Second, the status of the GLEDOPTO issue used as the ecosystem-pattern example: issue #4134 is closed, and the same symptom recurs in later reports under the same title, which is why it appears here as a recurring pattern rather than a single resolved bug.

What stays local regardless of manufacturer decisions is the pairing and control path through Zigbee2MQTT or ZHA. What still depends on the vendor is new-unit availability, warranty, device firmware, and hub-level security patching.