Understanding Thread/Zigbee and Wi-Fi Channels and How to Avoid Common Mistakes

[Pascal_Nohl]

Hello everyone,

Most Homey users are not technically experienced IT professionals or network administrators. In the community, people often recommend keeping Thread and Wi-Fi on different channels and choosing channels that are as far apart as possible. Some users then struggle with their router to move Wi-Fi to another channel—assuming their consumer router even allows manual channel selection. The situation becomes more complicated once multiple access points are involved.

Common mistakes

However, one of the most common mistakes comes from a basic misunderstanding of channel numbers.

For example, Homey Developer Tools may show that Homey has created its Thread network on channel 15. This may be different in your installation.

Warning: Do not change the Thread or Zigbee channel in Homey unless you fully understand the consequences. Changing it can cause devices to lose their connection and may require them to be recommissioned.

Now imagine that your router lets you choose between Wi-Fi channel 1 and Wi-Fi channel 11. Would you choose channel 1 because its channel number appears to be farther away from Thread channel 15?

That conclusion would be wrong.

The important detail is that we are comparing a Wi-Fi channel with a Thread channel. Wi-Fi and Thread channel numbers do not refer to the same frequencies. They use different numbering systems, even though both technologies operate in the 2.4 GHz frequency band.

Thread channel 15 has a centre frequency of 2425 MHz and a nominal range of approximately 2424–2426 MHz.

By comparison:

• Wi-Fi channel 1 at 20 MHz has a centre frequency of 2412 MHz and a nominal range of approximately 2402–2422 MHz.
• Wi-Fi channel 11 at 20 MHz has a centre frequency of 2462 MHz and a nominal range of approximately 2452–2472 MHz.

Two things immediately become clear.

First, a Thread channel is only about 2 MHz wide, while a 20 MHz Wi-Fi channel occupies a much wider part of the spectrum.

Second, Thread channel 15 is positioned very close to the upper edge of Wi-Fi channel 1, whereas it lies completely outside the nominal frequency range of Wi-Fi channel 11. Thread channel 15 is approximately 26 MHz away from the lower nominal edge of Wi-Fi channel 11.

Strictly speaking, Thread channel 15 does not fall inside the simplified nominal 20 MHz range of Wi-Fi channel 1; there is a small gap. However, real radio signals do not stop at perfectly sharp boundaries, so the larger separation provided by Wi-Fi channel 11 is still preferable.

The following two tables I’ve build show the Thread and 20 MHz Wi-Fi channels together with their centre frequencies and nominal frequency ranges.

I have made every effort to ensure that the tables are accurate, but I cannot accept responsibility for any errors, omissions, or consequences resulting from their use.

The 40 Ghz bandwith complexity

When the 2.4 GHz Wi-Fi channel width is set to 40 MHz, things become considerably more complicated.

No single 2.4 GHz Wi-Fi channel number represents a 40 MHz-wide channel by itself. Instead, Wi-Fi combines the selected primary channel with a secondary channel. The secondary channel is always four channel numbers away from the primary channel, corresponding to a 20 MHz difference between their centre frequencies.

But wait: if the secondary channel were four channels lower than Wi-Fi channel 1, it would have to be channel −3. If it were four channels higher than channel 13, it would have to be channel 17, which is not available.

Exactly.

This means:

• Primary channels 1–9 can use a secondary channel above.
• Primary channels 5–13 can use a secondary channel below.
• Primary channels 5–9 can theoretically use either direction.

And this is where the situation becomes even less transparent.

For channels 5–9, the secondary channel may be above or below the primary channel. Depending on the router, access point, firmware and automatic channel-selection logic, it may not always be obvious which direction is being used. Even some professional networking systems do not provide a simple manual setting for this.

Is that not complicated enough? Let us take it one step further.

Because a 40 MHz Wi-Fi channel combines two 20 MHz channels, the resulting centre frequency lies exactly halfway between the centre frequencies of the primary and secondary channels. The simplified nominal frequency range then extends approximately 20 MHz below and 20 MHz above that combined centre frequency.

For example:

• Primary channel 7 with secondary channel 11 gives a combined centre frequency of 2452 MHz.
• Primary channel 7 with secondary channel 3 gives a combined centre frequency of 2432 MHz.

The same primary channel can therefore occupy two completely different 40 MHz frequency ranges.

Because the secondary-channel direction for primary channels 5–9 is not always easy to control or identify, these combinations are often best avoided when predictable spectrum use is important.

