Removing and re-pairing devices without leaving ghosts

Why order matters#

A device does not have one relationship with your smart home. It has one per controller, and each is stored in two places: on the device, and in the controller.

Removing the device from an app deletes the controller's half. Only a properly delivered removal command deletes the device's half. When the two get out of step, you get a ghost: a controller showing a device that is gone, or a device carrying credentials for a controller that no longer exists.

For Matter, the device's half lives in the fabric table, and the specification only requires five entries. SupportedFabrics has a minimum of 5 and a maximum of 254, and constrained hardware really does ship with 5. Apple Home consumes two of them, because it synchronizes accessories through iCloud Keychain, which needs a second fabric. Removing a device in a controller's interface does not reliably send the remove-fabric command, so orphaned slots accumulate.

The symptom arrives later and looks unrelated. You try to add the device to one more ecosystem, pairing appears to progress normally, and the final credential step returns a table-full status that your app reports as pairing failed with no cause. Sharing a Matter device across ecosystems covers the slot arithmetic in full.

The clean removal, in order#

1. Write down what the device does

   Before anything, list the automations, scenes, groups and voice names that reference it. Re-pairing usually creates a new identity, so every one of these will need to be rebuilt. This step is the difference between a ten minute job and a week of noticing broken rules.

2. Remove it from every secondary ecosystem

   Start with the platforms you shared it to, not the one that commissioned it. In each app, remove the device normally: Apple Home, accessory settings, remove. Google Home, device, remove. SmartThings, device, delete. Alexa, device settings, delete. Home Assistant, the Matter device page, delete.

   Each removal should send a remove-fabric command for that controller's own fabric. Watch for the device staying online and responsive in the other apps, which is what success looks like.

3. Verify the fabric list if you can

   Home Assistant ships a "manage fabrics" interface for Matter devices precisely because the automatic path is unreliable. Open it and read the list. Entries you do not recognize are orphans, two Apple entries are normal for one Apple household, and an entry for an ecosystem you already removed means the removal did not deliver.

   RemoveFabric is not fabric-scoped, which means an administrator on one fabric may evict another fabric's entry. That is what makes cleanup possible at all. Almost no consumer app exposes the button, so Home Assistant is the practical repair tool even if you never use it for anything else.

4. Remove it from the primary controller last

   Now remove it from the ecosystem that originally commissioned it. Doing this first is the classic mistake: the other fabrics remain on the device, but you have lost the controller that could most easily have coordinated their removal.

5. Factory reset the device

   Follow the vendor's reset procedure, which is usually a long press or a power cycle sequence. A factory reset clears the fabric table completely, which is the only reliable way to reclaim orphaned slots. The device returns to advertising as commissionable, and a factory-new device with no fabrics may advertise for up to 48 hours.

6. Confirm it is really gone

   Check every app again. A tile that survives removal is a controller-side leftover and can usually be deleted directly. If a device still appears after a factory reset, you are looking at a stale entry, not a live device.

7. Re-pair, then rebuild

   Commission it into your primary ecosystem, following the normal commissioning flow, then share it out with multi-admin rather than commissioning it separately in each app, which spends slots for no benefit. Then rebuild the automations from the list you made in step one, and give it the same name it had before, following your naming conventions.

Zigbee: send a leave request, do not just delete#

Zigbee removal is a message, not a database delete. The coordinator sends a leave request, the device drops the network key, and the entry is cleared on both sides.

The failure mode is a device that is offline, out of range, or has a dead battery when you remove it. Your coordinator forgets it, the device never got the message, and it still holds valid credentials. Power it back on and it may rejoin unannounced, appearing as an unknown node, or sit there consuming a child slot on its parent.

Practical rules:

• Remove the device while it is powered and in range, then reset it separately if the vendor provides a reset.
• If a device was removed while offline, factory reset it before you try to pair it anywhere else.
• Removing a mains-powered router affects its children. Zigbee end devices attach to a single parent, so the sensors that were using it go quiet until they find a new one on their own sleepy schedule.
• Green Power devices need a proxy and do not appear in network scans, so do not read their absence as a removal.

Zigbee in 2026 covers the coordinator and router structure this sits on.

Z-Wave: exclusion is a protocol operation#

Z-Wave is the strictest of the three, and also the most forgiving if you follow it. A device is included into a network and must be excluded from it. Exclusion clears the device's stored network information and its node ID.

Put your controller into exclusion mode and trigger the device's exclusion sequence, which is usually the same button press used for inclusion. A device that has been excluded is ready to join any network, including the one it just left.

Two properties worth knowing. Z-Wave controllers can generally perform an exclusion on a device even if that device was never included into their own network, which is the standard way to reset a second-hand or previously-owned device. And a node that never responded to exclusion can be marked failed and removed from the controller's list, which cleans up your side but leaves the device itself still believing it belongs somewhere.

After removing or moving any mains-powered node, run your controller's heal or rebuild routes function. Classic mesh allows up to 4 hops and stores calculated routes, so devices that were routing through the node you removed will keep trying the old path until routes are rebuilt. Z-Wave Long Range is exempt, because it is a star topology with no repeaters at all. Z-Wave and Z-Wave Long Range has the rest.

Why the device came back as a new accessory#

This is the most common complaint after a successful re-pair, and it is structural rather than a bug.

Bridges expose devices as endpoints under an aggregator, and endpoint numbers are not reused when a bridge removes and re-adds a device. Your controller sees an endpoint number it has never seen before, so it creates a new accessory. The old one becomes a dead tile, and every automation, scene, room assignment and voice name attached to the old identity stays attached to the old identity.

Nothing in the standard fixes this for you. Plan for it: re-pairing a bridged device is a rebuild, not a repair. It is one more reason to fix the actual cause of a problem rather than reaching for a re-pair, since most unresponsive devices are network problems that survive re-pairing untouched. Matter bridges and what you lose through one has the wider list of what a bridge does not carry across.

Special cases#

Retiring a hub. Remove devices from the hub before you reset or sell it. A hub reset with devices still attached leaves every one of those devices holding a fabric or network entry for a controller that no longer exists. Switching platforms without rebuying has the migration order.

Moving out or in. Reset in the right order, and reset devices you are leaving behind so the next occupant can pair them. Devices you are taking need the same clean removal before they leave the house. Moving out and moving in covers the sequence for both directions.

Second-hand devices. A device that was never excluded or reset by its previous owner will refuse to pair, because its code is consumed and its credentials belong to somebody else. Z-Wave exclusion from your own controller usually clears this. For Matter, a factory reset is the only path, and you need the physical reset procedure for that model.

Devices that will not reset. Some products hide the reset behind an unusual sequence, and some bridged sub-devices have no reset of their own. In those cases the bridge is the only place to remove them.