Thread troubleshooting, in order of what is actually wrong
Most Thread failures are not radio failures. Work the list top to bottom and stop when the symptom clears.
Why this order#
The instinct is to blame the device first, then the radio. The real distribution is close to the reverse.
| Layer | Typical symptom | How often it is the cause |
|---|---|---|
| LAN discovery (mDNS, SRP) | Shows unresponsive in the app but responds to voice; works on one phone and not another; breaks after a router change | The most common by a wide margin |
| Thread network split | Half the devices are fine, half are slow, proximity does not explain it | Very common in multi-brand homes |
| Topology | One corner of the house is unreliable; unplugging a plug breaks a sensor | Common past 15 devices |
| Border router health | Everything Thread goes quiet at once, often after an update | Occasional, and obvious when it happens |
| Spectrum | Intermittent everywhere, worse when the microwave runs | Real, and over-diagnosed |
| The device itself | One device, one symptom, consistently | Least common |
That table is the whole page. The steps below just make it actionable.
The ordered diagnosis#
Confirm the symptom is Thread at all
A Matter device may be Thread or Wi-Fi, and they fail completely differently. Check the device page in your controller: Apple Home and Home Assistant both name the connection type. If it is Wi-Fi, go to the device will not join 2.4 GHz Wi-Fi or device unresponsive instead. If it is bridged from a vendor hub, the problem is the bridge, not Thread. See Matter bridges.
Test whether the mesh is fine and only discovery is broken
This is the highest-yield test on the page. Ask the device to do something through a path that does not use mDNS discovery from your phone: a voice command, or an automation that runs on the hub. If the light responds to voice but shows unresponsive in the app, the device is healthy on the Thread mesh and your controller cannot find it on the LAN. That is a network configuration problem, and steps 3 and 4 fix it. If nothing works by any path, skip to step 5.
Fix multicast on your home network
mDNS is multicast, and home networks break multicast in four predictable ways. Turn off client isolation (sometimes called AP isolation or guest mode) on the SSID your controller and border router use. Check IGMP snooping on managed switches and mesh systems: badly configured snooping without a querier silently drops multicast. If your IoT devices are on a separate VLAN or SSID from your phone, you must run an mDNS repeater or reflector across that boundary, or discovery cannot cross it. Finally, disable any "smart" multicast optimization your mesh vendor enabled by default. The full configuration is in the network setup a smart home wants.
Put the controller, the border router and the phone on the same subnet
Temporarily, as a test. Move your phone off the guest network, disable the VPN, and confirm the border router shares a VLAN with the controller. If everything works when they share a subnet, you have proven it is a boundary problem rather than a Thread problem, and you can fix the reflector properly instead of guessing.
Count your Thread networks
Open your controller's Thread diagnostics. Home Assistant's Thread panel lists every network it can see with the border routers underneath; Apple Home shows its network name in Home Settings; Alexa shows almost nothing. If you see more than one network, that is very likely your problem, and the fix is credential sharing rather than re-pairing. Why you have three Thread networks has the steps, and Thread devices dropping or split networks covers the diagnosis in more depth.
Check the border router is actually up
Reboot it and watch what recovers. If you run the Home Assistant OpenThread border router add-on, check you are current: the add-on has documented issues including a mDNS regression in OTBR 3.0.0 (issue #4634) and reports of the border router becoming unreliable after a few days (issue #4504). Home Assistant 2026.6 replaced the mDNSResponder implementation with OpenThread's own mDNS code to address this class of failure. If you have only one border router, add a second, because a single one is a single point of failure for every Thread device you own.
Count your routers
In the same diagnostics screen, count devices in the Router or Mesh Extender state. If the answer is one, everything is hanging directly off the border router and there is no mesh. Battery devices are sleepy end devices and never relay, so the fix is a mains-powered Thread device (a plug, a bulb, a wired switch) between the border router and the problem area. Two plugs usually beat another border router. See mesh design.
Look for the physical cause
Check what changed. A border router moved into a media cabinet or metal rack, a new appliance between two rooms, or a radio dongle plugged directly into a USB 3.0 port. USB 3.0 produces broadband noise across 2.4 to 2.5 GHz that cannot be filtered because it is in-band; the fix is a 1 to 2 meter USB 2.0 extension cable, which is why Nabu Casa ships one with the Connect ZBT-2. Also check whether the radio is attached over PoE or Wi-Fi rather than USB: the Spinel host-to-radio link assumes a fast, lossless connection and behaves poorly over a network hop.
Change channel only now
If your logs show
ChannelAccessFailure, the radio tried to transmit and never found the channel clear. That is congestion. Compare your Thread channel with your Wi-Fi channels: Wi-Fi 1 covers 802.15.4 channels 11 to 14, Wi-Fi 6 covers 16 to 19, and Wi-Fi 11 covers 21 to 24. Home Assistant recommends channel 26 in heavy Wi-Fi interference, with the caveats that many North American radios reduce transmit power there and that Bluetooth advertising channel 39 sits at the same 2480 MHz. Use the channel planner and read 2.4 GHz interference before you move anything, because changing the Thread channel can require devices to re-attach.Re-pair the device, last
If one device fails consistently while everything else on the same mesh is fine, now it is reasonable to suspect the device. Remove it from the controller first, then factory reset it, then add it back. Doing this in the wrong order leaves ghost entries that cause their own confusion. Removing and re-pairing devices cleanly has the order per platform.
Symptom lookup#
| What you see | Most likely cause | Go to |
|---|---|---|
| Unresponsive in the app, works with voice | mDNS blocked on the LAN | Steps 3 and 4 |
| Works at home, fails on cellular | Remote access, not Thread. Your hub or controller is unreachable | Local vs cloud control |
| Half the Thread devices are slow | Two Thread networks | Network merging |
| One corner of the house is unreliable | No relay in that direction | Mesh design |
| Everything Thread died at once | Border router down or rebooting | Step 6 |
| New device will not pair at all | Commissioning, not Thread routing | Matter pairing fails |
| Automations fire seconds late | Where the automation runs, not the mesh | Automations run late |
| Intermittent everywhere, worse in the kitchen | Microwave and Wi-Fi congestion | Step 9 |
What each platform lets you see#
Diagnostic visibility varies enormously, and it changes what "check the mesh" even means for you.
| Platform | What you can see | Practical effect |
|---|---|---|
| Home Assistant | Thread panel listing networks, border routers, and dataset details; OpenThread logs including ChannelAccessFailure | The best diagnostic view available to a consumer |
| Apple Home | Thread network name, and a per-accessory view of role and connection | Enough to spot a split network and count routers |
| Google Home | Limited, improving on Thread 1.4 hardware | You can usually confirm the border router, not much more |
| Alexa | Almost nothing published | Diagnosis is largely by elimination |
| SmartThings | Some Thread detail in the hub view | Middle of the pack |
If your platform shows you nothing, adding Home Assistant as a passive observer is a legitimate diagnostic move even if you never migrate automations to it. Running two platforms on purpose covers the setup.
Things that do not fix Thread problems#
- A Wi-Fi extender. Thread does not use Wi-Fi. Extending Wi-Fi coverage does nothing for the mesh, and a badly placed extender adds 2.4 GHz noise.
- A different brand of border router. Unless it joins your existing Thread network, it makes a new one and splits your relays.
- Moving the border router closer to the failing device. This usually strands whatever was relying on its old position. Add a relay in between instead.
- Re-pairing repeatedly. If the cause is mDNS, the device pairs successfully every time and then goes unresponsive again.
- Changing Wi-Fi to 5 GHz only. It removes interference and also stops most of your smart home from working, because nearly every IoT device is 2.4 GHz only.
Why do my Thread devices keep going unresponsive?
The most common cause is not the mesh. It is mDNS discovery failing on your home network, so the controller cannot find a device that is perfectly healthy on Thread. Client isolation, IGMP snooping, VLAN boundaries without an mDNS reflector, and multicast optimization on mesh routers all cause it. Test by using voice: if voice works and the app does not, it is discovery.
How do I know if my Thread network is split?
Look at Thread diagnostics for more than one network name. Home Assistant's Thread panel lists networks with their border routers; Apple Home shows its network name in Home Settings. The behavioral tell is that some Thread devices are consistently fast and others consistently slow, and moving devices physically closer to a border router does not change which group they are in.
Should I reset my Thread border router?
Not as a first step. A reset usually means re-pairing every Thread device attached to it, and it does not fix discovery problems, split networks or missing relays. Reboot it, check for firmware updates, and only reset after you have ruled out mDNS, network splits and topology. Adding a second border router is usually more useful than resetting the first.
Why does my Thread device work with Siri but show as unresponsive?
Because those two paths use different mechanisms. A voice command routes through the home hub to the device over Thread. The app tries to discover the device over mDNS on your LAN first. When mDNS is blocked, the mesh side keeps working and the app side does not. Fix multicast on your network rather than re-pairing the device.
What does ChannelAccessFailure mean in OpenThread logs?
The radio tried to transmit, listened first as the protocol requires, and never found the channel clear enough to send. That is congestion on your 802.15.4 channel: usually an overlapping Wi-Fi network, sometimes a microwave, a video baby monitor, or USB 3.0 noise. It is a spectrum problem, not a broken device. Compare your Thread channel against your Wi-Fi channels before changing anything.
Do I need to re-pair Thread devices after changing my Wi-Fi router?
The Thread devices themselves are unaffected, because they are not on your Wi-Fi. What usually breaks is discovery: the new router has different multicast, IGMP and client isolation defaults. Check those settings before touching any device. If the border router connects over Wi-Fi rather than Ethernet, it will need its own network credentials updated.
How long should a Thread device take to recover after a reboot?
Give it several minutes, not seconds. A rebooted border router has to rejoin or reform the network, routers re-establish links, sleepy end devices re-attach to a parent on their own polling schedule, and service records have to be republished over SRP and mDNS. If a device has not come back after 15 minutes, then start diagnosing.
Can too many Thread devices break the network?
Not in the way people expect. The limits are 32 active routers and a per-parent child limit that real firmware sets well below the 511 protocol ceiling, and practical guidance in the field is around 250 devices per network. Homes hit relay and link-quality problems long before address limits. If you are past 40 devices and struggling, look at router placement rather than device count.
Primary sources
Specification and vendor documentation we checked while writing this page. Where a claim depends on firmware behaviour rather than a published spec, the page says so inline.