Danfoss Ally 1.18 set external temperature to Radiator Covered TRV

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.

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

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
1 Like

hi i have just installed this blueprint (yesterday) but my external temp show this - is it normal ?

image

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

  - platform: template
    sensors:
      living_room_trv_valve:
        friendly_name: "Living room TRV valve"
        value_template: "{{ state_attr('climate.living_room_trv', 'valve')|int }}"
        unit_of_measurement: "%"
        device_class: power_factor
        icon_template: >-
            {%set val= state_attr('climate.living_room_trv', 'valve')|int %}
            {%if val < 15 %}
              hass:numeric-0-circle-outline
            {%elif val < 25 %}
              hass:numeric-1-circle-outline
            {%elif val < 45 %}
              hass:numeric-2-circle-outline
            {%elif val < 65 %}
              hass:numeric-3-circle-outline
            {%elif val < 85 %}
              hass:numeric-4-circle-outline
            {%else%}
              hass:numeric-5-circle-outline
            {%endif%}

I use your blue print - do I have to change something in it?

Target is set to 22 degrees

- id: '1642280549941'
  alias: Danfoss Ally TRV 1.18 set external temperature
  description: ''
  use_blueprint:
    path: luka6000/DanfossAlly1.18ExternalTempSensor.yaml
    input:
      danfoss_trv: climate.termostat_sovevaerlse
      automation_entity: automation.new_sove
      temperature_sensor: sensor.temp_sovervaerlse

well, it looks ok. Check this valve opening as mentioned.
I’m using this myself with temperatures ±0.2 during the day.


TRV had tendency to overheat so I’ve set -0.2 regulation setpoint offset.

I will check the valve later. my trv is 27 degrees to get to 22 degrees with this blueprint. :-/

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.

My temp is set to 22,5 but also does a bit of a rollercoaster up and down, is this normal? And can I fine tune it somehow?


Can you show graph for climate.trv?
What is your automation entity id?
Please paste your blueprint config.

Okay, but the external temp is not shown here:

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
  source_url: https://gist.github.com/luka6000/f5b80b9829bbc7c613eac6e909caea83
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

Please check blueprint automation config. For me it’s like this


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


Valve is pretty much stable arround 20% open

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

Remember, this is adjusted for ZHA.

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 :slight_smile: 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 :slight_smile:

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 :smiley:

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?

1 Like

Good to hear it works for you :slight_smile:
I’ve only seen parameters reset after update.