Zigbee2MQTT gives you two buttons for pulling a device off your network, Remove and Force Remove, plus the option of walking over to the hardware and factory-resetting it directly. They sound like escalating versions of the same action. They aren’t. Each one touches a different piece of state, and picking the wrong one is why a “removed” device sometimes keeps showing up, or why a sensor you gave away can still technically talk to your old network months later.
This is about the case where a device is a known, working member of your Zigbee2MQTT network and you’re intentionally decommissioning, replacing, or handing it off. If you’re instead looking at an orphaned entry with no clean device record, that’s a different failure mode covered in our ghost and phantom device troubleshooting guide. Everything below happens on your local coordinator and MQTT broker. Nothing here depends on a cloud service.
The three commands, and what each one touches
Remove asks the device itself to leave the network gracefully. Zigbee2MQTT sends it a leave request over the air, the device processes that request and clears its own stored network key, and only then does Z2M drop it from its database. That round trip is the whole point. Remove needs the device to be awake and responsive before it can complete.
Force Remove skips that conversation entirely. It deletes the device’s entry from Zigbee2MQTT’s own database, full stop. It does not touch anything on the physical device. The device’s radio still holds the network encryption key it was given when it joined, because nobody asked it to forget. Force Remove is a Z2M-side bookkeeping operation, not a network-security operation.
A physical factory reset is the only one of the three that acts on the device directly regardless of whether Zigbee2MQTT is even involved. Held-button sequences, pinhole resets, or app-based resets (where the manufacturer’s own app still works) clear the device’s stored credentials from the hardware itself. The procedure isn’t standardized. It varies by manufacturer and sometimes by generation within the same product line, and it doesn’t always succeed on damaged or bricked hardware.
These three names apply whether you trigger them from the Zigbee2MQTT frontend or by publishing directly to the bridge’s MQTT request topics. There’s a related, separate concept called Ban, which blocklists a device’s IEEE address from rejoining at all. That’s a different problem than the one this article covers.
Both Remove and Force Remove can be triggered from the frontend UI, or by publishing to the bridge’s device-removal request topic over MQTT:
# Remove — asks the device to leave gracefully
mosquitto_pub -h 192.168.10.20 -t zigbee2mqtt/bridge/request/device/remove -m '{"id": "sensor_hallway"}'
# Force Remove — deletes the Z2M-side record only
mosquitto_pub -h 192.168.10.20 -t zigbee2mqtt/bridge/request/device/remove -m '{"id": "sensor_hallway", "force": true}'
The broker address and topic root above are representative. The payload takes an id key (the device’s IEEE address or friendly name) plus an optional force boolean that defaults to false — that’s the current bridge/request/device/remove schema. Older Zigbee2MQTT releases exposed this through a different bridge/config/force_remove topic, so if you’re scripting against an older install, confirm the exact topic and keys against your installed version’s own MQTT reference page. And if you’re exposing the bridge request topics over MQTT at all, lock the broker down first — our MQTT broker security checklist covers that.
Why Remove fails silently on battery-powered devices
This is the single most common source of confusion around device removal, and it isn’t a bug. Remove needs the device awake to receive and acknowledge the leave request. Mains-powered gear (plugs, in-wall switches, most routers) is listening more or less continuously, so Remove usually completes in a second or two.
Battery-powered end devices, the door sensors, motion sensors, and buttons that make up most of a typical Aqara or Xiaomi Zigbee setup, sleep almost all the time to save power. They only wake briefly to report a state change or respond to a poll. If you click Remove while the device happens to be asleep, Zigbee2MQTT’s request just sits there with nothing to answer it. Nothing errors out. The device doesn’t come back off sleep in time to answer, and it stays in the device list looking exactly like it did before you clicked anything.
That’s the mechanism behind “I removed it but it’s still there.” It isn’t specific to one brand or one Z2M release. Support threads on both the Zigbee2MQTT GitHub discussions and the Home Assistant Community forum show the same pattern recurring across different hardware and different versions. Someone reports a device won’t leave, and the resolution is almost always “use Force Remove instead, since the graceful path needs the device awake.”
The security gap Force Remove leaves open
Force Remove solves the immediate annoyance. It does not solve the underlying problem, and that distinction matters more than the UI suggests.
Force Remove deletes the device from Zigbee2MQTT’s database, but it does not clear the network key stored on the device’s own radio. Until you separately factory-reset the physical hardware, it still technically holds the credentials to your network. This matters if the device is about to leave your possession, not just your device list.
Think through what that means for a device you’re selling, gifting, or sending back under warranty. You Force Remove it, the entry disappears from your dashboard, and the transaction feels complete. But the chip inside the device hasn’t forgotten anything. It’s no longer paired (Zigbee2MQTT isn’t listening for it anymore), but the stored key doesn’t evaporate on its own. In practice the realistic risk here is narrow, since the buyer would need the same coordinator and channel to do anything with a lingering key, not a remote attack surface. But “narrow risk” and “no risk” aren’t the same claim, and for hardware leaving your control entirely, closing it properly costs one extra minute.
I think Zigbee2MQTT’s UI undersells this. Force Remove and Remove sit next to each other as two buttons of similar visual weight, and nothing in that layout signals that one of them leaves a credential behind on the hardware. A one-line note next to the button would prevent a lot of the “is this safe before I sell it” confusion that shows up in community threads.
When a physical factory reset is the only option
A physical factory reset is the one method that works regardless of whether the device is awake, asleep, or already deleted from Zigbee2MQTT’s database, because it doesn’t depend on Zigbee2MQTT at all. It acts directly on the hardware.
Three situations call for it. The device won’t respond to Remove and you don’t want to leave a stale key on it, so you do Force Remove for the database cleanup and then physically reset the hardware to close the security gap above. The device is changing hands. Or you’re troubleshooting something misbehaving badly enough that a clean credential wipe is worth trying before you give up on it.
It’s also not guaranteed to work identically across your device collection. The button-hold sequence, the number of presses, and even whether a factory reset is exposed at all varies by manufacturer and product generation. Some devices only expose a reset path through their original manufacturer app, which is awkward if the whole point of your setup is running local-only. If you’re preparing secondhand hardware for a first pairing rather than decommissioning something you already own, that’s the inverse scenario covered in our guide to resetting secondhand devices with Touchlink before pairing.
Decommissioning correctly: keeping it vs. giving it away
If the device is staying in your household (moving rooms, swapping automations, or just retiring from a role) a plain Remove is fine, and Force Remove if it doesn’t respond because it’s asleep. The device won’t be re-paired to anyone else’s network, so a lingering key on hardware you still physically control isn’t a meaningful exposure.
If the device is leaving your possession (sold, gifted, returned, or discarded) treat Force Remove as step one, not the finish line. Force Remove it from Zigbee2MQTT to clean up your own database, then follow through with a physical factory reset on the hardware itself before it leaves your hands. That two-step sequence is the only combination that both clears your side and clears the device’s own memory of your network.
Quick-reference: which command for which situation
| Situation | Command | Clears network key on device? |
|---|---|---|
| Mains-powered device, staying in your home | Remove | Yes, as part of the graceful leave |
| Battery device asleep, staying in your home | Force Remove | No, but device stays in your possession |
| Any device being sold, gifted, or returned | Force Remove, then physical factory reset | Only after the physical reset step |
| Device unresponsive, troubleshooting a stuck join | Physical factory reset (works regardless of Z2M state) | Yes |
FAQ
Why does Zigbee2MQTT say a device was removed but it still shows up? Almost always a Remove attempt on a battery device that was asleep when the leave request went out. It didn’t get a chance to acknowledge and complete the process. Use Force Remove, then physically reset the hardware if you also want the stored key gone.
Is Force Remove safe to use on a device I’m about to give away or sell? It’s safe for cleaning up your own Zigbee2MQTT database, but it isn’t sufficient on its own. The device retains your network key until it’s physically factory-reset. Do both before it leaves your hands.
Do I need to factory reset a device before re-pairing it to a different network? Generally yes, if the device previously joined a network and wasn’t gracefully removed. A stored key from a prior network can prevent a clean join elsewhere. Our guide to Touchlink resets before pairing covers this from the receiving end.
What’s the difference between removing a device and banning it? Removal and banning solve different problems. Remove and Force Remove take a device out of your current device list. Ban prevents a specific IEEE address from rejoining your network at all, which is a blocklisting concept, not a removal one.
Why won’t my battery sensor let me remove it normally? Because it’s asleep most of the time by design, to conserve battery, and Remove needs it awake to respond. This is normal behavior for the device class, not a fault with that specific unit.
What this covers, and what to check yourself
This article synthesizes Zigbee2MQTT’s own FAQ and MQTT topic reference alongside recurring patterns from GitHub discussions and Home Assistant Community threads describing the same “force-removed but still listed” confusion. The mechanism described (Remove requiring an awake device, Force Remove being database-only, physical reset acting on the hardware directly) comes straight from those official sources, not from hands-on testing on this site’s own devices.
What stays local. All three removal paths described here happen entirely between your coordinator, your MQTT broker, and the device’s own radio. None of them touch a vendor cloud service.
What depends on device behavior you should verify yourself. The exact factory-reset procedure (button sequence, hold duration, whether it’s exposed at all) is manufacturer- and generation-specific. Check your specific device’s documentation or its Zigbee2MQTT device page before relying on a reset procedure you’ve seen for a different model. And if you’re scripting the MQTT commands shown above rather than using the frontend, confirm the current payload schema against your installed Z2M version’s own reference page, since request topic formats have shifted before across major releases.
If Zigbee2MQTT ever adds a single combined “release and reset” workflow that chains Force Remove with a request for the device to wipe its own key before confirming, that would close the gap this article spends most of its length explaining. Nothing in the current documentation suggests that’s planned, but it would remove an entire category of “is this actually safe” questions at once.