For a network in which a narrow 2 MHz Thread channel should operate with as little interference as possible, I would therefore limit 2.4 GHz Wi-Fi to 20 MHz channel width.

TP-Link’s Omada guidance also generally recommends using 20 MHz in the 2.4 GHz band and reserving 40 MHz for carefully controlled environments where interference and neighbouring networks can be properly managed.

For completeness, and to make the relationship easier to understand, the following table shows the possible 40 MHz Wi-Fi channel combinations.

I have made every effort to ensure that the table is accurate, but I cannot accept responsibility for any errors, omissions, or consequences resulting from this use.

Adding Zigbee to the picture.

Wi-Fi is based on the IEEE 802.11 family of standards, whereas Thread and Zigbee both use IEEE 802.15.4 for their radio and medium-access layers.

In the 2.4 GHz band, Thread and Zigbee therefore use the same channel numbering, centre frequencies and nominal channel width. The values from the Thread table can be applied directly to Zigbee:

Channels 11–26
5 MHz spacing between channel centres
Approximately 2 MHz nominal channel width

The table could therefore be labelled Thread / Zigbee / IEEE 802.15.4 Channels.

On Homey Pro, Zigbee and Thread share the same radio hardware. In Homey’s current implementation, they operate on the same IEEE 802.15.4 channel, meaning that their nominal frequency ranges overlap completely. Athom also notes that resetting Homey’s Zigbee network resets its Thread network because both technologies share this hardware.

This does not necessarily mean that Zigbee and Thread cannot coexist. Both technologies normally transmit relatively small packets and generally have a low radio duty cycle. IEEE 802.15.4 also uses mechanisms such as Clear Channel Assessment, collision avoidance, acknowledgements and retransmissions. In simplified terms, the two networks compete for—or share—the available airtime.

However, sharing one radio and one channel gives both networks the same interference environment and leaves less room for avoiding local radio problems. Separate radio resources or dedicated hubs can place Zigbee and Thread on different channels. This does not guarantee better performance, but it provides more flexibility when planning a busy 2.4 GHz environment.

For an independent Zigbee network, such as one managed by a Philips Hue Bridge, I would therefore select a different IEEE 802.15.4 channel where possible.

Unlike adjacent 2.4 GHz Wi-Fi channels, the nominal 2 MHz Thread and Zigbee channels do not overlap with one another because their centre frequencies are spaced 5 MHz apart. Nevertheless, greater separation can still be useful because real radio emissions do not end at perfectly sharp boundaries.

When several Thread and Zigbee networks are operating in the same home, channel planning can quickly become difficult. You may need to separate several IEEE 802.15.4 networks from one another while also avoiding the much wider 2.4 GHz Wi-Fi channels.

The situation becomes even more complicated in networks with several Wi-Fi access points using different channels. The available clear spectrum can disappear surprisingly quickly.

Keeping Control of Channel Selection

When channel selection is left on Auto, it is easy to lose track of which frequencies are actually being used, especially in a network with several access points. Automatic channel changes can also create new overlaps with Thread or Zigbee without the user noticing.

In my own network, I therefore configured all 2.4 GHz access points manually to use the same Wi-Fi channel: channel 11. I selected channel 11 because my Homey Thread network operates on Thread channel 15, and Wi-Fi channel 11 provides much greater frequency separation from it than Wi-Fi channels 1 or 6.

Using the same Wi-Fi channel on every access point does mean that access points which can hear one another must share the available airtime. However, this is often preferable to using strongly overlapping Wi-Fi channels, which can create more disruptive adjacent-channel interference.

This approach works particularly well when:

• 2.4 GHz is mainly used for IoT and low-bandwidth devices;
• access points are located on different floors or sufficiently far apart;
• transmission power is adjusted so that neighbouring access points do not overlap excessively;
• high-bandwidth devices primarily use 5 GHz.

The goal is not to maximise 2.4 GHz speed, but to create a predictable and stable radio environment for Wi-Fi, Thread and Zigbee.

[SunBeech]

Hello Pascal, Very usefull info. Especially also the 20/40 Mhz aspect.

Users might think that 40 is always better, because it is a higher number and/or seems to give you twice the WiFi speed. Especially in crowded areas with lots of such WiFi networks that is often not the case and can introduce instabilities in the WiFi network. Let alone, possible impact on other networks that use the same bands, like Thread en Zigbee.

