My TRV doesn’t seem to have a valve attribute. Any idea why?
I found it. It’s the pi_heating_demand value:
{{ state_attr('climate.danfoss_tv_stue_thermostat','pi_heating_demand') | int }}
you’re not using deconz integration, are you?
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!)
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
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
Well, it looks like you have more automations based on this, no?
I think so, but how do I check ? I’ve used to call my automations names danfoss or blueprint
well, start with this👆
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
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:
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
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”.
@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.
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?
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 .
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
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. 
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?
No. This works as designed by danfos with only difference you’re using your own temperature sensor or calculation.
It doesn’t work like that. There is no mechanical thermostat inside. There is a valve and a PID regulator which is an automation algorithm that tries to keep the measured temperature at setpoint by opening and closing the valve at calculated percentage.
No, you’re wrong. By using external temperature sensor you’re adding better data to the algorithm which is good and works as designed.
What you’re describing is external calculation of valve percentage opening. This is not the case here.
Hello everyone, thank you very much for this @luka6000
I have these TRVs with external temperature sensors, my radiators are not actually covered. What would be the best radiator_covered mode in your opinion, true or false ?
If I understand correctly, when true, it uses only the external sensor, but when false it uses external and internal temperature ? What is the benefit of this ?
I’m trying to get the best regulation possible.
Best regards
I would use radiator_covered=false. External sensor makes temperature readings more accurate since it’s the temperature away from the radiator so probably showing more less what you actually feel in the room