Danfoss Ally 1.18 set external temperature to Radiator Covered TRV

Blueprints Exchange
21

Hi all,

with the cold season approaching, I am also setting up my Ally TRVs :slight_smile:

I am using ZHA, so I adapted @oveand’s version with the following two changes:

  • Went back to the original way of delaying because my automations were not triggering due to last_triggered being unknown. Not sure if this is now fixed; but I ran the automations manually once and that seemed to take care of the problem
  • Use a selector to only select the Danfoss TRV devices and extract the IEEE from the device

Blueprint:

See below for fixed version! Danfoss Ally 1.18 set external temperature to Radiator Covered TRV - #28 by mhaas

As a bonus, here is a script blueprint to set the “radiator covered” mode. Save this under automation/script:

blueprint:
  name: Danfoss Ally TRV 1.18 - Set "Radiator Covered"
  description: Danfoss Ally TRV 1.18 - Set "Radiator Covered"
  domain: script
  input:
    danfoss_ally_trv:
      name: Danfoss Ally TRV
      description: TRV where "Radiator Covered" will be enabled
      selector:
        device:
          model: eTRV0100

sequence:
  - variables:
      danfoss_ally_trv: !input danfoss_ally_trv
  - service: zha.set_zigbee_cluster_attribute
    data:
      ieee: "{{ (device_attr(danfoss_ally_trv, 'identifiers') |list).0.1 }}"
      endpoint_id: 1
      cluster_id: 513
      attribute: 16406
      cluster_type: in
      value: 1

It would be neat to have a sensor which shows the attribute value so I can see if the value has reverted. Is this possible with zigbee attributes?

2 Likes
22

Thanks for this, it helps a lot to understand how things work.

I have a question though, that it might be obvious but is not for me. What is the reason for multiplying the temperature of the external sensor with 100 and sending this to the TRV? That means that instead of e.g., 25.17, we send 2517. I’ve actually noticed that then the TRV takes this value as is for its “external_measured_room_sensor”. Is it just how this variable is encoded?

23

well, this is how the temperature is encoded as integer. Integer memory take less space then decimals. So probably whole trv works with integer math.

24

My TRV doesn’t seem to have a valve attribute. Any idea why?

image
image1584×814 53.5 KB

25

I found it. It’s the pi_heating_demand value:

{{ state_attr('climate.danfoss_tv_stue_thermostat','pi_heating_demand') | int }}

26

you’re not using deconz integration, are you?

27

How did it work in ‘single’ mode? I’m using this (adapted for zigbee2mqtt) and it works well but I noticed sometimes it misses an update which I think is caused by a temperature based trigger coming immediately after a time based trigger like you described.

Now that I think of it, I guess I could also add a trigger so that it updates if the external measured temperature changes to -8000 which would be something of a backstop if everything else fails.

I’m going to write to Danfoss with some feedback and suggestions too because I think the thermostat should fall back to the non-covered radiator mode for 3 hours (well 2.5) if the external temperature isn’t updated within 30 minutes in covered mode because at least then it would still reference the external sensor to some extent if there’s a temporary loss of communications.

I also noticed that it seems to ignore the external sensor when I set ‘vertical orientation’ to true.

I would also like to know whether the adaptation uses the external temperature when in covered mode (it should!)

28

Hi all,

I’ve been wondering why my place is so cold - and why my TRVs are not taking my external temperature sensor into account. It turns out that there is a bug in the automation I posted above. I was a bit surprised that Home Assistant does not make it very obvious if an automation fails. I had to go into the traces section to see that there’s a problem.

The problem was a missing variable declaration for the danfoss_trv input. This caused the last node with the call to set_zigbee_cluster_attribute to fail!

Updated blueprint:

# https://community.home-assistant.io/t/danfoss-ally-1-18-set-external-temperature-to-radiator-covered-trv/380219/15
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:
        device:
          model: eTRV0100
    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
  danfoss_trv: !input danfoss_trv

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: zha.set_zigbee_cluster_attribute
    data:
      ieee: "{{ (device_attr(danfoss_trv, 'identifiers') |list).0.1 }}"
      endpoint_id: 1
      cluster_id: 513
      attribute: 16405
      cluster_type: in
      value: "{{ (states(temperature_sensor) | float * 100) | round(0) }}"
