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:
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
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:
Fully restart my home assistant machine. Did not help.
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. )
### 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.
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
I have only been running for a couple days in one room as a test but I am questioning this average value thing:
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.
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.
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?
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!