Choosing a Zigbee Channel Your Wi-Fi Isn’t Sitting On: A 2.4 GHz Overlap Map With an LQI Before/After Test

The failure mode: a Wi-Fi change, then intermittent Zigbee dropouts

A new access point, a mesh node added in the hallway, or a router that auto-selects a wider channel can change the 2.4 GHz environment without touching the Zigbee network at all. Days later, a few battery sensors start missing reports, a bulb occasionally fails to acknowledge a command, and the first instinct is to open the Zigbee integration and change the channel.

That instinct is backwards. A Zigbee channel change is a migration of every device on the network, and without a before-baseline you cannot tell whether the new channel helped, hurt, or did nothing. The useful deliverable is not a channel number. It is a repeatable procedure: map the overlap, record a baseline, change one variable, re-measure against a threshold you defined in advance, and be willing to conclude that the default channel was already correct.

This procedure is written for installed local-first stacks — ZHA or Zigbee2MQTT on Home Assistant, with Zigbee2MQTT, Z-Wave JS, ESPHome, and MQTT alongside. It assumes the network already works most of the time. If devices are failing to pair at all, fix the transport and the coordinator placement first; channel tuning is the wrong tool for a network that has never been stable.

Why the channel numbers mislead

Zigbee channels 11–26 and Wi-Fi channels 1, 6, and 11 are both numbered, and the numbers do not line up. According to Oscuim’s coexistence training material, Wi-Fi’s three non-overlapping channels (1, 6, and 11) use the exact same frequencies as Zigbee channels 11–22, and Zigbee channels 25–26 are not immune because they can be caught in Wi-Fi channel 11’s sideband lobe. The same source notes that Zigbee channel 26 is usually relatively unaffected by Wi-Fi, but that many Zigbee devices do not support it.

Two consequences follow. First, “Zigbee 11 vs. Wi-Fi 11” is not a like-for-like comparison; the overlap is a frequency relationship, not a numbering one. Second, “clear of Wi-Fi” and “usable” are different criteria. Channel 26 may be the quietest part of the band and still be the wrong choice if part of your device set will not join it. The overlap map narrows the candidate list; device support filters it.

I have not found a primary overlap chart that I can cite cleanly here — the Silicon Labs fundamentals document and the Wi-Fi Alliance channel page were both unavailable when I checked, so the Oscuim page is doing the work as a secondary source. Treat the map below as a planning aid, not a calibrated spectrum measurement, and verify against your own scan.

A working overlap map

The table is a coarse planning grid, not a measurement. “Overlap” means the Wi-Fi channel’s occupied spectrum falls across the Zigbee channel’s band; “edge” means the relationship is marginal and depends on width and proximity.

Zigbee channel	Wi-Fi 1	Wi-Fi 6	Wi-Fi 11	Notes
11	Overlap	—	—	Lowest Zigbee channel; sits in Wi-Fi 1’s range
12–14	Overlap	—	—	Still inside Wi-Fi 1’s footprint
15	Edge	Overlap	—	Between Wi-Fi 1 and 6; ZHA’s Smart scan prefers it
16–18	—	Overlap	—	Inside Wi-Fi 6
19	—	Edge	Edge	Between Wi-Fi 6 and 11
20	—	Edge	Overlap	ZHA’s Smart scan prefers it; check against Wi-Fi 11
21–22	—	—	Overlap	Inside Wi-Fi 11
23–24	—	—	Edge	Upper edge of Wi-Fi 11’s sideband
25	—	—	Edge	ZHA’s Smart scan prefers it; sideband risk near Wi-Fi 11
26	—	—	Edge	Often clear of Wi-Fi, but device support is the constraint

Read the table as a first filter. If your Wi-Fi is on 1 and 6, Zigbee 15 is a compromise, not a clean slot. If your Wi-Fi is on 6 and 11, Zigbee 15 or 20 may be the least-bad choice. If you have only one AP on channel 1, Zigbee 20, 25, or 26 are the candidates worth testing — subject to device support.

Step 1 — Inventory the 2.4 GHz environment

Before touching the Zigbee side, write down what is actually transmitting. For each access point and mesh node, record:

Channel number and channel width (20, 40, or wider).
Approximate location relative to the Zigbee coordinator and the worst-performing devices.
Whether the AP is yours or a neighbor’s. Neighbor networks are the ones you cannot reconfigure, and they belong on the map too.

Channel width matters because a 40 MHz bond occupies more spectrum than the nominal channel number suggests. A router that auto-selects 40 MHz on channel 6 is not equivalent to a 20 MHz AP on channel 6. If you cannot read the width from the router’s admin page, a Wi-Fi scanner on a laptop or phone will show it.

This is the same inventory discipline as auditing the small systems that quietly run your week — the point is to know what is deployed before changing anything. See How to Audit the Small Systems That Quietly Run Your Week for the broader habit.

Step 2 — Record the current Zigbee channel and build a before-baseline

In ZHA, the current channel is on the network information page: Settings → Connectivity → Zigbee → Network information. The documentation states that valid channels are 11 to 26, all in the 2.4 GHz band, and that the channel is the only field on that page you can change.

In Zigbee2MQTT, the channel is set in configuration.yaml under advanced.channel. The configuration guide’s minimal example exposes it, and the generator labels the field as the channel of the closest Wi-Fi 2.4 GHz network — which is a starting hint, not a measurement.

Now build the baseline. The goal is a snapshot you can reproduce exactly after the change:

Fix the device set. Record every device’s friendly name and IEEE address. Do not add, remove, or move devices between the before and after snapshots.
Fix the positions. Note where the coordinator and any routers sit. Moving a router between snapshots invalidates the comparison.
Record per-device link quality. In ZHA, the device’s diagnostic information includes LQI and RSSI where the device reports them. In Zigbee2MQTT, the frontend shows link quality per device, and the MQTT state topic carries it. Export the values with a timestamp.
Record the failure symptoms you actually care about. Missed reports, delayed commands, devices going unavailable. A count over a fixed window is more useful than a feeling.

LQI is not a calibrated unit. It is reported by the device or derived by the stack, and it is not safe to compare absolute values across different device models or firmware versions. Compare each device to its own before-value, and compare the distribution across the network, not a single device.

Step 3 — Choose candidate channels from the map, not from a best-channel list

From the inventory and the overlap table, write down two or three candidate Zigbee channels. Then filter them:

Device support. Channel 26 is often clear of Wi-Fi but poorly supported. If any device in your set refuses to join or behaves oddly on 26, it is out — regardless of how quiet the spectrum looks.
Coordinator support. Confirm your coordinator firmware offers the channel you want. ZHA’s dropdown and Zigbee2MQTT’s configuration both expose the channel, but the radio has to support it.
Neighbor networks. A channel that is clear of your APs but sits under a neighbor’s AP is not clear.

ZHA’s “Smart” option scans all channels once and picks the best one, preferring 15, 20, and 25. The documentation is explicit that this is a one-time operation and does not continuously monitor. That makes it a reasonable starting suggestion and a poor substitute for a before/after test — it cannot tell you whether the change improved your specific device set.

Step 4 — Execute the switch as a planned migration

Home Assistant’s ZHA documentation states that the best practice is not to change the Zigbee channel from the ZHA default, and it directs readers to review its interference-avoidance and pairing guidance before changing the channel on an existing network. That is not a prohibition; it is a warning that the default is a legitimate answer and that a change carries risk.

Treat the switch as an outage with a start and end time:

Announce the window. Automations that depend on Zigbee devices will be unreliable during the change and the settling period.
Change the channel once. In ZHA: Network information → pencil → select the channel. In Zigbee2MQTT: edit advanced.channel and restart the add-on or service.
Do not change anything else. No firmware updates, no new devices, no router moves. One variable.
Wait a fixed settling window before measuring. The retrieved sources do not establish how long devices take to rejoin after a channel change, or whether re-pairing is required for any given device class. I have not seen a documented universal figure, so pick a window, write it down, and use the same window for the after-test. If devices are still absent at the end of the window, that is a result, not a reason to extend the window until the numbers look good.

One confound to eliminate before you start: a coordinator connected over Wi-Fi. Zigbee2MQTT’s adapter documentation warns that Wi-Fi-connected network adapters may have reduced stability because the serial protocol lacks fault tolerance for packet loss and latency typical of Wi-Fi links, and recommends wired Ethernet for remote adapters. ZHA’s documentation similarly cautions against running a coordinator over a serial proxy via Wi-Fi, WAN, or VPN. If the serial link itself is lossy, channel results are noise. Fix the transport first.

