Danfoss Ally TRV working with remote temp sensor

[tproulund]

Hi Guys

Recently got an ally and got it integrated in z2m and running in covered mode with external temp sensor. This ally is on the kitchen radiator and the thing is, the radiator is really poorly placed. it is basically behind the counters with a open port over it.
When the room load is more or less constant the ally is able to track the temperature setpoint pretty but it over/undershoots quite a lot and you can also see on the valve opening (picture)

what are you guys experience with the Adaptation run control, as I understand it, the ally will try to “learn” the room and thereby better know how to control the temperature

I’ve seen in other comments that in ZHA people have enabled Adaptation run control by sending commands to the zigbee cluster ID, is there an equivalent way to do this in z2m and do you guys believe it will help ?

Control algorithm scale factor = 5

Control algorithm scale factor = 3

temp response with scale factor = 3 and setpoint = 21

[jjrytko (Jari Rytkönen)]

+1 I’m also very interested of this card

[jjrytko (Jari Rytkönen)]

If anyone else has an example how to create a sensor for Danfoss Ally valve state (pi_heating_demand I guess) I would be interested

[jjrytko (Jari Rytkönen)]

I was able to figure out myself how to get Danfoss Ally valve state by reading the PIHeatingDemand attribute periodically. I have updated the firmware of my Allys to version 1.18, haven’t tested this on earlier firmware versions. Here’s how I did it, hopefully someone else might find this useful:

First I installed zha-toolkit custom component: GitHub - mdeweerd/zha-toolkit: 🧰 Zigbee Home Assistant Toolkit - service for "rare" Zigbee operations using ZHA on Home Assistant. This custom components allows (among other things) one to read Zigbee cluster attribute and write it to a state of a sensor: GitHub - mdeweerd/zha-toolkit: 🧰 Zigbee Home Assistant Toolkit - service for "rare" Zigbee operations using ZHA on Home Assistant.

So as first step I created an automation that reads the PIHeatingDemand of my Danfoss Ally TRVs to sensors. Below is an example that creates a sensor called sensor.office_radiator_thermostat_valve_raw and writes PIHeatingDemand to it every 5 minutes

id: read_thermostat_values_to_sensors
alias: Read additional thermostat values and store them to sensors
trigger:
 - platform: time_pattern
   minutes: /5
condition: []
action:
 # Office radiator valve state
 - service: zha_toolkit.execute
   data:
     command: attr_read
     ieee: paste_your_trv_ieee_here
     endpoint: 1
     cluster: 0x0201
     attribute: 0x0008
     state_id: sensor.office_radiator_thermostat_valve_raw
     allow_create: True

Then I created a template sensor that follows the raw value and has a proper measurement unit and an icon set (I tried first customization for the raw sensor, but that didn’t work for some reason):

sensor:
  - name: "Office radiator thermostat valve"
    unique_id: office_thermostat_valve_wrapper
    unit_of_measurement: "%"
    icon: mdi:valve
    state: >
      {{ states('sensor.office_radiator_thermostat_valve_raw') | int(0) }}

This is jut one example how to create sensors from Ally TRV attributes. You can easily follow pretty much any attribute just by changing the cluster and attribute values of zha_toolkit.execute service call.

[le_top]

Happy to see that this feature is used !

I think there is no need to create a separate sensor if no value conversion or default value is needed.
The sensor state can be updated directly from the zha_toolkit.

Also note that instead of the IEEE address you can provide the entity name, and if there’s only one cluster of type 0x0201 in the device you can even omit the endpoint (but when setting it, zha_toolkit does not have to spend time and energy on finding these values).

[tuplas]

I just added a template sensor with:

- platform: template
  sensors:
    livingroom_heating:
      friendly_name: "Olohuone termostaatti ohjaus"
      unit_of_measurement: '%'
      value_template: "{{ state_attr('climate.danfoss_etrv0100_274b5ffe_thermostat', 'pi_heating_demand')}}"

Didn’t need the ZHA-toolkit

[jjrytko (Jari Rytkönen)]

