You’ve got a dead spot in the mesh, you’ve read that Zigbee2MQTT has a transmit_power setting in the advanced config, and you’ve raised it hoping for a quick fix. Then you check the frontend, the LQI numbers haven’t moved, and you’re left wondering if the setting even did anything.
It probably did something. You’re just watching the wrong number, and depending on which coordinator chip you have and which firmware is on it, you might be at the ceiling already. Here’s how the setting actually works, per adapter family, and how to check whether it took effect.
Where transmit_power actually lives
transmit_power sits under the advanced: block in configuration.yaml, documented on Zigbee2MQTT’s adapter settings guide. It isn’t YAML-only, though. The frontend exposes it under Settings, in the advanced section, where you can edit the value in place. It can also be set through the ZIGBEE2MQTT_CONFIG_ADVANCED_TRANSMIT_POWER environment variable, which is the route one user fell back on when the config file wasn’t taking. Whichever you use, the adapter only picks up the change on a Zigbee2MQTT restart.
The settings schema puts the accepted range at -20 to 20. The docs list 5 as the default, though a 2026 documentation change reworded the field’s description toward overwriting the adapter’s own default transmit power, on the reasoning that an unset value leaves the adapter at its stack default rather than pinning it to any particular number.
Per-chip ceilings: raising it might not do anything
For Z-Stack (Texas Instruments) coordinators, the ceiling depends on the chip:
- CC2652R / CC2652RB — capped at 5 dBm. If your coordinator uses this chip, setting
transmit_powerhigher won’t raise it, because there’s nowhere higher to go. - CC2652P / CC1352P-2 — up to 20 dBm.
Reaching that 20 dBm takes more than the right silicon. The adapter settings guide names a second condition: coordinator firmware from version 20211217 or later. An otherwise-capable CC2652P stick running older firmware won’t deliver it — which, as it turns out, explains one of the bug reports further down this page.
So the first things to check before troubleshooting a “no change” result are which chip you’re running and which firmware version is on it. A CC2652R-based stick set to transmit_power: 20 isn’t broken. It’s already at its limit and has nowhere to go.
Even on the P-variant chips, the number in your config is a ceiling request rather than a guarantee. The docs are explicit that the value can’t exceed the respective hardware’s maximum and may still be limited by firmware.
Does EmberZNet (EFR32) support it?
If you search for this, you’ll find older forum answers insisting the setting is Z-Stack-only. That answer has a history. A 2021 maintainer reply in GitHub discussion 6283 stated the feature was, at the time, only supported for Z-Stack adapters — meaning EmberZNet coordinators (Silicon Labs EFR32-based, including the SkyConnect/ZBT-1) couldn’t use it at all.
That’s no longer the current picture. The official EmberZNet adapter guide now lists transmit_power as a supported setting, alongside adapter_concurrent. Support expanded to Ember at some point between that 2021 discussion and now. The discussion was never marked answered, so treat it as historical context for why the older “Ember can’t do this” answers exist, not as a live contradiction of the current documentation.
What we can’t tell you is exactly when the capability landed. A documentation page’s last-updated date records when someone edited the page, not when the feature arrived, so anyone claiming a specific timeline for Ember support is inferring it.
Why LQI won’t move (the part nobody explains)
This is the confusing bit, and it’s why most people conclude the setting “did nothing” even when it worked exactly as configured.
transmit_power controls the coordinator’s outbound signal, the coordinator-to-device direction. The linkquality value on a device’s page — the number most people watch, in the Zigbee2MQTT frontend or in Home Assistant — is measured by the coordinator’s own radio on the last hop of what it receives from the device. It describes the opposite direction. Raising your own transmit power doesn’t move it, because it was never measuring your output.
That’s narrower than saying the outbound direction is invisible. On router links, Zigbee2MQTT’s network map can show a reading in each direction, because the map is built by querying each router’s own neighbour table rather than by reading the coordinator’s receive statistics alone — our network map explainer walks through what those paired numbers mean and is the other half of this answer. What you won’t find anywhere in the interface is a plain readout of the coordinator’s configured output.
The documented way to confirm the setting took effect is to enable debug logging and search the Zigbee2MQTT/herdsman log output after a restart for the radioTxPower value, as covered in discussion 12923. If it matches what you set, the coordinator applied it. The device-page LQI figure isn’t going to tell you either way.
Adapters that reject the setting outright
deCONZ-family adapters (ConBee, RaspBee) don’t support transmit_power at all. Setting it isn’t a harmless no-op on these — it can stop Zigbee2MQTT from starting entirely, with a “not supported” error thrown by the deCONZ adapter. One documented case on the Home Assistant Community forum describes exactly this: a user added transmit_power: 20, startup broke, and removing the line fixed it.
That thread adds a wrinkle worth knowing if you run the add-on. The fix required editing Zigbee2MQTT’s own configuration.yaml, which is a separate file from the add-on’s configuration page in the Home Assistant UI — and that distinction was the real source of confusion for the person posting.
If you’re on ConBee or RaspBee and range is the actual problem, transmit_power isn’t a lever you have. Mesh topology work is where that effort should go instead.
What the “it doesn’t work” reports actually show
Three reports across three years say some version of this setting does nothing. Reading them together is more useful than reading any one of them alone.
- Issue 8885 (2021): a CC2652P user compared no setting at all against 5, 10, 15 and 20 dBm, and saw the same link quality figure, around 25, every time.
- Issue 12232 (2022): another CC2652P user swept -20 to +20 dBm across two gateways on what they described as current coordinator firmware, with no observable change in connected devices’ reported LQI. Closed, with no visible maintainer resolution.
- Issue 19033 (2023): transmit power not applying from the config file, worked around with the environment variable mentioned above.
Two things stand out. The 2021 report was running coordinator firmware dated 20210708 — earlier than the 20211217 build the documentation names as the minimum for 20 dBm, so that one has a plain explanation that isn’t a Zigbee2MQTT defect at all. And every one of these judged the outcome by watching LQI, which is exactly the measurement the section above establishes cannot detect a change in outbound power.
None of that proves the setting worked in any of these cases. It does mean the evidence offered doesn’t establish that it failed. I’d rather see one radioTxPower log line than a hundred LQI screenshots on this particular question, and the absence of that log line from nearly every report is a fair part of why the setting has the reputation it does.
More power isn’t a range fix on its own
Real-world Zigbee range in a house is dominated by physical obstruction and mesh density — router placement and count — not by a few extra dBm out of the coordinator. Our ZBDongle-E vs ZBDongle-P comparison covers this in the context of picking a coordinator, and the short version carries over here: if you’re chasing a dead spot, adding a mains-powered router near it will usually do more than maxing out transmit_power.
Channel selection matters too, particularly if Wi-Fi interference is part of the problem — our channel change guide is the diagnostic path there. And route failures on Ember coordinators have their own troubleshooting story, which our write-up of Zigbee2MQTT’s many-to-one route failure covers separately; that one isn’t a transmit power problem and won’t be fixed by treating it as one.
Common questions
What does transmit_power do in Zigbee2MQTT?
It sets the coordinator’s outbound radio transmit strength, in dBm. Configure it under advanced: in configuration.yaml, in the frontend’s advanced settings, or via an environment variable. The documented default is 5 and the accepted range is -20 to 20.
Do I have to edit YAML to change it?
No. The frontend exposes transmit_power in its advanced settings section, and the ZIGBEE2MQTT_CONFIG_ADVANCED_TRANSMIT_POWER environment variable works as well. All routes need a restart to take effect.
Why doesn’t LQI change after I raise transmit_power?
The linkquality figure on a device’s page measures the device-to-coordinator direction. transmit_power affects coordinator-to-device output, so raising it has no reason to move that number.
What’s the max transmit power for a CC2652P coordinator?
Up to 20 dBm, versus 5 dBm for CC2652R and CC2652RB-based coordinators. Reaching 20 dBm also requires coordinator firmware from version 20211217 or later.
Does EmberZNet (Silicon Labs EFR32) support transmit_power?
Per the current official adapter guide, yes. Older answers saying otherwise reflect a 2021-era limitation that no longer describes the documented behaviour.
Why did Zigbee2MQTT stop starting after I changed transmit_power?
Most likely a deCONZ-family adapter (ConBee, RaspBee). These reject the setting outright and can fail to start with a “not supported” error until you remove the line.
What this covers, what stays local, and what to check
This is built from Zigbee2MQTT’s own adapter settings and EmberZNet documentation, maintainer replies in GitHub discussions 6283 and 12923, three issue reports on the setting not taking effect, and one Home Assistant Community thread on a deCONZ startup failure. No hardware was bench-tested for this article; the per-chip ceilings, the firmware requirement and the range are the project’s documented figures, and the bug reports are described as what individual users reported rather than as confirmed defects.
What stays local: all of it. Setting transmit power, restarting Zigbee2MQTT and reading the herdsman log happen entirely on your own hardware, with nothing sent anywhere.
What still depends on your hardware: whether a given coordinator honours the value you set. Chip, firmware version and the stick’s own RF design all sit between your config line and the antenna, and only the log check tells you where you actually landed.
What to check on your own setup: your coordinator’s chip and firmware version before assuming a ceiling, and your own frontend build for where the advanced settings live, since layout and labels move between releases.