This is blueprint automation to inject external sensor Celcius temperature to Danfoss Ally TRV firmware 1.18 with Radiator Covered = True. This blueprint uses deconz integration.
blueprint:
name: Danfoss Ally TRV 1.18 set external temperature
description: Set external measured temperature to Danfoss Ally TRV firmware 1.18 with Radiator Covered = true
domain: automation
input:
danfoss_trv:
name: Danfoss TRV
description: This is Danfoss Ally climate TRV entity with firmware 1.18 and Radiator Covered = true
selector:
entity:
domain: climate
temperature_sensor:
name: Temperature sensor in Celsius
description: This sensor acts as external temperature sensor for your Ally
selector:
entity:
domain: sensor
device_class: temperature
automation_entity:
name: Automation entity_id
description: This automation entity_id (only low case, underscores)
default: "automation.new_automation"
selector:
entity:
domain: automation
variables:
temperature_sensor: !input temperature_sensor
trigger:
- platform: state
entity_id: !input temperature_sensor
id: trig-temp
- platform: state
entity_id: !input automation_entity
attribute: last_triggered
for:
hours: 0
minutes: 30
seconds: 0
condition:
- condition: numeric_state
entity_id: !input temperature_sensor
above: '0'
action:
- choose:
- conditions:
- condition: trigger
id: trig-temp
sequence:
- choose:
- conditions:
- condition: template
value_template: >-
{{ (utcnow()|as_timestamp -
this.attributes.last_triggered|as_timestamp)/60 <5 }}
sequence:
- delay:
minutes: >-
{{ 5 - (utcnow()|as_timestamp -
this.attributes.last_triggered|as_timestamp)/60 }}
default: []
default: []
- delay:
seconds: '{{ range(1, 21)|random }}'
- service: deconz.configure
data:
entity: !input danfoss_trv
field: /config
data: >-
{ "externalsensortemp": {{ (states(temperature_sensor)|float *100)|int }} }
mode: restart
Can you show your blueprint-automation configuration?
So are you saying your room temperature has 2,5 degrees hysteresis? What was set at target temperature on the trv?
Also, try this sensor template to check valve opening history
Well isn’t it the best proof that external temperature sensor is actually working? My radiators are really covered and I usually see temperatures over 30 on trv to get the room to my preferred 23. And I belive my room sensor not the trv embedded one.
Confirm that you selected proper automation entity. If you don’t know it while setting it up for the first time, just edit it later. TRV requires to have temperature updated at least every 30 minutes. So I check when the automation was last triggered but to do that you need to put or select proper entity_id of the automation itself.
Yes the automation is correct. Just wondering if its normal for the valve to go up and down like that all day. It feels like its slow to respond when its get to hot or to cold.
I kinda agree that valve is a bit slow. I see that valve opens to heat up in the morning and then starts to close only after reaching set point. But then it closes to around 20% and stays there to keep the temperature ±0.2 maybe ±0.5. Definitely not the way you have it. How does it work for you without external temperature?
For the last 60+ hours I set my trv to constant 22. I don’t seethe behavior you’re seeing. My trv is at setpoint offset -0.2 and I see max +0.5 and -0.2 for the room temperature
Thx for the blueprint, I’ve adjusted it for ZHA.
May I ask why you have the random delay?
- delay:
seconds: "{{ range(1, 21)|random }}"
And doesn’t the mode: restart risk that the external temperature sensor is never updated?
If, e.g., the temperature_sensor is updating every minute the automation is then restarted every minute and hence last_triggered is reset ever minute. This means the script will always be stuck in delay sleep.
At least that is what I can see is happening when I debug the automation from this blueprint. Am I missing something?
I’ve tried to update the blueprint to take this into account. This only runs when last_triggered > 5 min, otherwise stop.
blueprint:
name: Danfoss Ally TRV 1.18 set external temperature
description: Set external measured temperature to Danfoss Ally TRV firmware 1.18
domain: automation
input:
danfoss_trv:
name: Danfoss TRV IEEE
description: This is Danfoss Ally climate TRV entity with firmware 1.18
selector:
entity:
domain: string
temperature_sensor:
name: Temperature sensor in Celsius
description: This sensor acts as external temperature sensor for your Ally
selector:
entity:
domain: sensor
device_class: temperature
automation_entity:
name: Automation entity_id
description: This automation entity_id (only low case, underscores)
default: automation.new_automation
selector:
entity:
domain: automation
variables:
temperature_sensor: !input "temperature_sensor"
trigger:
- platform: state
entity_id: !input "temperature_sensor"
id: trig-temp
- platform: state
entity_id: !input "automation_entity"
attribute: last_triggered
for:
hours: 0
minutes: 30
seconds: 0
condition:
- condition: numeric_state
entity_id: !input "temperature_sensor"
above: "0"
- condition: template
value_template:
"{{ (utcnow()|as_timestamp - this.attributes.last_triggered|as_timestamp)/60
> 4 }}"
action:
- service: zha.set_zigbee_cluster_attribute
data:
ieee: !input "danfoss_trv"
endpoint_id: 1
cluster_id: 513
attribute: 16405
cluster_type: in
value: "{{ (states(temperature_sensor) | float * 100) | round(0)}}"
mode: restart
This random delay is for those using same temp sensor for multiple trvs. I don’t want to push zigbee network too much since I’ve already seen congestion while trying to push configuration to too many devices at once. For all the rest of us having dedicated temp sensor per room per trv it’s not doing any harm.
Good catch with this restart setting. So my thinking goes like this: I prefer to update trv with temp sensor update than by time trigger. But there is limit to that, so sensor updates not more often then 5 minutes and schedule updates not less often that 30 minutes. If it’s updated trv with scheduled 30min update and then there is temp sensor update, it will wait up to 5 min and push real temp to trv. But as noticed if temp sensor updates are very often (<5min) then it will fall into loop and not updating trv at all. Does your temp really change that often by 0.1 degree? I think preferred way to solve this is to slow your temp sensor Like with using filter with throttle or min_max. Or just change it to single. Actually this might be the easiest and I think I could add this as parameter.
I see your point with random delay, makes sense then. Nice detail
I’ve seen it a couple of times with my old temp sensors (Eq-3 Max Wall thermostats) and they can sort of jump +/- 0.1 degree with only a couple of minutes between.
My suggestion above does have another flaw, I’ve realized. If temp update is received within 5 minutes it will not automatically update after the five minutes delay but wait until another temp state update is triggered. So running it as single might be the most robust solution.
I’m actually running this script with 30 min delay / 120 min max delay with non-covered trv. We’re turning down temperatures to 20.5 degrees during night and heats up to 22 degrees in the morning.
It seems like for our TRVs, if in covered mode, they are much more open (60%+) for a longer time when heating up compared to if TRV is in non-covered mode. Then they ramps up to 60% for a short period making the radiator rather hot but then the TRV is measuring high temps and the TRV is turning quickly down to ~30%. Heating up takes a bit longer time but I believe the radiator is more effective and saves energy.
But then again it is complicated to determine with Allys as they are non-deterministic and in two days they might behave slightly different when heating up as they have changed their algorithms
What you’re looking for this eq3 temp measurement is debouncing. I don’t see it as option in hass. Esphome has it as filter. In hass you could use filter sensor with throttle. Best option is to make measurement with 10 fold better accuracy and switch the measurement after crossing value by ±0.14. Actually you can set filter sensor with “time_simple_moving_average” filter and throttle to 5min and 0.1 precision. This should do the trick.
In non-covered mode trv calculates temperature as mean from internal and external measurement. That’s why you see it acts quicker on closing the valve. But the room temp is still not at setpoint thus room getting warm slower.
As I already mentioned I also see the tendency to overheat in covered mode. That’s why I’m using attribute 0x404B “Regulation SetPoint Offset” set to -2 which gives me setpoint correction of -0.2C. My trvs are really covered with no chance to show any rational measurements.
Or you could use the same correction attribute in non-covered mode but set it to +5 or even more. This will slow down the effect of internal sensor influence. But it’ll move your setpoint higher so be careful and just test.
Our thermostats are running much better with this blueprint. It even helped us cutting down our heat consumption. I’m using it with Sonoff temperature/humidity sensors. And of course radiator covered on the TRV’s.
Thanks for the great work!
I noticed one thing, that is not related to the blueprint, but I don’t know where to ask anyway, maybe some of you guys can tell me.
The radiator covered cluster was turned off on all my TRV’s a few days ago, so I had to activate it again. I could also see it on the TRV’s behavior. Anyone experienced that before and know why it happens?
Like with using filter with throttle or min_max. Or just change it to single. Actually this might be the easiest and I think I could add this as parameter.