Why you have three Thread networks, and how to fix it
Four border routers in one house usually means four weak meshes, not one strong one. Here is the mechanism and the manual fix.
What a Thread network actually is#
A Thread network is defined by a set of parameters called the Active Operational Dataset. The ones that matter:
| Parameter | What it does |
|---|---|
| Network key | The master secret. Two devices with different network keys cannot join the same mesh, no matter how strong the radio link. |
| PSKc | The commissioner credential, derived from the network name, passphrase and extended PAN ID. |
| Channel | Which 802.15.4 channel, 11 to 26, the mesh operates on. |
| PAN ID and extended PAN ID | Network identifiers used to distinguish neighboring meshes. |
| Network name | The human-readable label you see in diagnostics. |
Two Thread networks in the same house are not "one network having trouble". They are two networks, in the strict sense that neither can decrypt the other's traffic. A device on network A physically sitting next to a router on network B gets nothing from it. That is why "I added another HomePod and it did not help" is such a common report.
Why it happens by default#
When a controller sets up Thread for the first time, it generates a random network key and forms a fresh network. It has no way to know whether another network exists in the house, and no authority to join one if it did, because joining requires the credentials it does not have.
So the default outcome in a mixed-brand US home is predictable:
- Apple Home forms a Thread network on its HomePods and Apple TVs.
- Google Home forms one on its Nest Wifi Pro or Google TV Streamer.
- Alexa forms one across the Echoes and eeros.
- SmartThings forms one on the Station or the hub inside the TV.
- Home Assistant forms one on the Connect ZBT dongle.
Each of those is a real Thread network with its own key. The Thread fragmentation report tracks the vendor-by-vendor state.
What fragmentation costs you#
The one thing fragmentation does not do is break commissioning. A device pairs into whichever network its controller offers, and it works. It just works on a weaker mesh than the hardware you own should provide.
Thread 1.4 credential sharing, precisely#
Thread 1.4, published in September 2024, made credential sharing a required capability for certified border routers. Here is the actual mechanism, because the marketing summary ("Thread networks now merge") is misleading.
The border router that owns the network displays a Thread Administration One-Time Passcode: nine digits, shown as three groups of three, or the same information as a QR code. Both sides derive an ephemeral pre-shared key from that passcode. The requester opens a DTLS session to the border router and pulls the Active and Pending Operational Datasets, which is to say the network key, PSKc, channel and PAN ID. From that point the requester can form or join the same network.
Three properties decide how this feels in practice:
- It is user triggered. Somebody has to open a settings screen and produce the code. Nothing happens on its own.
- It is single use. The passcode is consumed by one exchange.
- It times out. Take too long and you start again.
So Thread 1.4 gives you a supported, secure way to merge networks. It does not give you automatic merging, and it never claimed to. Anyone telling you Thread 1.4 fixed fragmentation is describing the capability, not the experience.
Where each ecosystem stands, September 2026#
| Ecosystem | Will it share credentials out? | Will it accept credentials in? | Notes |
|---|---|---|---|
| Apple Home | Yes, to an iPhone or iPad, and the phone can pass them to other apps | Partially, in practice Apple prefers its own network | Apple TV moved to Thread 1.4 in a June 2026 update, and HomePods had not as of September 2026 |
| Google Home | Yes, and the Google TV Streamer (4K) can share by QR code | Improving, best on Thread 1.4 hardware | Nest Hub 2nd gen and Nest Hub Max were still on Thread 1.3 as of September 2026 |
| Alexa | Limited and poorly documented | Limited | Amazon exposes almost no Thread detail. Version claims are unconfirmed |
| SmartThings | Yes on Thread 1.4 hardware | Yes | The Station and Aeotec hubs are the usual anchors |
| Home Assistant | Yes, and it is the most transparent about it | Yes, it can import datasets from a phone | The Thread panel names each network and border router |
The pattern is that the two ends of the market cooperate best. Home Assistant and Apple expose the mechanics; Amazon exposes almost nothing.
How to actually do it#
The realistic goal is not "one network for everything". It is "one network for the devices that need to relay for each other, and no accidental splits".
Pick the anchor network
Choose the ecosystem with the most mains-powered Thread devices and the best border router coverage, because that is the mesh you want everything else to join. In most US homes that is Apple (several HomePods) or Home Assistant (a ZBT dongle plus known-good diagnostics). Write down the network name from its diagnostics screen.
Inventory what you have
List every Thread-capable box and which ecosystem it serves. The border router directory is the fastest way to check whether something is a border router at all, and the border router finder lets you filter it. Note that the Apple TV 4K 3rd generation only qualifies in the Wi-Fi + Ethernet 128 GB configuration.
Export credentials from the anchor
On iOS, share the Thread credentials to the phone from the Home app or from the Home Assistant companion app's Thread screen. On Home Assistant, open Settings, Devices and services, Thread, and use the option to send credentials to the phone. On a Thread 1.4 Google border router, generate the QR code or the nine-digit passcode from the Google Home app.
Feed them to the second ecosystem
On the receiving side, look for an option worded as "join existing Thread network", "import credentials" or "sync Thread credentials". On Android, the Home Assistant companion app exposes Thread credential syncing under Settings, Companion app, Troubleshooting. If the receiving controller offers no such option, stop here: that ecosystem will keep its own network, and you plan around it rather than fighting it.
Verify before you move devices
Open the diagnostics on both sides and confirm they now report the same Thread network name and, where shown, the same extended PAN ID. Two controllers claiming the same network name is the confirmation you want. If the names still differ, nothing merged.
Re-pair only what needs it
Existing devices stay on the network they joined. They do not migrate when credentials are shared. Devices that must move have to be removed and re-added, in that order, or you leave ghost entries behind. Follow removing and re-pairing devices cleanly.
Re-check the mesh a day later
Give the network a full day, then count routers and border routers again. A merged network should show more routers than either original did, and devices should be reachable from more than one direction.
When not to bother merging#
Merging is worth real effort when you have many battery Thread devices and coverage problems. It is not worth it in these cases:
- You use one ecosystem. Nothing to merge. Add a second border router of the same brand instead.
- The second ecosystem holds two devices. The mesh benefit is negligible. Accept two networks.
- Your problem is discovery, not topology. If devices show as unresponsive in one app but respond to voice, this is an mDNS problem and merging will not touch it. Go to Thread troubleshooting first.
- You are running two platforms on purpose. Running two platforms deliberately is a legitimate design, and Matter's multi-admin sharing operates at the fabric level, above Thread. A device shared to a second controller does not need a second Thread network.
What to expect next#
The direction of travel is toward controllers that offer to join an existing network during setup rather than silently forming a new one, which is the behavior Thread 1.4 credential sharing was designed to enable. Matter's own multi-admin work continues in parallel and solves a different problem: sharing a device between controllers rather than sharing a network between border routers. Both are needed. Track the gap between specification and shipping support in the Matter feature gap tracker.
Why do I have more than one Thread network?
Because each controller forms its own when it first sets up Thread, using a randomly generated network key. It cannot join an existing network without that network's credentials, and nothing hands them over automatically. Adding an Apple, Google and Amazon device to one house therefore produces three networks by default rather than one shared mesh.
Can Apple and Google Thread networks be merged?
They can share credentials, which is how merging is done, but the experience depends on firmware on both sides and it is a manual process. The Google TV Streamer (4K) can produce a QR code for sharing, and Apple can pass Thread credentials to an iPhone. As of September 2026, expect to do this by hand and to verify the result in diagnostics rather than trusting the UI.
Does Thread 1.4 merge networks automatically?
No. Thread 1.4 made credential sharing mandatory for certified border routers, but the exchange is started by a person, uses a single-use passcode or QR code, and expires. It is a secure, standard way to join an existing network. It is not automatic discovery and merging of nearby meshes.
What is a Thread network key?
The shared secret that defines the network. Every node holds it, and it is what makes traffic on one Thread network unreadable to another. It is part of the Active Operational Dataset along with the PSKc, channel, PAN ID and network name. Sharing credentials means transferring that dataset over an authenticated DTLS session, not typing a key in by hand.
Will merging networks make my devices faster?
Sometimes, and for a specific reason: a merged network has more routers, so a device may find a shorter or stronger path to a border router. If your latency problem comes from a cloud round trip or a controller running automations remotely, merging changes nothing. Where the seconds go in a late automation separates the two.
Do I have to re-pair devices after merging Thread networks?
Devices stay on the network they originally joined. Sharing credentials does not move them. If a device sits on a network you are retiring, remove it from its controller first, then add it to the target controller, so you do not leave orphaned entries. Devices already on the anchor network need no action.
How can I tell how many Thread networks I have?
Home Assistant's Thread panel is the clearest view: it lists each network by name with its border routers underneath. Apple Home shows its own network name in Home Settings. Google shows less, and Alexa shows almost nothing. If you cannot see the picture from your current controller, adding Home Assistant purely as an observer is a legitimate diagnostic move.
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.