Now that I see this is coming to c7 as well, my interest is heightened. But it’s still pretty new to me. And it’s matter, not thread yeah?
It’s effectively… devices can be controlled locally over wifi/lan right? Knowing the support is there, is there an actual reason I’d look to be choosing a matter device over zigbee or zwave, given I already have zwave and zigbee mesh and support in the hub?
You don’t have to choose one over the other. It simply expands the number of devices that can be used on Hubitat, locally. Choose whichever device best fits your needs.
It is Matter, not thread, but you probably already have a tread border router in your house, whether it be an Apple TV, HomePod, some Amazon Echo devices, or some Google home devices, or maybe others, such as Aqara’s newly release outlet that acts as a thread border router.
Yep I've got an apple tv.
As I understood things historically, people advised AGAINST wifi devices because they are cloud based. Some could be altered or otherwise be made to work locally.
Then the issue became that every wifi device talks to the router directly, so lots of traffic and potential range issues as you get farther from the router.
Now with Matter, which connects (initially?) to the thread border router like Apple TV... is thread mesh as well? Is network congestion still an issue then?
I bought a bunch of zigbee sensors off aliexpress cause they're cheap, mostly. But with Matter there can be a bit more of a compromise, it seems. Kasa, for example, has newer line of matter devices - so you get better quality control, build quality, and matter support. And readily available through Amazon or other.
Thread is a mesh network and quite similar to Zigbee, aside from having border routers (and being only the lower layers and not the full stack like Zigbee is--that's where Matter, other protocols in some cases, comes in). I'm not sure if this is what you're asking, but note again that Thread is separate from Matter, and a Matter over Wi-Fi devices does not need a Thread Border Router, nor does Matter escape the need for the Wi-Fi device to be within range of your Wi-Fi access point like any other Wi-Fi device.
Separately, many cloud devices are Wi-Fi or at least proprietary, or at least have historically been; if Matter catches on, that might change (though I suspect those will always be around). The nature of the device was always the biggest concern, not the protocol, though if you have lots of Wi-Fi devices and cheap consumer gear like an all-in-one ISP modem/router/AP, you might hit some theoretical or at least practical client limit. Not sure what's common these days...
Not any fault of HE, but for me, a downside to this is that none of the devices will be accessible by the Swap Apps Device tool, as they are all children. I use Swap Apps frequently when troubleshooting, modifying/upating automations, etc., and not having access to devices in that app is a issue for me. I already am blocked on Hue and Bond devices (which I had before Swapp Apps was released).
I don't want to add even more devices that are inaccessible to Swap Apps. I probably won't have to as I'm fully covered now w/my Zigbee/Z-Wave devices and only added Matter to help w/Beta testing. But if I had a hub full of devices that weren't accessible to Swap Apps it would be a bummer and a step backwards in terms of the manageability of my automations/devices.
You should of course do things the way you think best, but I think you may have gone down a mistaken path with this approach to apps and devices. I do a great deal of testing with devices and apps, and I can count on the fingers of one hand the number of times I've used Swap Apps Device. Each of those was to replace a failed device with a similar one. Perhaps there are better ways to accomplish what you're doing, or to rethink how you're going about managing things.
Hubitat supports Matter over thread with a thread border router. (Homekit for instance)
Matter over wifi is still 100% local.
That said not all wifi is cloud based. Integrations in Hubitat like LIFX, TpLink, Shelly, etc are all 100% local.
I could be misunderstanding the conversation here... But I expect I understand the limitations from previous conversations... So setting myself up for a simple rebuff...
That is certainly true if your choices regarding the way your devices are paired remain relatively consistent. HE does, however, offer the flexibility to move from, for example, having Hue bulbs and accessories paired to a Hue bridge to utilising custom apps like Coco-Hue. Similar examples may exist for those who transition from pairing devices to HE to utilising other platforms like Z2M or Home Assistant on another hub / server. In these cases it is desirable to have an easy transition from one approach to another.
I guess the simpler plea to make would be that matter devices don't have the parent association... Again I could be missing the reasons for this needing to be the case... But for me, it feels like it may introduce a barrier to people choosing to move from linking their existing Wi-Fi devices, in particular, via Matter. Hopefully I am wrong and can have this explained for (mostly) others to benefit from.
So for all intents and purposes, is this effectively the same as a matter device though? Given that, begins the scenes, a driver/handler has already been created
Of course that may be true, but I'm using Swap Apps in the way that HE staff explained it's use/usefulness when it was released. Some examples below:
Swap makes the replacing quick and easy.Instances when I really wanted Swap Apps but couldn't use it:
Poor poor, pitiful me. 
If any of these uses of Swap Apps don't make sense and there is an easier/faster way, I'm all ears. I love Swap Apps and find it makes actions like above almost a pleasure, rather than a chore.
+1
As someone who had to deal with a bout of "zigbee reboot disease" and was asked by support to remove any Zigbee devices "not on the compatibility list" this tool could have been more useful than it was (couldn't swap some zigbee switches & dimmers to extra Lutron or Kasa devices I had on hand, for instance).
I think I have found to isolate myself from this issue by putting devices on one hub and mesh them in to another hub where the automations live. Since hub mesh replicas are not child devices, I believe I can swap'em in automations at will, regardless of the source device (EDIT: never mind, doesn't work).
There should be a way to have that same experience on a single hub. Feels like there is a level of indirection missing.
Just because something is wifi or thread does not mean it's matter. Matter however does run over wifi or thread. wifi and thread. So think of it this way. wifi/thread is the transport layer and matter is the application layer. Application rides on top of the transport.
I don't think this is correct...I have a bunch of fans set up in the Bond integration on my C7, and to mesh them back to my C8 the only option is to mesh and select the parent device. On the C8 none of the fan child devices show up in Swap Apps on the C8:
You can only mesh the parent device, not individual children:
You end up w/Bond parent w/child devices on the C8, a mirror of the C7. None of the child devices are selectable in Swapp Apps.
As soon as the same child device is used in more than one rule I am using de-childifising
technique by creating a mirrored virtual device and using this virtual device in all rules.
For some devices this is very easy but for some a bit tricky. Anyway next time when I have to
replace one child device with another child or real device I have to make changes only in
ONE place.
That's exactly what I did for my Bond fans, and also I did not like how the Bond driver was working with Homebridge so I made my own custom virtual driver.
For me it’s not about the devices, but rather it’s about the mesh networks. My brother-in-law has a main house and guest house, and has a hub in each connected through hub mesh.
I have a hub at my camper that’s linked through hub connect, since that works remotely over the internet, that allows me to use my Amazon voice integrations since you can only link the Alexa skill to one hub.
I’m in the same boat with regard to Bond and HomeKit. Would you mind sharing your custom driver? Many thanks!
Check these two posts (on same thread)
Link to my driver code is here: Mirroring Virtual Fan to Physical Fan Controller - #7 by jtp10181
Briefly explained how I mirrored from real device to virtual: Mirroring Virtual Fan to Physical Fan Controller - #2 by jtp10181
Question:
Will I be able to use the Matter compatibility of the Aqara U100 lock to use it from Hubitat?
Do I need to have a Aqara hub to do that? Or is a Google Home enough?
From the Aqara ad for this device:
Download the Hubitat app
