Hello
I am migrateing my primary hub from HomeKit to Hubitat because I like it better than homekit, and I can use my pi for other things. The question I have is, will there be plans to support thread? I would love to have everything running on Hubitat, and only use Homekit as an interface.. but Half my home is running thread.. so it’s not currently possible. So curious when/if it will become possible?
It’s highly likely that the next release will contain a huge HomeKit / Matter update. I don’t know if that will include Thread support.
1 Like
By release you mean software, or hardware?
Software. That’s why there hasn’t been a release for over 6 weeks.
1 Like
I wouldn’t count on matter happening real soon. I also wouldn’t count on thread happening on a C-8 hub. Time slicing the Zigbee radio apparently is as bad of an idea as it sounds.
2 Likes
The info I’ve seen suggests that Matter is the big project in development ATM. It’s not a simple implementation, hence the time between releases.
I have no info on Thread support.
1 Like
I think you are misunderstanding the context of those comments from Bruce.
I recall reading that the C-8 will support Thread. There is no mention that I have found if any hubitat hub will support Matter. Thread is a device control WiFi protocol. by supporting Thread, HE will be able to integrate directly with WiFi device that implement Thread. Thread is a WiFi based protocol.
Matter is the integration protocol that work on your existing WiFi network. Hue, HomeKit, Alexa all support Matter today, and this enable HomeKit and Alexa to talk to hue, but I have not seen HomeKit nor Alexa talk to each other via Matter. I for one would love to see Matter support in HE, as it would obsolete my Hue custom code for a lot of things, reducing these integrations to simply filling in the gap of unsupported features -- in the case of Hue this means groups, and dynamic scenes would still need a custom app. More important to me, is it would mean that HomeKit, Hue, Google, Alexa, and all the other Matter supported hubs would be able to integrate with HE without having to create multiple integration apps that do things slightly differently.
You have it somewhat backwards, staff have said they have plans to support Matter (no ETA). They have also said Thread would not be supported on any current hub because it needs a 2.4ghz radio (like Zigbee) and the hubs only have one, which is used for Zigbee. They do not want to compromise Zigbee functionality by "time-slicing" the radio between two protocols.
The people who have said otherwise are not staff.
If you have a basic understanding of the networking stack there are lots of nice info graphics about thread / matter / zigbee comparisons
9 Likes
Hopefully that Hubitat will support connection to another Matter/Thread hub that it can comunicate with localy. I would be ok with 2 hubs as long as it stays local in some way.
Just to re-emphasize what’s been mentioned above.
Matter and Thread are not the same thing.
Matter might eventually be supported through software updates.
Direct support for Thread, if it’s ever supported by Hubitat in the future, would require new hardware (unless they change their mind about “time-slicing” between zigbee and Thread as @jtp10181 alluded to).
4 Likes
Hey if it can see all my thread devices through my HomePod mini I’m ok with that. I just want a smart home where everything works without the cloud
That is the beauty behind Matter… All these cheap devices coming out that usually have closed cloud based APIs are going Matter with a standard local API..
5 Likes
I'm sure you've seen more Matter devices than me but it just feels probable that the absolute minimum Matter compliance will be created. Will they retain 'all the good stuff' in a private API?
2 Likes
Not that I have seen, with what I have had my hands on… But it’s still pretty early days for the standard
4 Likes
I just like the private cloud stuff is on the way out… Long term I thing this is going to drastically increase the available devices… It makes it easier for manufacturers since they don’t have to write integrations for Alexa/Google/etc..
8 Likes
I think there may be less need for any type of a private API in Matter because the Matter standard provides a "standard" way to keep all the good stuff that used to require private APIs.
Specifically, the standard defines a "mode select" endpoint device (and you can have many of these) which can be used to display to the user a list of choices. So, for example, if you have a switch with a smart bulb mode, you can define an endpoint with the label "Switch Mode" and give it choices like "Smart Bulb Mode" and "Normal Mode". Or if you have a RGB bulb with lighting effects, you could have a "Lighting Effect" mode selector and choices like "Normal", "Flash", "Race", "Holiday Colors", etc. Your hub / app can read the "mode select" endpoint and display the choices (and they can be dynamically updated) - so, for example, if you can load different color effects into your bulb via Bluetooth, the mode select can dynamically update with new labels.
However, its a chicken-and-egg problem - I don't think this is in use by anyone yet. It seems that manufacturers are still doing just the basics! But that's an implementers fault, not a lack of capability in the standard.
Matter 1.2 is near release (there are pre-releases posted on the matter and Silicon Labs github sites) and includes new device example code that allows building virtual devices on a Rpi that do implement Mode Select, so hopefully these new examples help push the hub makers implement the corresponding functionality.
Among us Matter skeptics, I don't think any of us doubt that Matter is very well capable of satisfying a whole slew of connectivity headaches, but when push comes to shove, opening up all capabilities via Matter means dried-up revenue steams from unique hardware & features (walled gardens) for many manufacturers.
Hence skepticism about how things will actually go.
8 Likes
I think that summarizes my thoughts perfectly 
4 Likes
