Danfoss Ally thermostat living its own life

I’ve had a very hard time getting my six Danfoss Ally zigbee thermostatic regulator valves to work, but after adding a lot of zigbee repeaters, and moving my wifi network to a different channel, everything seemed (a lot more) stable. But then today, this happened:

The setpoint had been 17 C all night, and HVACaction was “idle”, because the temperature was just under 22 C. But then at 10:25 the valve suddenly decided to heat the room to 23 C, even though the setpoint was not changed from 17 C. Turning it down to 15 C made it stop.

These are very expensive regulator valves, and I’m getting very close to returning them all and going back to manual values. The other members of my household are quickly losing patience with me and Home Assistant…

EDIT: I don’t have a Danfoss gateway; the valves are integrated directly through ZHA.

The valve is measuring the temperature internally and sometimes a change in winds can mean the air around the valve gets pushed away and it then try to compensate.

If you do not use a Danfoss gateway, then I suggest you make you own control unit and active control the valves based on separate room thermometers.

The valve is measuring the temperature internally

Yes, that is the blue line on the top.

and sometimes a change in winds can mean the air around the valve gets pushed away and it then try to compensate.

But - it can only “try to compensate” if it measures a lower temperature, which we can see on the diagram that it doesn’t. When it turned on, it measured the exact same temperature it had been for the past many hours. So that explanation is insufficient in my opinion.

If you do not use a Danfoss gateway, then I suggest you make you own control unit

My goodness, that sounds complicated! Is that really necessary? In my opinion, it shouldn’t be necessary - that’s the whole point of a thermostat: to keep a constant temperature.

and active control the valves based on separate room thermometers.

In the longer run, I am considering external sensor input, but for now, I would like to just get my thermostats to do what the old, manual ones could.

Actually you can’t.
The values reported to HA is in steps of .5, but internally the steps might be lower.

My goodness, that sounds complicated! Is that really necessary? In my opinion, it shouldn’t be necessary - that’s the whole point of a thermostat: to keep a constant temperature.

And it is. The problem is that the Danfoss TRVs have an internal program to guestimate the settings to keep a stable temperature in the room, but the thermometer placed in the TRV is flawed, due to it close proximity to the heating source. The better option is to have a room thermometer placed centrally and that is the cause if the problem. Danfoss only accept its own devices as a replacement thermometer in its internal programs.

BTW. have you checked that it is not just doing a descaling routine?

I find it quite hard to figure out what might be going on by using ZHA. You are not able to monitor the attributes that could cause that heating. Probably there’s an adaption run going on.

As I told you in another thread on GitHub - you should really give Zigbee2MQTT a try. Then check some attributes: How is the pi_heating_demand (valve opening in %) behaving? Did the adaption run already succeed? If not, try to manually initiate an adaption run.

Also in ZHA the way setpoint commands are set is different (worse) than in Zigbee2MQTT, which might lead to slow valve opening and temperature overshoots. This might give you a start.

1 Like

I am setting up a Danfoss Ally TRV and plan to extend that to all my radiators.

I adjusted the quirk to get events for attributes, and specifically a heating request event. The heating request event will help me to activate or stop my heater.

I created a script using zha-toolkit to configure the TRV:
script_danfoss_ally_configure.yaml

Which I then call in a script that will eventually hold the configuration of all my TRVs so that the configuration is easily repeatable. Currently it is just one TRV, and it supposes that the script on the link above has the entity_id conf_danfoss_ally :

alias: Setup DANFOSS VALVES
sequence:
  - alias: Configure Living Room
    service: script.conf_danfoss_ally
    data:
      device: bd7c22c28205f2770c247f042ec906de
      set_min_temperature: 8
      set_max_temperature: 22
      enable_open_window: true
      view_direction: false
      covered: false
mode: single

I also notify the externally measured temperature to the TRV so that the influence of the wall and radiator on the room temperature is diminished:

Here is an example of the Danfoss TRV local temperature (blue) compared to the room temperature (purple).

The room temperature should be communicated to the TRV every 30 minutes but because of limitations on HA’s end this is not perfect yet (see other forum entry ).
We can see that the TRV leads the “external” temperature. The external temperature has itself an error of about 0.5°C. The setpoint during the night is 17°C, during the day 19°C and evening 20°C.

As far as I understand, the TRV learns how much the impact of the “load” is on the locally measured temperature.

At some point I’ll send the weekly schedule to the TRV itself which allows it to “pre-heat”. So I think this means that I can request to have a certain temperature at 9h and it will start heating some time before that depending on the current temperature, slope, etc.

That is when the “Heating request” will become extra useful so that the heater can be started when needed. HA will then have to perform the “or” function of all heating requests and I will have it control a on/off switch to enable the heater. I’ll be putting that switch in parallel of the output an independent wall thermostat that will serve as a backup.

Regarding the events notified thanks to the updated quirk, I am checking them using the following automation:

description: ""
trigger:
  - platform: event
    event_type: zha_send_event
    id: zha_event_id
  - platform: event
    event_type: zha_event
condition: []
action:
  - service: system_log.write
    data:
      message: "{{ trigger.event }}"
mode: queued
max: 10

Which shows me the heating requests:

2022-11-08 23:57:06.444 ERROR (MainThread) [homeassistant.components.system_log.external] <Event zha_event[L]: device_ieee=, unique_id=:1:0x0201, device_id=bd7c22c28205f2770c247f042ec906de, endpoint_id=1, cluster_id=513, command=attribute_updated, args=attribute_id=16433, attribute_name=heat_supply_request, value=Bool.true, params=>
2022-11-09 00:01:36.711 ERROR (MainThread) [homeassistant.components.system_log.external] <Event zha_event[L]: device_ieee=, unique_id=:1:0x0201, device_id=bd7c22c28205f2770c247f042ec906de, endpoint_id=1, cluster_id=513, command=attribute_updated, args=attribute_id=16433, attribute_name=heat_supply_request, value=Bool.false, params=>

but also updates of the pi_heating_demand for instance.

I did not ficure out yet how to catch the “Heating Request” events I added in the quirk:

According to the documentation, the TRV will try to make some kind of calibration and preferably during the night and the documentation indicates that this can cause sudden heating. The TRV is figuring out the caracteristics of the valve and the radiator to better choose the pi_heating_demand during regulation. This can be disabled or triggered manually (i.e., by writing attributes).