Interesting update from HA especially on managing Thread networks
I can’t imagine that Hubitat would want too many irons in the fire what with not being verified by HOMEKIT but in only in Beta currently. Then to bring in Matter at version 1.0—-! Let others work it out first before getting excited.
Looks like Matter still has quite a bit of maturing to do before it is ready for prime time.
6 Likes
I tend to agree. I embarked with my SkyConnect key and with an Eve Outlet on HomeKit.
Have been unsuccesfull in my attempts to make it work properly.
The Eve outlet received new firmware and added ok to Homekit (which it already did before obviously. But when i tried to add it to Home Assistant, the plug died in the sense of dropping of off HomeKit and being unable to re-integrate it.
Lets wait and see if and how Matter matures…
2 Likes
I found the video to be genuinely informative. Matter is very much at the beginning of implementation. Not soup yet.
1 Like
The video is good, valid and thought provoking but as in all things new an initial ‘not ready yet’ assessment, which I agree with. I am enthused that Matter will get there. Just not today.
However Hubitat always takes a safe yet indecisive position and that’s what they’re doing which is disappointing as this makes them a ‘me too maybe’ follower rather than a directional influence or leader in evolution, a role they could and should engage in more actively.
Grow some…..
What alternative is on offer? We do need a standard that work cross platform, vendor and transport.
At this stage, implementing and getting certified for HomeKit seems more like the puzzling choice particularly as there are many homebridge implementations which work quite well. Exposing Hubitat devices via matter bridging (see https://www.silabs.com/blog/bridging-non-matter-devices-to-a-matter-network ) would allow Hubitat devices to be controllable on iOS, Google Home, and Alexa without separate Homekit, Google, and Alexa plugins.
Its more than just IP. Its better routing and other changes that give overall much better network performance according to silicon labs and their benchmarking analysis. See Bluetooth Mesh, Thread, and Zigbee Network Performance Benchmarking - Silicon Labs . It looks like thread has about double the performance of Zigbee. See
And half the latency:
2 Likes
I think I may be hearing something very different from that video than others are.
The main issue pointed out by that video is not that the matter standard doesn't work, its that the end-device application, particularly Google Home and Alexa, aren't there yet.
So what does this really mean - the video seems to point out that Apple has generally gotten it right and if you are using an Apple ecosystem, it will work, but that Google / Alexa have a ways to go.
So, from a "what if it was implemented in Hubitat" perspective - the video shows that the standard is mature enough that a proper implementation (aka Apple) will work well. So, if Hubitat could correctly implement it, then Hubitat would have no problem controlling devices. Then what does this get people -- well, it seems most (or at least many) of us interact with Hubitat devices over Homebridge, Google Home community app plugin, or an Alexa plugin. At the least, for those devices that are Matter, we could drop having to use the homebridge plugin. In the meantime, you'd have to continue using the Google Home and Alexa plugin as we already do until Google / Alexa fixes their issues. Then those could be dropped.
In other words, I'm hearing that if Hubitat could control matter, we'd have access to this new protocol, could reduce reliance on homebridge plugins, and then when Google and Amazon finally get their act together, would reduce reliance on those plugins also. This seems to advocate more of a "get going on the Hubitat-side implementation and by the time that's ready, Google / Amazon are likely to be too" kind of mentality.
PS - and if we just focus on what doesn't work, rather than what does, we'd still all be focusing on ongoing problems with Z-Wave firmware updates, random device control delays, S2 issues, and routing problems! Talk about a perennially broken protocol that, IMO, seems headed for eventual abandonment by Silicon Labs.
2 Likes
I certainly see hear something different than you. Apple had a 20% failure rate in pairing most others were much higher. What I hear/see is that it is going to be a huge turnoff for people just getting into home automation that have an expectation that because of matter it will just work when it is obviously difficult at the moment. If it can bring frustration to a seasoned veteran, thing about how it will be for a non technical newbie. It still has a long way to go and all houses including apple need to get their shite together in fixing their stuff otherwise matter will be nothing but a failed experiment (which might be what some are looking for so they can keep their walker gardens)
3 Likes
I agree with this, I thought I was alone. I watched half that video and could not handle it anymore. Just looked like a show to cause controversy and gain traction for more views. The results seemed more like an opinion than scientific. People have issue pairing stuff on Hubitat sometimes also, it happens.
Just his face on the thumbnail of the video makes me want to NOT watch it, I had to force myself... its all click-bait for views.
Apple contributed the HomeKit onboarding process to Matter, so that's probably one reason the devices tended to work slightly more reliably for iOS pairing. Below is an example of successful onboarding. Also, for now, besides onboarding, Matter 1.0 functionality can be fairly limited. That's probably a bigger issue for most of the people around here.
These results seem very bias. As of now, Zigbee is a short-range communication standard based on personal area network (PAN) and operates on the industrial, scientific, and medical (ISM) band of 2.4 GHz. It also operates on 868 (it appears that this is the band used in the above throughput example you've provided) and 915 MHz frequency bands with the data rate ranging from 20 to 250 Kbps. It operates on 27 different channels, of which 16 are in 2.4 GHz, 10 channels are in 915 MHz, and 1 channel is in the 868 MHz band. The networking characteristics of Zigbee are depicted in Table 1. I'm not saying that it will fail as a protocol, but I definitely don't see the advantage over Zigbee.
The advantage over Zigbee is that it can run on any IPV6 stack, For example it can work on a special Thread network, or on an existing Wifi network. Really anything that supports IPv6 communications. At least that's how I understood it when I looked into it months ago.
2 Likes
Its true that both Zigbee and Thread start with IEEE 802.15.4 as the physical and media access control layer, but that is just part of the story and what makes Zigbee into Zigbee and Thread into Thread is how they build their network, discovery, routing, recovery, packet transmission, and other layers onto 802.15.4. In this, Zigbee and Thread are very different which may explain its lower latency and higher network throughput even though the physical layer is the same.
I don’t believe that IPv6 is an advantage. I think running this on your network is another point of failure and a security issue. My Zigbee mesh network is stable and works whether my local IP network is up or down. It’s dynamic and routed according to what is nearest to talk to first, until it gets to the hub. If the nearest device falls offline, it will just talk to the next closest device until it can finish a hop to the hub.
Didn’t you read what I sent you? Zigbee can have speeds of up to 250kbps, just as Thread. The 20kbps throughput is when using the 868mhz band. It would seem clear that they were not comparing apples to apples.
Most "Border Routers" are hubs and no different than Hubitat, with one big exception. They're dumb. The routines I run are far beyond anything you can ask Amazon's Echo or Apple TV to do. I tried to get Alexa to do an "If This, Then That, Else, This, and That, If This". Matter hubs are necessary for Thread to communicate, yet all the advertising says that you don't need a communications hub like Z-Wave and Zigbee. If that's not confusing, I don't know what is,
With no central point of communication, how do you write routines. Do you have to connect to individual devices and program it to do it's thing? I find it hard to believe that this is easier. What a mess it would be to connect to each device to see what's been programmed to do what. I already have hundreds of devices (well so it seems anyway) and I want one hub to go to to view everything. If you tell me that I can do that by looking at just one device on the Thread network, then you're back to having a hub, even if it is a light bulb.
Damn... I apologize, reading it all back, I think it sounds angry. LOL! It's not meant to be. 
1 Like
