private@homelab: ~/latest
local-first guides · privacy-aware · no noisy tracking
lightdark
private@homelab:~$ cat guides/article.md
·
·
6–9 minutes
read

Zigbee2MQTT Ghost Device 0x0000000000000000: How to Fix It

Zigbee2MQTT shows a phantom device at 0x0000000000000000 that keeps rejoining after removal. What it means and the fixes that actually clear it.

Zigbee2MQTT Ghost Device 0x0000000000000000: How to Fix It

You open the Zigbee2MQTT frontend and there’s a device you don’t recognize. It’s usually labeled with an IEEE address of 0x0000000000000000, sometimes with no friendly name at all. You didn’t pair it. You try to remove it. It either fails with no explanation, or it vanishes for a while and comes back. If you’re dealing with this right now, you’re not imagining it and you haven’t been compromised. It’s a known, recurring pattern that’s been reported against Zigbee2MQTT for years, across multiple versions, and there’s a real (if slightly ugly) fix.

I cross-referenced this against five separate GitHub issues spanning several years of Zigbee2MQTT releases to figure out what’s actually going on, since the official docs only acknowledge it in passing.

What “Ghost Device 0x0000000000000000” Actually Means

The all-zero IEEE address isn’t a real device identity. It’s what shows up in the Zigbee2MQTT log — something like “Starting interview of ‘0x0000000000000000′” — when the coordinator radio itself is generating a spurious join attempt, rather than an actual end device or router requesting to join your mesh.