Step 5 — After-test: repeat the identical snapshot

After the settling window, repeat Step 2 exactly: same devices, same positions, same fields, same export format. Then compare:

Per-device change. For each device, the after-LQI minus the before-LQI. A device that improved by a large margin is a data point; a device that got worse is a warning.
Distribution. Count how many devices improved, how many were unchanged, and how many degraded. A median shift with a long tail of degraded devices is not a clean win.
Symptoms. Compare the missed-report and unavailable counts over the same window length.

Define pass/fail before you start. A defensible threshold is something like: no device degrades by more than a small margin, the median improves, and the symptom count drops. The exact numbers are yours to set; the sources here do not establish a universal LQI threshold that defines a good link, and I would be inventing one if I gave you a figure. What matters is that the threshold is written down before the change, so the after-test can fail.

Step 6 — Rollback criteria and documentation

If the after-test does not clearly beat the before-test, revert to the original channel. “Clearly” means your pre-committed threshold was met, not that the graph looked better. Then write down the result: original channel, candidate channel, settling window, device count, and the outcome. The next person — or you in six months — should not repeat the experiment.

This is also where the honest answer is sometimes “no change.” The vendor default is a legitimate output of the procedure. If the map and the test do not show a clear improvement, the correct action is to leave the channel alone and look elsewhere: coordinator placement, router density, USB 3.0 interference near the coordinator, or a device that is simply at the edge of the mesh.

When a channel change is the wrong tool

Channel tuning addresses co-channel and adjacent-channel interference. It does not fix:

A coordinator on a USB extension cable next to a powered USB 3.0 hub.
Too few routers for the size of the space.
A battery device at the far end of the house with one marginal route.
A Wi-Fi-connected coordinator whose serial link drops packets.

If the baseline shows one or two devices failing while the rest are healthy, the problem is local to those devices, and a network-wide channel change is a blunt instrument. Fix the local problem first.

And if the requirement is simply that a light turns on when a switch is pressed, a plain switch or a mechanical timer is the smarter choice. A Zigbee network is a small distributed system; it earns its place when the coordination is worth the maintenance. Channel tuning is part of that maintenance, not a substitute for deciding whether the system should exist.

Maintenance habit: re-run the map when the topology changes

The 2.4 GHz environment is event-driven, not calendar-driven. Re-run the inventory and, if the map changed materially, the before/after test when:

A new access point or mesh node is added, or an AP’s channel or width changes.
A neighbor’s network appears on a channel that overlaps yours.
You add a significant number of Zigbee devices or move routers.
You replace the coordinator.

A quarterly reminder to “check the Zigbee channel” will mostly produce churn. A trigger tied to the Wi-Fi topology will produce decisions.

FAQ

Should I just pick Zigbee channel 26 because it is clear of Wi-Fi?

Not automatically. Oscuim notes that channel 26 is usually relatively unaffected by Wi-Fi but that many Zigbee devices do not support it. Check your device set first; a quiet channel that half your devices will not join is not a solution.

Does ZHA’s Smart channel option replace the before/after test?

No. The ZHA documentation describes Smart as a one-time scan that prefers 15, 20, and 25, and states that it does not continuously monitor. It can suggest a candidate; it cannot tell you whether that candidate improved your specific devices.

Will changing the channel require re-pairing my devices?

The retrieved sources do not establish this. Behavior varies by device and stack, and I have not seen a documented universal answer. Plan the change as an outage, use a fixed settling window, and treat devices that have not returned by the end of that window as a result to investigate rather than a reason to extend the window.

Can I compare LQI values between two different device models?

Not reliably. LQI is reported by the device or derived by the stack, and it is not a calibrated unit across models or firmware. Compare each device to its own before-value, and compare the network distribution rather than a single device.

My coordinator is connected over Wi-Fi. Does that affect the test?

Yes, it is a confound. Both Zigbee2MQTT’s adapter documentation and ZHA’s documentation warn against Wi-Fi-connected coordinators because the serial protocol does not tolerate packet loss and latency well. Fix the transport before tuning the channel.