Danfoss Ally TRV working with remote temp sensor

Hardware
,
183

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:

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

  2. 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?

184

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
185

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.

186

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?

187

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:

image
image491×551 36.2 KB

188

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.

189

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.

190

They started interacting with the external sensor! Thank you!

191

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.

192

In an effort to understand the official danfoss TRV specs, which weren’t clear at all to me, and after having tried a bunch of variations I’ve come up with the following interpretation which seems to work for me and makes more sense to me. I’ve only tested since a week or so in an unstable environment (renovations). It also looks to me it takes a while (several days - a week? for the TRVs to estimate room inertia I guess) for the heating curve to settle down. Obviously I could be completely wrong! Oh, very important, I also changed the Thermostat vertical orientation to true because of the positioning of the TRV. If somebody has a better interpretation or a better way to phrase which really and verifiably works please let me know!!

uncovered TRV external measured room sensor update with external temperature:

  1. by external temperature change event: every external temp absolute change bigger or equal to 0.1C compared to the TRV’s ‘external measured room sensor’ value and at least every 3hours (timer reset) since last TRV’s ‘external measured room sensor’ update time.
    OR
  2. by interval: between 30min and 3hours.

covered TRV external measured room sensor update with external temperature:

  1. by external temperature change event: every external temp absolute change bigger or equal to 0.1C compared to the TRV’s ‘external measured room sensor’ value and at least every 30mins (timer reset) since last TRV’s ‘external measured room sensor’ update time.
    OR
  2. by interval: between 5min and 30min.

what seems to work best for me is the uncovered by temperature with load balancing between 3 radiators enabled and implementing the danfoss load balancing specs in a script (not just purely the average of the sensors). By interval every 30mins seems to work ok as well ( have that on a different floor so I can compare :slight_smile: ). I’m testing covered by temperature change in a different room but that doesn’t seem great in my specific case.

here’s yesterday’s curve for the room with 3 radiators, load balancing, by temperature event, seems to still be settling, target temp is 19.5 during the day and 18 at night. At first glance average variations from the setpoint seem to be around ± 0.2C on average.
image

[edits to refine wording a bit to hopefully make things a bit clearer]

193

@surreallo, would it be possible to share you script? I would like to see how to implement load balancing with multiple radiators.

194

sure, it’s not pretty, dunno too much about HA scripting syntax and HA messed up the formatting a bit. If I did it properly it should be following the load balancing usecases as described in this document https://assets.danfoss.com/documents/202524/AU417130778872en-000101.pdf , section 2.2. it runs at 15 minute intervals.

alias: 2F-SCR-TRV update average load Living - logic
sequence:
  - service: number.set_value
    data_template:
      value: >
        {% set ns = namespace(sum = 0, count = 0, avg = 0) %} {% if
        (states('sensor.2f_trv_living1_load_estimate') | float > -500) %} 
         {% if  ((as_timestamp(now()) 
          - as_timestamp(states.sensor['2f_trv_living1_load_estimate'].last_updated  ) ) | float | round(0)
          < 5400 ) %} 
            {% set ns.sum = ns.sum + states('sensor.2f_trv_living1_load_estimate') | float %}
            {% set ns.count = ns.count + 1 %}
          {% endif %}
        {% endif %} {% if (states('sensor.2f_trv_living2_load_estimate') | float
        > -500) %} 
         {% if  ((as_timestamp(now()) 
          - as_timestamp(states.sensor['2f_trv_living2_load_estimate'].last_updated  ) ) | float | round(0)
          < 5400 ) %} 
            {% set ns.sum = ns.sum + states('sensor.2f_trv_living2_load_estimate') | float %}
            {% set ns.count = ns.count + 1 %}
          {% endif %}
        {% endif %} {% if (states('sensor.2f_trv_living3_load_estimate') | float
        > -500) %} 
         {% if  ((as_timestamp(now()) 
          - as_timestamp(states.sensor['2f_trv_living3_load_estimate'].last_updated  ) ) | float | round(0)
          < 5400 ) %} 
            {% set ns.sum = ns.sum + states('sensor.2f_trv_living3_load_estimate') | float %}
            {% set ns.count = ns.count + 1 %}
          {% endif %}
        {% endif %} {% if ns.count >0 %} 
          {% set ns.avg = ns.sum/ns.count %}
        {% endif %}  {{ ns.avg | round(0)  }}
    target:
      entity_id:
        - number.2f_trv_living1_load_room_mean
        - number.2f_trv_living2_load_room_mean
        - number.2f_trv_living3_load_room_mean
mode: single
1 Like
195

Hi all,

For a while I am busy with using Danfoss Ally trv in a covered way with an external temperature sensor. However, it is not able to reach and maintain a setpoint temperature yet.

zha_toolkit and the blueprints there to configure and update external temperature helped a lot. Currently I am using an automation based on danfoss_ally_remote_temperature.yaml with 30mins as max update interval.

However I still see my trv’s falling back to internal temperature sensor occasionally. Here is a snapshot of what is happening:
1st graph is a periodic(5min) read of trv’s external temperature sensor value.
2nd is heating demand.
3rd is actual state of external temperature sensor.

bedroom trv falling back to internal sensor
bedroom trv falling back to internal sensor2341×1149 134 KB

Note that trv is falling back to -8000 value pretty quickly, about 30mins.

I suspect two causes and solutions:

  1. Sometimes zha attr write to trv external temp fails. This can be solved by having ‘tries: X’ argument for zha_toolkit.attr_write.
  2. If the external temp value has not changed then the automation will not write. This can be solved by having ‘write_if_equal: true’ argument for zha_toolkit.attr_write.

I would be glad for any comments.

I am not yet bothered with if the trv is able to achieve and maintain the setpoint temperature since this current problem is a blocker. Next I will try to assess that.

196

@surreallo The danfoss document links are dead. Can you please provide the name of the document?

197

@oguzcanoguz
I think it’s the
Feature Catalogue
Ally™ electronic Radiator Thermostat (eTRV)