Danfoss Ally TRV working with remote temp sensor

Thanks @nslr and @bjorn.sivertsen for the code snippets. And especially @robertalexa for the PR to zigbee2mqtt. I’ve got it working with zigbee2mqtt, here are my snippets:

the script

sequence:
  - service: number.set_value
    target:
      entity_id: number.radiator_livingroom_external_measured_room_sensor
    data:
      value: >-
        {{ (states("sensor.dining_motion_sensor_temperature") | float * 100) |
        round(0)}}
mode: single
alias: 'Radiator Ext Update :: Living Room'
icon: mdi:radiator

the automation

alias: 'Radiator External :: Living Room'
description: Update the LR radiator with temperature readings from the table
trigger:
  - platform: state
    entity_id: sensor.dining_motion_sensor_temperature
condition: []
action:
  - service: script.radiator_livingroom_update_external
  - delay:
      hours: 0
      minutes: 30
      seconds: 0
      milliseconds: 0
mode: single

simple thermostat custom lovelace card

image

Link: nervetattoo/simple-thermostat

type: custom:simple-thermostat
entity: climate.radiator_livingroom
header:
  name: Great Room
label:
  temperature: At Radiator
sensors:
  - name: By Dining
    entity: sensor.dining_motion_sensor_temperature
control: false
2 Likes

Glad it is helping you guys :slight_smile:

1 Like

Slightly offtopic- has anyone encountered issues with Danfoss Ally TRV where it stops responding to commands to change target temperature?

This morning I noticed that my Danfoss TRV failed to change its set (target) temperature (from 19 degrees to 21) as I have a morning automation for that. I have then tried doing that manually through ios app, then from my browser. In all cases after I change target temp it would revert back to the original temperature which is 19 degrees. I then tried:

  1. Fully restart my home assistant machine. Did not help.
  2. Pulled batteries from Danfoss TRV and put them back in. And it worked! It started immediately again responding to home assistand target temp changes.

So it seems that is fixed for now. It seems that the issue was with Danfoss TRV itself and it was somehow hanging or in some other state that I do not understand that prevented it from listening to commands. While not responding to target temperature change commands, it was still successfully sending internal TRV temperature readings to home assistant.

My question to the community is, are there any workarounds for cases like this. Like sending reset commands to the TRV from Home Assistant?

Hi
I actually returned the Ally as I could not get satisfying results. However, it seems zigbee2mqtt now supports external sensor Danfoss 014G2461 control via MQTT | zigbee2mqtt.io - so I am waiting for when they go on sale, to give it a go.

I actually have 2 radiators on opposite ends of the same room, receiving measurements from an external sensor in the middle. Is there any known way to inform the radiators about each other? (I believe the Danfoss Ally software lets you flag which radiators are in the same room, which it would presumably use in their heating algorithm. But maybe I’m giving them too much credit. :grinning_face_with_smiling_eyes:)

As of the latest version of z2m you can use something called load balancing. Have a look at the release notes for more details

1 Like

I was just about to comment the same thing:

### Load_balancing_enable (binary)

Whether or not the thermostat acts as standalone thermostat or shares load with other thermostats in the room. The gateway must update load_room_mean if enabled.. Value can be found in the published state on the `load_balancing_enable` property. To read (`/get`) the value publish a message to topic `zigbee2mqtt/FRIENDLY_NAME/get` with payload `{"load_balancing_enable": ""}`. To write (`/set`) a value publish a message to topic `zigbee2mqtt/FRIENDLY_NAME/set` with payload `{"load_balancing_enable": NEW_VALUE}`. If value equals `true` load_balancing_enable is ON, if `false` OFF.

### [#](https://www.zigbee2mqtt.io/devices/014G2461.html#load-room-mean-numeric) Load_room_mean (numeric)

Mean radiator load for room calculated by gateway for load balancing purposes. Value can be found in the published state on the `load_room_mean` property. To read (`/get`) the value publish a message to topic `zigbee2mqtt/FRIENDLY_NAME/get` with payload `{"load_room_mean": ""}`. To write (`/set`) a value publish a message to topic `zigbee2mqtt/FRIENDLY_NAME/set` with payload `{"load_room_mean": NEW_VALUE}`.

### [#](https://www.zigbee2mqtt.io/devices/014G2461.html#load-estimate-numeric) Load_estimate (numeric)

Load estimate on this radiator. Value can be found in the published state on the `load_estimate` property. To read (`/get`) the value publish a message to topic `zigbee2mqtt/FRIENDLY_NAME/get` with payload `{"load_estimate": ""}`. It's not possible to write (`/set`) this value.

