Thread Essentials for Smart Home Enthusiasts
What is Thread?
Thread is a communications protocol created by Nest, and then evolved by Google, designed to provide a secure, scalable, and resilient networks for Internet of Things devices. Thread follows in the footsteps of Z-Wave and Zigbee in this regard, but takes lessons learned from these earlier efforts in the hopes of building a new standard that can resolve ongoing issues of compatibility, security, and reliability between the various automation platforms.
Thread is overseen by a consortium of companies called the Thread Group. Membership of the group is required use the technology and commands an annual license fee. An open-source version of the stack has been released by Google called OpenThread. Devices built using OpenThread, however, are still subject to certification requirements.
History of Thread
Nest created the early form of Thread and built it into their devices from day one. The protocol evolved until Nest Labs was acquired by Google in 2014. Subsequently the Thread group was formed to oversee the development and adoption of the format including a number of semi-conductor and device brands such as Samsung, Qualcomm, ARM, and Yale. Not much more was heard about Thread until Apple joined the Thread group in 2018, bolstering hopes that it may actually see some traction.
This movement began to coalesce with the formation of the Connect Home over IP initiative in 2019, bringing together Google, Amazon, Apple, Zigbee and other major smart home players in an effort to create a new open standard for smart devices.
2011 - Nest creates Thread
2014 - Google acquires Nest Labs
2014 - Thread Group created
2015 - Yale announced as first non-Google Nest adopter
2018 - Apples joins Thread
2019 - Thread 1.2 released
2019 - Lutron joins Thread Group
2019 - Connected Home over IP project announced
2020 - Apple HomeKit begins supporting Thread devices
2020 - Nanoleaf adopts Thread
2020 - Eve Systems adopts Thread
2021 - Thread adopted as core tech in the new IoT Matter standard
2022 - Thread 1.3 release, Matter enabled
2024 - Thread 1.4 release, single network interoperability
“No one has deployed an IP-based, secure and low-power wireless networking protocol with the same level of scale and functionality as the Thread 1.2 Networking Protocol. Not only can Thread 1.2 seamlessly integrate with other IP-based networking technologies, it has far lower power requirements relative to comparable solutions, thus improving the battery life of IoT devices.”
How does Thread work?
Thread is designed to provide a resilient, scalable mesh network supporting small devices and requiring very low power consumption. A key difference over other mesh network protocols is that Thread is not based around a master device that ‘owns’ the network. Instead, it allows any full Thread device to become a router, and these routers will automatically elect one of their number to be the ‘leader’. This process is dynamic, and responds to any change in the network such as the current leader being removed or unreachable for some reason.
This dynamic process means that there is no requirement for a ‘hub’ to manage the network, as any Thread Router device can create and manage additions to the network. Connectivity to other networks, such as a home Wi-Fi network or the internet, still requires a specific device known as a border router. A Thread network can have multiple border routers to provide redundancy. Border Routers are distinct from the management of the Thread network itself, although they may also be eligible to act as Routers as well.
Basic Thread topology
Unlike other IoT protocols, Thread does not aim to be all encompassing by dictating the types of actions and messages smart devices must use. Instead, Thread is designed as a network protocol which is application layer agnostic. The application layer in a protocol stack is the part that handles how the automation system talks to devices and includes things like device status messages and control commands. For smart home device, the Connected Home over IP project has been formed by major smart home brands to address this as an open standard.
Thread handles the layer below this, including security, network management, routing, mesh formation and device health checks. A key differentiator of Thread is its use of IPv6 for addressing, which gives it great flexibility in not only providing multiple addresses per device for different uses but enabling internet addressability for distributed applications. This is because Thread is not just smart home focused, but more broadly usable for all automation applications involving small low power devices, such as remote monitoring and industrial process control.
The structure of the network portion of the addressing allows for up to 32 routers, with each having 511 child devices. This gives a total network size of 16384 devices. Thread will promote and demote routers as required and will aim to keep the number between 16 (for resilience) and 23 (to allow for additions to extend range if needed).
As of Thread 1.4, Border Routers can now utilize Wi-Fi and Ethernet connections between each other to bridge gaps in the mesh allowing for easier, reliable placement of remote devices at the edge of the network.
“During my nearly 10 years overseeing the certification program for Thread-enabled components and devices, we’re seeing unprecedented interest in the 1.4 enhancements. Now that the 1.4 certification program is taking applications, our members are eager to roll its benefits out to consumers, installers, and those responsible for smart building deployments.”
Issues With Thread
The biggest problem facing Thread at the moment is a lack of control for end users. With more and more players now enabling Border Router functionality on their products, and all of them wanting to push their own Thread network, it’s quite possible for Thread devices to join different networks depending on how they are initially provisioned.
While under ideal conditions this isn’t technically a huge problem since all Thread devices are IP addressable through whatever Border Router is on their network, it does make troubleshooting very awkward. Without any reliable way to visualize Thread networks at the moment, and with not knowing what network a device is connected to, it can be problematic to know where to start diagnosing a problem.
The idea in the specification is for users to be able to add any Border Router to the network of their choice, this is now in the spec as of version 1.4, but no major device maker is using that yet. Adopting the new versions of the protocol takes time, so we’re stuck with potentially fragmented networks in the interim.
If, for whatever reason, a new Border Router can’t join an existing Thread network (because the device maker doesn’t want to do the work to determine if it should - looking at you Eero), it will create its own network. Any new Thread device that is added (that isn’t under the specific control of one of your networks platforms) could end up on either and may run into trouble communicating due to poor signal network configuration issues.
That shouldn’t happen, but even if traffic is able to flow without issues between Border Routers, having multiple Thread networks undermines the benefits of redundant connectivity and mesh range extension as the routers in each network aren’t part of the same mesh. Indeed, a rogue network may only have the one router that created it meaning devices that join the wrong network could be too far away to perform well.
Thread Benefits
IP Addressable
Thread aims to provide ‘interoperability through convergence’. This means that by using a widely adopted standard addressing standard, devices used for any application, on any platform, will be able to communicate over a common medium. To achieve this, it’s important to use a highly scalable and widely deployed means of referring to individual devices and getting traffic between them. The internet has been doing this for decides using IP addressing and routing, and Thread leverages the latest iteration of this technology, IPv6.
Highly Resilient
Thread’s key benefit is it’s highly dynamic mesh network. Thread devices can self-establish a network on their own, and allow other devices to join it. Any of those devices with full Thread capabilities can become routers on that network, and any one of those can by elected to take charge as required.
This lack of a central network owner provides for much greater resilience than typical meshes which are anchored on the original device that formed the network. Routers will be managed automatically and without any configuration required, and child devices will automatically manage their connection to a suitable router to maintain their connection.
Security
Here Thread has benefited from lessons learned with the real world use of other protocols, and bolstered by Google’s considerable security expertise.
Thread has been designed from the ground up with security in mind. Communications are secured with AES encryption at the network link level, using Data-gram Transport Layer Security (DTLS). There is a robust commissioning process to ensure new devices are authorized to join the network, and built in protection for identifying and blocking rogue devices.
Very Low Power
Thread claims to have even lower power consumption than competing technologies, and supports small battery powered devices that can sleep until needed. This is critical for smart homes where the need for remote sensors like motion, door/window, and switch type devices is very real. These type of devices need only send a message when something happens, so they can be idle most of the time and extend the life of even small batteries for years.
Flexible Application layer
By focusing on the network management side, Thread allows other technologies to provide the application level functionality. This allows for different uses over a single thread network depending on the purpose of specific devices. An example is ZigBee, where the application layer for ZigBee devices can be used on top of a Thread network, leveraging the benefits of both.
Technical Details
Radio Transmission
The underlying radio protocol Thread is based on is IEEE 802.15.4, which is the same standard used by ZigBee. IP routing is generally not efficient enough to support very low powered devices, so Thread uses the 6LoWPAN (IPv6 Low-power Wireless Personal Area Network) standard to provide a very low power IPv6 implementation. 6LoWPAN is defined under IETF standard RFC 6282.
Like many consumer radio protocols, Thread runs operates in the 2.4GHz band. This band is approved globally for unlicensed use, which ensures easy access to the same frequencies anywhere. While 2.4GHz applications are known for being susceptible to interference, Thread uses spread spectrum technology to help overcome this issue.
Device Types
Thread specifies a number of device types with different capabilities. Most Thread devices fall under the Full Thread Device class, but in order to support low power devices, a Minimal Thread Device class exists with reduced capabilities.
Within these are a number of sub types:
Full Thread Device (FTD)
Router
Router Eligible End Device (REED)
Full End Device
Minimal Thread Device (MTD)
Minimal End Device
Sleepy End Device
Routers in the network are simply REEDs that have been promoted to Routers by Thread on an as-needed basis. As network conditions change, Routers will be added or removed to maintain the optimal number 16-23 where possible.
Sleepy End devices are those intended for small battery powered operation. These devices will minimize the use of their radio to conserve power and cannot forward message traffic.
Any end device can also act as a Border Router (providing they have the necessary communication hardware). These devices pass traffic between the Thread network and a non-Thread network. Typically at least one of these will be required to facilitate communication and control from outside devices such as console or smart phones. There can be more than one Border Router in the network.
Network Management
Any REED can form a Thread network if there are none to join. As other devices are added to the network, additional REEDs will be promoted to routers to ensure resilience. One of these routers will be elected to be the Leader. This leader device manages network configuration information for all devices. If the Leader becomes unavailable a new one will be elected by the remaining routers.
Devices that are not routers will establish a link with one router only, based on the best options available to them. If they cannot establish a satisfactory connection to an existing router, a suitable REED will promote itself to a router for that device to connect to, if available.
This flexible self repairing capability means that a Thread network can be broken up in the event that communication between two portions of the network are disrupted. The portion without access to the leader will elect it’s own Leader and continue to function with the same security keys as the original network. These portions are called ‘partitions’. By retaining the same security credentials, the partitions can be reunited at a later point with no ill effects.
When selecting devices to become Routers, there are some rules that are followed to ensure the routers form a Connected Dominating Set (CDS). This ensures the minimum level of redundancy is maintained.
There is a Router-only path between any two Routers.
Any one Router in a Thread network can reach any other Router by staying entirely within the set of Routers.
Every End Device in a Thread network is directly connected to a Router.
In Practice
When a Thread network is created using an iOS or Android device, the credentials for that network (all the details required to find and join it) are saved in the device owners secure storage. For Apple users this is the iCloud KeyChain, for Google users this is the Google Play Services app. Unfortunately, neither system provides a way for users to view or manage these credentials. It’s all supposed to be hands-off and automated.
Processes exist for the device to select a preferred network to use when pairing new devices, but this may not actually be what you want and can result in issues. This is exacerbated by a lack of tools to help end users troubleshoot issues.
A couple of brands have provided some limited visibility, namely Eve Systems and Nanoleaf. The native apps from each of these device makers attempts to show you your Thread networks, but they both suffer significant limitations.
Our personal devices - those we use to add and use Thread devices - have virtually no visibility into the Thread network. We can only see service advertisements that come through the Border Routers over mDNS, which tells us nothing about the network itself. Having a router capable device on the Thread network allows makers to potentially gain some extra insight. The Eve app attempts to show the router state and link strength by pulling this data through their own API, but it’s limited to what their own device can see. At the very least, both these brands are able to show what Thread network their own devices are actually connected to.
A Case In Point
I recently had a problem where all my thread devices fell back to Bluetooth communication after an OS update. I only had one active Thread network running, so this was puzzling. Using the Nanoleaf app I was able to force those devices to join the correct one, but Eve stubbornly showed their devices on an eero network which was supposedly turned off.
After much trial and error and jumping back and forth between these apps I was able to determine that the credentials for the eero network (which it creates without consideration for already existing ones) were in my KeyChain. This shouldn’t matter if there are no active routers for devices to connect to, so there must be one running somewhere. Looking back through the Nanoleaf devices I found one bulb that was not showing it was connected to the right network, but WAS using Thread.
Forcing it to join the right network fixed the issue, killing the rogue network and forcing the Eve devices to look for another one - the only one. Better tools would have made this easy to identify and resolve, but we simply don't have them at the moment.
Useful Apps
Eve
The Eve app acts as both a HomeKit client and a device management app for Eve’s own devices. With a router-capable Eve device in your network, you’ll be able to see other Thread devices and active Routers, along with the link strength between them.
Nanoleaf
If you have Nanoleaf devices, this app can show which Thread networks youn have, their Border Router, and allow you to select the network for Nanoleaf devices to join.
Discovery
A tool for monitoring DNS-SD traffic on your network. This is where some Thread and Matter info can be captured. Look for these services:
_meshcop._udp. Shows Thread Border Routers.
_hap._udp. Shows Thread-based Apple HomeKit accessories.
Competition
It’s easy to assume Thread is a direct competitor to other IoT protocols like Z-Wave and ZigBee, but this is not really accurate. Thread has specifically avoided encroaching on the application layer where the actual automation functions work, and has focused on being the best possible network technology available for connected devices.
In this, it looks to have succeeded. Thread is the only protocol with the ability to completely self-manage its nodes, to the point of dynamically electing the controlling entities. All other protocols are dependent on a key device as the base of the network’s security infrastructure and management. This could be the Wi-Fi router in a typical home network, or a controller hub for Z-Wave. Thread avoids this need for specific hardware and, in so doing, removes any single point of failure (unless your network has only one Full Thread Device).
Protocol Comparison Table
Thread has also embraced its competitors to help remove obstruction to further adoption. As of Thread 1.2, Bluetooth is now an accepted radio technology, although only for the purposes of initial discovery during provisioning. Similarly, ZigBee has ported their application layer to run on top of Thread, allowing compatibility with existing ZigBee software implementations.
The presence of key players like Google, Amazon, Apple, and ZigBee in the new Connectivity Standards Alliance makes it more likely we might finally see a ubiquitous smart home interface that can work across all our devices. The Alliance has developed and released the new standard for smart home devices called Matter which is based on Wi-Fi and Thread initially.
How to Get Thread
Thread is still relatively new in the market but has seen a significant boost from the rollout of Matter in terms of device numbers. In order to use Thread devices, you need to have a Thread compatible device acting as a Border Router which will connect your Thread network to your main network.
Some Google Nest devices support Thread, and the main way to get it to date has been through Googles Wi-Fi routers. More recently, Apple’s HomePod Mini and newer Apple TVs have Thread support, and spurred the creation of HomeKit compatible devices using the technology. Other brands are now releasing Border Routers specifically for Thread and Matter, which is creating a more diverse landscape not tied to a particular platform.
Some Border Router options include:
Google Nest WiFi Mesh Router
Apple TV 4K
Amazon Echo (4th Gen)
Nanoleaf (Lines, Shapes, Elements)
Eero 6 mesh routers
Conclusion
The smart home industry, and IoT in general, remains a fractured market, with varying protocols and technologies vying for market share. This situation makes it confusing for newcomers looking to take up smart devices and adds expense and complexity for those already using one technology that want to broaden their options.
Thread hopes to standardize the underlying communications for all connected devices, and provide highly reliable, secure, and maintenance free access for low powered devices. Thread has learned much from the technologies that have come before it and looks to have achieved a superior mesh network implementation that ticks all the boxes for both smart home and industrial users.
Work remains to be done make Thread as seamless and reliable as envisioned, but the collaboration of most of the main players in this space is encouraging. Thread provides a solid foundation for that work and removes many of the obstacles that have been challenges up to this point. Until then, things can and do go wrong. While these issues may be uncommon, the lack of tools to troubleshoot Thread networks for end users can make this a real problem.
Hopefully we’ll see something to help in this space, or the consortium moves things along quickly enough to make them unnecessary.
