The smart home needed Matter, a universal language for connected devices that lets them talk to each other no matter who made them. But did it need Thread? We already had plenty of wireless protocols for most use cases — Zigbee for lighting, Z-Wave for security systems, Bluetooth for proximity control of devices like locks, and Wi-Fi for high-bandwidth needs such as cameras. If Matter had provided a secure, simple, local way to unify those protocols, it might be in a better place today.
Instead, Matter chose to use Wi-Fi and Thread for wireless communication, with other protocols needing to “bridge” into Matter, requiring an extra step from manufacturers that few have chosen to implement. So, why pick the relatively new Thread over existing options?
Probably politics. Two of the largest players in bringing Matter to fruition — Apple and Google — were already fully onboard the Thread smart home train when the Connectivity Standards Alliance (CSA), the group behind Matter, was formed. (Thread was originally developed by Nest, pre-Google, back in the early 2010s.) Plus, Thread is based on Zigbee, and the CSA was formerly the Zigbee Alliance.
But while the open-sourced Thread protocol does have compelling features (see sidebar), its rollout as part of the major shift Matter is trying to make in our smart homes needed to be better.
The problem is the current state of the Thread infrastructure, in particular, Thread border routers, which Thread devices need to connect to the internet and other IP-based networks. There are still relatively few Thread devices available to buy, and some platforms only halfheartedly support the protocol (most notably Amazon), making buying and setting up Thread-powered gadgets confusing and complicated.
But the biggest issue is the inability of the major platforms to get their act together and agree on how to implement one of Thread’s biggest benefits: a shared mesh network that any border router from any manufacturer can join to provide you with a robust, fail-safe, local smart home network.
This failure is not purely technical; it’s mostly political. The CSA and the Thread Group have left it up to the platforms and device manufacturers to figure out how to share this powerful new network in your home.
The Thread specification includes a foundation for adding a border router from any manufacturer to any Thread network, but Jonathan Hui, VP of technology at Thread Group, tells me, “Thread does not currently specify a protocol for securely sharing Thread credentials between different Thread Border Routers.” Meaning they don’t necessarily all join together on one network. “The platforms have yet to agree on a standardized way to share Thread credentials amongst each other,” Stefan Bauer-Schwan of smart home device maker Eve Systems tells me.
This is turning what should be an open network for IoT into yet another opportunity for walled gardens and special partnerships — exactly the situations Matter was advertised to prevent.
What’s the big deal about Thread border routers?
A border router is a key part of Thread. You need one, along with a Matter controller, to set up Matter-over-Thread devices in your home. Unlike Matter controllers, which are usually smart speakers or smart home hubs, a border router is not proprietary or platform-specific, and unlike traditional bridges and hubs, it doesn’t have to be a little white box hanging off your router.
The big selling point of a border router is that it can be built into any always-powered Wi-Fi device (such as routers, smart speakers, heck, even a TV or refrigerator) and can work with any Thread device, regardless of manufacturer. Some Matter controllers can also be Thread border routers, confusing the situation even more.
I have multiple border routers in my home, including Eero Wi-Fi routers, an Echo fourth-gen smart speaker, a SmartThings hub, an Apple TV, a HomePod Mini, two Nest Hubs, and some Nanoleaf light panels. But instead of one nice strong Thread network with multiple fail-safes, I have five, yes five, separate Thread networks, all competing with each other to gobble up any Thread devices I try to add to my network. And, once there, they can’t always see or talk to Thread devices on the other networks, thus breaking my smart home.
I have multiple Thread networks because the main Matter platforms — Apple, Google, Amazon, and Samsung — haven’t all agreed on who gets to own that one big network in your home. Instead, anytime I get a new device that’s a Thread border router, it’s just as likely to set up its own Thread network as to join one that’s already there.
This makes Thread’s biggest promise — that robust, self-healing shared mesh network — largely vaporware unless you stick with one or two manufacturer’s border routers. Something that’s going to be harder to do as more and more devices that can be border routers are launched; it’s not even possible to buy smart speakers, routers, TVs, and fridges all from the same company.
Shared mesh, wherefore art thou?
A shared mesh is the foundation of Thread. It has a lot of features, but key to it is the ability for multiple Thread border routers to join together to form a single network. This creates a stable, self-healing mesh network for all your Thread-powered locks, lights, sensors, and thermostats, with multiple fail safes.
Its “shared’ nature provides redundancy and improves reliability — if one border router fails, another can pick up the slack, so your network will keep on ticking. Also, more border routers mean a broader reach for your network and less latency because devices have shorter pathways, Thread Group’s Hui tells me.
Anytime I get a new device that’s a Thread border router, it’s just as likely to set up its own Thread network as to join one that’s already there
To form this shared mesh, border routers have to be using the Thread 1.3.0 specification. As of today, most are. Apple added support with iOS 16.5, putting its HomePods and Thread-capable Apple TVs on 1.3.0. All of Google’s border routers are on 1.3.0, as are Samsung’s various options. Nanoleaf has updated its border-router-capable lighting panels to support joining existing Thread networks, and Amazon’s Thread-capable Eero Wi-Fi routers are on 1.3.0.
(Amazon’s lone Alexa border router — the Echo fourth-gen smart speaker — is still on 1.1. Amazon spokesperson Connor Rice says the speaker “supports all Thread 1.3.0 features required of Matter devices.” But the Echo isn’t a Matter device; it’s a Matter controller, and Matter doesn’t require Thread certification for controllers.)
Next, these border routers have to share credentials with each other — similar to using a password to join a Wi-Fi network. To keep this messy, risky password-sharing process out of the hands of users, the Thread Group decided to make Thread networks self-configurable — i.e., they set themselves up.
Now, when a new Thread device or border router shows up in your home, something has to give it the credentials to the network (besides you typing in a 32-digit alphanumeric code). For a Thread gadget like a plug or light bulb, it should be able to grab those from whatever phone you set it up with. To do this, Apple and Google created keychain APIs for their phone OS, through iOS for an iPhone or Google Play services for Android.
But when a Thread border router wants to join the network, it may not be able to access those credentials, or it may choose not to. Because border routers aren’t Matter devices, Matter doesn’t specify how it joins the network. And because Thread Group hasn’t told manufacturers and platforms how to handle this handshake, they have to figure it out between themselves.
This means Apple has to work with Samsung; Amazon has to work with Google; Google with Samsung, and so on. While this is happening, it’s been very slow. And the current state of play is that the manufacturer can decide if its border router will join the Thread network created by its competitor or go ahead and set up its own network in your home.
Currently, Amazon border routers will only work on a network set up by their devices (some Eero Wi-Fi routers and Echo fourth-gen smart speakers) and won’t join an existing Thread network nor allow devices from other manufacturers to join their networks.
According to Amazon’s Rice, the company plans to fix this soon: “We’re currently previewing an API with developers for Thread credential sharing that will enable, with the customer’s consent, the device maker to read Thread credentials through an Alexa Skill,” Rice says. When it arrives, this Skill will allow Amazon’s Echo smart speakers to join existing networks, as well as allow border routers from other manufacturers to join an Amazon Thread network.
It’s a similar case for SmartThings. Mark Benson, head of SmartThings US, tells me the SmartThings app stores the Thread network credentials of a SmartThings border router into the iOS or Android Thread credential storage, then other border router apps can, in theory, read those credentials during their setup process and join that Thread network. “Whether they do that or not is up to each border router manufacturer,” he says.
If you already have a Thread network set up and add a SmartThings device that’s a Thread border router, it will set up its own network. “We are continuing to test different network configurations and interoperability between border routers and would like to enable this in the future in collaboration with others in the industry,” says Benson. “Today, to ensure the best experience for our users, we set up a new SmartThings Thread network.”
It’s back to Android vs. iPhone
To complicate things further, those Android and iOS APIs for managing Thread credentials “do not currently synchronize with each other,” says Thread Group’s Jonathan Hui. So, how your Thread network is configured and what border routers can join it will depend on which phone you used to set it up.
A border router you set up using iOS won’t see or talk to those you set up with Android unless you first set it up with iOS. And this only works if the platform or device has both an Android and iOS app.
If (or more likely when) you end up with multiple Thread networks, there is no easy way to merge them, something else the Thread spec doesn’t provide a path for.
Kevin Po, group product manager at Google, told me that while the capability exists to change network configurations “over the air,” it’s not easy. “The Thread Group is working with the industry on best practices for identifying when a given network should change its configuration and how to enable users to easily do so without disruption to their existing setup,” he said.
How your Thread network is configured and what border routers can join it will depend on which phone you used to set it up.
The two platforms that have things set up best right now are Google and Apple. It helps that they control the OSes where the credentials are shared and that they’ve been using Thread in their products for a few years now.
Google’s Po tells me that “Apple and Google Thread border routers can share the same Thread network by leveraging the iOS Thread network APIs.” So, you could have a Google Nest Hub Max and an Apple TV join a single Thread network if you set them both up using an iOS device.
However, the same is not true in reverse because an Android phone can’t access the iOS keychain, and there is no Android app that will set up a HomePod or Apple TV (and probably will never be).
If you use both iOS and Android, Hui says that Google Home can synchronize Thread credentials across your devices and populate them on both platforms, allowing new Thread devices to join the same network regardless of which OS they were set up on. Eve’s Bauer-Schwan goes into more technical detail on this in this excellent interview with Frank-Oliver Grün.
So, while you might get a robust Thread network if you have all HomePods and Apple TVs and Google Nest devices that were set up on iOS, or all SmartThings hubs, or all Amazon’s border routers, you can’t easily mix and match — yet.
Multiple Thread networks do not allow devices to leverage each other for better connectivity
It’s worth noting that multiple Thread networks aren’t necessarily a problem, and it is — in theory — possible for separate Thread networks to communicate with each other over another IP-based network. But not having one shared mesh for all your border routers negates Thread’s biggest benefit. “Devices in different Thread networks do not form part of the same mesh, and so cannot leverage each other for connectivity,” Hui says. “As a result, they would not gain the benefits from a stronger mesh network.”
He does point out that “for most users, this may never be an issue given Thread’s inherent range and responsiveness.” But the ideal state is one big mesh love-in, where all your border routers support each other. Running just one border router isn’t recommended because if someone unplugs it, your network will fail, just like Zigbee and Z-Wave meshes will.
The solution is that the platforms and manufacturers need one way to share Thread network credentials across their platforms and devices, an industry standard for securely creating a single Thread network within the home.
Everyone is clearly working on this, based on my interviews for this article. But that’s also what most of them told me back in 2022 at the Matter launch event. We’re now nine months into Matter, and this problem is still here, and it’s about to get bigger as more Thread devices launch and more people invest in border routers to set up these devices.
The CSA and Thread Group need to put their collective foot down hard and either tell “the industry” that it needs to come together on this or provide a clear path for executing it. Because the green bubble blue / bubble platform fight is bad enough on our phones — we don’t need it in our homes.