Have you updated to at least v3.4 of the integration? Recommend 3.4.2.
1 Like
How can I check what integration version I am on?
Found it - in HACS panel I can see I am on 3.2.2. Upgrading to 3.4.2 now.
Wish that came into notifications for available updates
enabled development features in HACS, and you’ll see updates.
You can use an automation to notify you of updates available in HACS. Use sensor.hacs as the trigger with numeric state > 0. I’ve actually used this to create a template binary sensor that I use as the trigger instead. Then just send a notification in the usual way, or create a persistent notifcation in HA using the persistent_notification.create service.
Thanks, that’s a really good idea. I couldn’t work out how to do it myself but found someone else who had already done it: Automation to create notification when HACS addons get new updates? - #3 by PickOne
Has anyone here noticed if their radiator TRV’s have decided to lose temperature accuracy? My TRV’s measure the ro9m temp ok when cold but when the heating comes on they all turn off approx. 1.5-2.5c below their temperature setpoint i.e. at 16c the TRV’S states 16c but at 18c the TRV’s will state temp is 20c and turn off! I have to have the setpoint at 22c to get a room temp of 20c which i think is a big difference.
The TRVs have always been pretty inaccurate and out by a few degrees.
I did some analysis on this about a year ago, which I posted in this thread, but it makes the case for using a room thermostat very strong. Because of this, I bought a load of room thermostats (expensive, but worth it IMO) and now only have two rooms where I am using just the TRV without a room thermostat associated and these are in the Utility Room and the Garage. Two rooms I don’t really care about accuracy or temperature consistency in.
So, yes, having to compensate quite dramatically in one direction or the other for a TRV is normal. It’s right next to the heat source, so (IIRC) Drayton have compensated for this in the software, by lowering the reading and also the responsiveness to sudden changes in heat.
However, dependent on the TRV installation position (bottom or top of the radiator) and whether the TRV is pointing up (vertical), or out (horizontal), which will depend on your plumbing, their allowance for this can overcompensate.
My TRV heads are at the bottom pointing horizonally, rather than vertically, and they read consistently lower than the real temperature. I suspect Drayton have designed for the most common installation, which is the TRV heads pointing vertically up at the bottom of the radiator. Are yours horizontal at the bottom by any chance?
I see much the same. In a room which contains a roomstat and iTRV’s, there is approx 2.0 to 2.5C difference in the reported tempeature. The roomstat is showing 20C and the iTRV 22.5C. I have also placed a digital thermostat in the room and that pretty much agrees with the roomstat plus/minus 0.1C. So yes, there can be a fair discrepency for the iTRV’s and some allowance should be made for that in any taget temperature settings.
My TRV’s are all at the bottom of the radiators and vertical. I have asked Drayton if they can do something to improve it but like everything that is suggested it likely wont happen.
Good luck with that. An offset for both the room thermostats and TRVs is a much requested (and probably the biggest missing) feature, that could easily be added with a software/firmware update and is something most of the competitors have. Nothing has happened with regards to it being addressed since I have been using it (coming up to 1.5 years).
Until (if) it’s addressed, you just have to make allowance for it in your target temperatures. Not a showstopper, but it is irritating. 
I wish they would release a room thermostat that just monitors the temp, so no screen or controls just for this scenario. Would be cheaper. £90 per room is rather steep
2 Likes
A TRV is never going to be able to accurately measure the room temp because it is sat an inch away from a pipe that swings between cold and boiling hot. A separate room stat is the best option, but the Wiser ones are stupidly expensive. In the absence of that, stop thinking of the TRV temp as a temp, and instead treat it as just a number, and find the number that brings your room to the temp you like.
They may not report an accurate temperature number, but the way Wiser TRVs work is actually pretty clever given their environment, over time they really do learn how to bring the room to a consistent temp. You might need to set the TRV to “22” to bring the room up to an actual 20 degrees for example, but it will do it consistently.
1 Like
Yep, another thing on the wanted list. New hardware though, rather than something that can be implemented for existing devices. The crazy thing is they actually have this available already for the Hub 2 (available in Europe) that’s not available in the UK although it’s not currently compatible with the HubR. So maybe it is something they could fix with software after all i.e. add compatibility.
You can get the room thermostats for around £60 if you look for deals. It’s still very expensive if you need a lot of them though.
Hopefully this gives you some pointers. There maybe a more efficient way to do it but wanted to share at this step. I also wonder if this is better as a card-mod theme (saves having to keep adding all the code to every card), which I will look at soon.
card_mod:
style:
ha-state-control-climate-temperature:
.: |
:host {
--state-climate-cool-color: var(--disabled-color);
{%- if state_attr(config.entity, 'is_passive') %}
{% if is_state(config.entity, 'auto') -%}
--state-climate-auto-color: var(--light-green-color);
--state-climate-heat-color: var(--light-green-color);
{% elif is_state(config.entity, 'heat') -%}
--state-climate-heat-color: var(--light-amber-color);
{% endif %}
{% endif %}
}
$:
.: |
.buttons { visibility: hidden; }
{%- if state_attr(config.entity,'percentage_demand') | float(0) > 0 %}
.label { color: var(--amber-color) !important; }
{%- endif -%}
ha-control-circular-slider:
$: |
{%- if state_attr(config.entity, 'is_passive') %}
{% if is_state(config.entity, 'auto') -%}
.background {
stroke: var(--light-green-color) !important;
opacity: 0.75 !important;
}
{% elif is_state(config.entity, 'heat') -%}
.background {
stroke: var(--amber-color) !important;
opacity: 0.75 !important;
}
{% endif %}
{% endif %}
Passive Auto
Passive Heat
Passive Heat - with demand
1 Like
Can anyone help with the styling of the slider when NOT using passive mode please? I’m struggling changing the colour of the slider dynamically based on the heating state. If I’ve understood the elements of the card correctly, there is no .high or .low to target when not using Passive mode, so I’m not sure of the syntax required to target the slider.
Using card mod helper, the selector it gives me for the slider is:
"body>home-assistant$home-assistant-main$ha-drawer>partial-panel-resolver>ha-panel-lovelace$hui-root$#view>hui-view>masonry-layout$#columns>div:nth-child(1)>hui-thermostat-card$ha-card>ha-state-control-climate-temperature$div>ha-control-circular-slider$#display>g>path.arc.arc-colored.value"
and in the developer tools, I can see that the slider is picking up the ‘auto’ HVAC mode green colour from the --state-climate-auto-color but I’m not sure how to target and override this, past the ha-control-circular-slider level in card mod?
EDIT: Just seen Mark and Robert’s posts as I finished putting my post together, so I should be able to figure it out from there by the looks of it.
Here’s my updated card-mod YAML for the main thermostat card (the rest of the code was posted above yesterday) that changes the HVAC mode button colours.
It’s not perfect, as it does change the glow colour for Passive Manual mode to amber, instead of keeping the default deep orange, but unless someone cleverer than me can figure out how to address the HVAC mode buttons without changing the --state-climate-heat-color variable, or until I have more time to investigate, it will have to do. Other than that, I’m fairly happy with this.
Passive Manual:
Passive Auto:
card_mod:
style:
ha-state-control-climate-temperature:
$:
.: >
.buttons { visibility: hidden; }
{%- if (state_attr(config.entity, 'percentage_demand') | float(0) > 0) or state_attr(config.entity, 'is_heating') -%}
.label { color: var(--deep-orange-color) !important; }
{%- endif -%}
ha-control-circular-slider:
$: >
.high {
stroke: var(--disabled-color) !important;
opacity: 0.4 !important;
}
{%- if state_attr(config.entity, 'is_passive') and is_state(config.entity, 'auto') -%}
.background {
stroke: var(--light-green-color) !important;
opacity: 1 !important;
}
.low {
stroke: var(--light-green-color) !important;
opacity: 0.5 !important;
}
{%- elif state_attr(config.entity, 'is_passive') and is_state(config.entity, 'heat') -%}
.background {
stroke: var(--amber-color) !important;
opacity: 1 !important;
}
.low {
stroke: var(--amber-color) !important;
opacity: 0.5 !important;
}
{%- endif -%}
.: >-
{%- if state_attr(config.entity, 'is_passive') and is_state(config.entity, 'auto') -%}
ha-card {
--state-climate-auto-color: var(--light-green-color);
}
{%- elif state_attr(config.entity, 'is_passive') and states(config.entity, 'heat') -%}
ha-card {
--state-climate-heat-color: var(--amber-color);
}
{%- endif -%}
Many thanks @msp1974. 
Someone cleverer than me was able to do it. 
Weird, I just posted what I had come up with at the same time. I will take a look at this and implement. I did not know there was such a thing as a card-mod theme. That sounds useful!
@msp1974 Oh, just reading through your code and I think this essentially does the same thing as I came up with and unfortunately suffers from the same problem of changing the heating glow colour, as that uses --state-climate-heat-color.
@Scoff If you’re just wanting to change the auto colour that’s fairly easy. Just use this:
ha-card {
--state-climate-auto-color: var(--amber-color);
}
It’s when those variables i.e. --state-climate-heat-color are used by other parts of the card and you don’t want to change them that it becomes much more difficult.
It does yes. Will have a look at that.
1 Like