SiLabs describes 'Dynamic Multiprotocol' where (as in Ti's DMM) the application timeslices the radio, rapidly changing configurations including the channel) but also discuss 'Concurrent Multiprotocol' where both Zigbee and Thread can run concurrently on the same radio, sharing the same channel. This would appear to take the burden of complexity away from the application code.
That approach may still be on the horizon though, as they note "Zigbee and Thread are one example of suitable protocols for a concurrent multiprotocol implementation (not yet implemented in SiliconLabs stacks). I don't see a date on that doc, but haven't found one newer than rev 0.3.
Neither approach comes without drawbacks and constraints, as SiLabs notes:
Note: When a radio has to switch between two different PHYs, it 'disappears' from one network or another. For protocols where the device might be the 'parent' of a sleepy end device, if the parent device is not available when the sleepy end device wakes up to send a message, regular dependency on retries will impact the sleepy end deviceās battery life.
And neither would any data go out when the thread devices are connected on a vlan that has no access to the internet. I honestly don't know which way this will go. But thread devices apparently get an IPv6 network address on the 2.4ghz spectrum. If you currently run Ubiquiti or Omada or something similar, you have network gear that is excellent at assigning devices network addresses and routing traffic through and between them. Why not use it?
With both Ubuiqiti and Omada it is fairly straightforward to prevent any device from communicating with the internet, I don't see why if they came out with a thread implementation it would be any different. At least with something like Ubuiqiti and Omada you would need to setup the proper ACL's to ensure the devices don't communicate with the internet. With Hubitat, I don't know how you would do that, you could disconnect the HE from the Internet, or take Hubitat's word that their thread devices won't communicate with the internet.
Who knows, I definitely don't know how this will turn out. I would just be surprised if thread does become popular, if it is not build into most home routers and/or networking equipment.
Matter is a local hub mesh solution. Matter will allow any Matter controller to talk to any other Matter controller for which it is linked, directly -- no internet. Matter gateways may act as a bridge between matter controllers on the LAN and devices in the cloud, but the Matter controllers can choose to provide cloud based hosting as well, but as a bridge in that case.
I can't find a good reason to support another device clogging up the already over used 2.4GHz band that doesn't have a good advantage over the current standards. If you compare Zigbee vs Thread, they're nearly identical, except the IP (which is just putting additional traffic on my current network) and that went over like a lead balloon for "Zigbee IP".
C-8 is a great hub. Hoping that there is a Matter firmware update in the future as indicated when it was released. That will help those of us who are cross platform
Curious - Are you successfully using Matter on any other platforms currently? I agree that Matter has the promise of improved cross-system compatibility. I just have not seen Matter take off very quickly in the marketplace. I am fine with that as I'd prefer vendors 'get it right' versus rushing buggy products to the market.
Just curious if you already have a current use-case for Matter devices on multiple platforms?
Yes - I work in cross platform in two locations - ST/Z-wave, WF (Kasa/tapo) C-8/z-wave, WF(kasa/tapo, zigbee). Goal to have Dashboards in C-8, Sharptools and Homekit. C-8 with the homekit integration allows Homekit control.
Matter allows for devices to controlled directly across platforms - But - It is not always easy in early days.
strong text C-8 with the homekit integration allows Homekit control.strong text
Does one NEED C8 to get good HomeKit control? I was planning on waiting to go to C8 when I move to a new house, but that may be while yet. I can upgrade easily, so, if HomeKit works better or has a more aesthetically pleasing dash under C8, please let me know. Thank you.
Whether using Hubitatās built in HomeKit integration, or going through Homebridge, the experience shouldnāt depend at all on different hardware revisions of each hub (all other things being equal).
Please be aware, that all HomeKit integrations (built-in or via HomeBridge) allows Apple HomeKit to monitor and control most Hubitat hub devices. (Note: Please read Hubitatās HomeKit integration documentation to see the restrictions)
Hubitat cannot directly control any HomeKit-only devices. The workaround for this is to expose Hubitat virtual devices to HomeKit, and then to creat HomeKit automations that synchronize the virtual devices with native HomeKit devices.
I have a C7 and use HomeBridge to control all of my Hubitat devices from the Apple Home app. I don't like Google Home and don't like Hubitat Dashboards on my phone. Maybe some day they will beef up the capabilities of the Hubitat mobile app to be on par with the UI for Apple or Google Home.
HomeKit and Matter are two completely different things. To clarify, the HomeKit integration permits Hubitat-paired devices to be made available to Apple HomeKit. It doesn't work the other way around.
@danabw@bobbyD , Me too, nice update overall - things are looking a bit slicker.
Looks like homebridge for me is on the way out, less moving parts should = more reliability.
- Are you successfully using Matter on any other platforms currently? I agree that Matter has the promise of improved cross-system compatibility. I just have not seen Matter take off very quickly in the marketplace. I am fine with that as I'd prefer vendors 'get it right' versus rushing buggy products to the market.
