yup, I read the documentation but it’s not clear to me what the effect is… one would indeed think that it’s the delay between valve adjustment (pi_heating) and the effect of the measured temperature but the description “Scale factor of setpoint filter timeconstant” is clear as mud 
Given the wording “aggressiveness”, this seems related to the “integration” filter that smoothes out the reaction of the control vs. a change in input. The bigger the integration time constant, the slower the reaction.
However, the higher level documentation indicates that there is only one functionnal level. Which when interpreted literally means there is only one behavior. I suppose that the author meant to say that the aggressive control is either on or off and that settings 1 to 5 are the same, and 6 to 10 also. See this PDF:
I’m thinking the danfoss hub must do some calculations and adjustments and not everything is contained in the TRV itself… I have a hub but have no idea if it’s possible to monitor it’s behaviour
[edit, btw, thanks for that document, it’s alot more informative than just the api doc!!! ]
Something I don’t see widely circulated, but is evident from a couple of Blueprints out there (and my own testing).
You have to multiply the inbound value for external_measured_room_sensor by x100
Therefore, 20c needs to be sent as 2000 etc.
My 20 valves (all set to radiator covered = true) started working perfectly after this. Beforehand, they did not stop heating and the only way to get them to calm down was to set radiator covered back to false.
4 Likes
Thor, bjorn. or someone else please tell me how to implement Thor script and automations if I have more than one Danfoss Ally TRV? In living room I have a Danfoss Ally room sensor and two Danfoss Ally TRV. I would like both heads to read the current temperature indicated by the sensor
Sharing some expérience (again) - the regulation is not very satisfactory with my big/old cast iron radiators. If you ignore the glitch of the orange filling in the graph below (of which the variable edge <>21°C is the temperature fed back to the valve), we can see that there is a considerable delay in the adjustement of the valve opening.
That results in over- and underheating which requires me to cover/uncover myself…
You need to setup an automation for each radiator.and the script presented above would better be adapted to use “fields” that you can use as a parameter.
Personnaly, I use my automation blueprint which proposes fields(parameters), which is reused for every TRVI have.
Note that when you have two TRVs in the same room, you better also update the load balancing which implies that you ensure you get the load of both TRVs, average them and send that back to both TRVs.
There is at least one discussion on this forum,
And you can read more details in this documentation:
I have the following script and automation, but the head heats up until it reaches the set temperature and then turns off even though the temperature on the sensor is a few degrees lower
Script
‘1700560558754’ :
alias: Big room sensor temperature
sequence:
- service: zha.set_zigbee_cluster_attribute
data:
ieee: 04:87:27:ff:fe:fa:92:aa
endpoint_id: 1
cluster_id: 513
attribute: 16405
cluster_type: in
value: “{{ (states(“TZ3000_mxzo5rhf TS0201”) | float * 100) | round(0)}}”
mode: single
Automation
alias: Temperature actualization Big
description: “”
trigger:
- platform: state
entity_id:- sensor.tz3000_mxzo5rhf_ts0201_temperature
condition:
action:
- sensor.tz3000_mxzo5rhf_ts0201_temperature
- service: script.1700560558754
data: {}
mode: single
Did you configure your TRV for covered mode?
I also have a script to configure the devices:
And to redo all my cnofigurations, I call that script in another script that configures all my valves so that i ccan repeat or update the configuration easily (only showing two configurations in my script):
alias: Setup/Configure DANFOSS TRV VALVES
sequence:
- alias: Configure Ovvice
service: script.conf_danfoss_ally
data:
device: 03f4d27dfcccefd69aff452e5016c3f8
set_max_temperature: 22
set_min_temperature: 8
enable_open_window: true
view_direction: false
orientation: false
covered: true
- alias: Configure Living Room
service: script.conf_danfoss_ally
data:
device: 96affbce3c7e0f8f1fb5dbeae0bb8048
set_max_temperature: 22
set_min_temperature: 8
enable_open_window: true
view_direction: true
orientation: false
covered: true
mode: restart
maybe this will help… I have the following errors in the logs:
Temperature actualization Big: Error executing script. Error for call_service at pos 1: Error rendering data template: ValueError: Template error: float got invalid input ‘unknown’ when rendering template ‘{{ (states(“TZ3000_mxzo5rhf TS0201”) | float * 100) | round(0)}}’ but no default was specified
Error while executing automation automation.temperature_actualization_big: Error rendering data template: ValueError: Template error: float got invalid input ‘unknown’ when rendering template ‘{{ (states(“TZ3000_mxzo5rhf TS0201”) | float * 100) | round(0)}}’ but no default was specified
As you sensor does not have a known temperature, no temperature update should be sent to the TRV. That allows the TRV to fallback to its internal sensor (after 3 hours). Setting (=sending) a default temperature would result in an undesired outcome.
Normally this should occur only after a HA restart and disappear once temperatures are received.
The presense of this error message helps remind you that you may have an issue with the sensors or the configuration thereof.
To avoid the error, the script needs to be extended with a test that verifies that the temperature is valid (the zigbee sensor value is set and <> 0x8000, so for that purpose the sensor value default can be signed 16 bit hex 0x8000 or -16384). And when the temperature is invalid nothing should be sent to the sensor.
Possibly even log an error message every hour if this situation lasts for more than one hour.
In the script that I propose, I did not put the effort to avoid the error because:
- It is not essential when the sensor is reporting temperatures;
- I am quite busy so because of 1., this is not a priority in my schedule…
What does it mean?
Message malformed: template value should be a string for dictionary value @ data[‘sequence’][0][‘data’]
alias: Big room sensor temperature
sequence:
- service: zha.set_zigbee_cluster_attribute
data:
cluster_type: in
ieee: 04:87:27:ff:fe:fa:92:aa
endpoint_id: 1
cluster_id: 513
attribute: 16405
value: {{ (states(“sensor.tz3000_mxzo5rhf_ts0201_temperature”) | float * 100) | round(0)}}
mode: single
I think that problem is in value line… My temperature room sensor is also humidity sensor and maybe there`s some problem with sensor id?
Just hooking on to this thread, as I am getting a new heater/heatpump in three weeks and will also install TRV’s in each room, which I want to control from HA. My idea is to have a few rooms with external sensors, and in the less used rooms I will just rely on the TRV internal sensor. I mostly heat only the living room, but I want to be able to heat the other rooms individually when needed.
I currently use ZHA with a Sonoff , and from what I have gathered on the forum, currently there aren’t many options for TRV’s that can work on external sensors. The Danfoss/Popp ones look good though. I have a few questions:
-
Is the combination of ZHA and Danfoss Ally TRV’s a good way to go if I want to achieve a reliable setup? If not, are there other TRV’s that are more reliable? When I say reliable I mean that the hardware doesn’t break and the connection has a high uptime. Small inaccuracies in the temperature are less important to me. Are there better options if I switch to Z2MQTT? That would be a bit of work since I have about 30 devices already and a bunch of custom automations but if I am going to switch this would be the time
-
In the setup described in this thread, what happens if you manually set a setpoint with the knob? Is that setpoint then related to the internal temperature sensor or does it work the same as setting the setpoint remotely?
You should paste the yaml code in a ```yaml CODE ``` block to make it readable and properly indented:strong text
alias: Big room sensor temperature
sequence:
service: zha.set_zigbee_cluster_attribute
data:
cluster_type: in
ieee: 04:87:27:ff:fe:fa:92:aa
endpoint_id: 1
cluster_id: 513
attribute: 16405
value: {{ (states(“sensor.tz3000_mxzo5rhf_ts0201_temperature”) | float * 100) | round(0)}}
mode: single
The following should be more appropriate:
alias: Big room sensor temperature
sequence:
- service: zha.issue_zigbee_cluster_command
data:
cluster_type: in
ieee: 04:87:27:ff:fe:fa:92:aa
endpoint_id: 1
cluster_id: 513
attribute: 16405
value: >-
{{ (states("sensor.tz3000_mxzo5rhf_ts0201_temperature") | float * 100) |
round(0) }}
mode: single
There are a few types of sonoff usb coordinator sticks.
If https://better-thermostat.org/ does the job, then any TRV can be transformed - not tested.
It does the job for me, but I use zha-toolkit as well with zha for more features. I’ve shared my blueprints/automations/scripts for Danfoss Ally there.
I have not tested other ones. I can tell that I had to reset(battery removal/entry)/reconfigure about 4 Danfoss TRVs out of 7 in 1.25 years.
There is only one active setpoint on the TRV which is the one you see on the TRV, that you can also change with the knob if you did not block that in the configuration), is related to the selected reference temperature: the external room sensor if you enabled that or the internal sensor if the external room sensor is not enabled or stopped providing data since 3 hours.
When you change it using the knob, the new setpoint value is sen to the zigbee coordinator/home assistant and updates in the UI.
Thanks for the info, very helpful!
If I understand that correctly, it can’t work with external sensors directly under ZHA, but you can use the integration to read the external sensor, and send an offset setpoint to the TRV. That works I guess, but it’s not quite the same.
Is it possible to directly read and/or write the valve position?
From what I understand (without reading any detail), Better thermostat will send a temperature setpoint to the thermostat (including TRVs) that will compensate for offsets with a room temperature sensor, window openings, etc. and possibly in a dynamic manner (the offset is not always the same).
You can read the valve position of the Danfoss Ally (pi_heating_demand) but I did not manage to set the valve position. I know a Zigbee TRV where you can set the valve position, but it is only for sale in B2B and not marketed - and it also supports a remote temperature sensor directly (end-device-to-end-device reports).
The Danfoss Ally allows a report configuration for this value which I am tracking on some valves:
I am not happy about how it regulates my home-office - it’s kind of the “russian mountains” (translated from french/roller coaster in plain english). The remote temperature is the lower edge of the orange zone - the bottom graph shows the valve position - it’s an old cast iron radiator and the TRV does not manage the lag very well:
Yeah, that doesn’t look like a well-tuned system. Do you get access to the feedback parameters (PID or whatever they use) ?
Right now all I have is an on-off signal to the boiler so I expect to get at least some improvement even if it isn’t perfect. Main thing for me is to choose the right TRV now. I am considering these and Aqara E1’s mostly ATM. E1 only has external sensor support in Z2M right now, but on Github I can see it’s in the pipeline for ZHA as well.
Then there is Tuya and all the clones of it, I’m not too sure about that, there must be a reason why they are cheaper. Same for Sonoff. I like cheap stuff sometimes but in this case I’d rather invest in something a bit higher in quality. I also saw a reasonable deal on Bosch TRV’s , that’ a brand with a good reputation but the ZHA compatibiltiy isn’t as good AFAICT.
The TRV seems to regulate better with modern radiators that do not have as much heat capacity - but the temperature is constant where I have those, so the TRV has to cope with smaller temperature variations.
Personnaly I would not use Aqara - no good experience with the devices I tested.
They started interacting with the external sensor! Thank you!
As I had some issues with external set temps, I stumbled over this very helpful Danfoss Ally document and thread about multi radiator setup.
Thought it’s a good idea to leave it here as well.