I believe I generally understand Matter/what Hubitat is doing with it, with one caveat. It's well known that multi admin is generally a ■■■■ show now. Is the current implementation just wading into that? If I take my pixel phone and my Google home and use those to provision a device will those as well as my Hubitat hub all function as controllers? Will they share the same fabric?
My understanding is - yes, both Google Home and Hubitat will function as Matter controllers and will share the same Matter Fabric.
(edited)
1 Like
That is correct,,,
Yes. And the status from the device will be updated to everything. Now the real issues are the devices themselves.
Nanoleaf String lights-Keeps dropping back to BLE. Nanoleaf unresponsive
Meross Outlets- Drop of the fabric within hours. Difficult to initially pair. Need propecia to replace some hair you may have lost during the process.
Tapo outlets-Fantastic... Solid...
Bottom line is, check ratings on devices here to see what people's experience with that device is...
Note: The next iteration of the HE's app will have access to the bluetooth controller, so Hubitat will then become a Commissioner and you will not need to onboard from another system.
2 Likes
My understanding of this particular question, contrary to the above, is "no." I believe they are different Fabrics or "networks." But this is mostly a technical distinction you don't need to worry about; the important part is that they will both work to control the device, do the answer to your other question, as stated, is "yes."
2 Likes
For a better understanding see What is a Matter Fabric? | Know-how | matter-smarthome. Matter Fabrics are independent of each other. In this scenario, a matter device would be connected to two different ones (Hubitat and Google Home). From a "use" perspective, it does not matter as there will be a bi-directional sync keeping the device in the correct state.
2 Likes
@JB10 In my case of having 4 Matter devices, all of them first commissioned via Apple Home, and then paired with Hubitat (using Apple Home to put it in pairing mode), the diagram should look like this :
Each Matter devices is storing two certificates - the first one from Apple Home, the second certificate from Hubitat. This is the Matter Multi-Admin mode
1 Like
That's exactly how it works. I've got three (Apple, Google, and Hubitat), so each of my devices have three certificates for three different Matter Fabrics.
1 Like
Interesting distinctions here I was missing! Does that mean the main issue with multi admin is thread devices not being connected to each other/ I suppose not being on the same fabric?
Thread doesn't use "Fabrics"; Matter does. 
But Thread does have its own concept of networks (really all that term means for Matter, too). Thread 1.3 is supposed to make sharing keys among Thread Border Routers from different manufacturers possible, enabling them (and all their devices) to form a single Thread network, but I'm not aware of any working implementations of this at the moment.
So, for now, your Apple, Google, Amazon, etc. Thread networks are all separate, if that's what you're asking. Such devices could still all join the same (and/or different and/or multiple) Matter Fabrics without problem, however. Thread routers on one just won't route for Thread devices on the other regardless, sort of like how Zigbee devices on different hubs don't, either.
Just a side question: My google thread network says it uses channel 22. Is that numbering scheme the same as the zigbee one?
I believe the channels are the same. I haen't used a TBR that has let me set (not sure if it's spec to just auto-manage? wouldn't surprise me...) or even see the channel yet (never used Google), so that's actually interesting to know!
I have a slightly different issue/question, but thought this an appropriate thread to tack it on to.
So I'm building out my matter devices (and adding them to my HE infrastructure), but have some issues with devices reporting in Apple Home but not updating in HE e.g. a EVE door sensor. Apple Home reports the door has opened/closed, but this isn't always being reflected in HE.
I have quite a large area to cover with several small buildings. I have a Apple TV in each with the expectation this would provide a stable TBR in each building (even thought the thread wifi network might not reach between the buildings).
Plus some of the buildings have old tin cladding (one is actually an old cow shed) so signal penetration is poor. The apple TVs are connected via Wifi but to APs inside those buildings.
Using the EVE app I can see that I have a single Thread network (which is what I hoped) and I assume the Apple TVs are linking up all these thread areas via normal Ethernet. Is this how one would expect it to work?
The Nanoleaf mobile app reveals that I have 3 different Thread networks : one named "MyHome61"using Apple Border Router on channel 25, specific PAN ID, specific Extended PAN ID, Network Key and PSKc (don't know what it is).
On the same Nanloleaf "Thread Network" page, there are two more Thread networks - one is called ST-401****** and is created by my SmartThings V3 hib, and a third one called TMSThread_**** with a TBR named "OpenThread" - this should be my Zemismart M1 Matter bridge.
So, I have undoubtedly ended up with three different Thread networks... 
In your case, however, all your TBRs are using one and the same brand, which probably uses one and the same iOS keychain for the SSL certificates. So in your case it may be one Thread network, I am not sure.
So my concern (perhaps this is a misconception) with all these independent thread networks is that they'll each use their own frequency, which could end up impacting other services. I assume that by using a single vendor (at least in these early days) will mean that there will be a single Thread network using the same frequency even thought each TBR might be isolated from each other (from a thread perspective) as I mentioned.
I haven't been able to find much information about this either so would love to know more from anyone who does, but I assume Thread uses the same channels Zigbee does, and with independent Thread networks, they'll likely be on different channels -- which sounds like your concern. (I haven't used any Thread network that lets me choose that channel like most Zigbee coordinators can, so I assume it's either automatic per the spec, perhaps handled under the hood as needed; or every implementation I've found so far just chooses to do that for end-user ease.)
But even the same Thread network could do, that too: if you have one group of Thread devices that can't wirelessly communicate with another group, they'll form their own "partition" while using your LAN as the backbone, while transparently behaving as a single Thread network so you don't really need to know the difference (perhaps slightly different from your concern in that this is unlikely to happen if they're truly within radio range of each other and likely the main reason you'd care, but still a possibility).
