# Understanding Thread/Zigbee and Wi-Fi Channels and How to Avoid Common Mistakes **URL:** \ **Category:** Questions & Help\ **Tags:** tutorial\ **Created:** [August 3, 2026, 9:59am UTC](https://community.homey.app/t/understanding-thread-zigbee-and-wi-fi-channels-and-how-to-avoid-common-mistakes/157859 "2026-08-03T09:59:33Z")\ **Posts on this page:** 2\ **Page:** 2
**Author:** ![Pascal\_Nohl](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/pascal_nohl/32/164446_2.png) [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)\ **Post date:** [August 7, 2026, 11:21am UTC](https://community.homey.app/t/understanding-thread-zigbee-and-wi-fi-channels-and-how-to-avoid-common-mistakes/157859/21 "2026-08-07T11:21:17Z")
> [@deejayreissue](#): > > Is there scope here to build a slightly different setup tool That would be great, but Homey currently does not even allow the user to select the Thread channel during setup. Even afterwards, the channel cannot simply be chosen in the normal interface. In Developer Tools you can reset the Thread channel, but you do not select a specific value. Homey chooses another channel, so if the result is unsuitable you have to repeat the process until you eventually get one that works well with your Wi-Fi environment. That can become quite a guessing game. Your idea would therefore be very useful in principle. During setup, Homey could ask which 2.4 GHz Wi-Fi channel or channels are being used and then suggest or select the Thread channel with the least expected overlap. However, I also see some practical problems for average users. Many consumer routers are configured to use automatic channel selection, and additional access points often use Auto as well. The user may therefore not even know which channels are currently in use, and different APs may use different channels. Homey could select the best Thread channel at the time of setup, but that would not necessarily produce an optimal result without also changing the Wi-Fi channel plan. Even if the initial configuration were perfect, an access point using automatic channel selection could later move to another Wi-Fi channel and create interference that did not exist during setup. So I am not sure that fully automatic Thread channel selection based on the current Wi-Fi environment would be the best long-term solution. What I would really like to see is a simple choice during setup: - **Auto** - or **Manual** , allowing the user to select the desired Thread channel directly. That would keep the setup simple for normal users while giving advanced users control over their RF design. ---
**Author:** ![Pascal\_Nohl](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/pascal_nohl/32/164446_2.png) [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)\ **Post date:** [October 4, 2026, 10:35am UTC](https://community.homey.app/t/understanding-thread-zigbee-and-wi-fi-channels-and-how-to-avoid-common-mistakes/157859/22 "2026-10-04T10:35:39Z")
**Some new findings I’d like to share** **1. Hidden networks you can’t control** Your home may contain devices that build their own hidden Wi-Fi networks. You can’t manage them, and they can cause real trouble. In my case there are two of them: - **Aqara G4 doorbell:** The chime connects to my Wi-Fi and then builds its own hidden network to talk to the outdoor unit. Omada can’t control it. - **Eufy HomeBase S380:** This one is much worse. It’s connected by Ethernet but runs its own very strong hidden 2.4 GHz network for the cameras. An Omada interference scan shows it, but there’s no way to set its channel. Switching the HomeBase from “Performance” to “Standard” mode is supposed to pin it to channel 11. For me it moved to channel 6 anyway, at −27 dBm and only 3 m away from my Thread radio. You might think: fine, then move your own channels out of its way. Unfortunately the HomeBase hops channels on its own, so you can’t plan around it. How I found it: The OpenThread Border Router add-on log in Home Assistant was full of \*\*`ChannelAccessFailure`\*\*errors, many per minute. That means the Thread radio couldn’t transmit because the channel looked busy. My Thread network runs on channel 15 (2425 MHz), which sits right between Wi-Fi channels 1 and 6. When I unplugged the HomeBase, the errors stopped almost immediately, and all 71 Matter devices came back. Moving the ZBT-2 away from the cluster of radios helped as well: the access point, the HomeBase, Homey and the Hue Bridge had all been within 1.5 m of it. **2. Thread is not independent of your LAN and Wi-Fi** This one surprised me. Thread devices talk to each other over 802.15.4 radio, but everything around them runs over IP: - Matter controllers reach Thread devices through the border routers, using IPv6 over your LAN. - Border routers announce themselves and their routes with IPv6 multicast (mDNS, Router Advertisements). - Several border routers can link up directly over the LAN or Wi-Fi (TREL). And HomePods are border routers that are **only on Wi-Fi**. So when the LAN hiccups, Thread devices drop offline, even though the Thread mesh itself is fine. In my case I suspect an unstable link between my router and the main switch. My main suspect is a third-party SFP module that is sold as “compatible”, and I have a support ticket open. Every time that link flaps, the switches flush their MAC tables (spanning tree topology change). Multicast snooping can also lose its state for a while. The result is that border routers briefly lose each other and the Matter server’s sessions time out. The symptoms looked like this: - Devices go unavailable **in waves** : many at once, across all brands and device types. - Battery devices (sleepy end devices) are hit hardest. They depend on a single parent router. - A device can answer a ping and still show as unavailable in HA. The subscription keeps dropping. - Unplugging and replugging the router–switch cable fixes it, at least for a while. **3. Things that helped me narrow it down** - **Change one thing at a time** and write down the time. Otherwise you’ll never know what caused what. - Check the **OTBR add-on log** for `ChannelAccessFailure` (radio interference) and `NoAck` (neighbor not answering). - Check the **Matter server log** for waves of `offline grace period expired`, and compare the timestamps with network events. - Run an **interference scan on your access point** , also in the 2.4 GHz band, and look for strong hidden SSIDs. - Keep your Thread border router’s radio **away from other 2.4 GHz devices**. A USB extension cable helps. - Be careful when restarting controllers that use **Matter multi-admin** (Homey, in my case). On startup they re-subscribe to every device at once, which floods the mesh for a while. [Previous page](https://community.homey.app/t/understanding-thread-zigbee-and-wi-fi-channels-and-how-to-avoid-common-mistakes/157859.md?page=1)