I don't have any Matter controllers that properly act as bridges other than my dev kit I am coding devices on (I also setup a bridge for testing while setting it up).
For me, this is one of those chicken and egg things. If I had a Matter controller that correctly presented non-Matter devices via a bridge I would probably start tinkering with HE drivers. But I don't.
( snarky uncalled for adder that should be totally ignored: I'm much more interested in ZWave LR support. I have a ton of those to test. )
Be you here notified that my lawyer will contact you seeking compensation for the expenses (2 x C-8 hubs) that soon to be incurred by me because of your "Hub Failover" app.
However, all hassle can be avoided if two brand new C-8 hubs are credited to me, as a form of avoiding litigation and subsequent legal expenses.
I truly believe that this offer is quite reasonable and I expect to hear from you soon with your acceptance of it.
Saw this on AppleInsider:
Aqara's new smart plug is also unique, being one of the first to include Thread border router capabilities baked in. It bridges your Thread network to your Wi-Fi for a more seamless smart home experience
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.
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.
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:
Moving devices between hubs. Swap existing automations to virtual device, remove device, pair device on second hub, Hub Mesh back to first, Swapp meshed device(s) in to replace virtual device(s). This was required by C8 issues w/some (officially supported) Zigbee devices on C8 that myself, community, and HE staff were unable to resolve over several months (including C8 hub replacement). Moving devices from C8 to C7 was only approach that finally worked.
Replacing existing devices for something newer/better. I have replaced multiple contact and motion sensors in my home over the years for devices that had better battery life and/or better sensing, etc. Swap new in to replace the old in all automations.
Wife prefers tiny sensors...doesn't want ones that are (her definition) "too big." So in some cases she'll ask me to swap locations/uses of Iris v2 (favored "tiny") vs. Iris v3 ("a little too big") motion sensors. I inflict my home automation hobby on her, so she gets the veto vote.
Replacing old sensors that are dying/dead. I have a lot of old sensors, particularly Iris v2/v3 motion sensors and Visonic contact sensors that I like because they work really well and are wife approved. I have had some of them die off on me. Also have to admit I've dropped a few of the Iris sensors when changing batteries and some of them didn't come back from the drop, unfortunately. Swap makes the replacing quick and easy.
Instances when I really wanted Swap Apps but couldn't use it:
Changed out six Hue bulbs for brighter versions. I had to manually go and update each automation for every bulb. Poor poor, pitiful me.
When I moved to the built-in Bond integration had to manually edit every fan automation to replace the community integration devices w/the HE integration devices. Then, when I had to add a new child instance of a fan in the HE Bond integration to resolve a fan control problem that Bond support worked w/me to resolve, I had to manually edit every automation that fan was in to replace the old fan child instance w/the new one.
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.
)
Swap makes the replacing quick and easy.