mode: restart
29

When I remove the blueprint and the automation - I get this error on reboot of Home Assistent

Invalid config for [automation]: Failed to load blueprint: Unable to find luka6000/danfoss-ally-1-18-set-external-temperature-to-radiator-covered-trv.yaml (See /config/configuration.yaml, line 121).

18.58.10 – (FEJL) components/blueprint/models.py - beskeden forekom først kl. 18.35.01 og ses 12 gange

Invalid config for [automation]: Failed to load blueprint: Unable to find luka6000/danfoss-ally-1-18-set-external-temperature-to-radiator-covered-trv.yaml (See /config/configuration.yaml, line 121).

18.58.10 – (FEJL) components/blueprint/models.py - beskeden forekom først kl. 18.35.00 og ses 12 gange

30

Well, it looks like you have more automations based on this, no?

31

I think so, but how do I check ? I’ve used to call my automations names danfoss or blueprint

32

well, start with this👆

33

FYI:

A blueprint for ZHA is available at zha-toolkit/danfoss_ally_remote_temperature_min_delay.yaml at 54157359326577ea971fd76a78d9fbfa272103d4 ¡ mdeweerd/zha-toolkit ¡ GitHub - it requires that you also have zha-toolkit .

There is also a configuration script: zha-toolkit/script_danfoss_ally_configure.yaml at 54157359326577ea971fd76a78d9fbfa272103d4 ¡ mdeweerd/zha-toolkit ¡ GitHub .

I use the configuration script in another script so that I can repeat/adjust the configuration whenever needed (in visual mode you can easily select the valve and change the settings):

alias: Setup/Configure DANFOSS VALVES
sequence:
  - alias: Configure Kitchen
    service: script.conf_danfoss_ally
    data:
      device: 05a5be28148c6e810c20f4386565cb25
      set_max_temperature: 22
      set_min_temperature: 8
      enable_open_window: true
      view_direction: true
      orientation: false
      covered: true
  - service: script.conf_danfoss_ally
    data:
      device: 7d16a871a8caa808d80e23f5d92ca65d
      orientation: false
      view_direction: true
      covered: true
      enable_open_window: false
    alias: Configure Room X

image
image650×778 46.9 KB

With regards to the remote temperature blueprint, you should select 5 minutes when in covered mode and 30 minutes in remote mode. IMHO covered mode is also recommended in situations where you radiator is not covered but when the remote temperature is lagging a lot on the local temperature or not very stable vs. the local temperature.
I have one automation for each TRV to link the remote temperature to the TRV.
Also, when the remote temperature is a zigbee device, the more 0.01°C precision temperature is retrieved by performing a read from cache (provided by zha_toolkit). While the absolute precision is worse, I do this so the TRV gets information about the delta changes in temperature to help adjust its regulation.
There is also a trick to let the automation know when a new temperature was received from the thermometer - even if it is only 0.01°C.

Example configuration:

image
image822×706 48.7 KB

Finally there is a script to start the adaptation run.
This is supposed to have the TRV determine its regulation settings.
It was not straightforward to ensure that the device does not consider itself as adapted, but this automation does it.
You should not change the TRV’s settings until after the adaptation process is finished (which takes up to 3 hours or so according to the documentation).
One of the things I found the TRV to do is to increment the valve percentage 5% by 5%.

After triggering this automation, the TRV is set into mounting mode (which opens the valve completely to facillitate mounting). You need to press the TRV button for a second or so to exit the mounting mode - you’ll hear the internal motor move to close the valve. The automation waits for this step (there is a repeat loop) and then initiates the adaptation run. The actions can be observed by listening on the ‘zha_done’ event or by checking /config/csv/danfoss_adaptation_run.csv .

This is the adaptation run script: zha-toolkit/script_danfoss_ally_adaptation_run_init.yaml at 54157359326577ea971fd76a78d9fbfa272103d4 ¡ mdeweerd/zha-toolkit ¡ GitHub

