A "retrofit" Thread/Zigbee stick on existing hubs is a very cool idea... and makes some sense given the idea that a hub should last for very long time - like a washing machine or dishwasher. Seems like a good way to monetize existing and stable setups in addition to the subscriptions.
Not sure if the increased support costs would be worth it though. Also any next gen hub will likely have other internal updates that preclude this from really being effective and as a company you've added to your dev process even more having to now contend with a next gen model, old models with retrofit, old models etc.
Doable maybe but worth it from a business standpoint?
I don't see why it can't simply communicate with any thread devices via the ip network. I am sure we'll all have border routers already, or can get them really cheaply. Then Hubitat just has to have a firmware update to speak Matterish to them.
We're only one silicon labs firmware update away from the 700 series working properly, so not so bad. I hear we'll never have to worry about ghost nodes or the SDK refusing to remove bad devices again!
(In seriousness, I'm much more optimistic about openthread / matter given the the physical layer is very well established 802.15.4 -- the IEEE that set this up is a pretty thorough organization and its time tested, as well as the open-source development of openthread is really just a a routing / management layer on top of this, and given all the companies that have been able to look it over, as well as the fact that Matter on top of that is just a refinement of well-established zigbee cluster libraries).
So the hub firmware would support the matter stack but not be a border router - that seems cool as long as there are enough hub resources for it.
The issue is you are at the mercy of the 3rd party border router providers to determine what kind of access you get to the devices on the Thread network - you only get a baseline of functionality depending upon the spec.. unless I'm mistaken and I could be!
Hubitat would ultimately want to be a border-router I would think...
I believe that’s primarily because at the beginning they were repurposing hardware originally built for other functions. Since then, they’ve clearly worked out a manufacturing process for their own hardware needs.
Not suggesting they would never consider using add-on USB modules ever again. They since have done it to add WiFi connectivity to the current gen hub. So anything’s possible.
But Matter connectivity and Thread connectivity are two different things, as @Inge_Jones pointed out.
A big question for me is what devices and capabilities get exposed by the border-routers.. We are already seeing some variations with Apple and possibly Philips/Hue.
If you look at Hubitat's processor and memory utilization (at least on my system with about 100 or so devices), you have an incredible amount of spare processing power and memory, so it seems, in an "ideal" world, you could envision them including both border router functionality as well as a Zigbee / Z-wave to matter bridge functionality (as a replacement for the current Google Home, Alexa, Homebridge plugin routes for working with the "outside world"). And, based on Silicon Labs press releases, Silicon Labs will be providing the software as part of their SDK, so maybe less work thany trying to keep the individual plugins for Google Home, Alexa, homebridge, up to date. Tremendous possibilities.
So for existing hubs and matter support it could be doable but that's probably a question for the system engineers - I have low resource utilization too but I offload my rules.
My understanding is border router capability would require a new chip - the existing one in the HE can't do thread. So to @Inge_Jones point - matter first but then maybe thread for a next gen hub.
Note: since the new chips can handle both Zigbee 3 and Thread implementing doesn't seem all that bad from a risk standpoint. It's just the other stuff - board design, lead time, cost etc...
I'm assuming that, at some point, there will be a full switchover of chips (800 series Z-wave, updated zigbee / thread ). I'll likely be first in line for that (its like being in the beta program and clicking on "update" when there is a new beta - the temptation is too much).
Rumor is there will also be an update to Groovy 5,0 and the latest linux underpinnings as well as an overhauled and more flexible UI for drivers, and fully documented structured classes for development (yeah, I'm making that all up).
Is it possible that current manufacturers of routers and wifi equipment (Ubiquiti, TP-Link, Netgear, etc.) will implement border router functionality into their routers and wifi equipment. Is it possible they could do this with existing gear, through a firmware update? To me this makes the most sense. Then (if I am understanding this correctly), all HE needs to do is implement Matter, since the router and HE would already be connected through one's home network.
See I have a different take - The EERO is in fact one of Amazons smart hubs so falls into the same category as Google Home, Apple Home, etc.
I think the big players especially Philips/Hue should be very concerned with a commoditization of thread like that. They would have far less control over their systems/hardware than they are used to and as I mentioned in another post, China is poised to flood the market with cheap (not necessarily good) stuff.
Based on your response, I see I need to rephrase my question:
Is it possible that current manufacturers of routers and wifi equipment (who do not have the mining of people's data as one of their principal business operations), will implement border router functionality into their routers and wifi equipment. (thinking of manufacturers like Ubiquiti, TP-Link, Netgear, etc...)?
Do those exist anymore? I think not. Pretty much every connected service has a clause about data collection in their ToS. I suppose the differences are whether or not selling that data is a primary part of their business model.
I'm not really bothered, Happy to let Google Nest Hub at my smart stuff at least until evidence emerges that they are selling my data to burglars to let them know when the house is inactive.
Or insurance companies (here in the US) or your employer or your government or a foreign government etc etc.. the big problem is we don't know what we don't know about this stuff or how it could be used or is being used against us. Monetization and marketing is just one aspect..
The safest position is to run as locally as possible..
Indeed I do! And yes I absolutely agree with you - I only have my Den and Kitchen lights shared right now, nothing else. My Alexa is on a smart plug on a schedule.
My other data collection devices include Nest, Ring and Sonos. Next to Alexa/Ring, Nest is probably the second most worrying. Sonos collection is just target marketing data unless Alexa is activated. My Ring stuff is all outdoors where there is no real expectation of privacy. However I would eventually like to move to a local system.
Edit: I should point out though the scary bit about Ring and other cloud surveillance is with the advent of AI to index pictures and video - Ring could identify who was coming to your door and what they were carrying... no need for a stakeout, all info is right there... etc.