but strangely I have not seen a way to assign values to it in Z2M on the Ally page. Reading the documentation on Ally it sounded more like you were to add both thermostat to a group and then call that group to make sure the same settings were being pushed everywhere.

I wanted to contribute with some of my files. I decided to display the average temperature directly in lovelace, so created a new sensor:

sensor:
  - platform: template
    sensors:
      temp_chambre:
        friendly_name: Temperature Chambre
        unit_of_measurement: °C
        value_template: >-
          {{ ((states('sensor.temp_2_temperature') | float + state_attr('climate.chambre', 'current_temperature') | float ) /2) | round(2) }}

and I hide the other sensors in lovelace:
image

type: custom:simple-thermostat
entity: climate.chambre
header:
  name: Chambre
  faults:
    - entity: sensor.chambre_battery
      icon: mdi:battery-low
hide:
  temperature: true
sensors:
  - name: Temperature
    entity: sensor.temp_chambre
  - name: Humidity
    entity: sensor.temp_2_humidity
control: false

I would probably send Kenny a message on the PR to ask for more details about how this functions:

Hope this helps

thanks. I Updated Z2M and I am now seeing the features!

what would be interesting would be to have someone with the actual Ally gateway give us an idea of how to calculate the shared load so we can use it in a script/automation.

based on the product page:

Device type specific configuration

How to use device type specific configuration

    legacy: Set to false to disable the legacy integration (highly recommended!) (default: true)

I also added legacy: false to my devices.yaml, not sure what it does

edit2: what I find surprising is I get a status of off or idle but yet the valve (pi) keeps increasing so it is still adjusting the heat. I wonder what they really classify as off.

Just curious, have anyone circumvented the average temperature thing, and thereby make the Ally only react on a remote temperature sensor? Or any other TRV?
I find it oddly difficult to achive and refuse to pay an absurd amount for tado and their temperature sensor :stuck_out_tongue:

I have only been running for a couple days in one room as a test but I am questioning this average value thing:
image

for the past day I seem to be tracking the external sensor more closely thant the average (which is always 0.5-1 degree higher than target temperature)

edit: to use another TRV as the external sensor look at my post above, you just need to create a sensor calling the temperature from climate and then use that in the script.

Quick question, why do you want it to follow the onboard sensor at all? It’s pretty much useless as a data source since it’s so close to the radiator.

It’s more that there doesn’t seem to be a way to only link an external sensor

Huh odd. But yeah I remember it as not following the exact avarage, but not leaning that much towards the external.

I meant a TRV that is not the Ally, i.e. of another make had the option to only use external temperature sensors. But nice tip with climate.

Exactly! I have only been able to find people who have manipulated full open/close, or built their own TRV. The Ally seemed so promising as you could send external temperature to it - but not exactly as this thread hints.

Ah I see. Well at least it’s fortunate that it leans most against the external, rather than the average.

Based on somebody’s earlier observation that the Ally appeared to use the simple average of the internal and external sensor, I did some algebra to figure out what value to set to bring the external sensor to the desired target temperature (i.e., effectively cancel out the internal sensor).

EDIT: after a few days running like this, each of my Ally TRVs began overshooting the target room temperature by 1-2°, so I reverted to supplying the raw external temperature reading, which now works fine! The TRVs do in fact appear to “learn” over a few days. The “bad news” below still applies for the time being.

For posterity, here’s what I came up with:
value: '{{ ((2 * (states("sensor.external_temperature") | float) - 1 * (states("sensor.danfoss_temperature") | float) ) * 100) | round(0)}}'

The good news: this seems to do the trick, getting the room to the desired target temperature and keeping it steady once there. (I did experience occasionally that the room overshot the target temperature in my at first, but that might have been a consequence of the external sensors not updating the TRV often enough in my original script, or, optimistically, maybe the TRV “learns” a bit from how the room responds??)

The bad news: the TRV seems content with getting there rather slowly; i.e. if the room needs to be heated from 18° to 20°, that can take 3-5 hours!

This is despite the “Control algorithm scale factor” confirmed to have a value of 1 (the default), which corresponds to the most aggressive setting of “5min(Quick)”, according to Danfoss’s technical document. Maybe there’s still something in the algorithm that prevents the internal temperature from going too high, even in what should be the initial rapid heating phase. Has anybody gotten better performance? If so, any tips?

EDIT:

1 Like

Interesting, so by adding the omboard sensor and weighting it out, you get to that point.

Good work!

To the device to run only from the external room sensor there attribute “Radiator Covered” should be used, this is not in the 01.08 or 01.12 firmware but Danfoss is working on this and should soon be released a new firmware with support of “Radiator Covered”. Stay tuned!

4 Likes