Thread devices dropping, and how to spot a split network

Splits, partitions and dead spots are three different things#

These produce similar complaints and need different responses.

A split is two or more separate Thread networks. Different network keys, different extended PAN IDs, no possibility of relaying between them. This is permanent until you act, and it is the default outcome of buying border routers from two brands.

A partition is one network temporarily broken into pieces because a link failed. Each piece elects its own leader and keeps working. When the link returns, the partitions merge back automatically. Partitions are normal, self-healing, and not something to fix. Thread over Infrastructure in Thread 1.4, which tunnels 802.15.4 frames inside UDP over your Wi-Fi and Ethernet, exists partly to reduce them.

A dead spot is one network with no relay in a particular direction. Battery devices are sleepy end devices and never route for anyone, so a house with twenty battery sensors and one border router has no mesh at all, just twenty spokes.

Telling them apart matters because the fix for a split is credential work, the fix for a partition is nothing, and the fix for a dead spot is a mains-powered device in the right place. Designing a Thread mesh that holds up covers the third.

How you got more than one network#

Nothing about Thread merges networks automatically. A border router with no credentials creates a network: it picks a channel, generates a network key and a PAN ID, and starts advertising. Every device you commission through that ecosystem joins that network.

So the count follows your ecosystems, not your hardware. Three Apple border routers form one Apple network, because they share credentials through iCloud. Add an Echo, a Nest Hub and a SmartThings Station and you have four networks in one house. There is nothing broken about any of them, and the per-vendor state of this is tracked in the Thread fragmentation report.

The symptoms of a split#

A split does not usually look like a Thread problem. It looks like inconsistent devices.

• Two speeds. One set of devices is consistently fast and another consistently slow or flaky, and the sets do not correspond to distance from any single box.
• Distance stops predicting reliability. A device ten feet from a border router is worse than one across the house, because they are on different networks and the far one has more relays behind it.
• Adding a repeater does nothing. You plug in a mains-powered Thread device to help a struggling sensor and nothing improves, because the new device joined the other network.
• One ecosystem is fine, another is not. All Apple accessories work; the Alexa ones limp. Each network has its own router count and its own coverage map.
• The problem started when you bought a hub. A new speaker or streaming box quietly became a border router and started pulling new devices onto a second network.

Beware of the false positive: a device that shows as unresponsive in the app while voice control still works is a discovery failure, not a split. That is blocked multicast, which a device shows as unresponsive covers and the network setup a smart home wants prevents.

Proving it, platform by platform#

Diagnostic visibility differs enormously, and it changes what you can even check.

Firmware matters more than the box#

Credential sharing only works between border routers that implement it, which as of September 2026 means the hardware is uneven inside the same brand.

Apple TV moved to Thread 1.4 around June 2026, and the Google TV Streamer updated at roughly the same time, around 10 June 2026. HomePods and Nest Hubs had still not moved to Thread 1.4 as of September 2026. Amazon has committed to updating Echo devices, and exposes almost no Thread diagnostics in the meantime, so its status is hard to verify from outside.

The practical consequence is specific. If your only Apple border router is a HomePod mini, you cannot use Thread 1.4 credential sharing on the Apple side today, whatever the Thread Group specification says. Check what hardware you actually own before planning a merge. The border router directory lists what each device is, and the border router finder filters it by ecosystem.

What to do about it#

There are three legitimate answers, and merging is not always the best one.

Merge onto one network. This is right when your ecosystems all have 1.4 capable border routers and you want one mesh with every relay available to every device. The procedure, per ecosystem, is in why you have three Thread networks. Expect to re-pair some devices, and expect the merge to be a manual, user triggered action every time you add a new brand.

Pick one network and stop feeding the others. Often the pragmatic answer. Choose the ecosystem with the most border routers and the best diagnostics, commission all new Thread devices there, and share them to your other platforms with Matter multi-admin instead of commissioning them separately. Multi-admin shares the device, not the mesh, so a device stays on one Thread network while appearing in several apps.

Deliberately run two, but staff both. Acceptable if each network has several mains-powered devices to route through and the areas they cover are distinct. What does not work is one healthy network and one with a single border router and a scattering of battery sensors.

Whichever you choose, count relays afterwards. A Thread network targets 16 to 23 active routers and promotes standby devices when the count drops below 16, within a hard limit of 32. What matters at home is that mains-powered Thread devices exist between your border router and your problem areas. Two smart plugs usually beat a second border router.

Things that look like fixes and are not#

• Adding another border router of a different brand. It creates a third network and splits your relays further.
• A Wi-Fi extender. Thread is not Wi-Fi. It adds nothing to the mesh and adds 2.4 GHz noise.
• Factory resetting the border router. It usually forces you to re-pair every Thread device attached to it and does not merge anything.
• Moving the border router closer to the failing device. This strands whatever depended on its old position.

If you have merged and things are still unreliable, the cause is probably not topology. Work Thread troubleshooting, in order, which starts with mDNS and moves to radio. Interference is a real possibility too: Thread shares the 802.15.4 PHY with Zigbee and sits underneath your 2.4 GHz Wi-Fi, and 2.4 GHz interference has the channel math.