“Failed to configure” can appear after a device pairs or when Zigbee2MQTT starts. Sometimes the device still works; sometimes an important reading or command is missing. The warning alone does not tell you how much of the setup succeeded.
Read the failed command and response beside it. An unsupported attribute, an unreportable attribute and a binding timeout need different checks. The examples below use Zigbee2MQTT’s local Zigbee and MQTT paths; you do not need to reconnect the device to a vendor cloud to inspect them.
What “Failed to configure” actually means
A supported device definition may include a configure function. That function can bind clusters, set up attribute reporting, read calibration factors or initial values, and write model-specific settings. It is more than a generic “turn on reporting” step, and some definitions do not need one at all.
Look for the endpoint, cluster, attribute and operation immediately before the error: read, write, configReport or bind. “Failed to configure” means an error escaped that device’s configure function; it does not say that every operation in it failed.
This normally follows interview and identification, rather than an initial join failure. If the logs say “Failed to interview,” investigate that stage first. An incomplete or duplicate entry may also need the ghost-device checks. A visible model name by itself is not proof that the entire pairing process finished cleanly.
The Zigbee2MQTT 2.14.2 configure extension records the definition version after a successful function call. It can configure routers at startup, while end devices normally wait for device activity. It also responds to join/interview and last-seen events. A missing or changed configured marker can therefore lead to retries, but not every device is reconfigured immediately on every restart.
Two attribute-status codes to recognize
Two useful ZCL responses are UNSUPPORTED_ATTRIBUTE and UNREPORTABLE_ATTRIBUTE. They are examples to recognize, not a measured ranking of all configure failures.
UNSUPPORTED_ATTRIBUTE means that the specified attribute does not exist on the device in that request’s context. Check the endpoint, cluster and any manufacturer-specific handling, as well as the exact firmware and fingerprint. A converter can ask for an attribute that one revision does not implement, or use an operation that the device rejects.
Issue #31917 gives two concrete Moes examples: a ZG-101ZD knob rejected a Basic-cluster read, and an ERS-10TZBVB-AA button rejected an operation-mode write. The reporter said actions still worked. That is evidence about those units and operations, not a general guarantee that unsupported-attribute errors are cosmetic. The issue is closed as completed after a maintainer reported a development-branch fix and one user confirmed improvement. A later September 2026 comment still reports the button’s write failure on Zigbee2MQTT 2.12.1, despite that firmware being able to read/report the attribute. Check the full follow-up and your exact fingerprint and installed release rather than treating the closed status as proof that both cases are resolved.
UNREPORTABLE_ATTRIBUTE means periodic reports cannot be issued for the specified attribute. It does not necessarily mean that choosing a different interval will fix it. The attribute may be readable by a separate request, or may update by another mechanism, but those possibilities depend on the device and converter.
Neither response means that Zigbee2MQTT has no definition for the device. That is a separate support problem, discussed in the no-converter guide. Here the definition exists and one of its setup operations is failing.
| Failure signature | What it establishes | What to check |
|---|---|---|
| UNSUPPORTED_ATTRIBUTE | The requested attribute is unsupported in that operation/context | Exact attribute, endpoint, fingerprint and converter; whether the failed operation is essential |
| UNREPORTABLE_ATTRIBUTE | The requested attribute cannot provide periodic reporting | Whether the current definition needs polling or a model-specific reporting change |
| bindRsp / binding timeout | The binding transaction did not complete in time | Wake state, radio path, router/coordinator behavior, firmware and software |
When it’s safe to ignore, and how to tell
Check every function you actually use: switch control, button actions, motion, temperature, power and energy as applicable. A working switch proves switching works; it does not prove power measurement works. Likewise, one fresh reading does not establish that reporting continues after the device sleeps or Zigbee2MQTT restarts.
If the failure concerns an optional attribute and all required functions continue to work, it may be reasonable to leave the device running while following its issue or converter fix. If a missing operation affects a function you rely on, treat it as a functional fault even when the device otherwise responds.
Configure is not a database transaction that rolls every device change back. Earlier binds, reads or writes can have succeeded before a later call threw. Some converters deliberately catch known optional failures and continue, so not every rejected attribute causes the top-level error. When an exception does escape, the success marker is not newly written for that run. In 2.14.2 automatic retries stop after three failed attempts for that device in the current process. A successful configuration clears the failure counter, and a manual configure request bypasses the automatic limit. This explains repetition without implying an endless retry loop.
For metering, #23155 and #22808 show model-specific reporting and polling problems. In #22808 a Colorock CR-MNZ1’s values could be read manually while reporting setup failed. Later comments discuss polling, scaling and revised converters. Do not paste an old external converter simply because the warning matches: match the manufacturer fingerprint and check the current released definition first.
Binding-timeout failures: a different problem, a different fix
A timeout such as AREQ - ZDO - bindRsp around 10000ms is different from a device returning a ZCL rejection code. It means the expected binding response did not arrive within that adapter/request’s timeout. Other adapters and versions can show different wording or durations.
A weak or congested radio path is one possibility. A sleeping end device, interrupted power, device firmware, coordinator firmware or a software problem can also prevent completion. The timeout does not by itself prove that the mesh is the cause, or that the device fully supports the attempted binding.
A single retry after waking the device or improving its radio conditions can be useful. Repeatedly pressing reconfigure without changing anything adds traffic and may keep reproducing the same error. Save the debug log before restarting or removing the device.
Check whether other devices are also missing responses. If several are affected, inspect coordinator placement, interference and router availability. The many-to-one route-error guide covers a specific Ember log message, while the coordinator firmware guide helps distinguish a relevant update from a speculative reflash. Neither message alone identifies the cause of your configure timeout.
Battery devices and the wake-before-configure trick
A sleeping battery device cannot immediately answer setup requests. Zigbee2MQTT avoids ordinary startup configuration of end devices for that reason, but manual requests can still arrive while the device is asleep. A suitable wake procedure can make the difference.
Use the exact model’s instructions. On some sensors, a brief press wakes the device; a long press factory-resets it. Do not reset it simply to keep it awake. Trigger configure while the device is active and watch the response. A new battery is worth checking if communication remains unreliable. The official pairing FAQ also documents battery and wake-state checks, though a configure failure is a later stage.
Triggering a manual reconfigure
Use the configure action on the device’s Zigbee2MQTT frontend page, or publish the documented MQTT request. This retries the definition’s configure function without removing the device or starting a full re-pair.
mosquitto_pub -h 192.168.10.20 \
-t zigbee2mqtt/bridge/request/device/configure \
-m '{"id": "living_room_motion"}'
Replace the illustrative broker address and device name, and the zigbee2mqtt base topic if yours differs. Use the broker’s required authentication/TLS configuration. The backslash line continuation is shell syntax for Bash/POSIX shells, not PowerShell.
The MQTT API accepts the object shown or a bare device ID; the ID can be a friendly name or IEEE address. Check zigbee2mqtt/bridge/response/device/configure for ok or error and read the log. A definition without a configure function cannot use this action. It is intended for troubleshooting, rather than routine reconfiguration of a working network.
If a careful retry still fails, look up the exact model/fingerprint and failed operation. A supported converter update may be appropriate. Removing and resetting the device is a later recovery option, not a way to add an unsupported attribute. The remove, force-remove and factory-reset guide explains what each changes before you choose that more disruptive route.
When repeated failures are worth digging into further
Collect the Zigbee2MQTT version, adapter model and firmware, device model/manufacturer fingerprint, and full failed command. Check whether the same failure is already tracked and whether a fix is included in the release you use. A closed issue with a development-branch fix is not automatically evidence that an older installed package contains it.
Include the missing behavior as well as the warning: “the switch works but voltage never updates” is much more useful than the log line alone. If all required functions work, document which optional setup operation failed and follow that specific report. If several devices fail together, include network-wide symptoms and recent coordinator or configuration changes.
FAQ
Does this mean the device is broken? No. It means the configure function failed. The impact depends on the operation and the functions that still work; the warning cannot certify that the device is healthy either.
Can waking a battery device help? Yes, if it was asleep when the requests were sent. Use its wake procedure, not an accidental factory reset. A returned unsupported-attribute response needs a different investigation.
How do the two attribute codes differ? UNSUPPORTED_ATTRIBUTE says the requested attribute is unsupported. UNREPORTABLE_ATTRIBUTE says periodic reports cannot be issued for that attribute. Neither guarantees that the remaining setup completed.
How do I retry? Use the device’s configure action or the MQTT bridge/request/device/configure endpoint, and inspect its response. A manual retry is distinct from removing and re-pairing.
Will restarting fix it? It may trigger eligible configuration attempts again, but a persistent attribute mismatch or communication problem still needs attention. End devices normally wait for activity rather than being configured immediately at startup.
Sources and version context
The retry and marker behavior comes from the 2.14.2 configure extension. The exact ZCL meanings are recorded in the bundled herdsman 10.10.0 status definitions. The official MQTT reference provides the request and response contract; the linked reports give model- and version-specific examples. These checks review documentation and source, without claiming a physical-device test.