Very pragmatic. This to me demonstrates 1) the need is real and 2) the solution could be a level of indirection. Would be sweet if the platform could provide it transparently.
AFAIK, once you've joined the device to Hubitat the device won't care if the commissioning device is awake/asleep/off, as it will communicate w/the Hub over the Wi-Fi network (Matter/Wi-Fi devices) or Thread (Matter/Thread devices).
I've tried to pay attention in class...pretty sure that's correct, but would be good to get that verified. 
Once upon a time, an iPad could be used as a Homekit hub.. no longer. An Apple TV or a HomePod are now the options.
"Thread-enabled Matter accessories require a Thread-enabled home hub, such as HomePod mini or Apple TV 4K (3rd generation) Wi-Fi + Ethernet, or a supported third-party border router. When you set up HomePod mini and HomePod, they automatically become home hubs. Just make sure that you're signed in to iCloud on your iPhone or iPad with the Apple ID that you used to set up your HomeKit and Matter accessories in the Home app."*
1 Like
The current price of 189 EUR isn't that bad as importing a hub from the USA will cost you at least $216 (150 a hub + 26 cheapest FedEx shipping + VAT on a hub and shipping when in Portugal). FedEx may also charge you extra for customs processing. And you get 3 months guarantee on a hub instead of two years.
If you need a spare hub you can have a look at the customer returned hub which is just like a new one with 2 years guarantee. The only difference is that someone bought it, found out it's not for them and sent it back. It's 14 EUR cheaper.
2 Likes
Hi @Ultrasmart.pl,
I’m already a customer of yours - a hub and counting … and I bought one more for a client.
I’m fully aware of the taxes for importing from US to EU - that’s why I don’t even think of buying from the US. No way!
However, whenever Hubitat starts a campaign with discounts I get jealous because I can’t get the same discounts from Ultrasmart … I would be sooooo happy if you’d do it too 
2 Likes
Any chance support is coming for Hubitat as a matter bridge? Matter bridge, pretty please?
I don't mind at all if I have to buy a new hub to get this support & can't use my old hubitat hub 
Would just be an amazing feature
1 Like
Does that require require a thread border router to be baked in?
No, it does not.
A Matter Bridge is what Philips Hue and Aqara have added to their Zigbee only hubs. It allows those Zigbee devices to be shared with Matter Controllers.
It is very much analogous to Hubitat’s built-in Apple HomeKit support, where Hubitat Zigbee, Z-Wave, and some LAN devices can be exposed to Apple Home as HomeKit devices.
3 Likes
On the plus side, supporting Matter Bridge feature for Hubitat might (?) mean that they no longer need HomeKit, Alexa and Google integrations further down the line ?
4 Likes
Yes, true, the Matter Bridge could in theory handle all of them I think, and all locally (Alexa and Google are currently cloud based). This would greatly depend on Matter expanding its device capabilities, in order to get the same functionality.
You could also bridge to Home Assistant, or any other platform that can use Matter. No more custom plugins and integrations.
That would actually be pretty cool.
Speaking of which, if Home Assistant does a Matter bridge, we could use that to get devices from HA to HE, instead of the all-or-none HADB app. Have never used it but I understand it sends ALL device data to HE, and there is no way around that.
1 Like
What makes you think an eventual bridge feature on HA would do any different ?
Good point... it would possibly behave the same way 
I was imagining something like the HE integrations where you can pick which devices to export.
Not sure why HADB does not have a device selection on it, maybe not possible with the HA plugins, not a huge user of HA but follow some of the topics if interesting.
HADB does have an “App” that allows one to choose which HA devices you want included on the Hubitat side…. However, HADB is a 100% Hubitat side code solution. There is no custom code on the HA side of things. In order to achieve this simple design, HADB simply connects over the LAN to HA’s Event WebSocket. As such, every status update from HA must be processed and filtered on the HE side of things. What would make it much more efficient, is if there were some sort of Maker API style interface on the HA side of things. This would allow the filtering on the HA side of things.
6 Likes
For me, I had a C4 that needed to be rebooted every few days to keep it from locking up, Splitting the devices from the automations was the solution. The C4 was eventually replaced with another C7. It was easier to keep things split than to bring it all back together. Now the C7 has been replaced by a C8 one C7 runs the app and automation and the other C7 handles all of my cloud stuff. There is an orphan C8 hanging around looking for something to do. If the C8 pro comes to fruition one of the C7’s wil likely join it, or both C7’s will go in reserve and the active hubs will all be C8/ C8P. However unless there is some big speed or memory upgrade, I likely won’t be rushing to get the pro on launch like I did with the C8. I wanted the external antennas. So unless there a big speed or memory improvement or other compelling reason it won’t be high on the list to be included in the near term.
2 Likes
Because most of the Zigbee or BT devices made by Aqara, Tuya, SwitchBot, etc.. use non-standard ZCL commands (or unsupported BT), and these non-standard devices will not work when paired directly to HE (except someone keeps writing dedicated custom drivers for HE for each new device that popups every month).
With Matter Bridge functionality implemented in their hubs, there will be no need for HE custom drivers anymore for these Aqara/Tuya/SwitchBot devices that are exposed by their Matter Bridge hubs. Unfortunately, not all device types are supported at the moment, but it is a start.
2 Likes
Sorry, I meant more than one Hubitat hub. I fully understand needing hubs for other ecosystems.
OK, I have misunderstood your question...
This is a bit off-topic, but I wanted to share it - something very interesting is coming from Aqara : (source)
"....Aqara is launching an automatic backup feature with the M3 where if you have two or more Hub M3, your automations can be automatically mirrored to the secondary hub, which can take over if the main hub fails."
3 Likes
You use the word "need" and I'm pretty sure I do not need the 6 active, powered Hubitat hubs I'm using. But I would never go back to fewer either. Four of my Hubitat hubs are active as one production system: two C-8 and two C-7, and the other two are Development hubs: a C-7 and a C-5.
Running on fewer hubs means that any hub disruption takes out the whole house. It eases the upgrade process for me because each of my hubs has a specific area of the home that it manages. I can reboot 'that one' because no one is in that area and isn't likely to be in the next 6 minutes.
I grew up joining gizmos together to yield a greater-than-the-individual result. Applying the same to hubs is almost impossible to prevent, in my case I started with a single Hubitat hub yet within a few months I had a second and then a few weeks later, a third. Interconnection of hubs was rudimentary in those days. I had to treat the hub for an area as standalone, as if it was an apartment, and the next hub was for a different apartment. I used Upstairs and Downstairs as the 'names of the two apartments' Interconnecting hubs today is far from rudimentary.
2 Likes
But the M3 doesn't support ZWave, which is certainly the Tent Pole in failover. Don't get me wrong, I'd love to buy another 4 hubs to be redundant to the 4 I already have, so I understand the impetus of your remark. I don't know what foresight the originators of the protocols had, certainly not 20 years. Did they know that hubs would exist 5-6 years out? Doubt it. The 'promote secondary to primary' is the only path in ZWave in the past and present. How does that work when the secondary promotes itself to primary and then the primary comes back. Nothing in the protocol suggests how to handle the drab basics of failover. Minutes after failover is resolved, load balancing rears its head.
I'm eager for an active/active failover, which is load balanced by nature. I don't think I'll hold my breath though.
I think that a high-availability / redundant system can be built using Hubitat hubs and Matter devices even now.
- All Matter devices will be paired to both HE1 and HE2 hubs. There will be two different Fabrics.
- HE1 will be the master hub, HE2 will be the failover hub.
- HE1<>HE2 will be checking periodically the connectivity between the two hubs
- Any event or attribute update from the Matter device is sent to both HE1 and HE2 hubs.
- The Matter device can be controlled from both HE1 and HE2 hubs.
- Both HE1 and HE2 hubs will run the same automations.
- The automations will execute only on the active (master) hub. The failover hub will be passive.
- The master hub will sync the automation states / variables to the failover hub.
- If the connectivity is lost - the failover hub will become master.
- When the connection between the two hubs is restored - HE1 will become master again.
... something like this.
3 Likes
