Half your Thread devices responding to one hub while the other half respond to a different one looks like one broken network, but it’s actually one of two genuinely different problems. Telling them apart matters, because one fixes itself and the other doesn’t.
Direct answer: this is one of two different problems, not one
Problem one is a partition, the same Thread network, temporarily split by a radio dead zone, that will merge back together on its own once connectivity is restored. Problem two is two entirely separate Thread networks, formed independently by two different ecosystems in your home, that were never the same network to begin with and won’t merge without a specific mechanism designed for exactly that. The symptom, devices split into two groups that don’t talk to each other, looks identical from your phone. The fix is completely different.
Problem one: a partition, same network, lost radio connectivity
Thread’s own architecture documentation describes this directly. A Thread network can split into partitions when one group of Thread devices loses radio connectivity with another group. That can mean a dead zone forms, a device that was bridging the two groups gets moved or loses power, or physical interference cuts the path between them. Each partition then behaves, temporarily, like its own independent network, with its own leader and its own view of what devices exist.
Critically, both halves still share the same underlying network credentials. They were never two separate networks; they simply cannot hear each other for the moment.
Why a partition heals on its own, and what to check if it has not
Thread devices are built to actively look for other partitions of the same network and merge back in automatically once radio connectivity returns. Each partition carries information, a partition ID and a ranking, that devices use to decide which partition to merge into when they detect a stronger one nearby. This isn’t something you trigger manually; it happens as soon as the radios can hear each other again.
If a partition genuinely hasn’t merged after a reasonable wait, the underlying cause is very likely still a radio connectivity gap rather than a broken merge process: the two groups still can’t hear each other. That points back to placement: a device or repeater sitting between the two groups that’s been moved, lost power, or is now blocked by something new. Checking what physically changed in the space between the two device groups is a more productive step than assuming the merge logic itself has failed.
Problem two: two genuinely separate Thread networks
This is the one that doesn’t resolve itself, because there’s no partition to heal: there were always two different networks. It typically happens when two ecosystems each set up their own Thread border router independently: say, a Google Nest Hub forms one Thread network when you set it up, and later an Apple HomePod forms an entirely separate one, each with its own distinct credentials, because nothing told them to share.
Devices you added through the Google ecosystem join the Google-formed network. Devices you added through Apple join the Apple-formed one. Nothing is malfunctioning; each device is correctly connected to whichever network it was commissioned onto. They simply were never the same network.
Thread 1.4 credential sharing, and why it may not have merged them yet
Thread 1.4, finalized in 2024, added a mechanism specifically for this: border routers on the same local IP network can discover each other, negotiate, and synchronize onto one shared set of Thread credentials, effectively merging what used to be separate networks into one.
Whether this has happened in your home depends on whether the specific border routers involved (the ones inside your Google, Apple, Amazon, or other devices) have implemented that side of the 1.4 specification and have it active. As of 2026, this varies by platform and is still settling across the industry. A network that hasn’t merged this way isn’t necessarily broken; the credential-sharing negotiation may simply not be supported yet between that specific pair of ecosystems. For more on what a given border router actually needs to do its job, see how many Thread border routers you actually need.
The one test that tells you which problem you have
The fastest way to tell these apart: check whether the two groups of devices were ever added through the same app or ecosystem.
- Same app, same ecosystem, devices split into two groups → almost certainly a partition. Look at what changed physically between the two groups and give it time to re-merge.
- Different apps or ecosystems for each group (some devices added via Google Home, others via Apple Home) → almost certainly two separate networks. Whether they merge depends on Thread 1.4 credential sharing being active between those specific platforms, not on anything you did wrong.
If neither explanation fits (same app, same ecosystem) and it still hasn’t recovered after a genuinely long wait, that’s worth treating as a general connectivity problem rather than a Thread-specific one. Start with the device, radio, router or cloud test, and for the wider pattern of a device that used to be reliable and no longer is, see why a smart device that was working starts dropping off.
FAQ
How long should I wait before assuming a partition won’t merge on its own?
Thread’s merge logic runs continuously once radios can hear each other, so if the physical cause (a dead zone, a moved repeater) has been genuinely fixed, merging typically follows without a long wait. If it’s been a long time and nothing has changed physically, the partition explanation is less likely and it’s worth checking whether this is actually two separate networks instead.
Can I force two separate Thread networks to merge manually?
Not directly as a user action. Merging via Thread 1.4 credential sharing is a negotiation between the border routers themselves, not something triggered from a device settings menu. Whether it happens depends on both platforms supporting and enabling that feature.
Does it matter which ecosystem’s Thread network wins if they do merge?
The credential-sharing process elects one border router as the authority based on stability and precedence rules built into the specification; it isn’t something you choose manually.
Is having two separate Thread networks actually a problem if everything still works within each one?
Not necessarily. Two separate networks that each work fine for the devices on them is a fully functional (if slightly less efficient) setup. It only becomes worth fixing if you specifically need devices on both networks to interact directly with each other.
Will resetting my border router fix a partition that won’t merge?
Only if the underlying radio connectivity problem is also fixed. Resetting a border router without addressing what’s physically blocking the two groups from hearing each other is unlikely to hold.
Sources referenced in this article
- OpenThread, Node Roles and Types.
https://openthread.io/guides/thread-primer/node-roles-and-types(accessed 2026-08-06). Source of the partition mechanism, the automatic re-merge behavior, and the partition ID/ranking system devices use to merge. - Espressif Developer Portal, Thread Network Credentials Sharing.
https://developer.espressif.com/blog/2026/01/thread-credential-sharing/(accessed 2026-08-06). Source of the Thread 1.4 credential-sharing mechanism (discovery, negotiation, synchronization between border routers) and the caveat that platform adoption is not yet universal as of 2026.
Review interval: 6 months (Thread 1.4 platform adoption is actively changing).