I love it when they contradict themselves

The Verge hyping a "Thread" based motion sensor and how no hubs are needed etc. But read very closely.

1 Like

Ahhh BS article strikes again. It's so tiresome reading tech news.

Doesn't need a hub**

** but it needs a routing device

Same people who scream about how Wifi devices are so much better because they didn't need a $99 hub to run their devices, then promptly go out and buy a $600 mesh Wifi setup to reduce congestion in their network.

Crazy GIF by Steve Harvey TV

7 Likes

Well you can have several border routers in your mesh, which all have equal rights to route, so it's not exactly a lie that there isn't a single point of failure

1 Like

This! Sloppy reporting it seems - My understanding is that you need at least one border-router but can have many. The cool thing as @Inge_Jones mentions is it's dynamic so can "automagically" change depending upon mesh conditions.

How is a thread border router different from a zwave or zigbee repeater?

image

2 Likes

I read this article previously, popped up in my Google app I think.

From my understanding this device will communicate via the HomeKit application stack only, via Thread, since it only supports HomeKit. Next step forward is to instead communicate via Matter and it could be easily compatible with more ecosystems. It probably would have come out with Matter support already if it fully existed yet.

I am starting to think this is really going to take smart home tech to the next level. The key is going to be getting Thread border routers built in to more devices so people do not have to buy an extra "hub" if they only want simple automations.

1 Like

I'm excited about the possibilities of Thread but not yet convinced about "Matter"..

Ah! So a system will need at least one, and possibly more than one internet connection device (border router).
I see where the kerfuffle is coming from now.

1 Like

Without Matter you still have multiple application stacks to deal with, to support different ecosystems. If you think about it, Thread is basically just taking IPV6 and moving it from Wifi to a different mesh system. One advantage being I would assume it is built for low power consumption, and it also creates a mesh instead of point to point like Wifi normally does, So without Matter its not a whole lot different than the same problem we have with Wifi devices, they all talk to each other in different ways.

I've been thinking of it more as an advanced/improved Zigbee network - no user configuration (other than initial pairing I guess), dynamic controllers etc.

I bet there is still room for irritation though, if we see their routing table and start wondering why the most-used border router is the opposite end of the house to the wifi router it's talking to

1 Like

I think the Thread/Matter combo would take this role, but Thread on its own is more like a low power independent Wifi mesh from what I can understand.

Zigbee encompass the application stack down to the protocol stack. Thread is just the protocol, and Matter is the application stack.

3 Likes

What part of the application layer does Zigbee mesh network handle? I thought a controller like HE provides the application control. I'm always a little confused when it comes to discussing the OSI model though.. :exploding_head:

1 Like

I could be wrong since I don't know a ton about Zigbee, but I am thinking that the Zigbee version we refer to (v3.0) is the application layer of Zigbee, the standards of how the devices talk to each other over the Zigbee protocol/network. I am assuming that the full Zigbee standard encompasses the entire protocol stack. So yeah the Hub probably handles the application layer but the Zigbee standard defines it (I assume). Similar would go for Z-Wave standards.

Where as Matter is application layer only, Thread is (according to this article) actually the "Link" layer. In between is using existing standards (IPv6).

image
Ref: Protocol stack - Wikipedia


Ref: Why Matter matters, and how does WiFi and Thread fit into it.

1 Like

I got this..

_zigbee_osi

So I think that is saying that the ZigBee alliance has some say in the Application stack but also partially on the user application itself?

Yeah not sure - it looks like Zigbee is not part of the application layer other than providing an interface which I assume is via a fixed controller like HE. This seems to be the same thing as Thread except with thread it's called a border-router and there can be multiple border-routers living on the mesh and each one could potentially provide the API as necessary.

I forsee border routers being incorporated into devices such as TV's and such. This would put the big boys into a strong lead over others. Why buy a border router if you've got them all over the house already. Maybe the next iteration of Hubitat just needs to tap into that border router mesh. Or alternatively become an appliance in itself.

What appliance would make sense to house the HE hub and border router? How about an Android TV stick? That way it pops onto a tv and becomes an upgrade to the TV's capability and provide far more "smarts" than any TV has ever had. They could maybe do a collaboration with someone like Roku.