Regarding the latter and in the context of Homey, are you planning to add some information on Zigbee networks. They use the same channel numbers as the Thread ones you are highlighting (not sure whether their frequency is also the same). On this forum you’ll often find references to this article that explains the overlap between WiFi and Zigbee channels: ZigBee and Wi-Fi Coexistence.

[Pascal_Nohl]

@SunBeech

Hello Pascal, Very usefull info.

Thank you.

@SunBeech

are you planning to add some information on Zigbee networks.

I had not originally planned to, but since you asked—and the relationship is quite straightforward—I will expand the original post with information about Zigbee soon. That way, everything will remain together in one place.
Done.

[Pascal_Nohl]

I would also like to point out that RSSI alone is not always a meaningful indicator of connection quality.

Let us take one example from my own network.

The Freedompro app reports an RSSI of -68 dBm for the roller-shutter relay that is the most difficult Wi-Fi device to reach in my house. For a smart-home device that exchanges only small amounts of data, that initially looks like a perfectly acceptable value.

Many consumer-grade routers do not expose detailed client signal information, but fortunately my Omada system does. The Omada access point reports approximately -74 dBm for the same relay.

Is one of those values wrong? Not necessarily.

They are effectively describing the connection in opposite directions:

• The relay measures how strongly it receives the signal transmitted by the access point.
• The access point measures how strongly it receives the frames transmitted by the relay.

The access point has a more capable radio, larger or better-positioned antennas and usually a higher transmit power. The small relay may therefore receive the access point quite well and report -68 dBm.

In the opposite direction, however, the relay has a small antenna, limited transmit power and is installed inside a wall box. Its reply may consequently reach the access point at only -74 dBm.

This is a normal example of an asymmetric wireless link. Differences in measurement methods and calibration between manufacturers may also account for a few decibels.

Another important point is that RSSI measures received signal strength, not the actual quality or usability of the connection.

My previous ASUS access points were extremely powerful and produced a strong signal throughout the house. In the WC, the reported RSSI was still approximately -68 dBm, yet a speed test achieved only around 8 Mbit/s.

With the new Omada access point in approximately the same position, the RSSI is weaker at around -74 dBm, but the speed test reaches approximately 87 Mbit/s.

The RSSI became worse, while the usable data rate became considerably better.

Possible reasons include:

• a better signal-to-noise ratio;
• less interference or airtime congestion;
• fewer retransmissions;
• better antenna and radio design;
• improved handling of multipath propagation;
• and more efficient channel and client management.

RSSI alone does not show noise, interference, packet loss, retries, latency or how much airtime is available. It also does not show whether the uplink and downlink perform equally well.

Without proper monitoring of both sides of the communication, it is therefore very difficult to draw reliable conclusions from a single RSSI value.

[Takie]

Very insightful posts! Thank you! Made me realize I have my Homey Zigbee/Thread on channel 20 and one of my wifi channels on 9. Which is the worst overlap! I won’t be able to change the wifi channel to something more suitable, so I’ll have to change the zigbee channel. Which will be a PITA I think because I will need to re-pair all my thread sensors and fix all the flows that use those sigh

[SunBeech]

@Takie

because I will need to re-pair all my thread sensors and fix all the flows that use those sigh

No, You only have to repair (not re-pair) the Zigbee devices. By repair I mean using the ‘Try to repair’ option that you’ll find in the Maintenance section in the device tile. If you repair existing devices, you don’t have to update any flows.

[Takie]

Is this also the case for thread devices? I have no zigbee devices (well, except Hue which are connected to their own bridge)

[SunBeech]

I don’t know. I only have experience with the Zigbee part (I had to perform a reset and repair my Zigbee devices).

Maybe an other user can confirm how it works with Thread based devices.

Note that, should you have to actually remove and re-pair your devices, then make sure to note the device ID that Homey assigned to each device, before you perform the reset. You can find them in the Devices section of the Homey Developer Tools.

After you re-paired devices (as part of which Homey assigns a new/different device ID), use the Flow Converter app to update the old with the new device IDs in your flows. This way you don’t have to update flows manually.

[dsdevries]

hey @Pascal_Nohl ,
Thanks for the interesting article. I already knew quite a lot about Wi-Fi, their bandwidths and channels, but not so much about the thread frequencies. Although I find it interesting to know how the channels of both technologies overlap, I doubt it will produce any noticeable real life side-effects.
Compared to a Wi-Fi network, a Thread network is very dormant. Every once in a while commands, attributes or events are send. These commands are often grouped in clusters creating only a few actual packages to be send. Compared to Wi-Fi, this is nothing. It wouldn’t have any noticeable effect on signal to noice.

