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.
I’m confused.
Your second generation Nest thermostat uses a different Thread (yes, there are two) than eero.
That’s because once upon a time (2014) Google donated a version of Thread to a nonprofit open standards organization, the Thread group. That version was called “OpenThread.” But Google kept its own version which does diverge somewhat, usually called “Google Thread.” (Sometimes called “Thread for Nest.”) at the time, the two were usually described as “cousins.“
Your eero router is certified for OpenThread. (So, btw, is the Google Nest WiFi Router.) But the current Nest thermostat is not.
https://www.threadgroup.org/What-is-Thread/Thread-Benefits
Google has said that the new “Nest Thermostat,” which I believe will use OpenThread, will support Matter, but the original “Google Learning Thermostat,” which uses Google Thread, will not.
(It’s a little like custom Zigbee profiles: Control4 uses its own flavor of Zigbee which isn’t interoperable with the standard Zigbee 3.0.)
I know these days everybody just says “Thread” regardless of which version they mean, but there are two currently in use. Eve and Nanoleaf are certified for OpenThread. (See link above.) Current Nest products are mostly not.
So this statement:
“ all Thread-capable devices will end up seeing one another and working well together.” will only be true for the ones certified for Matter, because they will all be using the same version of OpenThread.
It will not be true for some existing Google Thread Nest devices which people may already have.
The Matter logo is going to end up doing a lot of the heavy lifting for interoperability understanding if this all works out as planned. If the device has the matter logo, it should be able to work with any of the voice assistants that have the same logo, any of the apps that have the same logo, and consequently it will be able to be combined in routines with other devices that have the same logo. That’s all the consumer will need to know. But older devices already in the home, whether they are “thread“ or anything else may not work in a matter setup.
Thank you Stacey for leaving in the incorrect information. This is so much more useful when rereading an article to help see what was incorrect. So often I read articles that have been “updated to include correct ino” without any idea what has changed.
Thread right now is a hot mess IMHO. Thread on Apple TV, Thread on Eero, Thread on Nest hubs, thread on Nanoleaf bulbs. Nothing really wants to talk to each other but the Nanoleaf and AppleTV.
I much prefer Zigbee that everything talks to each other. I haven’t use Control4, but otherwise, hue, sengled, ge, cree, innr, ikea, seedan, third reality, lutron all talk to each other. Some controllers may not be programmed to work particular devices, but they will all pair and talk to each other.
Zigbee has, by design, multiple profiles and devices of different profiles do not talk to each other. They don’t even necessarily use the same addressing system.
Manufacturer proprietary profiles are allowed, which is what control4 uses. But there are also multiple other profiles like green energy, retail (for cash registers), one for smart meters, etc.
https://www.eetimes.com/zigbee-applications-part-6-profiles/
Tuya uses proprietary clusters even for some of its zigbee 3.0 devices, which means they won’t necessarily work with other Zigbee hubs, at least not without custom code. Same with Aqara’s newest models.
Philips hue uses two different zigbee profiles. The Hue Tap and the Friends of Hue wirefree switches use the green energy clusters which are supported by some hubs, and the hue bridge, but not all. For example, you cannot add a hue Tap zigbee switch to a smartthings zigbee hub. And while some third-party zigbee bulbs work with the hue bridge, not all do. It depends on the profile being used.
We get questions every week in the smartthings community forum from people who bought a device with a zigbee logo and can’t figure out how to make it work with smartthings. Some of them will, some of them will with custom code, and some of them just won’t.
(Most Lutron devices, including the Caseta switches, use a proprietary protocol called “clear connect.“ Not Zigbee. They do have a few zigbee devices, including the aurora, but not many.)
So, yes, thread is a mess. But so is zigbee right now. Even Zwave can have some compatibility issues. That’s why we have the first rule of home automation: “the model number matters.“ Which is annoying, but it’s where we are right now.
The most important thing about the Matter initiative is that the logo really mean something. That is, that buying something with the Matter logo is enough to know that it will work with your other devices with a Matter logo using an app that has Matter compatibility.
I don’t know if that’s what they’ll really deliver, but I’m hopeful.
JD I never heard of those wirefree switches, just looked them up. I have not used any tuya products yet either. I guess any standard can have its deviations to be exceptions to the rule. Like IKEA buttons draining away to zero when paired to SmartThings but not to ikea’s own hub or other hubs.
Matter’s seal could mean a lot IF the members live up to its promise. Multi-Admin is the biggest foundational feature. Alexa and Siri sharing devices. Homepod Mini sitting next to an Echo and having use of Zigbee and Thread devices in Alexa and Homekit? BAAAM #Mindblown
Time will tell. I wonder what will launch first, Artemis I or Matter
LOL! Good question!
When it comes to standards, it’s up to the certifying body how much deviation they will allow. Some third-party specifications are, well, very specific. Others court manufacturers by allowing for lots of deviations. I don’t think we know how matter is going to handle it until we start seeing devices released.
How many z-wave devices can you name which use proprietary commands?
I can only think of one produced in the last 15 or so years, it is a wall scene controller which worked fine with standard commands.
If you are comparing Z-wave networks to Zigbee networks? Z-wave controllers can co-exist and control devices on the same network, despite almost all of the z-wave controller manufactures explicitly saying that they do not support this feature.
With Zigbee, 3.0 was supposed to force compatibility, it obviously failed to do this. I do not see how Matter, which is based on the Zigbee Cluster Library, is going to succeed at what Zigbee has failed to deliver.
Zigbee has no history of having multiple controllers communicating with devices on the same network; the ZCL wasn’t designed with this in mind.
The Connectivity Standards Alliance history with Zigbee?
I don’t think the CSA’s history inspires confidence in Matter.
There are many zwave devices which use proprietary commands, and the option is included in the zwave standard. For example, every Leviton and Cooper switch through the 5th generation which used the Hail commandset had licensed Lutron’s patent and that was not available with devices of other brands.
Fibaro for many years had a tamper alert for their sensors which didn’t work with other brands.
In fact, the zwave specification includes the ManufacturerProprietary Command Class which is designed to allow manufacturers to add features above the shared specification and still be considered compliant.
Zwave’s command structures assumes multiple levels of commands.
“Basic” are required of all zwave devices and is the only level at which compatibility is guaranteed. On/off for a switch, for example.
“Recommended” are advanced optional features. Manufacturers don’t have to include them, but if they do, all manufacturers implement them in the same way. The usual example is all lights on at once.
“Optional” are manufacturer-proprietary features and don’t have to be compatible with other brands. A good example is a child lock feature on a light switch. Both Leviton and Cooper offer this but it’s not implemented in the same way. Cooper also offers a panic alert strobe feature for its light switches which doesn’t work with other brands.
In addition many hvac devices, including thermostats, use manufacturer proprietary commands for advanced features like multiple setpoints and fan speed. Sometimes these get added to the optional group in later zwave generations, sometimes not. But there are a bunch of brand-specific versions. For example, an air conditioner controller which offers an “Eco” mode with a different setpoint or a built-in cycle timer will use manufacturer proprietary commands.
Locks are another example where different manufacturers do things in different ways. They’ll all lock and unlock with a network command. But when it comes to setting or changing user codes there are major differences between manufacturers.
Vesternet has a good article on this aspect of zwave architecture.
https://www.vesternet.com/en-us/pages/how-z-wave-controllers-devices-work
So how many zwave devices can I name which use proprietary commands? At least several dozen. That same device ALSO has to respond to the required basic commands, so it’s technically compatible with all certified zwave commands, but it may be missing advanced features or have greatly reduced functionality.
As far as zigbee and multiple hubs on one network under the home automation profile, it’s not uncommon, but it has to be done with manufacturer-proprietary clusters. Control4 probably has the largest number of residential installs with this architecture. They designate one as the primary (Director) and the others as secondaries. But you have to be using their hardware and their installation software.
Nothing is ever quite as clear as it seems from the marketing materials when you dig down into the engineering specs. Including “compatibility.”
As for what will happen with Matter, we will have to wait and see. As far as I can tell from what’s been released so far, they’re going to enforce a level similar to Zwave’s “basic” commandset, but there will be lots of optional features that still work differently on different platforms.