The most consistent explanation across the reports is that this traces back to the coordinator adapter, not anything wrong with your paired devices. Reports centered on CC253x-based coordinator sticks describe the same address showing up repeatedly, tied to a hardware or firmware quirk in that adapter generation rather than anything in your network configuration [source: GitHub issue #6661].

The official Zigbee2MQTT FAQ acknowledges the behavior directly: if a device joins with 0x0000000000000000 as its IEEE address, it says, your CC253X adapter might be broken. It frames this as an adapter-level fault rather than a defect in Zigbee2MQTT’s own code. That’s a useful data point if you’re worried this is a sign Zigbee2MQTT itself is broken. It isn’t. Your coordinator hardware is talking to itself, in effect, and the software is faithfully reporting what it sees.

Why It Won’t Go Away After You Remove It

This is the part that trips people up. You remove the ghost device, the list looks clean, and then a few hours or days later it’s back. The standard removal path frequently doesn’t actually do anything to a ghost entry. Reports describe zigbee2mqtt/bridge/request/device/remove, the force_remove option, and the plain remove config directive all completing without error and without any visible effect on the underlying issue [source: GitHub issue #17720].

Because there’s no error in the log, it looks like the removal worked. What’s actually happening is the coordinator keeps generating the same spurious join attempt, so the entry keeps reappearing regardless of how many times you clear it out of the device list.

Trying the Standard Removal Path First

It’s still worth doing the normal removal before assuming you’re stuck with the deeper fixes below. It’s a lot less disruptive if it happens to work for your setup.

  • From the frontend, select the ghost device and remove it.
  • Alternatively, publish to zigbee2mqtt/bridge/request/device/remove with the device’s IEEE address as the payload.
  • If neither sticks and the entry reappears within a day or two, treat that as confirmation you’re dealing with the recurring adapter-level version of this, not a one-off.

Worth knowing: a ghost device sitting in the list doesn’t appear to interfere with your real devices’ pairing or automations. It’s a nuisance entry, not something actively degrading your mesh, at least based on what’s reported across these threads.

What Actually Clears It: Power-Cycle, Reflash, or Replace

If the standard removal doesn’t stick, the Zigbee2MQTT FAQ gives a documented escalation path for a misbehaving CC253X coordinator. None of it is timing-critical — you’re not trying to catch the radio mid-interview, you’re resetting the adapter cleanly:

  • Clean power-cycle of the coordinator. Stop Zigbee2MQTT, unplug the coordinator, wait about ten seconds, plug it back in, start Zigbee2MQTT again, and try pairing your real device. Because Zigbee2MQTT is stopped while the stick is unpowered, this is a full reset of the adapter rather than a restart of the software around it.
  • Reflash the coordinator firmware. The FAQ notes reflashing the coordinator does not require re-pairing devices that are already on your network, which makes it a relatively low-risk step. A corrupt or aging firmware image on a CC253x stick is a plausible source of the spurious join, and a clean flash rules it out.
  • Nuclear option, only if you’re switching adapters anyway. Removing data/coordinator_backup.json and data/database.db forces Zigbee2MQTT to rebuild from scratch — which does clear the ghost, but also erases your network and requires re-pairing every device. This is a last resort, not a routine fix.

Be honest with yourself about what these buy you. On a genuinely marginal CC253x stick, a power-cycle or reflash is a stopgap: it can clear the current occurrence, but if the hardware is failing, the ghost tends to come back. That’s the signal to stop patching and look at the coordinator itself.

Root Cause: Is Your Coordinator Adapter to Blame?

The pattern isn’t a single-release regression. The same underlying issue has been reported against separate Zigbee2MQTT and hassio-zigbee2mqtt versions across several different years, tracked in at least five distinct GitHub issues (#6661, #9116, #17720, #30816, and hassio-zigbee2mqtt #584) [source: GitHub issues #30816, hassio-zigbee2mqtt #584]. That spread is the strongest evidence this is an adapter-class quirk rather than something a point release broke and another point release will quietly fix.

Some of the threads go further and tie recurrence specifically to aging or marginal coordinator hardware. They recommend a firmware update, or replacing the coordinator entirely, as the fix that actually holds, rather than repeating a power-cycle every time the ghost reappears [source: GitHub issue #6661].

When the Real Fix Is Replacing Your Coordinator

If the ghost device keeps coming back on a schedule — weekly, say, or every time you restart Zigbee2MQTT — that’s the signal to stop treating this as a one-time annoyance and start treating it as a hardware question. The reports point toward CC253x-based sticks specifically as the common thread. Moving to a modern EmberZNet (EFR32) or current-generation Z-Stack (CC2652) coordinator is the fix multiple threads describe as durable, versus one that needs repeating. If you’re weighing which chipset to move to, the trade-offs between the two common Sonoff sticks — the EmberZNet-based ZBDongle-E and the Z-Stack ZBDongle-P — are worth understanding before you buy, since they behave differently under Zigbee2MQTT.

If you’re also dealing with USB port reliability or want to move your coordinator off a USB hub and onto Ethernet, that’s a separate but related upgrade path worth reading about before you buy a replacement — see our SMLIGHT SLZB-06 Zigbee2MQTT-over-Ethernet setup guide.

The more useful signal here isn’t the ghost device itself. It’s that a legacy CC253x coordinator can degrade in ways that surface as strange, self-generated join attempts the software can only report, not suppress — which is part of why coordinator choice matters more than most setup guides give it credit for. If you’re still deciding how to run your Zigbee network in the first place, our comparison of ZHA and Zigbee2MQTT for Aqara devices covers the platform side of that decision.

FAQ

What does IEEE address 0x0000000000000000 mean in Zigbee2MQTT?
It’s not a real paired device’s address. It shows up when the coordinator adapter itself generates a spurious join attempt, most often reported on CC253x-based coordinator hardware. The Zigbee2MQTT FAQ describes it as a sign your CC253X adapter might be broken.

Why does a ghost device keep coming back after I remove it?
Because the standard removal commands (remove, force_remove, bridge/request/device/remove) frequently don’t stop the coordinator from generating the same join attempt again. The list looks clean immediately after, then the entry reappears.

Does a ghost device affect my real Zigbee devices or automations?
Based on the reports, no — it doesn’t appear to interfere with existing paired devices or automations. It’s an annoyance in the device list, not a functional problem for your working devices.

Can I permanently stop ghost devices from rejoining my network?
A clean coordinator power-cycle or a firmware reflash can clear a given occurrence. Whether it stays gone depends on whether the underlying adapter issue recurs — some users report it comes back, which is the sign you’re looking at a hardware question, not a one-time fluke.

Is a recurring ghost device a sign my coordinator is failing?
It can be. Several threads tie repeat occurrences to aging or marginal CC253x-based coordinator hardware and recommend a firmware update or hardware replacement as the fix that actually holds. The FAQ pins the behavior specifically on CC253X adapters; there are no comparable reports tying it to current-generation EmberZNet or Z-Stack coordinators, though that may reflect their newer and smaller install base as much as any proven immunity.

If you’ve replaced a CC253x stick and the ghost device never came back, that’s a data point worth more than another year of GitHub comments — but nobody’s tracked outcomes that systematically yet. Until someone does, treat the power-cycle and reflash as stopgaps, and the coordinator swap as the fix you reach for once it’s clearly recurring rather than a one-off.

local-firstHome Assistantno-cloud