We need to talk about Thread

Note: This story ran in the May 13, 2022 newsletter, but because of a misunderstanding, parts of it were wrong and another part needed clarification. I have adjusted the post below to provide y’all with the most accurate and most recent information.

Thread launched back in 2014 as a wireless networking protocol designed for a world of millions or billions of connected devices. The idea behind the radio was that connected devices such as sensors, thermostats, doorbells, etc. needed mesh capabilities, the ability to conserve power, and a direct connection to the internet.

While the code underneath has changed, the basic design of the technology and its requirements haven’t changed much. It has since become the low-power data transfer option for the Matter smart home interoperability standard, which means Thread will soon play a huge part in smart home and building infrastructure.

But it does have a few problems the industry needs to address.

Thanks to my own experiences with Thread and conversations with several device manufacturers that have embraced the technology, it’s clear that there are two key areas where the protocol needs some work. And that work needs to happen as part of the Thread Group or as part of the work associated with making Thread work for the Matter protocol.

First up, there is drama when it comes to border routers breaking down. First up, there is a concept related to a shared mesh and the network topology. The Thread protocol has three components: sleepy nodes, powered nodes, and border routers. A sleepy node is a device that is battery-powered, dumb, and reports its status to other nodes or a border router. A powered node may not have a lot of computing capacity, but it does have access to power and can store state data forwarded to it from sleepy nodes as needed.

The border router is also the big brains and networking way station of the network taking in data and transferring it to other nodes and out to the internet at large if it’s connected to Wi-Fi or directly to the internet. Most border routers will translate Thread to Wi-Fi.

But if you’re like many smart home device lovers, you may be running multiple Thread border routers in your home and you want them and the devices associated with them to have a shared mesh. There needs to be mechanisms that allow Border Router makers to use the same mesh owned by the user on their smartphones. There have been APIs on iOS that facilitate this since last year, and Android announced their equivalents earlier last week at Google I/O.

Right now, there is no clean failover when a border router goes offline, which means that devices communicating with a specific border router might end up falling offline for a time. Eventually the network will reconfigure itself, but it can take time, as in a few hours.

This reminds me when a decade or so ago you’d bring a Wi-Fi or Zigbee network offline and it would take time to repopulate and set up the network. Since border routers can be something as essential as a router or as portable as a HomePod Mini that might get unplugged, having a rapid and clean transition when devices go offline is pretty important.

Gimmy Chu, the CEO of Nanoleaf, acknowledged to me that this is a problem, but said he hopes these issues will get worked out as part of the Matter standard, or simply as companies prep Thread for Matter.

There’s another issue as well. Jonathan Beri, CEO of Golioth, a platform for IoT hardware makers, told me that up until now not all Thread-capable devices were built to interoperate. He said that the original Thread code built by Nest didn’t focus on the application layer, which meant that some elements that are taken care of up the stack, such as provisioning a device, can lead to user confusion when trying to provision a Thread device. aren’t defined as part of Thread just yet.

This is why Apple’s Thread-capable devices might not work with all Thread devices. Beri is confident that Matter is going to solve these problems going forward, since Matter is trying to unify aspects of the smart home, such as provisioning at the application layer. But it also explains why some devices that have Thread, such as my second-generation Nest thermostat, won’t speak with other Thread-capable devices such as my Eero router.

This should change soon, again because Google tweaked its Android operating system to make sure Thread credentials are shared in the device’s onboard keychain. This will make it easier for device APIs to provision devices using both Android and Apple phones and help created a true shared mesh.

The Thread Group or efforts from the Matter Working Group will likely fix both of these issues. In the meantime, Beri stressed to me that there is currently work going on in The Thread Group associated with provisioning and security, so as Thread becomes the underpinning for Matter, all Thread-capable devices will end up seeing one another and working well together.

This is good, because as someone who remembers how frustrating it was when various different Zigbee devices didn’t work together, no one wants Thread to have a similar problem. Especially since it’s such an essential element of Matter, and because Matter is supposed to make the smart home simple.