Thread 2020: and now things get interesting

Devices & Integrations
,
1

This is going to be super geeky, so bear with me, and I’ll try to keep the concepts understandable.

Thread is a mesh protocol that runs on the same frequency (so can run on the same radios) as Bluetooth and Wi-Fi. This is a cousin to, but not identical to Nest Thread. It’s been around for a few years but hasn’t really been used for anything practical up until now. But it’s supposed to be an open standard and there are a lot of big players joined onto the advisory group. Even the Samsung smartthings V2 hub was released with specs that said it was “thread-capable“ (most likely via the Bluetooth radio which hasnever been used for anything) but then silence after that.

Now Apple’s new $99 HomePod mini has working thread inside.

And (drumroll, please) third-party manufacturer eve just announced that they are going to reconfigure some of their existing HomeKit devices, including their door sensor, to use thread via a firmware update. Which probably means switching the internal radio from Bluetooth to thread, although they haven’t said that specifically.

https://9to5mac.com/2020/11/11/eve-thread-homekit/

“Support for HomeKit over Thread takes the entire Eve platform to the forefront of smart home innovation, and we’re thrilled to be among the first to bring this cutting-edge smart home technology to HomePod mini users’ homes.”
.
“By enabling Thread on their devices, Eve delivers a meaningful value today, and lays the groundwork for a scalable, robust smart home ecosystem,” added Sujata Neidig, vice president of the Thread Group. “This progressive approach improves their customers’ experience now, and helps ensure they’ll enjoy a dependable and seamless smart home for years to come.”

And (break out the kazoos! :tada:) in case you missed it, thread is also one of the protocols announced for use with project CHiP. (Whose working group includes Apple, Amazon, Google, and smartthings, along with the zigbee alliance)

Which could, although not necessarily has to, mean that there will be project chip certified Wi-Fi devices and project chip certified thread devices using the same messaging protocol. :exploding_head: (it doesn’t have to mean that, though: project chip could end up working like Zigbee profiles do now. With not all devices using the same message structure.)

But whether that last bit happens or not, actual live thread devices happening is a big deal and the fact that they are happening through a firmware update is even bigger news, although most people won’t notice that part.

Here’s the basic Takeaway for consumers:

Thread should mean that your smart home devices work faster, more securely and with less issues than ever before; especially compared to Bluetooth and Wi-Fi devices.

And here’s a good Geeky-but-no-math-required overview of Thread:

Thread is a mesh network that doesn’t require a hub. That’s been done before (ZLL, for example), but it’s still interesting. And thread covers more device classes with better security than ZLL.

What does this mean for smartthings? Well oddly, it might be one reason why Samsung is moving out of the home automation hardware business. If all of this happens on the current project timeline, project chip for both Wi-Fi and thread, and Apple, Google And Amazon all adding thread to their HA devices, It could be a very different HA world by Christmas 2021. There will be those things that work with thread or project chip certified Wi-Fi, in a race to the bottom on price, and there will be cool platforms that provide UIs, voice assistants, and rule engines. Usually as a means of selling other stuff, including smart phones. HomeKit, obviously. Alexa routines. Whatever google’s equivalent of Alexa routines turns out to be. And…?

You can see which side of the equation Samsung would probably like to be on. :wink:

4 Likes
2

But they’re still developing hub firmware for WASH devices, so wouldn’t Thread impact that if Samsung wants to support thread?

1 Like
3

Nanoleaf announced they are adding Thread support.

1 Like
4

Yes, but if they are turning themselves into tuya as far as providing a platform to other device manufacturers, they don’t get slammed as hard by the drop in hardware prices and they don’t have to do as much customer support.

1 Like
5

Also, did you notice who gets left out of this party? (Hint: it starts with Z, there’s a W in the middle, and it operates on different frequencies in different parts of the world.) :thinking:

@johnconstantelo

6 Likes
6

what are the main advantages thread has over zigbee? IP addresses?

7

Yes, that’s one. :sunglasses:

Probably of more interest to the voice assistant companies is that thread does not require a hub. To put it technically:

Thread authentication and commissioning is smartphone-based, while with Zigbee, authentication is centralized through a trust center with proximity-based commissioning.

The “trust center“ is a hub or bridge.

Thread vs. Zigbee – what’s the difference? - Embedded processing - Technical articles - TI E2E support forums

ZLL doesn’t need a hub, but in practice when once you go beyond lighting, particularly when you include locks, Zigbee does require a hub.

2 Likes
8

I know you know the following, but for the people who don’t, the advantage of having IP addresses is this (statement from the thread group)

Thread ensures end-to-end communication — device-to-device, device-to-mobile, and device-to-cloud — reliably and securely connecting hundreds, and even thousands, of products.”

Zigbee gives you device to device communication, but it doesn’t give you device to mobile phone or device to cloud. For that you need a hub.

Because, as mentioned above, thread’s “trust center“ can be on a mobile phone and it’s IP-addressable, you don’t need a hub to get you to the internet. Just your Internet router.

You still need an app on the phone that knows what to do, which is where apple’s HomeKit and other UI supports come in. But the belief is that and users will find it all much less mysterious if it seems to work more like Wi-Fi. :sunglasses:

9

Is there really that many people that would even use thread or ZLL devices without a hub? I’d imagine most people. Want their thread or zll devies to interact with other iot devices, which would require some kind of hub/bridge.

