The orange is more subtle, I am using that now too.
Update: I am using the variable instead:
style: |
{% if state_attr(config.entity,'is_heating') %}
ha-card #slider-center #temperature > svg > text {
fill: var(--state-climate-heat-color);
}
{% endif %}
Sorry for the offtopic but have you ever use a 2x1.6v Zink batteries instead of alkaline for iTRVâs?
Morning All,
Just got setup with HA last week and managed to fudge my way to getting HACS and the Wiser integration installed, thanks to the devs and community for such a complete integration!
Iâve come up against the usual issue with the iTRV reporting a temp higher than the room temp (sometimes about 4 degrees!)
Iâve found the recipe here which looks like it sorts my issue wiserHomeAssistantPlatform/manage_temps_v2.md at d32a901382b5872389dfba71ad5a44d3d46936e2 ¡ asantaga/wiserHomeAssistantPlatform ¡ GitHub and have put a spare Hue Sensor in the affected room to get a âtruerâ temp reading.
I am quite new to HA but think I have it all setup correctly by creating the automations and pasting in the YAML text then inputting my sensor info etc. However, it does not seem to be working.
The 2 potential issues are;
Any help is appreciated, I have not posted the code as concious of the wall of text, but everything is as standard in the link above with the appropriate changes as below
trigger_variables:
temp_sensor_integration: hue
temp_sensor_prefix: sensor.hue_motion_sensor_1
temp_sensor_suffix: temperature
Question for the people that have an underfloor heating controller or an electrical heat switch in their system:
Both of these are mains-powered devices that communicate with the hub via zigbee.
The question is: Do these devices also act as relay nodes to extend the mesh network, like wiser plugs do?
I read somewhere that any mains-powered device should be able to act as an extender, but Iâve only seen plugs used for this purpose.
Would be interesting to check, if anyone has either of these devices, if other TRVs and roomstats have connected to them in the network diagram.
âhueâ is the correct integration name. If you manually run the second automation I think you will get an error as it relies on info passed from the first automation in the event data, which you wonât have if you run manually.
What is it you are looking at to know itâs not working? You can look at the trace on the second integration to see if it has been triggered. This way you will know if first one is working or not.
If youâre struggling, do post full yaml and I can have a look at it for you.
Thank you, code is as below. My testing at the minute is to simply boost the heating in the wiser app for an hour then run the first automation after a few minutes, which does not seem to trigger the second automation to adjust the temp. Running on Syno box in Docker.
alias: Event from Thermostat Reading
description: ""
trigger:
- platform: event
event_type: state_changed
variables:
temp_sensor: "{{trigger.event.data.entity_id}}"
condition:
- condition: template
value_template: |-
{% if temp_sensor in integration_entities(temp_sensor_integration)
and temp_sensor.startswith(temp_sensor_prefix)
and temp_sensor.endswith(temp_sensor_suffix)
%}
True
{% endif %}
action:
- event: external_temp_sensor_changed
event_data:
entity_id: "{{temp_sensor}}"
old_temp: "{{trigger.event.data.old_state.state}}"
new_temp: "{{trigger.event.data.new_state.state}}"
trigger_variables:
temp_sensor_integration: hue
temp_sensor_prefix: sensor.hue_motion_sensor_1
temp_sensor_suffix: temperature
mode: queued
max: 25
And
alias: Adjust Wiser Boost for Ext Temp Sensor Heat Management
description: Uses External Temp Sensor To Achieve Target Temp in Room
trigger:
- platform: event
event_type: external_temp_sensor_changed
variables:
temp_sensor: "{{trigger.event.data.entity_id}}"
temp_sensor_temp: "{{trigger.event.data.new_temp}}"
climate_entity: |-
{% for wiser_climate in area_entities(area_name(temp_sensor))
if wiser_climate.startswith('climate.')
and wiser_climate in integration_entities('wiser')
%}
{% if loop.first %}
{{wiser_climate}}
{% endif %}
{% endfor %}
schedule_temp: "{{state_attr(climate_entity, \"current_schedule_temp\")|float(0)}}"
current_temp_delta: "{{(schedule_temp - temp_sensor_temp)|round(1)}}"
boost_delta_temp: "{{(((current_temp_delta * 1.5) * 2 )|round(0)/2)|round(1)}}"
condition:
- condition: and
conditions:
- condition: template
value_template: "{{ states(climate_entity) is defined }}"
- condition: template
value_template: |-
{% if (
current_temp_delta > tolerance_delta
and not state_attr(climate_entity, 'is_heating')
and not state_attr(climate_entity, 'is_boosted')
)
or
(
current_temp_delta < tolerance_delta
and state_attr(climate_entity, 'is_boosted')
)
%}
True
{% endif %}
action:
- service: wiser.boost_heating
data_template:
entity_id: "{{climate_entity}}"
time_period: "{{ 0 if current_temp_delta < tolerance_delta else boost_time }}"
temperature_delta: >-
{{ 0 if current_temp_delta < tolerance_delta else [boost_delta_temp,
max_boost_delta]|min}}
- service: logbook.log
data_template:
name: Wiser Temp Boost by Ext Sensor
message: |-
Temp Sensor - {{temp_sensor}},
Temp Sensor Temp - {{temp_sensor_temp}}°C,
Climate Entity - {{climate_entity}},
Schedule Temp - {{schedule_temp}}°C,
Current Temp Delta - {{current_temp_delta}},
Action -
{% if current_temp_delta < tolerance_delta %}
Boost Cancelled
{% else %}
Boosted By {{[boost_delta_temp, max_boost_delta]|min}}°C for {{boost_time}} mins
{% endif %}
entity_id: "{{climate_entity}}"
domain: wiser
trigger_variables:
boost_time: 30
tolerance_delta: 0.5
max_boost_delta: 5
mode: queued
max: 10
@georgek - I have an EHS an can confirm that it does act as an extender - currently on my network diagram I have x1 TRV connecting to it
Looks like bunch of new firmwares are being released again https://wiser.draytoncontrols.co.uk/new-and-improved-wiser-app They are actually stating numerical versions this time, so I wonder if that bit is finally fixed. Also hub is jumping to v4, 
they fixed it being stuck without connection with red light.
Has anyone already got updates?
thatâs great, thanks for confirming!
Ah, so thatâs how you use it with the variable. I tried it with that, but was missing the var() declaration. I really should make time to read the documentation! 
First time using cardmod. Thanks.
The automation basically works as this:
First automation:
When it receives a temp update from your temp sensor (in this case you hue motion sensor), it trigger the first automation to send an event.
Second automation:
This listens for the event from the first automation and compares it to the scheduled temp. If the temp from the hue motion sensor is less than the schedules temp and the room is not boosted and not heating, it will boost the room for 30 mins.
On each temp sensor reading, this process repeats until the room hits the schedule temp as read by the hue motion sensor.
As such, if you boost the room, nothing will happen on these automations. You need to set a scheduled temp, wait for wiser to think it has reached that temp and stop heating for this to fire (assuming the hue temp sensor says it is lower than the scheduled temp).
Oh thats great, thanks for taking the time to explain. I have not quite got my head around the syntax yet (its on my to do list) as I only really know SQL and a bit of Python so that really helps.
I have adjusted the schedule to test for the room and the current sensors are:
Hue: 15.8
TRV: 20.0
Target: 20.0
So when the Hue sensor changes temp either way the automation should kick in? At the moment the first automation is resolving to false on the condition in the trace menu as below:
condition: template
value_template: |-
{% if temp_sensor in integration_entities(temp_sensor_integration)
and temp_sensor.startswith(temp_sensor_prefix)
and temp_sensor.endswith(temp_sensor_suffix)
%}
True
{% endif %}
I can confirm that the UFH acts as a relay too - several iTRV and a Room stat are connected in our system.
Someone posted a link on the Schneider forums to documentation about the Wiser ecosystem that I hadnât seen before.
It talks about all the different devices available in Europe, and their compatibility with the HubR (which is the one we all have), and goes into more detail about Eco and Comfort mode. Seems like a good resource, compared to the broken images and links on the Drayton Wiser support site.
Note that it has details about all the devices available in France, which may make us jealous.
While weâre sharing links hereâs a really useful training video from James at Drayton that explains a quite a bit about how the system works and answers a few of the questions that have come up regarding load compensation and modulation and how it decides when to heat etc, plus the different settings for the boiler and how they affect how often it fires etc.
We had an issue with our hot water tank today, which made me talk through how it works with my wife which always helps me think better about things.
The hot water tank has a thermostat on it. When that reaches the set temperature, it stops requesting hot water from the boiler. So if I left the Hot Water setting on 24/7 the boiler would only fire to heat the water when the temperature in the tank fell below the setting - the topping up would happen as needed. Wiser might think the boiler was on all the time but it wouldnât be.
So perhaps the best setting is to set the Wiser Hot Water schedule On for most of the day, and trust that the insulation of the tank is good enough that the boiler mostly only fires up when a top up is needed (e.g. someone had a bath).
Does this seem like a good strategy?
Iâve been pondering that exact scenario since installing my wiser hub and creating my HW schedule.
I expect a lot depends on your typical HW usage throughout any given day. For us (2 adults), I currently only have the HW heating up for 1 hour in the morning. This seems to be enough to provide us with a shower each, plus the odd bit of HW throughout the day, but with a cold fed dishwasher, any additional HW demand throughout the day is minimal. This does mean however that an unexpected shower requirement could end up with the water running cold at some point 
Iâve been meaning to find out at what point, if at all, during the 1 hour of HW heating, the tank thermostat kicks in and stops the boiler from firing to heat any further water up. I suppose that doesnât really matter, as it isnât going to waste heating fuel, all it would do is show the hub HW demand as âonâ, but the boiler wouldnât actually be firing.
We have a thermal insulation jacket around the tanks own built in insulation, but Iâm not confident that this would retain enough of the internal HW temperature, and by leaving the hub HW demand set to âonâ 24/7 I imagine all the top-ups of hot water for the tank as the internal temperature dips and rises again would just be wasted until there is actual demand for HW the following morning.
Just a theory, and i would need to conduct temperature readings of the tank water over time periods to see how efficient the insulation is and whether it can retain the temperature of the water that it has heated long enough until that heated water is actually demanded and used, rather than just cooling down internally without being usedâŚ
i think the only way to determine if the tank thermostat is âon/offâ is to measure the voltage across the switch. This comes with the usual warnings, about high voltages etc (I think the tank thermostat is a 240v endpoint)
There is a gap in the market for a smart tank thermostat that talks to smart heating systems like Wiser.
Iâd like to see the following features:
T-smart looks partly there, but maybe doesnât talk to boiler, and may be proprietary.
Genius solution is also partly there, but tied into their ecosystem. Looks quite DIY.
Mixergy replaces the whole tank so quite a big project.
Schneider should be in on this.
I had considered this, but itâs a bit of a black hole regarding knowing exactly what is happening and that the hot water tank thermostat is stopping the boiler from firing when itâs not supposed to. I donât really like the idea of leaving it on 24/7 (or most of the day anyway, no need for it to be on at night) and just relying on the fact that it should only fire when needed, as dictated by the tank thermostat.
It would also potentially be firing more than needed to keep it at temperature, as very rarely is there a demand for hot water in the middle of the day, but thereâs always that odd occurance, when someone decides they want to take a bath or shower during the time period when itâs off.
There are various options for manually boosting when needed e.g. a Zigbee button in the bathroom or Alexa voice command and telling people to use them when they go for a bath, but it requires them to remember to do so. What I really want to acheive is full automation, so it just boosts automatically in those instances.