Hi,
One of the most requested support from European users is certainly the support for more TRV models. Most manufacturers announce Matter compatible devices or devices that are exposed as Matter devices by a hub. Homematic IP is one of the most popular systems for heating in Europe (aside Bosch) and their TRV are great, but it's a closed system. Bridges like the Mediola ( Matter Bridge Homematic IP ) bridge expose them as Matter devices.
Correct me, if I'm wrong. Hubitat needs a unique Matter TRV driver to be able to pilot Matter TRV devices (similar to the generic TRV driver that never works). And, Hubitat should be able to connect to exposed Matter devices. If so, the development of a Matter TRV integration would open a completely new world of TRV devices to the European users. One driver. What holds Hubitat staff back from doing it ?
I've noticed that more high-quality Matter-compatible TRVs are becoming available on the market, and I was wondering if there are any plans for Hubitat to support these devices. It would be great to know if this is something in the pipeline and, if so, when we might expect it.
For many of us in Europe, this feature is quite important in making Hubitat a competitive alternative to other systems. I purchased my C8 Pro based on the promise of Matter support, but it seems that full integration, particularly for TRVs, is not yet in place. Any updates or information on this would be greatly appreciated!
No, I don't. If the Matter bridge worked with Hubitat that could be an alternative, but I prefer to wait for the Thermostat II (+M) that will be released soon as stand-alone Matter TRV. Also, the Tado Matter TRV that is already available, is expensive but seems to be very high quality as Tado always is. As TRV support is a long-standing issue with Hubitat I don't understand that Hubitat is not integrating its Matter support as a priority, making all Europeans happy and solving a mass of complaints.
I'm using 'Google Nest Matter Thermostat' driver for 4th Gen Nest thermostat and find there is no thermostatOperatingState value returned from the driver. I need the value for my automation. My 3rd Gen Nest thermostat using 'Google SDM API' returns thermostatOperatingState value. Why the matter driver doesn't?
Other problem of 3rd Gen Nest thermostat using 'Google SDM API' is that the attribute values have never been refreshed after changed. I have to refresh to get changed values, so I made a RM routine refresh every miniutes but it doesn't look clean.
I'm not sure why, but some other thermostats and TRVs I've tested using the Matter protocol do not return or update the thermostatOperatingState. I'm considering simulating this attribute at the driver level by setting it to 'heating' when the heating setpoint exceeds the measured room temperature. But I can't say when this may happen.
The Eve TRV is delivered as Homekit version, but can be connected to the Eve App (iPhone) and updated to Matter Firmware. I have no idea if it works well with Hubitat, but with Apple Homekit and as Matter version it works extremely well, and all available features in Matter are reporting and working. Maybe the Matter updated TRV is a solution for Hubitat users. When I have the time I will bind one to my C8 Pro as Matter devices can be bound to more than one controller in parallel. I think that it is a Hubitat thing, as all my spirits worked flawless with my eedomus system, but became very unreliable when connected to Hubitat. As this one is the only officially supported TRV I became frustrated, and I am switching to Apple Homekit. Another interesting thing with Eve is their thermostat controller, a small device that you can place anywhere in your room, that measures temperature, where you can set temperature and that uses Matter direct binding to control my 2 TRV in that room without passing by the central and all three devices show up as one thermostat only in the dashboard...
Tado X connects flawlessly with Matter and is working with the "Google Nest Matter Thermostat" driver as kkossev mentioned. I also tried some other drivers (not all thermostat drivers), without succes. One downside I noticed so far with the Nest driver: it has to be initialized about every 2 days, or else the hubitat will not receive updates. I will solve this by automatic triggering the "initialize" every day in rules machine. Does anyone has a better solution for this?
well, a bit late but I have tried to look in to it, finally... The matter bridge is a bit unclear for me how to get the Tado X device working as an thermostat. I have been using the "google nest matter thermostat" driver for months and with an daily "configure" command for all my Tado X devices, these kept working in Hubitat (C8) flawlessly.
Since this week I wanted to use the RH (humidity) from some of my Tado X devices and since this week I noticed that the "Google nest matter thermostat" driver does not report this. So I looked for another driver and I today tried the FW inbuild "Meross Matter Thermostat" which seems to work and reports the RH humidities. Maybe it is an option for other users too, would be nice to see your results in this thread (?). Don't know if it still needs an initialize command each day, but I recently build an Hubitat app for my indoor climate control values settings outdoor combination etc, which will do this daily.
I build this app so I could use my Duco HRV system (for which I also had to build an driver to get all the values from an local IP address web interface) to get a bit more control of my humidity inside without getting unnessairy ventilation settings when outside RH is to high to get an lower indoor RH. Perhaps something for another thread...
I’ve been away from this forum for quite a while, as I moved most of my setup over to Apple Home. Today, nearly all of my devices — window contacts, TRVs, smart plugs, locks, and more — are Matter-enabled, with only a handful still being HomeKit-only. Overall, the system works well by juggling mainly three apps: Home, Eve, and Controller.
However, I really miss two features that HomeKit doesn’t offer: virtual devices and variables. My plan is to use Hubitat mainly for these, exposing them back to HomeKit through the Hubitat–HomeKit integration.
Now, in theory, this should be a game-changer, because all Matter devices should also work directly with Hubitat. But reading through the forum, I start to doubt whether Hubitat handles Matter in the right way. In my view, there shouldn’t be “Nest Matter drivers” or “Meros Matter drivers” — just a generic Matter TRV driver that follows the standard.
So my question is: Is Matter in Hubitat implemented according to the standard, so that a Matter TRV will simply work out of the box once it has been paired with a Border Router (like an Apple TV or HomePod)?
I tried pairing the Eve Thermo (TRV) – unfortunately without success. It doesn’t work with either the Google Nest Matter driver or the Meros Matter driver.
On top of that:
There is still no proper TRV dashboard tile – it continues to display a “Fan,” which a TRV obviously doesn’t have.
Eazy Dashboards still reports an error for the TRV type.
So basically, nothing has changed for us in Europe.
For now, my C8 Pro will end up being used only as a standalone Homebridge, to provide virtual switches and dimmers (0–100 values) to HomeKit. At least until I finish setting up my ESP32-H2 project, which will also expose virtual switches and dimmers to HomeKit – and for under $10, I’ll even make a backup device.
There is a good reason Hubitat is nearly unknown in Europe. It seems to be a market that Hubitat ignores.
Matter defines standard device types (TRV, lock, sensor, plug, etc.) with clear attributes. According to the standard, the correct generic driver should be assigned automatically during pairing – the user should not need to pick or change it.
In Hubitat, however, devices like TRVs are still detected incorrectly and tied to brand-specific drivers. What we really need are generic Matter drivers for all standard device types, assigned automatically, to align Hubitat’s implementation with the Matter standard.
Unfortunately, none of the major smart home ecosystems — Apple Home, Amazon Alexa, Google Home, or even Matter — currently define a dedicated device type for Thermostatic Radiator Valves (TRVs).
All TRVs are exposed through the broader Thermostat / Climate Control category, which is why different platforms often display or handle them inconsistently. Until a specific TRV device type is added to the standards, this behavior is expected across all ecosystems.
I switched to Apple Home after requesting proper TRV support in Hubitat for over two years. I am currently using Matter-based TRVs, including the Eve Thermo (Matter) and two Bosch Radiator Thermostat [+M] devices. All of them work flawlessly together in Apple Home and are correctly exposed as TRVs, not generic thermostats.
They intentionally do not offer fan modes or HVAC-style controls. They expose exactly what the Matter standard defines for this device class:
target temperature
current temperature
mode (heat / off)
And that is entirely sufficient.
By design, TRVs contain their own internal control logic and do not require direct valve-level manipulation. Additional behavior such as boost can easily be implemented via automations, even if the Matter specification itself does not define a dedicated boost mode.
The Bosch TRV is a good example:
When used via the Bosch Zigbee hub, it offers many additional features (schedules, boost, frost protection, etc.). Under Matter, however, it exposes only what the Matter standard defines. Do I miss those extra features? No. Quite the opposite.
What matters most is interoperability, correct device classification, and predictable behavior across ecosystems — and this is exactly what Matter delivers.
Some device-specific settings are intentionally handled outside Matter.
For example, Eve allows temperature offset calibration in its app, while Bosch provides this directly on the device itself. Both approaches are valid and do not contradict Matter’s design philosophy.
Where Hubitat falls short is its fundamental understanding of European heating systems.
TRVs are not a niche use case in Europe — they are the norm. Treating them as secondary devices or approximating them with generic thermostat models completely misses their role.
The idea of having brand-specific Matter drivers is especially problematic.
A properly implemented Matter TRV driver should work with any Matter-compliant TRV, regardless of brand. That is precisely the purpose of Matter. Unlike Zigbee or Z-Wave — where capabilities often have to be inferred — Matter defines every cluster, attribute, and behavior explicitly.
And finally: Thread.
In real-world usage, Thread has proven to be significantly more reliable and robust than legacy mesh protocols.
Hubitat often claims to represent “how a smart home should work.”
That may be true for the majority of US-based setups, but it does not translate well to European households, where heating, TRVs, Matter, and Thread are central — not optional.
From a European perspective, these aspects are not edge cases — they are core smart home functionality.
Is Matter in Hubitat implemented according to the standard, so that a Matter TRV will simply work out of the box once it has been paired with a Border Router (like an Apple TV or HomePod)?