Interesting, I didn’t know that Zigbee cluster attributes are available as state attributes of the Ally thermostat entity. How often do the attributes update? If the update interval is acceptable this looks like a very elegant way to get the valve state

[tuplas]

The fastest seems to be about every 7-10min.

[le_top]

And you could configure that using zha-toolkit/conf_report !

[Taner (Mariusz)]

+1 If possible I would also ask for instructions on how to do it.
Thank you in advance.

[napalm]

Hi all, first post in this community.

I’ve recently bought these TRVs and installed Home Assistant, still learning home assistant concepts etc. This thread (and a few others) has great amount of info to learn from regarding these TRVs, appreciate the discussions here.

I noticed there is a relatively recent “Programming Guide” document (June 08, 2022) on the official Danfoss support site. Not sure if it was unavailable before, or if it is just a new version, but it has a wealth of information about this product and actually explains some of the odd features that have been discussed here. I’ll outline the main points here, but I encourage everyone to go to the official support site and read it themselves: Danfoss Ally™ support | Danfoss

External Temperature Sensor
There were some guesses in this thread of how the behavior of this TRV is when using an external sensor, specifically in (default) uncovered mode. The guide explains that the eTRV actually still uses it’s internal temperature sensor for operation, but the reported external room temperature is used to set a temperature offset between the internally measured and actual room temperature, and is not measuring by an average between them. This explains why the initial guidelines in this mode were to report this value once every few hours, but not more often than 30 minutes - the offset should not change so often, and should be relatively constant with normal operation. I would imagine this would also save battery life due to less frequent communication. Additionally, it explains that the max offset is ±4 degrees, which also explains why some failed to see big differences in operation, even after putting the external sensor outside.
For covered mode it acts as was already discussed here - the internal measurement is ignored, and that is also why this mode requires more frequent communication.

Alternatively, it seems one could just set a raw offset value.

Load Balancing
They explain how the room load balancing is supposed to work:

The gateway calculates an average of the load for all the
radiators in the room and distributes it to all the eTRVs in the
room via the attribute 0x4040 ”Load Radiator Room Mean”
every 15 minutes.
The Gateway must discard all the values below -500 (too
low) down to -8000 (invalid/inactive) and values older than
90 minutes. The average must then be calculated with the
values from the other eTRVs in the room.

Sending the -8000 value will actually deactivate the feature

Another interesting thing I noticed - there is a manufacturer specific command which can be used to set the heating temperature with different behaviors. The standard approach of just setting the setpoint (which I assume is what happens by default) will, as I understand, gradually change the behavior. However, there is also a “user interaction” setpoint change, which is equivalent to the user physically turning the TRV knob, and will do an aggressive adjustment to arrive at the requested temperature as soon as possible.

During a User Interaction (setpoint change by turning the dial or setpoint change via ”SetpointCommand + UI=1”)
the motor jumps to a much different position regardless of limitations for battery saving and energy
efficiency.
NOTE: The aggressive command (type 1) must not be used all the time for schedule changes!!! If done, it
could reduce comfort, energy efficiency and battery lifetime!

It seems the main intended use case is to pick up when the dial was turned on one TRV, and then this command can be sent to other TRVs in the room, to force them also to do an “aggressive” adjustment, or use it when a user changes the temperature in dashboard.

The document also has nice pictures and operation/communication examples, and also describes other features like display orientation, installation orientation, eTRV internal schedules etc.

I’m still just starting out with Home Assistant, so many home-assistant / zigbee details are a bit over my head for now, but so far most or all of these features seem relatively straightforward to implement.

[bjorn.sivertsen]

Interesting stuff! Thank you for the deep dive!

[napalm]

I tried my hand at creating an automation blueprint for updating the external temperature for this TRV. This automation is meant to respect the Danfoss recommended intervals (at least every X, but not more often than Y), though these values have to be configured manually.

