Can you describe what that would look like, concretely?
I'm not sure I understand why you care, given you shared that you own multiple TBRs already and:
This already works. In my case, it has had the effect of making Home Assistant a more attractive toy since I can play with it using the same devices without adding dependencies between systems (however I am concerned about the idea of spreading automations "all over the place" and forgetting what is controlling my home and from where).
The fact that HE supports Matter (even if said support is certainly perfectible) AND offers a programming interface puts it in a unique position IMHO, with the rapid progress of AI coding tools. I've had good success building fairly complex automations using straightforward prompts that generate just a few hundred lines of code. Some of our most prolific community devs have also show the way.
Thank you for sharing your thoughts and of course we hate to see you leave.
On several occasions I have mentioned that more options and flexibility introduce the possibility of complications.
The tradeoff becomes what would you rather have, a product that can get the job done or a product that; at some point, will not automate what you need it to do? I imagine you will come up on a task that the tool will not be able to accomplish what you need it to that could have been accomplished with Hubitat. That's is just my opinion.
Cloud based, never again. I have tried several as far back as Insteon. Many of us may remember that nightmare. Since then other cloud-based automation companies have went out of business, cloud-based lock companies have closed, you get the idea. I will never be held hostage by a cloud-based automation system again.
An additional; and extremely important free asset; is the community support you get here. I honestly don't know what support is like for the product you are moving to. Will it be like the Hubitat community and Hubitat support? I have personally benefited from countless individuals jumping in to help me with questions and issues and Hubitat support incorporating incorporating a suggestion into the product.
What about the stability of Hubitat. Once things are setup and you leave the hub alone how often does it "hang", need to be rebooted, etc. 99.99% of the time problems are introduced either by hardware failure or change. In my earlier days of my hub (basic lights on/off, opening closing drapes, etc.) my hub was up for months unless I chose to upgrade the OS. Only when I started getting more advanced (my own worst enemy) for example:
When entry gate is opened
Flipping the TV on using 3rd party Broadlink (only if someone is in the room)
Switching TV to HDMI port with apple TV to view security cameras
Start timer for viewing outside cameras
Wait until there is no longer any motion outside within a while loop
Flipping the TV back to HDMI port for watching TV.
My point to all this mess is that I am the guy driving up the CPU and later wondering why the hub is slowing down when I have this kind of stuff goin on LOL.
Lastly, The owners of Hubitat. To use your words " From a technical standpoint, Hubitat has an extremely solid core : local execution, powerful automation capabilities, and a level of control that mass-market systems rarely offer"
Hats off to these folks. They listen to their customer base and are continuously improving the product. There are definitely some smart folks there and have put together a solid product. They have a great track record of responding to product bugs and continuing to improve the product. I for one could not ask for more.
I respect you feelings and wanting to move on. It's a personal decision and for you the right one. For me personally I can't imagine ever needing to do so. Wishing you all the best in your home automation endeavors.
Let me clarify, because this is specifically about shared Matter devices, not direct pairing.
Hubitat currently cannot pair Thread Matter devices directly.
In my setup, the Eve Thermo (Matter TRV) is paired to Apple Home, and then shared to Hubitat via Matter.
The issue is what happens after that:
Hubitat receives the Matter device
but does not correctly identify the device type
the device appears as “Unknown / Other”
and none of the standard Thermostat capabilities are exposed
According to the Matter specification, a TRV exposes well-defined device types and clusters.
A controller consuming a shared Matter device should be able to map those automatically.
This is what I meant by “if Matter had been implemented according to the standard” — in this case, Hubitat’s Matter consumer side is currently incomplete for TRVs.
A programming interface is great — but for standard Matter devices, it shouldn’t be necessary.
The whole point of Matter is that device types and capabilities are defined and work out of the box.
@pascal.nohl
I've read this thread and can I say that you have not (in my opinion) come on here to rant and rave about the shortcomings you are encountering with the product.
You have articulated your findings for your environment and needs and found a few issues that are not good in your setup.
People have responded and have not necessarily agreed with your findings.
I'd just like to say that it's nice to see someone report their findings/issues in a manner that is calm, also responded to posts calmly and we haven't all got caught up in a slanging match about personal opinions etc. (Well done everyone!!!)
Have a happy new year and all the best for your future automation journey.
The issue here is that in Hubitat’s current Matter implementation, neither applies in practice:
the device does not work out of the box
and there is no programming interface available to bridge the gap
So while the statement is true conceptually, it doesn’t reflect the current real-world behavior for Matter TRVs on Hubitat.
That’s not quite accurate.
Hue and HomeKit are local-first platforms. The cloud is optional and mainly used for remote access, not core automation.
That matches my own experience as well.
I’ve been using both Hue and HomeKit for a year and never had to rely on vendor support. Whenever I needed help, it was usually just community knowledge (e.g. YouTube) about better ways to structure automations — not fixing outages or cloud issues.
Simply true. But it's the same for Hue and Homekit.
Thank you, I appreciate that.
And yes, it is a personal decision. My intention here isn’t to convince anyone to move away from Hubitat.
I just wanted to share my experience — especially for users who need reliable TRV support — and point out that there are alternative approaches if someone finds themselves struggling day after day.
For many setups Hubitat works great, but for my use case this turned out to be a better fit.
That was exactly my intention — to share my findings for my specific environment and use case, without turning it into a rant or a “right vs wrong” discussion.
Different setups and priorities naturally lead to different conclusions, and that’s perfectly fine.
Happy new year to you as well, and all the best for your own automation journey.
Some of this may not be the fault of Hubitat'. As below, none of the Matter thermostats that were tested exposed certain values. So if the thermostat manufacturer doesn't expose something, how is Hubitat to implement such things?
@pascal.nohl, @kkossev wrote a matter TRV driver about a year ago for the Aqara E1 I believe, you might want to reach out and see if he could help you get your TRV up and running.
Thanks to Hubitat now I have TRUE Smart Apartment. Everything is 100% automated over 5 years span. True Automation means you do not need any Button Push (well there are few Buttons around for things which is impossible to automate algorithmically), no Voice Commands, no Dash Boards. Everything is driven by sensors and associated RM Rules. Cloud-based integrations basically no go (only 1 or 2 left for none critical automations). And thanks to Hubduino project I can build any device I want if it does not already exist.
I don't know any other platform (it doesn't mean there is no other one around) with this huge capabilities and flexibility.
But again, this isn't really your issue, is it? If the device was correctly recognized when paired via another controller, would that work for you?
I didn't see anything specific to TRVs in the Matter specification, but could have missed it. In any case, I fail to see what you believe is special about a TRV, it isn't functionally different from a line thermostat with proportional triac control. Any thermostat, including TRVs, should expose the Thermostat and Temperature clusters.
Works for me, but, granted, I don't have any Matter thermostats, only plugs, switches, dimmers and a number of sensors.
You might however have found a bug for your thermostat (unexpected fingerprint? I hear Matter devices pick arbitrary endpoints sometimes...) and perhaps for Matter thermostats in dashboards. I saw some posts here about Matter thermostats not reporting thermostat operating state, maybe that's what's breaking the dashboard tile? Did you already try getting support to look at this?
I just want to give my opinion here based on my own experience:
His points about legacy dashboards and rule machine are SPOT ON and resonate with me. I think Hubitat is amazing and I am very happy that I selected it. I have seen it grow and become much better compared to just a few years ago. Hubitat leadership: please listen to him at least regarding the two points above!!! Rule machine is AMAZING but it needs more polish so badly. It would be an absolute sin not to make RM and legacy dashboards (please rename it DASHBOARDS) better. They are so very powerful!
Thank you to Hubitat for all that you do and Happy New Year. You make a very good product and deserve my money. This is a fantastic thread with many great posts and everyone here should be proud of it.
"Easy Dashboards" is the biggest mistake I have seen the Hubitat team make in my time here. I really want this thread to be constructive. I love Hubitat and have no plans to leave.
I haven't read every word of this lengthy thread but I do agree the dashboard tools are crude for Hubitat. I know there are two HA camps; dashboarders and non-dashboarders. Non-dashboarders presume proper automation doesn't need a dashboard due to presence detection (motion, door switches, ...) and well conceived rules whereas dashboarders prefer to control via a nicely designed interface.
I am a dashboarder but find editing CSS lines cryptic and very unproductive. Hunting with a browser to find the proper/exact class name you are wanting to modify then experimenting with CSS code to tweak it the way you intended seems circa 1990's. I wish there were more powerful tools to lay out dashboards, figure out the exact class names behind the curtain (I don't even want to know it), and allow you to tweak in place then have all the CSS code just falls into the right places.
I just don't think you should have to buy a book on HTML to create a dashboard. Accordingly I was disappointed in how little EZ dashboard moved the bar forward.
The rest of the platform is great in my opinion. Rule Machine is powerful and I am still learning how to use it best. I haven't wandered into creating any apps or drivers (yet) but I am happy it doesn't require a PhD to go there.
I use mostly ZWave devices and generally find that network stable but sometimes it bogs down on complex back to back commands to large groups of devices. I think there could be better traffic management of the ZWave system to meter out large traffic bursts. I am also a little suspicious of how the ZWave system selects routing paths when direct shots to the hub aren't adequate. I have seen some pretty tortured routing of late that can't possibly be the most preferred route to the hub. Maybe some of this is due to the EOL nature of Z/IP so fingers crossed ZWave-JS eventual smooths out these wrinkles.
I have a couple of matter devices and they work just fine. I am not interested in some universal multi system peer to peer control scheme where Alexa, Apple home, and Google home, Hubitat, HomeAssistant, ... all participate in some sort of perfect harmony. I just don't think those vendors deep down really want that so we will surely be disappointed when it falls short.
This is a hobby for me so I don't mind some experimentation.
Held my tongue thus far, but had to chime in (in case HE team is listening) that I would be a 'Dashboarder' if legacy DB were susceptible to easier CSS customization. Been down that rabbit hole a number of times and always failed to arrive at a presentable, maintainable, human-readable, repeatable layout that works across multiple browsers.
Does such a unicorn even exist? Maybe not. My hopes of adding animations, borders and tile grouping had me trying a number of alternative DB solutions (all of which required their own care and feeding). So I learned to live without until Legacy DB got tweaked, but I don't really think that's gonna happen.
I guess I am somewhere between, leaning strongly towards non-dashboarder. I spent a lot of time tweaking them, trying various substitutes, apps, CSS, you name it. Realized I only use them for troubleshooting, as all else is automated. One button by both sides of bed for sleep/wake. I guess I'm saying that dashboards are nice, but don't need improvement.
The TRV you’re referring to is not a native Matter TRV.
As Meross states on their own website, “Meross Matter Hub MSH450 is needed for installation.”
In that setup, the hub is the Matter device, not the TRV itself. The hub decides which capabilities are exposed to other controllers.
The same applies to older Bosch TRVs: they can be made available via Matter through the Bosch Smart Home Controller, but only the newer [+M] models implement Matter natively at the device level.
So comparing hub-bridged devices with true native Matter TRVs isn’t quite apples to apples.
My findings are specifically about native Matter TRVs and how their standardized device types and clusters are currently handled when shared to Hubitat.
Partially yes — and this is exactly where the conceptual difference lies.
Matter drivers are not supposed to be user-written or device-specific.
They are platform-level implementations of standardized device types and clusters.
The whole point of Matter is that:
the device type is defined by the standard
the clusters and attributes are defined by the standard
and every compliant controller implements those once, centrally
If users are expected to write their own Matter drivers, then Matter loses its purpose and effectively turns back into a per-platform integration problem — which is exactly what Matter was designed to avoid.
That’s why I see this as a platform implementation gap, not something that should be solved by user code.