10

It really doesn’t require a hub/bridge in the same way that Wi-Fi devices don’t. It requires an app to create rules, but not another physical device.

Just look at all the companies that have been releasing Wi-Fi and Bluetooth versions in the last year or so, including Leviton, Fibaro, Jasco… all so they can sell them with a product description that says “no hub required.“ That’s a really big market. Even Phillips hue has released a line of bulbs that can be set up with just a phone, no bridge, although you don’t get all the same features, and they do encourage you to add the bridge later.

Personally, I think this is the fault of hub manufacturers who didn’t provide good apps. That is, it was a UI issue, not a “this needs an extra box” issue. That, and standards that made adding devices too complicated. people don’t have problems buying a sound bar for their television, or a game console. It’s the setup friction that was the issue, and that has given hubs a bad name that they didn’t have to have. JMO

2 Likes
11

But they still require a box with a radio that connects to the internet …which sounds very much like a hub/bridge :grin:

12

No, it’s not. My new HomePod mini Doesn’t need anything different than somebody else’s full-size HomePod (with no thread) needs. You do need a router if you want to talk to the Internet, but that’s a different question.

A hub or bridge is used to establish a trust center for a local network or to connect devices of one protocol to another protocol (like the hue bridge does for zigbee and Wi-Fi).

Thread Devices work just like ZLL Devices, like if you bought a hue dimmer switch and a hue bulb, no bridge. They really can talk to each other without needing a hub.

https://www.amazon.com/Philips-Hue-Installation-Free-Exclusive-Assistant/dp/B016AEHU70

13

Right, but who in 2020 is going to setup their hue bulb and remote and then not want to control it from outside their house, via Alexa, on a schedule, etc.? You need something with a non-WiFi radio in it. Whether that’s a HomePod mini, a echo dot or anything else. Standalone bridges may be going away, but they’re just being moved to inside existing devices.

1 Like
14

Yes, if You count a mobile phone or tablet as one of those “anything else” things with a non-Wi-Fi radio in it.

Or a thread capable router, some of which already exist.

It really is going to feel more like adding a Wi-Fi pocketsocket. You don’t have to buy and set up an additional device: you probably already have it operating, which seems to be the point of friction for many consumers.

15

Some notes from this week’s big Project CHIP webinar & announcements,

  1. Thread will be the low-bandwidth protocol for CHIP-certified devices, while Wi-Fi is the high-bandwidth protocol. Bluetooth LE will be used for provisioning.

  2. Current non-CHIP IoT devices can join the CHIP “network” via a CHIP bridge; the CHIP side is what’s certified, but no requirements for whatever’s on the other side (Z-Wave, etc.).

  3. At 22:13, the speaker mentions “Thread / BLE combo radios”.

  4. At 34:49, the speaker notes that if devices support 802.15.4 and/or WiFi, they can be upgraded to CHIP certified, but it will depend on the available compute and memory, the manufacturer, the chipset, and whether that’s the best approach versus a dedicated CHIP bridge.

  5. Samsung SmartThings was present at the Webinar via Mark Tekippe, along with Google, Apple, Zigbee, Tuya, Comcast, and Infineon: Google actually had three representatives.

And it’s been covered on Stacey On IoT, as well. The orange circle with the inscribed “T” is Thread. See “Other protocols” at the top, with a very Phillips Hue-like hub, Alexa speaker, and Google Nest Hub.

2560×1440 140 KB

The panelists also confirmed that CHIP devices will use Wi-Fi for high bandwidth applications and Thread for low bandwidth applications. The standard will also use Bluetooth Low Energy for device provisioning, which is a nice win for BLE because those radios will still be inside most smart home devices. That makes sense given that provisioning is likely to happen in most homes using a mobile handset.

//

There are definitely mechanisms to convert current ZigBee radios to Thread radios on a low-level, but it likely depends on interest & budgets.

Q: We recently upgraded our SoC from the CC2531 to the CC2538. We are referencing the document ‘Z-stack OTA Upgrade Users Guide’. We plan to build and test the demo using the CC2538EM dev kit – but this looks like an OTA from one SoC (server) to upgrade a client that is using a compatible SoC.

Here is the ‘what-if’ scenario that we would like to test:

The CC2538 supports both ZigBee and Thread. Today we are using ZigBee – but perhaps the industry has decided to move the Thread in the future. Is there a way to remotely update the firmware to accommodate Thread? In general, is there any way to update the firmware on the SoC itself wireless?

A: While the CC2538 supports both Zigbee and Thread, what you’re wanting is not supported for this device, as the CC2538 does not have TI OAD capabilities. However, the CC2538 does support Zigbee OTA Upgrade (TI OAD and Zigbee OTA Upgrade are able to co-exist, as they are two separate entities). With using Zigbee OTA Upgrade, you would have to develop your own proprietary BIM in order to perform the update wirelessly. Or upgrade manually through a serial upgrade.

However, with our new CC2652R and CC1352R devices, this is most definitely possible to do wirelessly, as this supports both Zigbee OTA Upgrade and TI OAD, which enables the ability to switch between different technologies via the BIM supplied.

//

Many moons ago, @JDRoberts noted that the official FCC certification for the Samsung V3 hub does include a “Thread Ant[enna]”, but if there’s any hope for that ever functioning is anyone’s guess.

1134×1235 479 KB

3 Likes