It uses the external sensor state change as the primary trigger, and additionally uses a timer to refresh the temperature after the required period, even if the temperature sensor did not change during this time. You have to manually create a timer for each TRV and set the timer interval accordingly - for uncovered mode it should be “at least every 3 hours” (I use 2h30m), and for covered it should be “at least every 30 minutes” because the covered mode will switch off if no reading is received for 35 minutes. I think it is safe to use max values for each timer as it is only a fallback. You should create a new timer for each TRV as it will be reset on each automation activation, so reusing one timer might cause some of the TRVs to go without a reading for a longer time (though technically I think it should be OK to reuse timer if you also use the same source temperature sensor, but I’d still create unique ones to be sure)

For the “Minimum update interval” input you should again use corresponding value depending on if the TRV is in covered or uncovered mode. By Danfoss documentation it should be 30 min for uncovered and 5min for covered.

Here is the blueprint you can put in your /config/blueprints/automation/ or a subdirectory within.

blueprint:
  domain: automation
  name: Ally Temp Update
  description: Update Danfoss Ally TRV external temperature with min/max refresh rate
  input:
    ally_device:
      name: Ally TRV Device
      description: Temperature reading will be sent to this device
      selector:
        device:
          manufacturer: Danfoss
          entity:
            domain: climate
    min_update_minutes:
      name: Minimum update interval
      description: >
        Updates will not be sent if time from last update is less than minimum interval.
        Normally 30min for uncovered, 5min for covered.
      selector:
        number:
          max: 360
          min: 1
          unit_of_measurement: minutes
          mode: box
    temp_sensor_id:
      name: Temperature Sensor
      description: External sensor from which the temperature will be read. Expects data format 12.3
      selector:
        entity:
          domain: sensor
          device_class: temperature
    max_update_timer_id:
      name: Timer entity
      description: >
        Timer that will be (re)started on update.
        Set this timer to slowest interval you want the device to update at.
        Normally 3h for uncovered, 30m for covered.
        Use separate timer for each automation.
      selector:
        entity:
          domain: timer

variables:
  device: !input ally_device
  ieee: "{{(device_attr(device, 'identifiers')|list)[0][1]}}"
  min_update_minutes: !input min_update_minutes
  temp_sensor_id: !input temp_sensor_id
trigger:
- platform: state
  entity_id:
  - !input temp_sensor_id
- platform: event
  event_type: timer.finished
  event_data:
    entity_id: !input max_update_timer_id
condition:
- condition: template
  value_template: >
    {{ as_timestamp(now()) - as_timestamp(state_attr(this.entity_id,'last_triggered'),0)|int
    > (60 * min_update_minutes) }}
action:
- service: zha.set_zigbee_cluster_attribute
  data:
    ieee: '{{ ieee }}'
    endpoint_id: 1
    cluster_id: 513
    cluster_type: in
    attribute: 16405
    value: '{{ (states(temp_sensor_id) | float * 100) | round(0)}}'
- service: timer.start
  target:
    entity_id: !input max_update_timer_id
mode: single

I only tested it briefly so there could be some bugs, but I think it works. Do let me know if someone else tries this if it works for you or not.

edit: had to add default timestamp value, otherwise would fail to run the first time

[micha_og (Michael)]

Hey, nice work, thank you!

Did just install the blueprint and it did not throw an error. Seems like its working, but I don’t know how to test if it really works.
My Card says the thermostat is heating although the temperature is way higher than heating trigger?

Also the temperature the card shows is not the temperature of the external sensor
Which is about 22,7 °C.
As I understood, the external sensor temperature is used to control the heating of the thermostat.

Do you have a hint, where exactly I can see, if this is the case?

Kind regards,
Michael

[napalm]

Yes, the default card will always show the temperature reading from the TRV itself. You can check if the attribute was sent to the TRV by going to the device in settings, and selecting “Manage Clusters” on the device info 3-dot menu. There you should select the correct cluster and attribute (see below) and click “get zigbee attribute”:

The value should be your last sent external sensor reading (i.e. 2270). Worth remembering that the behavior depends on whether your TRV is in “uncovered” (default) mode, or “covered” mode. In uncovered, it calculates an offset from the external reading, but still actually uses the internal sensor. The offset is calculated automatically and limited to ±4 degrees. Whereas in covered mode the internal sensor is ignored, so the external measurement updates are required more often.
At least that’s what Danfoss documentation says.

Judging by other people experiences in this and other threads, it can take a few days for the TRV to “learn” the heating response of the radiator, but it tends to behave well after that. I’m not sure about the state “heating” - we are still not in heating season, so I am just testing my TRVs without actual heating operation, but I also have noticed them being in “heating” mode even if the temperature is higher than the setpoint. I’m not sure how reliable that indicator is.

You can also check the attribute “pi_heating_demand” of the TRV climate entity, which should correspond with the actual open/closed level of the valve. If the measured temperature is higher than setpoint, it should slowly lower.

One last thing to note - I think by default, setting the setpoint through HA or from TRV handle, will initiate the setpoint change command with “user action” command, which will make the TRV to update the setpoint very aggressively, and it can overshoot the target temp. Also something to keep in mind, if you did recently change the setpoint.

[micha_og (Michael)]

Hi Napalm,

all clear and everthing you mentioned is as it should be.
The value is indeed the same as the external temperature sensor, also the mode is uncovered, so the value for heating should be calculated with the offset. I am really curious how this works as soon as heating season begins. If it is not I might switch to covered mode.

pi_heating_demand is currently always on 1 which i assume means 1% opened. Which also then leads to the question if this might be the “anti freezing” heating.
But I have no clue why this started yesterday.

One last thing to note - I think by default, setting the setpoint through HA or from TRV handle, will initiate the setpoint change command with “user action” command, which will make the TRV to update the setpoint very aggressively, and it can overshoot the target temp. Also something to keep in mind, if you did recently change the setpoint.

Do you mean it then might take some time to learn again which the correct target temp?

Regards,
Michael

[napalm]

@micha_og

pi_heating_demand is currently always on 1 which i assume means 1% opened. Which also then leads to the question if this might be the “anti freezing” heating.
But I have no clue why this started yesterday.

For me all TRVs are currently on pi_heating_demand 0. Heating season has not begun here either, but I did see different values as well before when I was playing around.
Once heating season starts, I think it is worth manually initating the adaptation run by sending 1 to attribute 0x404C. But I think I will put it in mounting mode and back again before doing that, as documentation states it will not run if valve characteristics is already found (no idea if automatic run already did anything while heating was off).

@micha_og

Do you mean it then might take some time to learn again which the correct target temp?

No, it should not impact learning. What I meant was that the “aggressive” manual control might overshoot when actual heating is being done - for example, your room temperature and setpoint is at 18, you feel cold so you turn the dial or set from HA target temp to 22. The TRV reacts immediately and tries to get to 22 as fast as possible, bypassing the gradual “learned” response, but since there is a delay until the room heats, it might easily overshoot to, for example, 25, and take time to cool down again. But I don’t think it impacts learning itself, so it should still end up following the external temp sensor, as long as that value is sent to it regularly.

But since I see now you are also not in heating season yet, I don’t think that is the case.

[DaPe]

Hi everybody,

As many I’m preparing for winter and so checking that everything works fine.

I’m wondering about a functionality that I have not been using last year : Heat Available (attribute 0x4030). The documentation says " by default the heat is considered on if the gateway does not send any info about that".
The thing is that my boiler is not always on and I start to think that this could mess with PID

So, my question is : am I wrong not using it since the beginning? Is anybody using it to declare that the boiler is on ?

Thanks for your answers!

[le_top]

@micha_og

1% opened. Which also then leads to the question if this might be the “anti freezing” heating.

When the valve is “1%” open, there generally is no water flow. Depending on the valve water flow could easily start only at 30% and more.

[le_top]

@nslr

so the “k” is probably “1000s”, not “kelvin”

No K can be read as Kelvin, and I think it stems from the fact that a valve needs to have a 2K range regulation according to EN215 standard.