The key takeaway here is to not mess around with your Thread network. Treat your Wi-Fi network as any other Wi-Fi network and optimize it how you normally would and follow the general recommendations. Keep the 2.4Ghz band to 20Mhz and optimize it for stability rather than speed. Use the least congested channels. If you have a modern gateway with multiple access points (unifi, tp-link, etc), leave channel selection to auto. If you are experiencing issues, debug the problem or switch to manual channel selection and pick channels far apart.

What also worked for me is to have the 5Ghz and 6Ghz networks broadcast on all APs and reduce the 2.4Ghz network to only a few APs. This keeps the 2.4Ghz network simple and manageable. In my house I have 4 AP’s, but only 2 of them are broadcasting the 2.4Ghz network.

I also have separate vlans for the IoT, Guests and Clients network. The IoT and Guests networks are only on 2.4Ghz, while the Clients network is only on 5Ghz and 6Ghz. I don’t have any legacy client device, so I don’t need 2.4Ghz. This also helps keeping signal to noice down.

[dsdevries]

@SunBeech

Users might think that 40 is always better, because it is a higher number and/or seems to give you twice the WiFi speed. Especially in crowded areas with lots of such WiFi networks that is often not the case and can introduce instabilities in the WiFi network.

The 2.4Ghz frequencies carry far, but do not have a high bandwidth to begin with. It doesn’t make sense to optimize the 2.4Ghz network for higher bandwidth. Any modern device that requires high bandwidths nowadays will use 5Ghz or 6Ghz. Doubling the channel width of the 2.4Ghz would still not match the bandwidth of the 5Ghz network, let alone the 6Ghz. As the 2.4Ghz frequencies carry far, doubling the channel width would only make the network less stable. Not only for you, but for all your neighbors as well. The 2.4Ghz network should be optimized for high stability serving devices that don’t require high bandwidths.

The 5Ghz network can be used to optimize for speed. If you use more access points with lower power (effectively whispering in your ear), you can safely choose 80Mhz channel width. In rural areas, you can even experience with 160Mhz channel width.

In the 6Ghz network you can even experiment with higher channel widths.

[Pascal_Nohl]

@dsdevries

Although I find it interesting to know how the channels of both technologies overlap, I doubt it will produce any noticeable real life side-effects.

I agree that channel overlap does not automatically create visible problems. In a small and quiet network, both technologies may coexist without the user noticing anything.

However, saying that it is unlikely to have real-life effects goes too far.

Thread and 2.4 GHz Wi-Fi use the same spectrum, but Wi-Fi occupies a much wider channel and normally transmits at considerably higher power. When they overlap, a Thread device may have to wait because the channel is busy, retry transmissions, or fail to deliver a message altogether.

The possible real-life effects are not necessarily dramatic or immediately obvious. They may appear as:

• delayed commands or state updates;
• occasional missed messages;
• devices temporarily becoming unavailable;
• additional retransmissions;
• increased battery consumption;
• or instability that appears only when Wi-Fi traffic is high.

The effect also depends strongly on signal strength. A Thread device with an excellent link may tolerate interference without noticeable consequences. A device near the edge of coverage may become unreliable with exactly the same channel configuration.

So channel separation is not a guarantee that Thread will be stable, and overlap does not guarantee that it will fail. It is simply one important source of avoidable interference.

For me, good channel planning is therefore preventive engineering: remove a known risk before spending days trying to diagnose intermittent problems later.

[SunBeech]

@dsdevries

Although I find it interesting to know how the channels of both technologies overlap, I doubt it will produce any noticeable real life side-effects.

I am not sure whether you made this remark from a Thread context only or for Zigbee as well.

From personal experience I do now that in the Zigbee context, overlapping channels can render a Zigbee network completely dysfunctional.

Some time ago I set up a temporary system with Zigbee2MQTT and a USB Zigbee dongle for the purpose of performing OTA updates on some of my Zigbee devices (Homey did not yet have that feature). The Zigbee device was in close proximity to the Zigbee dongle and that dongle only needed to manage that one Zigbee device. So a very simple setup.

If the Zigbee dongle operated on an overlapping channel with my 2.4Ghz WiFi, then Zigbee communication between the dongle and device was severely impacted and e.g. pairing a device was not possible.

So, at least in the Zigbee context, it can have noticeable real life side-effects.

[smarthomesven]

