A sensor in the far room drops out once a day, the lamp responds after three seconds — and in any smart home chat within a minute someone will tell you to “move to channel 25 or 26, there’s no Wi‑Fi there.” The advice is half-working and half-harmful. Below are four common claims and what the manufacturers’ documentation and official project docs say about them.
Myth 1. “These are different technologies, they don’t interfere with each other”
They do interfere because they live in the same slice of spectrum. IEEE 802.15.4 on 2.4 GHz is 16 channels numbered 11–26, central frequencies from 2405 to 2480 MHz, step 5 MHz, occupied bandwidth 2 MHz. Wi‑Fi there also uses up to 22 MHz: the first channel spans 2401–2423 MHz, the sixth 2426–2448, the eleventh 2451–2473. A narrow Zigbee signal cannot “punch through” Wi‑Fi — it either fits in the gap between bands, or it doesn’t.
*Bands are based on data from NXP JN-AN-1079 (802.15.4: step 5 MHz, 2 MHz band)
Thread and Matter-over-Thread operate on the same 802.15.4 and use the same channel numbering. If a Thread border router runs next to a Zigbee coordinator, they share the spectrum not only with Wi‑Fi but with each other.
Myth 2. “Put it on channel 26 — it’s the farthest from Wi‑Fi”
The upper edge of the band is indeed free. But 26 is not in Zigbee2MQTT’s recommendations (11, 15, 20, 25), nor in ZHA, whose “Smart” selection, on first startup, scans all channels and prefers 15, 20, and 25 to others.
A second, more serious reason is rarely discussed: on channel 26 the transmit power is reduced. Texas Instruments’ FCC certification guide for Z‑Stack explicitly sets ceilings for their boards: LP_CC2652RSIP and LP_CC2652PSIP — maximum 2 dBm on channel 26, CC1352P_2_LAUNCHXL — 15 dBm. The reason is the second harmonic, which causes boards to fail certification on the upper channels.
The spread is huge: 2 dBm on one board vs 15 dBm on another in the same document — even though the CC2652P chips themselves are rated up to +20 dBm. Eighteen decibels of headroom equals roughly an eightfold decrease in range; indoors it’s worse, but a network after such “improvement” still collapses. Look for limits in your device maker’s docs, not in chat advice.
Myth 3. “If I change the channel, everything will be fixed”
Switching channels on a live network is an operation with side effects, not a free button. In Zigbee2MQTT it’s supported only for adapters zstack and ember; some devices can’t switch at all and will require re-pairing, and sleeping battery-powered sensors will not hear a broadcast message: ZHA suggests it can take up to an hour to re-pair all devices and advises speeding up the process by power-cycling devices. The official ZHA guidance is that the channel chosen during initial setup should preferably not be changed.
So you should start not with Zigbee, but with where your access point sits:
# your own and neighbors’ SSIDs with channel numbers and signal levels
nmcli -f SSID,CHAN,FREQ,SIGNAL dev wifi list | head -20
Next — as per the table; “free” means Zigbee bandwidth lies entirely outside the 22 MHz of that Wi‑Fi channel.
| Wi‑Fi Channel | Occupied Band | Free Zigbee channels |
|---|---|---|
| 1 | 2401–2423 MHz | 15, 20, 25 |
| 6 | 2426–2448 MHz | 11–14, 20, 25 |
| 11 | 2451–2473 MHz | 11–15, 25 |
You can see why 25 is the most common answer: among the recommended options, only it is free regardless of Wi‑Fi position.
The table is valid only for a 20 MHz Wi‑Fi channel width: in 40 MHz mode the point occupies almost half the band and there are no gaps left. Also make sure the channel is fixed and not on “auto” — otherwise the router will move at night and take your gap with it.
Myth 4. “The problem is the channel — the real issue is the half-meter of cable”
The most common cause of a bad network is not about channels at all. USB 3.0 creates wideband noise right in the 2.4–2.5 GHz band — described in the USB-IF document that hardware manufacturers have cited for years. A coordinator plugged right next to a USB 3.0 port or an external SSD can mute itself.
Zigbee2MQTT documentation states plainly: an adapter near a USB or HDMI port can kill the radio entirely, and a USB extender of about 50 cm is enough to noticeably reduce interference. ZHA adds: avoid USB 3.0 ports, use USB 2.0 or a hub with external power.
What to do if the network is failing:
- Use a 50 cm extender, USB 2.0 port, keep it away from the case, SSDs, and the router — often fixes the issue.
- Manually fix the access point channel, keep the width at 20 MHz.
- Add powered, network-driven devices (smart plugs, relays) into problematic zones — they help less than they hurt.
- Only then change the Zigbee channel, preparing to re-pair some devices.
Sources
- NXP JN-AN-1079: Co-existence of IEEE 802.15.4 at 2.4 GHz — frequencies and channel bands
- TI Z-Stack: FCC Certification Considerations — transmit power limits on channel 26
- Zigbee2MQTT: network configuration and range and stability
- Home Assistant: ZHA — channel choice and USB recommendations
- USB-IF: USB 3.0 Radio Frequency Interference Impact on 2.4 GHz Wireless Devices
Related forum thread: Smart home without internet: stress test for autonomy.
What channel is your Zigbee network on, and have you had to change it? And what helped — USB extension or moving across the spectrum?