A device appears in Zigbee2MQTT, then pairing stops at “Failed to interview.” The more useful part of the log is often the next phrase: “can not get node descriptor,” “can not get active endpoints,” or an error while reading an endpoint or enrolling a sensor. Each identifies the stage that failed, rather than a single universal cause.
Interviewing comes after the device starts joining the network. It is different from the later “Failed to configure” stage. An incomplete join can also leave an entry that needs investigation, as covered in the ghost-device guide. The presence of an entry alone does not tell you which of these happened.
Start with the device’s pairing instructions, battery and radio conditions. Remove an existing entry only when a deliberate re-pair is needed. Repeated force-removal or coordinator resets can discard useful evidence without solving the underlying problem.
What “interview” actually does after a device joins
Joining establishes network membership; interviewing discovers what the device can do. Zigbee2MQTT uses zigbee-herdsman to request a node descriptor, active endpoints and each endpoint’s simple descriptor. It also reads Basic-cluster attributes and performs additional work such as IAS enrollment when applicable. The device-support documentation explains why this information matters for device definitions.
The node descriptor contains information such as logical device type and a numeric manufacturer code. It does not supply the familiar model and manufacturer strings: those normally come from Basic-cluster reads or received attributes. Simple descriptors identify endpoint profiles, device IDs and input/output clusters. Together these give the converter the information it needs.
The sequence includes retries and model-specific exceptions. In the herdsman 10.10.0 implementation bundled with Zigbee2MQTT 2.14.2, node-descriptor retrieval can be tried six times, active endpoints twice, and some known devices have interview quirks. Cached information may also be reused. So a failed stage is a useful clue, but it does not prove that the device never answered any earlier request.
While a device is still being interviewed, Zigbee2MQTT normally skips converting its incoming messages into regular state payloads. Some devices can still send traffic or have partial information available. Look for “successfully interviewed” and the subsequent configure result before treating a new pairing as ready.
The two failure messages, and what each one is telling you
Issue #20333 is one historical example of interview failure. The exact wording varies across versions, so keep the full error and the debug lines immediately before it.
| Message | Stage | What it establishes |
|---|---|---|
| can not get node descriptor | Obtaining basic node information | The required descriptor was not obtained after the implemented attempts; it does not identify the cause. |
| can not get active endpoints | Retrieving the device’s endpoint list | That request did not complete successfully, even though earlier information may already be known or cached. |
A timeout can result from a sleeping device, weak or interfered radio communication, an adapter problem, a firmware quirk or a software bug. Other errors may report a specific response status rather than silence. Neither phrase rules out configuration or compatibility problems elsewhere in the setup.
Why a previously paired device may be difficult to re-add
Some users can add a new unit but cannot re-add one that previously belonged to the same network. #14135 and its January 2024 follow-up, #20670, document reports across several brands. They establish a recurring experience, not a measured failure rate proving that used devices generally fail more often.
Leftover network state or an incomplete factory reset is one possibility. It is not the only one: the follow-up contains reports where removing entries and resetting did not help, and later comments describe success after completing a model-specific reset or updating coordinator firmware. Those are individual outcomes, not a single confirmed explanation for the whole thread.
Check how the device was removed and what its reset indication actually means. A short button press may wake a device without resetting it; a long press may erase its network settings. The remove versus force-remove guide explains the distinction. A reset and a database removal affect different sides of the connection.
Check removal and reset state before re-pairing
First check whether the device already has an entry, and save its name, settings and any relevant automation references before removing it. If it is reachable, try a normal removal while it is awake. This asks the device to leave. If it is unreachable and normal removal fails, force-removal can clear the stale entry so that you can deliberately reset and pair it again.
# Replace the broker and device name for your installation.
mosquitto_pub -h 192.168.10.20 -t zigbee2mqtt/bridge/request/device/remove -m '{"id": "sensor_hallway", "force": true}'
The MQTT reference accepts a friendly name or IEEE address in id and an optional force boolean, defaulting to false. Replace the example broker address and base topic if yours differs, and use your normal authenticated/TLS client configuration where required. Check the matching bridge/response/device/remove response and logs; an ordinary removal can fail or time out, rather than silently doing nothing.
Force-removal removes Zigbee2MQTT’s entry without requiring the device to leave successfully. It is not a factory reset and does not revoke a network key that the hardware still holds. Reset that exact device using the manufacturer’s procedure before pairing it again. This is a targeted recovery step, not something to run on every device with an interview error.
For second-hand equipment, start with the hardware’s reset instructions. Touchlink factory reset is an option for supported devices, especially some bulbs; it is not a universal reset method for sensors and switches.
Check range, interference and wake state
The official interview-failure checklist recommends trying a closer location, reducing interference with a USB extension cable, checking the battery and keeping a battery device awake. Use the model’s own wake procedure; repeated short presses are appropriate for some devices, but do not hold a reset button unless you intend to reset it.
The interview requires several exchanges, so joining successfully does not prove that communication is reliable enough to finish it. Try a practical nearby position, or pairing through a suitable nearby router. Keep the coordinator away from USB 3 interference, Wi-Fi equipment and metal obstructions. A better result after moving supports a location or radio-path problem; failure in both positions does not rule interference out.
If the device pairs nearby, test it again in its final position. Some end devices, including some Aqara models, are reluctant to change parent routers. Pairing near the router you intend it to use may work better than pairing beside the coordinator and moving it far away. Zigbee2MQTT’s joining guide also notes that selecting a router does not guarantee it will be selected or retained.
Do not confuse interview failure with a device that interviews successfully but cannot then be controlled. Despite its title, #21363 initially describes completed interviews followed by failed commands. That is useful context for a post-pairing failure, not evidence that weak signal caused an interview timeout.
When a targeted restart is useful
A restart may help if the adapter or application is stuck, or after a setting that requires one has changed. It does not replace the device’s reset procedure or prove that its radio link is healthy. Restart one relevant component at a time and keep the before/after log, rather than rebooting everything at once.
The installation support discussion illustrates how several attempted remedies can become mixed together. Use the official pairing checklist for the initial sequence and your exact adapter’s documentation for firmware advice. Old CC2530/CC2531-specific power-cycle or reflash advice should not automatically be applied to a modern coordinator.
Restarting Zigbee2MQTT or unplugging the coordinator interrupts other traffic and any joins in progress. Save the error first, allow an interview attempt to finish, and avoid network-key changes or deleting the whole database as general interview remedies.
Compare the unit, location and model-specific reports
#23700 describes a sixth Sonoff ZBMINI-L2 failing at active endpoints while five others worked, on Zigbee2MQTT 1.39.1 with a SkyConnect coordinator. Crucially, the reporter later said pairing through a nearer router fixed it. That report does not establish a faulty unit or a firmware defect.
Comparing another unit remains useful, provided you account for location, power, firmware and pairing history. A single failure can be a unit fault, but it can also be a battery, router choice or installation problem. Search by exact model and manufacturer fingerprint, record both Zigbee2MQTT and coordinator firmware versions, and include debug logs if the current supported setup still fails. Use those details to distinguish a reproducible model issue from one troublesome installation.
FAQ
What does interview mean? It is Zigbee2MQTT’s device-discovery process after joining: descriptors, relevant Basic attributes and any required enrollment. A successful interview lets normal device handling proceed.
Does failed interview mean my settings are wrong? Not necessarily. The error identifies a failed discovery stage, not its cause. Sleep, interference, reset state, software, firmware and configuration/compatibility all deserve consideration.
Should I force-remove the device first? Only when an existing stale entry needs clearing and normal removal is unsuitable or fails. Check the model’s reset and wake instructions first. Force-removal alone does not reset the hardware.
Are previously paired devices known to fail? There are recurring reports, including #14135 and #20670. They do not prove one common cause or that a complete reset always fixes the problem.
Can I move the device after pairing? Test it in place after moving. Some end devices stay attached to their original parent, so pairing through a nearby final-location router can be preferable.
Sources and version context
The discovery sequence and retry/quirk behavior were checked against herdsman 10.10.0’s device implementation, bundled with Zigbee2MQTT 2.14.2. The official FAQ and MQTT API provide the practical steps and removal payload. Linked issue threads retain their version-specific context and follow-up outcomes. No device was paired or reset for this documentation-based guide.