A device joins the network, the log line ticks forward, and then Zigbee2MQTT reports “Failed to interview” and the pairing stalls. Sometimes it’s more specific: “Interview failed because can not get node descriptor,” or the active-endpoints version of the same message. Either way the device never becomes a usable entity, and restarting the pairing reproduces the same failure.
That’s a different failure stage from the errors this site has already covered. Ghost devices are orphaned entries left after a join goes wrong. “Failed to configure” is a device that interviews fine and fails later, during binding. An interview failure sits between the two — after the radio-level join succeeds, before Zigbee2MQTT knows what the device is.
This is research synthesis from Zigbee2MQTT’s own documentation and several independent GitHub issues, not a bench test. Everything below runs between your coordinator and the device, with no cloud service involved.
What “interview” actually does after a device joins
Joining and interviewing are separate steps, and the terminology blur is most of the confusion. Joining is the Zigbee radio-layer handshake: the device associates with your network and gets a network key. Interviewing happens immediately after — Zigbee2MQTT actively querying the new device to work out what it is.
Specifically, the coordinator asks the device for its node descriptor, its list of active endpoints, and the simple descriptor for each of those endpoints. That sequence is what tells Zigbee2MQTT the device’s manufacturer and model and which endpoints exist to query further (Zigbee2MQTT’s device-support documentation walks through the same sequence from the angle of adding a new device).
Until that exchange finishes, the device isn’t usable. Zigbee2MQTT doesn’t yet know what converter to apply or what to expose to MQTT, which is why a stuck interview feels like the device vanished. It’s still there on the radio. Zigbee2MQTT just never got far enough to do anything with it.
This covers the interview stage specifically — the discovery queries that run right after a join. If your device gets past this and fails later with a different message, see the failed-to-configure explainer linked above.
The two failure messages, and what each one is telling you
Both dominant messages point at the same event: the coordinator sent a discovery query and the device never answered inside the window Zigbee2MQTT allows, not a misconfiguration on the Zigbee2MQTT side (GH #20333). The exact wording has shifted across versions, so don’t expect your log line to match a search result character for character — match on which query failed.
| Message | What was queried | What it usually means |
|---|---|---|
| Interview failed because can not get node descriptor | The device’s basic identity record, requested first in the sequence | The device never answered the very first query at all |
| Interview failed because can not get active endpoints | The list of endpoints the device exposes, requested after the node descriptor succeeds | The device answered the first query, then the sequence broke down — reported for both marginal links and one-off unit faults |
Neither message tells you why the device didn’t answer. No single issue thread explains that, which is why the pattern below is drawn from several.
Why previously-paired devices fail more than brand-new ones
A device that was already on your network, got removed, and is now being paired back fails interview specifically on that re-pair, even though a fresh unit of the identical model interviews cleanly. This has its own history in the tracker: GH #14135 was closed, and GH #20670 was opened in January 2024 explicitly to reopen it.
What makes it a pattern rather than a device quirk is its spread. The reports name hardware from IKEA, Sonoff, illuminize and Ubisys among others, across unrelated device types, and the shape holds every time.
That points away from a hardware fault and toward stale state. Either the coordinator’s database still holds some remnant of the device’s previous membership, or the device’s radio still holds binding or key state from its prior pairing that confuses the fresh exchange. Neither thread pins the mechanism down. What they agree on is the observation: same model, same firmware, different pairing history, different outcome.
Which is why how the device left matters, and why the site’s remove versus force-remove guide is the right companion here. A device that lost power mid-removal, or was force-removed, or was never cleanly removed at all, can retain exactly the kind of stale state that trips this pattern.
Fix 1: force-remove before you try again
If the device has any pairing history on your network at all, even a brief accidental join, clear it from Zigbee2MQTT’s database explicitly before trying again. Every thread above starts from the same place.
# Force-remove a stale entry before re-pairing
mosquitto_pub -h 192.168.10.20 -t zigbee2mqtt/bridge/request/device/remove -m '{"id": "sensor_hallway", "force": true}'
That topic and payload are the current documented form: zigbee2mqtt/bridge/request/device/remove takes an id — either the IEEE address or the friendly name — plus an optional force boolean that defaults to false, per Zigbee2MQTT’s MQTT topics reference. Two caveats matter. A plain remove asks the device to leave and needs it awake to receive that request, which is why it silently does nothing on a sleeping battery sensor. A force remove clears the database entry only: until the device is factory reset, it still holds the network key.
Set expectations honestly, though. In #20670 the reporters describe deleting the device, checking the database files, factory-resetting the hardware and re-pairing, and still hitting the failure. Clearing stale state is the right first move because it’s cheap and eliminates the most common variable, not because it’s a documented cure.
If the device came from a previous owner rather than your own network, the stale state lives on the hardware instead of in your database — a different starting point. Touchlink factory reset covers clearing that first.
Fix 2: pair close to the coordinator, then relocate
Devices stuck in a join, fail, drop, rejoin loop are common enough to have their own threads (GH #21363, closed without a fix). None establishes a single root cause, so treat what follows as reasoning from how the interview works, not a documented diagnosis.
The interview isn’t one exchange. It’s a node-descriptor query, an active-endpoints query, and then a simple-descriptor query per endpoint — several round trips that all have to land in quick succession. A basic join needs far less. So a link that’s marginal but good enough to associate can plausibly pass the join and fail the tighter sequence that follows.
The step costs nothing either way. Pair the device within about a meter of the coordinator or its nearest router, let the interview complete, then move it to its final position; ongoing communication is more forgiving of a weak link than the interview handshake is. If pairing at arm’s length works and pairing in place doesn’t, you’ve learned something about that spot. If both fail, you’ve ruled signal out cheaply.
Fix 3: restart as a last resort, not a first move
A community support thread shows people working through coordinator restarts, Home Assistant restarts, Zigbee2MQTT restarts, battery swaps, and device resets, with mixed results and often none at all (Zigbee2MQTT Discourse, similarly reported on the Home Assistant Community forum). Restarting everything is the instinctive first move, and the wrong order of operations for this failure.
Neither the stale-state pattern nor the signal explanation above is addressed by restarting anything. If you skip straight to power-cycling the coordinator, you are not touching either candidate cause, and repeated coordinator restarts can interrupt other devices that are mid-join or mid-report elsewhere on the network.
Restarting has a real place, mainly when a coordinator’s radio seems to have wedged after several failed joins in a row, or when you’ve changed a setting Zigbee2MQTT needs to pick up. Try it after ruling out stale state and signal, not before.
When it’s the unit, not your setup
Some interview failures don’t generalize, and it helps to know what that looks like. GH #23700 is a useful example: someone adding a sixth Sonoff ZBMINI-L2 to a network where five identical units had been running for weeks or months, failing with “can not get active endpoints.” Five units of the same model on the same coordinator had interviewed fine, so whatever went wrong points at that individual unit or its position rather than at the model or the reporter’s configuration. We could not confirm a maintainer or vendor diagnosis for it, and there’s no published firmware-side cause to point at.
So if you’ve cleared the stale entry, paired within range, and it still won’t interview, check that model’s own issue history before assuming the problem is in your setup. What you’re looking for is repetition — many unrelated reporters, different coordinators, different firmware versions, same symptom. A single thread about a single unit is a data point, not a diagnosis.
One opinion: Zigbee2MQTT’s frontend should flag a device as previously known to the network before the interview starts. Both fixes above depend on knowing that history, and the interface gives no hint of it until the failure has already happened.
FAQ
What does “interview” mean in Zigbee2MQTT?
It’s the automatic discovery step right after a device joins, where the coordinator queries the device’s node descriptor, active endpoints, and simple descriptors to work out what kind of device it is and what to expose. The device isn’t usable until this finishes.
Why does Zigbee2MQTT say “failed to interview”?
One of the discovery queries didn’t get a response in time. Both common variants, can not get node descriptor and can not get active endpoints, describe a query that timed out, not a Zigbee2MQTT-side configuration mistake.
How do I fix a Zigbee device stuck in a pairing or interview loop?
Force-remove any existing database entry for the device first, then try pairing it within about a meter of the coordinator before relocating it. Restarting the coordinator or Zigbee2MQTT rarely resolves this failure on its own.
Does re-pairing a previously removed Zigbee device cause interview failures?
It’s a documented recurring pattern, tracked in GH #14135 and reopened as GH #20670. A device removed and then re-paired to the same network fails interview more often than a brand-new unit of the same model, most likely because of leftover state. Note that those reporters had already factory-reset their devices, so a clean removal is not a guaranteed fix.
Does moving the device closer to the coordinator fix interview failures?
Sometimes, and it’s cheap enough to be worth testing early. The interview exchange needs several quick, successful round trips, which a marginal link can fail even though basic joining still works. Moving the device back afterward is fine once interview and configuration have completed.
What this piece verified
This is a research-synthesis explainer, not a bench test. No device was paired for this article, and nothing above reflects hands-on testing on this site’s own hardware.
The interview mechanism comes from Zigbee2MQTT’s device-support documentation, and the remove topic and payload from its MQTT topics reference. The previously-paired stale-state pattern is the best-sourced claim here: #14135 closed, #20670 opened in January 2024 to reopen it, spanning multiple vendors and device types. #20333 covers the two failure messages, and a Discourse thread corroborates that restarts alone don’t reliably resolve this failure class.
Two things are deliberately hedged. #21363 confirms pair/interview loops get reported but doesn’t establish weak signal as the cause, so Fix 2 is reasoning from the documented query sequence, not a diagnosis. #23700 is one report about one unit with no confirmed cause, so it illustrates how to read a model-specific report rather than proving a firmware bug. And what we could not find documented anywhere is the internal reason previously-paired devices fail more often — the pattern is well reported, the root mechanism is not.
Nothing in the interview process touches a vendor cloud service. Check your own Zigbee2MQTT version and the device’s issue history before assuming either fix applies exactly as described, and confirm the MQTT payload against your installed version if you’re scripting the force-remove rather than using the frontend.