You can also use DFS channels on 5Ghz. I use this to prevent interference, since there are many networks from neighboring buildings in my area, and most of them use cheap ISP routers which don’t support DFS, so I can use the full channel bandwidth.

[dsdevries]

Well think of this from the perspective of the developers of Thread. Thread is a new technology developed knowing fully that it operates in the same frequency range as WiFi. They must have developed it in a way that doesn’t create any problems. As it turns out, they actually did!

First because of the relatively dormant nature of Thread, the fact that it uses very low transmitting power, and very narrow channels, means that it is virtually impossible that Thread will impose any noise or problem to Wi-Fi networks.

The other way around is actually possible. A busy Wi-Fi network on channel 1 can actually cause interference with a Thread network. However, there are mechanisms built into the Thread to make sure the network can cope with that.
First of all the Thread narrow 2Mhz channels are spaced strategically chosen to sit between the most busy part of the Wi-Fi channels.
Second, Thread can dynamically switch between channels to keep optimizing the signal to noise on the fly.
Third, Thread uses DSSS (Direct-Sequence Spread Spectrum). The bandwidth at which the radio is transmitting is actually wider than it needs in order to transmit the information it carries. This means that any noise introduced in the signal, is less likely to impact the actual information. It also carries redundancy information to be able to reconstruct the message in case some information actually has been destroyed.
Fourth, Thread has path redundancy. Information follows multiple paths across the network (from multiple devices to multiple devices). If one path was unsuccessful in transmitting the information, it can still flow across a different path.
Fifth, when all the other measures failed, it can simply try to send the message again. You will see this as MAC-layer retries. Any number below 15% is acceptable. If the numbers become higher, you will start to notice this in the performance of your network.

TBH, I wouldn’t worry about all of this too much. It’s premature optimization. When you encounter performance issues in your Thread network, it’s time to debug them. If you find High retries, maybe switch your WiFi to a different channel. If you encounter performance issues in your WiFi network, the problem is very unlikely to originate from your Thread network.

[Pascal_Nohl]

@dsdevries

Second, Thread can dynamically switch between channels to keep optimizing the signal to noise on the fly.

Yes, but not on Homey as it would disconnect all Zigbee devices that are on the same channel.

[Pascal_Nohl]

@dsdevries

Well think of this from the perspective of the developers of Thread. Thread is a new technology developed knowing fully that it operates in the same frequency range as WiFi. They must have developed it in a way that doesn’t create any problems. As it turns out, they actually did!

I agree that Thread contains several mechanisms intended to improve coexistence with Wi-Fi. However, I think some of your conclusions go considerably further than those mechanisms justify.

Thread does not make interference disappear. Listen-before-talk, spread-spectrum modulation, retransmissions and alternative mesh routes improve robustness, but every retry still consumes airtime, increases latency and may affect battery life.

Thread also does not necessarily change channels dynamically “on the fly”. A Thread network can perform a coordinated channel change, but this is an optional implementation feature and requires the network dataset to be updated. It is not comparable to continuous frequency hopping, and we cannot assume that every consumer implementation enables automatic channel selection.

Likewise, DSSS improves resistance to interference, but it should not be described as generally reconstructing damaged messages through redundancy.

The mesh provides alternative routes, but an individual packet is not normally transmitted simultaneously over several paths. A different route can be selected if the current one becomes unsuitable.

Finally, I am not aware of any universal Thread specification stating that a MAC retry rate below 15% is acceptable. That sounds more like a product-specific guideline.

So yes, Thread was designed to coexist with Wi-Fi, but coexistence mechanisms reduce the risk; they do not make channel planning irrelevant. Avoiding obvious overlap is a simple preventive measure, especially because intermittent interference is much harder to diagnose afterwards.

[dsdevries]

I’m not saying that interference of wifi signals cannot cause problems to a thread network. I’m just trying to say that worrying about it, or not choosing channel 1 for your Wi-Fi network, before you actually notice problems might be premature optimization. It could even do more harm than good, because your wifi network might actually perform better on channel 1.

The 15% retries is not a brand-specific recommendation. It has been a general guideline to indicate problems in radio communication in general. In radio communication, retries are unavoidable and could be attributed to a number of things and not necessarily to interference. Even in an optimal network Retries are typically around 3% to 5%. A retry percentage of 15%, means that over 92% of messages are simply delivered correctly. This should not impact the performance of your network to a noticeable degree.

If you are experiencing issues, you can start debugging and look for abnormal retries. If retries are generally high across your network, it might be an interference problem. If retries of a specific device are higher than normal, it might also just be a problem with that device.

