adapter_concurrent sits in the same advanced: block of configuration.yaml as transmit_power, and it gets found the same way — a reader is chasing something else (commands to a room full of lights feel staggered, a group doesn’t land uniformly, or a log line mentions the adapter running out of buffers) and stumbles on a setting with almost no explanation behind it. The settings reference does tell you the field’s shape (a number or null, bounded 1 to 64, applied on restart), and the adapter-settings page adds two example values. What neither page says is what the number actually means, or when touching it is the right move. That explanation exists in one place: the project maintainer, answering the same question twice on GitHub.
What adapter_concurrent actually controls
adapter_concurrent sets how many Zigbee commands your coordinator can have outstanding — sent, and waiting on a confirmation — at the same time. It is not a signal-strength setting, and it is not a bandwidth or throughput dial. It’s a queue depth.
The clearest description of this comes directly from Koenkk, the Zigbee2MQTT maintainer, answering the question in a GitHub discussion: if concurrency is set to 2 and you issue a command to three devices at once, the first two go out immediately and the third sits in a queue until one of the first two confirms. Raise the number and more commands can be in flight simultaneously; lower it and fewer can.
That distinction matters because the symptoms that lead people here — slow-feeling multi-device commands, a light group that doesn’t fire evenly — look like they could be a radio problem. They aren’t. They’re a queuing behavior, and the fix Koenkk actually recommends for that specific complaint isn’t raising this number at all (more on that below).
Where it’s set, and what the default (null) does
adapter_concurrent lives under advanced: in configuration.yaml, the same section as transmit_power, channel, and the other adapter-level tuning options. Left unset, its value is null, which the docs describe as Zigbee2MQTT using the adapter’s own “recommended value” — no number is surfaced to you when it’s null. You only see a concrete figure if you set one yourself.
The settings reference is more specific about the field’s shape than the adapter-settings page is: the accepted type is a number or null, the minimum is 1, the maximum is 64, and a change only takes effect after a Zigbee2MQTT restart. That restart requirement is the detail most worth carrying away — it’s the reason a value edited in the Configure UI can look like it did nothing.
advanced: # null (default) = use the adapter's recommended value # accepted range if you set one yourself: 1-64 # takes effect on restart, not on save adapter_concurrent: null
The example numbers docs give aren’t a universal table
The official adapter-settings page gives exactly two example values: 2 for the CC2531, and 16 for the CC26X2R1. Both are per-chip recommended defaults — the number Zigbee2MQTT falls back to for that specific adapter when adapter_concurrent is left null — not a general-purpose range that applies across every supported coordinator. Zigbee2MQTT doesn’t publish a full table mapping every adapter to its default concurrency value; the two figures shown are illustrative, not exhaustive.
Does your adapter support it?
Documentation coverage isn’t uniform across coordinator firmware families. Z-Stack adapters (the CC2531/CC2652/CC1352 family, which is what you’re running on a Sonoff ZBDongle-P) get named example defaults directly in the docs. EmberZNet — Silicon Labs EFR32-based coordinators, covering the Home Assistant Connect ZBT-1 and the Sonoff ZBDongle-E — lists adapter_concurrent on its own adapter-specific page alongside transmit_power, but gives no EFR32-specific recommended number the way the Z-Stack examples do.
deCONZ-family adapters (ConBee, RaspBee) are the odd one out: their adapter page names baudrate as the extra setting it documents and doesn’t mention adapter_concurrent at all. Be careful how much weight you put on that. adapter_concurrent is a general option in the global advanced: schema rather than a per-adapter feature flag, so a page that doesn’t mention it is a gap in that page’s coverage — not a documented statement that a ConBee or RaspBee ignores a value you set.
| Adapter family | Listed in that adapter’s docs? | Recommended value given in docs |
|---|---|---|
| Z-Stack (CC2531) | Yes | 2 (example, used when null) |
| Z-Stack (CC26X2R1) | Yes | 16 (example, used when null) |
| EmberZNet (EFR32, e.g. Connect ZBT-1, ZBDongle-E) | Yes | Not specified — no chip-specific number given |
| deCONZ (ConBee, RaspBee) | Not mentioned | None given |
Should you actually raise it?
Twice, in separate GitHub discussions, someone has asked essentially the same question — “what does adapter concurrency do, and should I raise it?” — and Koenkk has given the same answer both times: the default is normally correct, the number isn’t derived from a chip’s datasheet or firmware spec sheet, and raising it is a troubleshooting step for a specific symptom, not something to tune routinely.
More specifically, for the complaint that most often sends people looking at this setting — commands to several devices at once feeling slow or uneven — Koenkk’s stated recommendation is to use Zigbee groups instead of raising concurrency. A group-addressed command reaches every member in a single message rather than the coordinator queuing individual commands to each device one at a time, which addresses the actual symptom without touching a setting most people don’t need to change. If that’s your situation, our guide to Zigbee2MQTT groups versus scenes is the better starting point — worth reading before reaching for adapter_concurrent at all.
The “adapter ran out of buffers” symptom — related, not confirmed connected
A 2025 GitHub issue reports an EmberZNet (“ember:ezsp”) coordinator’s buffers becoming exhausted after roughly 69 consecutive commands were sent from Home Assistant in quick succession — degraded performance, and new device pairing blocked until the adapter was reflashed or restarted. It’s a real, documented failure in the same general territory as command-queue depth.
This buffer-exhaustion report does not establish a causal link to adapter_concurrent. The issue was closed as “not planned,” it does not identify concurrency settings as the cause, and it does not report that changing adapter_concurrent fixed or would have prevented it. The reporter’s transmit_power value is mentioned only as configuration context, not as a stated cause. Treat this as an unresolved, related symptom in the same problem space — not as evidence that tuning adapter_concurrent causes or cures buffer exhaustion.
Separately, an older (2020) issue reported a validation error — “Unknown options adapter_concurrent” — when the setting was configured through Home Assistant’s Supervisor add-on on a CC1352P-2 coordinator. That report predates several Zigbee2MQTT config-schema revisions since 2020, and there’s no indication it reflects current versions. It’s historical context for how long this setting has existed and how it’s occasionally tripped up config validation, not something to expect on an up-to-date install.
FAQ
What does adapter_concurrent do in Zigbee2MQTT?
It sets how many Zigbee commands can be outstanding at once — sent and awaiting confirmation — before additional commands queue. Per the maintainer’s own explanation, it’s a command-queue depth, not a signal-strength or bandwidth setting.
What’s the default adapter_concurrent value for my coordinator?
The default is null, meaning Zigbee2MQTT uses your adapter’s own recommended value without showing you a number. Docs give two concrete examples — 2 for the CC2531, 16 for the CC26X2R1 — but there’s no published table covering every supported adapter, and EmberZNet’s adapter page gives no chip-specific figure. If you do set a value yourself, the settings reference puts the accepted range at 1 to 64, and the change only applies after a restart.
Does raising adapter_concurrent fix “adapter has run out of buffers” errors?
Not confirmed. A 2025 EmberZNet buffer-exhaustion report is in the same general problem space, but the issue doesn’t establish that adapter_concurrent caused it or that changing the value would prevent it. Treat it as an open, unresolved, related symptom — not a documented fix path.
Does deCONZ/ConBee support adapter_concurrent?
The deCONZ adapter page doesn’t mention it, naming only baudrate as its extra documented setting. That’s a documentation gap rather than a documented incompatibility: adapter_concurrent is a general option in the global advanced: schema, not a per-adapter feature flag. Nothing in the docs confirms either way what a ConBee or RaspBee does with a value you set.
Should I raise adapter_concurrent or use Zigbee groups for multiple devices?
For the common complaint of slow or uneven multi-device commands, the maintainer’s own recommendation is Zigbee groups, not raising concurrency. A group-addressed command reaches every member at once; raising adapter_concurrent changes how many individual commands can queue in parallel but doesn’t collapse them into one message the way a group does.
What’s confirmed here, and what to check yourself
Confirmed directly from official Zigbee2MQTT docs and two independent maintainer answers on GitHub: adapter_concurrent is a command-queue-depth setting, not a signal or bandwidth control; its default is null (adapter-recommended); the accepted range is 1 to 64 and a change requires a restart; the two example values in the docs (2 and 16) are per-chip defaults, not the bounds; EmberZNet’s adapter page lists the setting without a recommended number; the deCONZ page doesn’t mention it at all; and the maintainer’s own preferred fix for slow multi-device commands is Zigbee groups, not raising this value.
Deliberately left hedged: the EmberZNet buffer-exhaustion issue is presented strictly as an open, unresolved, related report, not as a confirmed cause-or-cure case for this setting. The 2020 validation-error issue is historical context only and shouldn’t be expected on a current install. If you do change this, restart Zigbee2MQTT and watch whether the behaviour you were chasing actually moves; that’s the only feedback the setting gives you.
This is research-synthesis, not a bench test: no hardware was reconfigured to produce these findings, and no claim here goes beyond what the cited docs pages and GitHub discussions state.