34

Hey @luka6000 , many thanks for this blueprint.

1 Like
36

Hello le_top, may u explain how to use your zha based blueprints? I am new to home assistant, installed zha and activated it in configuration.yaml, copied your blueprints into blueprints folder, but i only get the following error “Invalid blueprint: required key not provided @ data[‘blueprint’]. Got None”.

37

@Klausi You may have copied some scripts.
The blueprint files have ‘blueprint:’ near the head and this is what Home Assistant is looking for.
The error message indicates this is missing.

Once you have the blueprint, you can add an automation using it.

Further above, I give an example of how to use the configuration script which is not a blueprint - you can add the script using the UI and call that script from another script.
In the example I show how to configure several valves by calling the configuration script.

38

Thank you for your reply. I cannot follow you :-. I explain what i have done:

  • I copied the files from your github folder “blueprints” to my folder blueprints.
  • I created a script like yours but with my device informations like this:

alias: Setup/Configure DANFOSS VALVES
sequence:

  • alias: TCV Buero
    service: script.conf_danfoss_ally
    data:
    device: 76acb3bc60bde503d691f83a0d9ef47c
    set_max_temperature: 23
    set_min_temperature: 16
    enable_open_window: false
    view_direction: true
    orientation: false
    covered: true
  • alias: TCV Dusche
    service: script.conf_danfoss_ally
    data:
    device: 8bf454613cf73a1ef978c7e41a063b4b
    set_max_temperature: 23
    set_min_temperature: 16
    enable_open_window: false
    view_direction: true
    orientation: false
    covered: true
    mode: single

When i try to call it, it gives me the following error:
Setup/Configure DANFOSS VALVES: Error executing script. Service not found for call_service at pos 1: Unable to find service script.conf_danfoss_ally

Maybe zha-toolkit is too powerful and nothing for beginners? I just the functionality to set parameters of the trvs, which i had with z2m before, back. Is it also possible, to set load balancing with 2 or more trvs with zha-toolkit?

39

The blueprint(s) should only be used for automations here (i.e., regularly update the ermote temperature for the TRVs).

The script you wrote needs another script:

You need to add that to your scripts and call it conf_danfoss_ally .

image
image956×724 38.8 KB

The name is the entity_id when you create the script.

Or, you can add the script to “scripts.yaml” in the config directory :

[... other scripts]
conf_danfoss_ally:
  alias: Danfoss Ally TRV configuration
  sequence:
  - variables:
      ieee: '{{ (device_attr(device, ''identifiers'')|list)[0][1] }}'
      default_tries: 3
  - alias: Configure reporting of local_temperature in Thermostat cluster
    service: zha_toolkit.conf_report
    data:
      ieee: '{{ ieee }}'
      cluster: 513
      attribute: 0
      tries: '{{ default_tries }}'
      event_done: zha_done
      reportable_change: 20
      max_interval: 300
      min_interval: 19
  - alias: Read back reporting configuration, for debugging
    service: zha_toolkit.conf_report_read
    data:
      ieee: '{{ ieee }}'

# Rest of the script

scripts.yaml is included because of the following (I think default) line in configuration.yaml:

script: !include scripts.yaml

When you add the script manually to the file, you need to reload the scripts with a click on Developer Tools>YAML>SCRIPTS

1 Like
40

Very nice explanation, now i understand that it didnt work, because the first script doesnt found the other one, because of the entity name. THANK you. Thats what i wanted to achieve. :slight_smile:

41

Am I correct that with this, as with any scheme where there is an external thermometer updating the TRV at a relatively high rate, that battery consumption will be significantly higher?

I’m assuming that with these TRVs (mine are Danfoss Ally), a “thermostatic” mechanical element inside the device makes the real-time valve adjustments, and the motor moves that assembly according to the desired setpoint - in the same way that the big knob does on traditional TRVs.

Whereas with external sensing on an electronic unit, the effect of the external input is to “adjust the knob” at relatively high frequency in order to outsmart the thermostatic element - thereby using the battery each time.

Do I have this right?