I personally live in a city in an old brick building with wooden floors. There are about 200 apartments in close proximity. At any given moment there are over 100 Wi-Fi networks broadcasting at channel 1 that my APs can pick up. I have about 10 Thread devices connected to Homey and none of them experience Retries higher than 5%.

Again, I’m not stating that Wi-Fi interference cannot be a problem to a Thread network. I just find it highly, highly unlikely that it will cause any noticeable problems.

[Pascal_Nohl]

@dsdevries

If you are experiencing issues, you can start debugging and look for abnormal retries.

That is exactly the point where I disagree, both from a user perspective and from an engineering or network-design perspective.

If everything is running perfectly, adding just a single Wi-Fi device can still change the radio environment. It consumes airtime, participates in channel contention, may cause additional retransmissions and can influence how an access point schedules and transmits traffic.

If that device is mobile, such as a smartphone or laptop, the situation becomes even more dynamic because signal levels, modulation rates, roaming decisions and interference patterns continuously change as the device moves through the house.

Waiting until problems appear and then starting to debug them can therefore become extremely time-consuming. In the worst case, you may also discover that correcting the problem requires changing channel assignments or reconfiguring multiple devices.

A large part of this can often be avoided through proper network design from the beginning.

I know people who design and maintain Cisco and Meraki networks, as well as engineers working with professional Netgear AV networks. None of them would approach a network by simply deploying everything first and waiting for problems before thinking about RF design.

They spend considerable time planning AP placement, channel allocation, channel width, transmit power, expected client density, interference, roaming behaviour and the physical environment.

In many cases they deliberately start with the most restrictive and predictable configuration, even when that initially conflicts with what the customer would prefer. Additional flexibility is introduced later, once the consequences are understood.

Of course, troubleshooting and analysing retries is useful when a problem already exists. But that should be the second line of defence, not the design philosophy.

In fact, from a network-design perspective, I consider the advice to simply wait for problems and then look for abnormal retries potentially dangerous. It encourages users to build an RF environment without considering known interference mechanisms, on the assumption that they can debug it afterwards if something goes wrong.

The problem is that wireless failures are often intermittent and highly dependent on traffic, device location, neighbouring networks and time. By the time symptoms appear, the network may contain dozens of devices, and changing the channel plan can require considerable reconfiguration.

A good design should eliminate known and avoidable sources of interference from the beginning. Troubleshooting should then deal with the remaining unexpected problems, not with problems that could reasonably have been prevented during planning.

Preventing a predictable RF problem is almost always easier than trying to reproduce and repair an intermittent one afterwards.

Of course, the consequences are not comparable, but the engineering principle is the same: Would an aircraft engineer build a plane, fill it with passengers, send it into the air and say, “If something goes wrong, we’ll start debugging”?

Good engineering starts by identifying and eliminating foreseeable problems before they occur, not by deliberately waiting for them to appear.

[deejayreissue]

@Doekse Is there scope here to build a slightly different setup tool (advanced mode) which analyses a user’s wifi in the setup stage and Homey picks the most appropriate channels before Thread/Zigbee is enabled.
An extra selection to tell Homey the channels of other Zigbee networks (e.g. Hue Bridge) could be a good idea too.

Catching these issues early and also educating the user base on 2.4ghz would probably lead to much better consumer outcomes in the long term.

[Doekse]

I think the idea is sensible in principle, especially as an educational or advanced setup step, but I’m not sure it would solve as much as people might hope.

Most Zigbee/Thread coordinators will either scan for a suitable channel when the network is created, or use a default/allowed channel set. That initial choice is useful, but the 2.4 GHz environment is not static. Wi-Fi traffic, Bluetooth, neighbouring networks, microwave ovens and other interference can change at any time.

Wi-Fi generally copes with channel changes much better. Zigbee and Thread can use different channels, but they are not normally designed around frequent channel hopping in the same consumer-friendly way. On Zigbee especially, changing channel after devices have joined can be disruptive, and some devices may not follow correctly.

That said, we already try to educate users about this through our Knowledge Base articles, including guidance around Zigbee, Thread, Wi-Fi interference, placement, and building a stable mesh. There is always room to improve how and when that information is surfaced, but the basics are already documented for users who want to dive deeper than “I just want it to work”.

Below is an example of my own 2.4 GHz spectrum. Thread/Zigbee settled on channel 20, although based on the current interference profile, one of the lower channels would probably have been the better choice;