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.
Dashboards are always useful — just not always as a primary control surface.
For example, closing blinds from a tablet costs nothing more than a relay, whereas adding physical switches everywhere adds hardware, wiring, and maintenance. In that context, dashboards make perfect sense.
For lighting, I agree that direct automation often covers most needs, but dashboards are still very useful for scenes (Hue is a good example), where a single tap can control multiple lights and states.
So for me, dashboards aren’t about replacing automation or physical controls — they’re a complementary layer, especially for shared or multi-function controls.
And what makes it a bit frustrating is that this doesn’t feel like a fundamental limitation — adding clearer, more consistent CSS classes to the generated HTML would be a relatively small change for a Hubitat developer, but would greatly improve flexibility and maintainability on the user side.
Until then, people tend to either work around it or learn to live without it.
That’s a great setup, and I fully respect that approach.
One important distinction though: in the US context this works extremely well because most systems are HVAC-based, not room-level TRVs. With central HVAC, sensor-driven automation and Rule Machine really shine.
In European apartments with room-level heating (TRVs), the requirements and edge cases are quite different — that’s where my experience diverges.
Different environments, different challenges — but the underlying automation philosophy is absolutely the same.
It seems there is a general misunderstanding about why Matter is fundamentally different from Zigbee and Z-Wave.
With Zigbee and Z-Wave, device behavior is not strictly standardized.
Clusters and attributes can be used differently by different manufacturers — for example, cluster 2 might expose temperature on one device and an operating mode on another.
Because of this, device-specific drivers are required.
With Matter, device types, clusters and attributes are strictly defined by the standard.
Every controller knows exactly what data exists and where it is.
That’s why a single system-level implementation is sufficient, not per-device drivers.
Matter can run over different transports (Wi-Fi, Ethernet, Thread). Thread is the preferred radio for many devices because it is lightweight, fast and low-power — but it only handles transport, all device semantics come from Matter.
With Zigbee and Z-Wave , transport and device definition form a single tightly coupled system , which is why platform-specific drivers are unavoidable.
With bridged Matter devices (not to be confused with shared Matter devices), the bridge itself is the Matter device and decides which capabilities are exposed — which is why bridged devices may behave differently than native Matter devices.
With shared Matter devices, the device remains native Matter; it is simply made available to another controller, which is then expected to interpret the standardized device type and clusters correctly.
I am not sure why it is different with TRVs.
BTW, I created a virtual cooling zones (no need for heat, I am in South Florida) with adjustable (of corse, automated) vents and ceiling fans (also automated).
Temp balancing across apartment is near perfect.
This is not true. The application layer of Matter (and the Thread physical later that predates it, FWIW) is substantially based on Zigbee -- including the very concept of "clusters" and even the names/functions and cluster IDs (numbers), and commands and attributes that belong to them, of some common ones. It is true that Zigbee offers the ability for manufacturers to use manufacturer specific clusters, but so does Matter. Extensive use of these for standard devices in Zigbee is uncommon (and even less so in Matter from what I've seen so far), but it's typical for device-specific preferences where nothing else makes sense or for non-standard devices, most notably with Tuya and clones but likely lots of other budget manufacturers who advertise things for use with only their own ecosystem. That last category of devices is not a good representation of Zigbee (in this context typically meaning ZHA 1.2 or Zigbee 3.0) in general.
Command classes in Z-Wave are analogous to clusters in Zigbee and Matter. And if anything, Z-Wave devices tend to be stricter about their use (probably because most Z-Wave devices are certified and chips were and possibly still are hard to get without certification).
Related to your point, every device on Hubitat requires a driver. Additionally, due to how the hub is architectured, every driver must specify (at compile time, not dynamically/at run time) what capabilities it exposes. This mostly determines what commands and attributes are available, but it generally matches up with real-world device functionality (and many of these were actually inspired by Zigbee clusters).
I think a better way to state your concerns, if I understand them correctly, is that they are a combination of the following:
every device on the hub requires a driver (this is not specific to Matter but is certainly applicable to such devices) and because of the above, any combination of different capabilities you may want in a driver would require a different driver;
apparently no driver exists with your particular desired combination of capabilities commands, and attributes (though from other posts, I'm not convinced that maybe the more specific issue is that perhaps your desired dashboard tile just doesn't know how to use the one you have?); and
device-specific drivers exist, even for Matter.
Regarding that last point, Matter is still pretty new, but was especially new at at the time when some of these specific drivers were written. Such a device could have been the only one of its kind on the market at that time, and the process of writing a "generic" driver for anything besides a simple device could have been complicated since the difference between "generic" and "specific" in the real world was hard to see at the time. More "Generic Matter..." drivers have been added to the platform since then, and I'd expect more to come in the future.
Further, I expect new and existing Matter drivers to get better, especially as staff figure out better ways to examine device functionality. Matter does provide some ways to do this that are perhaps not used as much as they could be yet (and I do think Matter is a bit better than Zigbee about this, despite the similarities). It should also help as everyone gets a better idea of what kinds of devices actually exist. For example, there's a need for -- and there is -- a Generic Matter Motion Sensor driver, but what other combinations might be needed (e.g., motion plus temperature, humidity, illuminance, and/or whatever else), keeping in mind again that drivers must be written for a specific set of hub-defined capabilities? (That or use child devices like Bridge-type drivers, which is also an interesting idea, althoug some people have a thing against child devices...)
There are also some gaps on the manufacturer side, as mentioned above. And in some cases, there could be both.
A major improvement to the Hubitat platform would be the addition of dynamic capabilities for drivers. This would greatly reduce the number of drivers needed for both Zigbee and Matter devices.
Do you know if this request could be brought back to the table in 2026?
Thanks for the detailed and knowledgeable reply — I agree with much of the historical and technical background you describe.
Where I see the key difference is not the existence of clusters or specifications, but the strictness of certification and enforcement.
Zigbee and Z-Wave certification primarily ensure protocol compliance, while still allowing significant flexibility in cluster usage, combinations, and optional attributes. That flexibility is exactly why device-specific drivers are common and often unavoidable, even for certified devices.
Matter certification is intentionally much stricter.
A Matter device must fully conform to a defined device type, including mandatory clusters, attributes, and behavior, to be certified. In other words, Matter devices are expected to be 100% specification-conform, not just “compatible”.
That stricter certification is why Matter is architected around platform-level implementations, rather than per-device drivers — and why deviations show up immediately at the controller level.
PoC: I can build a Matter device on an ESP32 and it works out of the box across Apple/Google/Alexa. That’s the “implement once, consume everywhere” promise — and it’s exactly why missing capability mapping on the controller side stands out so much.
Edit:
Device-specific drivers can make sense for non-standard extensions and could even be a bonus that differentiates Hubitat from pure Matter platforms .
However, basic Matter functionality must work first ; everything beyond that should be treated as an optional extension — especially since many of those advanced features are often already configurable in the manufacturer’s app or directly on the device itself (e.g. Bosch TRVs via on-device menus).
You’re absolutely right about the control logic — balancing temperatures via sensors, actuators, and automation rules works the same in principle, and Hubitat is very capable of doing that.
The difference with TRVs is that they contain their own internal control logic (setpoint handling, valve positioning, safety limits, boost modes, etc.) and expose this through a standardized thermostat device model.
That’s why TRVs are typically not controlled as simple actuators, but as thermostats.
This would still work very well with Hubitat if those standardized TRV/thermostat capabilities were exposed correctly at the driver and dashboard level.
So the issue isn’t the automation logic — it’s the missing abstraction layer for native TRVs.
The only workable TRV for me was the Z-Wave Spirit, but it required a retry/verification loop due to unreliable command execution — something I didn’t need with the same devices on previous controllers.
Everything your asking for is blocked because of this.
Even if they had to do it via preferences and you could turn on/off capabilities manually it would be better than nothing. It's just architecturally that is the biggest issue with Hubitat and joining devices it's all based on predetermined devices and drivers for them.
Fully agree
yes but for 1st timers and the mass market simple is what is wanted and needed its a hard thing to keep everyone happy.
It has nothing to do with Matter its just unfortunately the difference between how North America and the rest of the world does business. We see this all the time in my job working with a multinational company, unfortunately they like to think they are siloed and don't tend to look out until it's too late. Where as the rest of the world has no choice but to look out from the beginning. Architecturally that makes it easy to do things locally but then very difficult to then change when you want to open up to a MUCH bigger market of the world.
Matter does force this on a application level but the system still needs to run it.
I don't agree with this, yes in the past it was true but the team have done some amazing work to improve this. Editing rules is now supper easy with cloning, copying and moving things around. Now i would say it's the opposite and its harder (longer) to build a rule from scratch than to take one that is almost there and edit it. If we were able to share backups of rules directly on the forum a nice library could be built to help newcomers.
I do agree with the graphical one though, but then there are options for those type of users.
If they fit your needs then why not! KISS as they say, the simpler the better every time!
TRVs and just heating as a whole on Hubitat for non "cooling" countries is just crap. What annoys me the most its it must be easier to do as there is much less going on. So just have a basic heating only dashboard device and a basic heating only driver.
As I wrote you earlier, this is not something specific to TRVs. Line thermostats with proportional control are common in the US for baseboard heating and the norm where I live.
There is nothing in the Matter spec that specifically adresses TRVs.
I think @bertabcd1234 hit it on the nail - what you're really asking for is dynamic capabilities.
I agree.
My hope was simply that a proper Matter implementation would finally help bridge exactly this gap — that’s essentially the core reason Matter exists in the first place: reducing regional and ecosystem fragmentation at the device level.
I agree — there has clearly been a big effort and a lot of progress, and that deserves credit.
My comment was based on past experience (roughly a year ago), not meant as a statement about the current state.
Rule Machine has always been one of Hubitat’s greatest strengths for me. Even if it’s not the most user-friendly, it was never a reason to leave — quite the opposite.
I agree — simpler is often better.
Since my move, I spend much less time coding and debugging. Fewer complex options often lead to simpler thinking to achieve the same goal.
A good example for me is lighting effects: I once wrote fairly complex Rule Machine rules just to cycle colors on two lights, whereas with Hue dynamic scenes the same result is literally a few clicks — even for 10 lights.
You’re right that this isn’t TRV-specific — proportional control thermostats exist in many forms.
What matters here is that Matter defines a single, standardized Thermostat device model, which explicitly covers heating-only and proportional-control devices, including TRV-style actuators (Matter Spec 1.x, Thermostat device type).
So what I’m asking for is not dynamic capabilities, but correct exposure of the standardized Thermostat/TRV-related capabilities already defined by Matter.
Dynamic or device-specific extensions would only make sense after that standard model is correctly implemented.
Not sure — I don’t know whether this is a bug in the Generic Matter Thermostat driver specifically, or a more general limitation in how Hubitat maps Matter thermostat devices.
Conceptually, Matter defines a Thermostat device model with a set of mandatory and optional clusters/attributes. A TRV / heating-only thermostat typically exposes only a subset (e.g., setpoint, system mode like off/heat, and measured temperature). A compliant controller should handle that subset gracefully: it shouldn’t require “missing” clusters to exist, it should simply use what the device actually exposes.
From a user perspective, the expected result is straightforward: a usable device in Hubitat with (1) a setpoint you can change, (2) the current room temperature, and (3) an off/heat mode — and a dashboard tile that can control/show exactly those.
Right now, that’s not what I’m seeing when the device is shared into Hubitat via Matter: the standardized thermostat capabilities are not exposed/usable, and the dashboard can’t control it properly. So yes — something in Hubitat’s Matter thermostat handling (driver and/or platform mapping/UI) needs to be fixed for these devices to work as intended. Edit:
To be honest, I suspect part of the difficulty is architectural: Hubitat’s underlying framework was designed long before Matter, around a driver- and capability-centric model that works extremely well for Zigbee and Z-Wave. Matter introduces a different, more dynamic device model, and adapting to that without breaking existing logic is likely non-trivial.
All of this is nearly directly based on the ZCL (Zigbee). It's nothing new. The one thing that seems new is the feature map.
Note that ONLY the Thermostat cluster is mandatory !
Right, and we're back to the dynamic capabilities request (sorry! ).
Here are the ways to handle "optional" clusters (capabilities) in a Hubitat driver which, as Robert explained, by design, has to declare those at driver compile time:
include only mandatory capabilities (e.g. in a "generic" driver)
create a device-specific driver that includes only those optional capabilities the actual device supports (and adress any manufacturer-specific clusters)
include all optional capabilities and "wing it" it at run-time. Some capabilities won't work, which may be confusing to the user, but those that the device exposes would work. Some community drivers work this way.
OK, I'm going to jump in and make a comment that has nothing to do with Matter, but does relate to the user experience. Because of the rather limited capabilities of HE's dashboards and the annoying (sometimes downright illogical) way Rule Manager works, I've been using Home Assistant for more and more of my home automation. But I've kept HE in the mix to handle things like Z-wave and my Ecowitt sensors, as well as the excellent Weather Underground driver. I have HE integrated into HA.
Just this morning, I was working on an automation in Home Assistant and trying to test it with an HE dashboard (watch the dashboard for changes to a Hubitat Z-wave device while editing an automation in HA). The HE dashboard wasn't showing me what I expected to see, so I checked the actual device. It was working perfectly, as was HA, and so was HE's control of the device. What was the problem? The Q#$##@%^m HE dashboard! It just wasn't consistently updating. Arrgghh!
I've found HE to be a very reliable Z-wave controller, and I really like the drivers for both Ecowitt (maintained by @sburke781 ) and Weather Underground (maintained by @dJOS ). But those are now my ONLY reasons for staying with HE rather simply buying a Z-wave antenna for HA (they now offer a very nice one) and just moving on. So look, HE management, I've purchased four devices and subscribed to your services for several years now (and btw, the subscription renewal was a big PITA, but you have supposedly fixed that, finally). I don't really want to leave. But frankly, it feels like you are presiding over an increasingly big PITA that isn't keeping up in some key areas. You don't need to do anything, of course. You can just let the chips fall where they may, and hope those of us who are complaining are a bunch of idiots, and that we're complaining over nothing. That may be true. But don't say we didn't tell you, well in advance, that the relationship is getting increasingly threadbare. I don't particularly want to leave. But I'm getting sort of tired of finding more problems than improved capabilities I value.
C'mon that's a bit harsh and over the top. One of the struggles with HA is that the agenda often gets hijacked by elite super technical users. Their wish lists are long and often niche like. The platform vendor can chase all these inputs at great expense (massive development teams) and still not better the platform for the majority (i.e. the other 99% users). So as everything in life it is about balance. I would encourage Hubitat to spend more effort on basic things like not needing CSS/HTML expertise to DIY a nice looking dashboard. Beyond that maybe some better editing tools for larger Rules instead of the cumbersome edit methods of today. More device integration sure, but if Hubitat is relevant, the device vendors will be incented to get drivers created.
).
