You can still have hubs and but with the Matter multi-admin feature, you aren't limited to a single central point. Instead, each device can report to and be controlled by multiple hubs which are equal peers. Thus, for example, a device could talk to a hub like Hubitat, an iOS device, a Google Home device, and Alexa. Changes to the device which may be caused by one device are then reported to the other controllers by the multi-admin feature.
I'll check it out when I get home, but so far it just looks like we're muddying the waters with more stuff. BTW: My neighbors kid can download utilities to break into my WiFi, but he knows nothing about my Zigbee mesh and it doesn't extend far enough for him to try and find it.
1 Like
Some good Thread information here.
https://openthread.io/guides/thread-primer
Yes, there are security/privacy considerations. And even as the Thread network is more complex than a Zigbee network it also has more tools to self-manage and heal. For example, the network can partition itself when necessary. From an end user perspective the Thread network manages channels and there are no end-user channel settings.
Matter 'fabrics' are required to use Matter devices within a specific company's ecosystem, whether those devices communicate via Thread or WiFi. In theory a company, e.g. Hubitat, can have a Matter fabric even if they don't have a Thread border router as part of a main controller.
Also, Thread network can (and does) carry other 'languages' than Matter, even simultaneously.
As posted some posts above, Home Assistant has some good documentation of the intermixing of Matter and Thread:
Thread and Zigbee function similarly at the 802.15.4 link level but there are notable differences in how the meshes function (aside from Thread's use of IP).
A Zigbee mesh features a single coordinator and device roles that basically include router and end device (which may be 'sleepy' if battery powered). A Thread mesh has no coordinator; its device roles include leader, router, router-eligible, full end device, minimal end device (akin to a sleepy device but with always on radio) and a couple of categories of sleepy end devices (differentiated by how their periodic wakeups to communicate with their parent are scheduled).
Thread routers provide both joining and security services so no coordinator is required to form or maintain the network. Zigbee HA meshes depend on a single coordinator/trust center that is critical to the network (with no architected provision for redundancy).
In a Thread network a single 'Leader' router is required; it's dynamically 'elected' and if the current one fails, another is automatically chosen; so single point of failure (assuming provisions have been made for border router redundancy).
A key function of the Thread leader router is to decide which routing capable devices actually function as routers in the network-- this is another difference between Thread and Zigbee, and likely responsible for the measurable differences in latency due to minimizing broadcast traffic. In a Thread mesh, at any point in time only a subset of routing-capable devices will actually function as routers; they're considered 'Router-eligible devices' and their current role is managed by the leader router.
By minimizing the number of active routers, route discovery broadcast overhead in a Thread network can be minimized. In contrast, all routers in a Zigbee network actively participate in periodic route discovery (generating broadcast traffic that can become more significant as the size of the mesh increases).
How all of this plays out in practical use will be interesting to see. While Thread wins latency benchmarks (at least those publicized by SiLabs) a key point is that a 5-hop Zigbee mesh can still provide sub-100ms multicast response times (with 200ms being the benchmark for 'human noticeable' response). That's key for eliminating the 'popcorn effect' in lighting automations using group messaging.
Texas Instruments (provider of both Zigbee and Thread certified stacks) notes that the typical Zigbee device control application payload is likely to be smaller than Thread's datagrams; its (admittedly old) whitepaper Thread vs. Zigbee – what’s the difference? - Embedded processing - Technical articles - TI E2E support forums comparison for application packets rates Zigbee 'Optimum' for power performance and 'Best' for latency (TI assigns Thread 'Very Good' on both measures). SiLabs' power profiling of Thread and Zigbee sleepy end devices concluded that both are capable of providing multi-year battery life using wafer cell batteries; Thread seemed to have a very slight edge, but again the application payload sizes chosen would affect the outcome.
9 Likes
Security Through Obscurity. The tried and true approach. 
2 Likes
No worries, your surrounded here by folks who get excited and rant about all kinds of geeky stuff. 
2 Likes
As I mentioned previously, Zigbee is also self healing and uses 27 channels that you don't have to manage either.
The problem for me is that this new protocol and mesh do not answer a need, other than to promote the "Cloud", which like all services will become less affordable as it is adopted by the majority.
Major contributors to jump onto this new technology:
Google, Samsung SmartThings and Apple,
Does HomeKit work without an internet connection?
Yes, but you won't have access to Siri, automations, and HomeKit devices that use the cloud.
How Does Nest Function When The Internet Go Out?
Nest will function without a Wi-Fi connection. However, it cannot be used as a “Smart” thermostat and only as a regular thermostat.
The SmartThings Hub could be an essential smart hub in your home.
PROS
compatible with a wide range of smart devices
works with android and smartphones
CONS
requires wired internet to work
does not support Nest smart thermostat
I have been doing home automation for about 8 years and have never had any device go to "sleep". I have had inexpensive devices lose connection and I will bet money that it will also happen with devices created for Thread mesh, as they are all open source and invite innovation from smaller companies that will use less desirable materials.
I can see this causing a split brain phenomenon. We see it all the time in the IT world, where one device claims to be MASTER and is giving commands that conflict with another device is saying that it's in charge, giving it's own commands. Code can and will go wrong.
On top of that, it seems like the Thread leader router could be the same single point of failure as having one Hubitat router. I can also setup a secondary Hubitat to use shared devices from the first, to verify routines have executed properly and /or execute them if the first hub did not.
I'm just an observer in the main discussion here, but this statement seems unlikely.
All of your battery ZigBee devices (e.g., motion sensors, contact sensors, etc.) keep their radios on 24x7x365 remaining responsive to any signal from the hub? The common behaviour is for these devices to turn on their radios when they have an event to report, or some other sensor side activity occurs (e.g., time to report battery, someone pushed a button, etc.).
2 Likes
Inconclusion, as previously mentioned, it seems that Thread mesh and Matter devices are just "cloud" promoting. Most of us left the "cloud" for local control and I'm not giving that up. IMHO, adding mesh to your WiFi network is just asking for trouble, if your network get hacked.
Then you have the cost of these devices. With all the hype, these devices are selling for more than 3x the price of the inexpensive Zigbee counter parts. Last, even if you don't have any split brain or other technical issues with this very convoluted setup, this will go the way of X10 (I was an early 1990's adopter) and Zigbee IP if the "cloud" companies Google, Apple, and Samsumg SmartThings can't make enough money off of you and abandon their participation. I believe this will become a subscription based product like Wink (I was an early adopter in 2015). There's no other reason for those big three corporations to jump on board.
I have battery Zigbee products that are reporting are second floor wireless contact sensors (all others are wired with Konnected). I also have three dead bolts and not one of them has failed to communicate, whether via routine script or manual trigger from Hubitat. The dead bolts have been installed for about three years and the contact sensors (16) for a little over a year. These were previously connected via Wink and 3rd Reality hub and did not "sleep" on them.
Please explain what happens when you see one "sleeping" and how you get it to reconnect. If mine are "sleeping", they must wake up immediately upon command.
BTW: Batteries last about 4 months in the door locks and 16 months for the contacts.
It seems you are using "sleepy" to describe a device that has lost connection and not communicating with the hub anymore. That's not what this means.
A sleepy device is one that only turns on its radio only if it has something to say due to an event on the sensor side. You can't poll it from the hub because it isn't listening. However, if the contact opens, or if you push a button, or it is configured to report battery every 4 hours and that time is up, then the device knows it has something to say and says it.
A "sleepy" device isn't broken. It is working perfectly as designed to prolong battery life.
7 Likes
Yes, that is what I thought the term was used for. As an IT guy, I am familiar with devices that have issues when they "sleep" and won't wake up, unless rebooted.
Thread is 100% local, it would be up to the border router (such as an apple homepod or lets say an echo with thread enabled which apple uses mostly thread) to keep it out of the cloud. Lets say that Hubitat had a thread enabled radio (essentially another zigbee radio in order not to time slice a single radio), hubitat could control that thread device (lets say an outlet) with no cloud involvement what so ever. Thread is a pretty mature protocol and the specs for it and open and laid out pretty clearly. Matter on the other hand? You will need a matter enabled unit to make the primary connection, but again, lets say that you use an Echo to connect it to matter and Hubitat is matter compliant, then once the device is available to the matter mesh, you can remove control and communication to the echo device and no cloud is needed as matter would be running over thread. Again though I'm sure that amazon, google, etc will try to monetize the data but in the end, it doesn't have to be cloud based.
The key word you used here is Hubitat. Without it, none of that works. I've tried to ask Alexa to do complex routines and it cannot. So once again, we're not fixing a current problem we're just adding more to an already muddy water, because Hubitat can already manage what you have locally. If they do improve Hubitat to support Thread and Matter devices, no one will purchase devices that cost 3x the current technology with it being able to fix a current need. By the time China is producing cheap knockoffs, those big three will be charging for "cloud" services or they will have left the game. They're in this to make a profit and they wouldn't invest in it if they didn't feel there was a large opportunity to do so. Charging for "cloud" services is their only hope. I work for large corporations and are projects designed to increase the bottom line, while looking like they are helping a greater cause.
From my limited understanding, it answers a need for separation of concerns (network stack / application layers). Need being expressed by chip manufacturers, among others. Irrespective of any differences between them at the network level, ZigBee appears to try to "do it all". Thread/Matter seems like a cleaner/useful split.
This kind of thing has been litigated to no end for multiplayer games (a low latency network application with exacting users). One of the problems is how do you migrate any state info when you elect a new leader. I won't bore people here with all the scenarios. A "single-point of failure" can also be a "single point of success". There are many tradeoffs. Very curious to see where the chips will fall in practice.
Ya that's one scenario, cluster split.
Fun times !
1 Like
As @HAL9000 noted, the sleep state is fundamental to how all battery operated IoT devices work.
Typical design point for an SoC in a Zigbee (or Thread) end device like a contact sensor is to target 'sleep' mode 99.99% of the time. The chip does include an 'always on' portion of the core logic which is capable of ultra low power consumption (typically less than 1.5uA) yet capable of responding to external events (like a contact closure or real-time clock interrupt) that enable it to wake up the rest of the system, enable the radio, transmit & receive as necessary and then return to sleep.
Zigbee (and Thread) devices like pushbuttons and contact sensors could theoretically remain sleep forever unless wakened by an external event, but this isn't how they are designed. They need to remain logically joined to a parent router in order to be capable of transmitting or receiving messages (all data transmitted or sent to a sleepy Zigbee or Thread device is queued in message buffers in the parent router); that parent device needs to receive a periodic poll from its sleepy child devices within a defined timeout interval or it will assume they've left the network and free up their message buffers for future use.
Depending on the device (and profile in use), that poll interval could be several seconds or an hour or more. I've timed the poll interval of my Zigbee lock at roughly 3 seconds which means it's essentially dead to the outside world aside from a few milliseconds 20 times every minute. So depending on when the 'unlock' command hits my Kwikset lock's always-on parent router, it could take up to 3 seconds for its Zigbee chip to wake up, initiate a check-in with its parent and determine if an 'unlock' command has been sent for it to execute.
Sleep mode power savings make it possible for the battery life of sensor type devices to approach years rather than weeks while using a small battery; other optimizations like shortening message frames (by associating 64 bit MAC addresses with 16 bit device ID's) minimize the radio-on time, saving considerable power (a Zigbee SoC's current consumption while transmitting is several thousand times more than while sleeping). Zigbee Green Power truncates message frames even more, making batteryless operation possible (nanojoules per bit add up, especially when you're harvesting the kinetic energy of a button press in order to power the radio).
5 Likes
Previous post have shown that I have misunderstood information provided, so please feel free to redirect me if the information below is not what you were speaking of. 
Thread uses all stack protocol layers, just as Zigbee.
Example application layer protocols that Thread uses:
3.5 ICMP
Thread devices support the Internet Control Message Protocol version 6 (ICMPv6) protocol as defined in RFC 4443, Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. They also support the echo request and echo reply
messages.
3.6 UDP
The Thread stack supports User Datagram Protocol (UDP) as defined in RFC 768, User Datagram Protocol.
3.7 TCP
The Thread stack supports a Transport Control Protocol (TCP) variant called “TCPlp" (TCP Low Power) (See usenix-NSDI20). A
Thread-compliant device implements the TCP initiator and listener roles as described in:
• RFC 793, Transmission Control Protocol
• RFC 1122, Requirements for Internet Hosts
• Thread Specification 1.3.0: Existing TCP implementations are typically not tuned to work optimally over wireless mesh networks and
with the limited 802.15.4 frame sizes. Therefore, the specification defines those elements and parameter values required for an efficient TCP implementation over Thread Networks (see Thread Specification 1.3.0, section 6.2 TCP).
UG103.11: Thread Fundamentals
IP Stack Fundamentals
silabs.com | Building a more connected world. Rev. 1.4 | 10
3.8 SRP
Service Registration Protocol (SRP) as defined in Service Registration Protocol for DNS-Based Service Discovery is utilized on Thread
devices as of Thread Specification 1.3.0. There must exist a Service Registry, maintained by a border router. SRP clients on the mesh
network can register to offer various services. An SRP server accepts DNS-based discovery queries and additionally offers public key
cryptography for security, along with other minor enhancements to better support constrained clients.
Yes, but my understanding is Zigbee goes much further up into the app layer, with the ZCL defining interfaces for end user devices like thermostats and window coverings.
This is the relevant picture in your document:
Just below the figure :
A standard definition of an application layer is an “abstraction layer that specifies the shared protocols and interface methods used by hosts in a communications network” (Application layer - Wikipedia). Put more simply, an application layer is the “lan- guage of devices,” for example, how a switch talks to a light bulb. Using these definitions, an application layer does not exist in Thread.
My understanding is that Matter goes above the dotted line, where Zigbee ventures and Thread does not.
3 Likes
You need to be careful with this statement, Some battery operated devices don't sleep and can receive commands all the time like the Smartthings multi-sensors and a few others that I don't have in mind right now (I think the Hue motion sensors also never sleep but not 100% sure). So although most do sleep not all go to sleep and this can be important for some setups.
2 Likes
