Good to know, I’m considering moving to Z2M so it it’s helpful to know they do it like that.
From what I read you cannot bind the external sensor directly as it would hit the battery of the Ally too much so the bridge will need to push the information in the same way as we currently do.
Currently we make it set a temperature which is the average between the onboard and the externally measured temperature.
On paper, they should allow it to only adhere to the external temperature. As it they have acknowledged that for instance, the valve might not be in the same room as the radiator.
Check the post by @randomuser above
By the way, it took a few hours, but all the TRVs have updated themselves to the newest version.
were you able to find a change log?
I was thinking we should also reorg the various sensors to fall within the new 2021.10 categories, but not quite sure how to tackle that.
It’s reportingly a feature for people who use the gateway, so we just need to figure out how to do the same interaction without the gateway. I’ll ask if anyone has been making any progress in the Danish HA Facebook group, as they have a lot of Danfoss users, who don’t frequent this thread.
OK, my initial impression from last night’s TRV behavior under the new firmware is encouraging! Some notes – I’m using ZHA:
- I set the “radiator_[c]overed” flag for all of my TRVs:
Manage clusters → DanfossThermostatCluster → radiator_[c]overed → set value to 1
(Note that ZHA’s “get” function returns bool.true or bool.false, but bool.true doesn’t stick when using the “set” function. Just use 1.)
BTW, all of my radiators are actually covered
- I got the impression that many (all?) previous settings on the TRVs were wiped by the OTA update and returned to the defaults. Under that hypothesis, plus the likelihood that the external temperature reading is taken into account differently now, I thought it’d be a good idea to activate the “Adaptation run”:
Manage clusters → DanfossThermostatCluster → adaptation_run_control → set value to 1 - 1 room has 2 radiators, so I thought it would make sense to leave load balancing enabled (the default) for that room, but disable it for my 3 other rooms that only have a single radiator.
Results:
- the room with 2 radiators (with load balancing enabled) maintained the lower overnight temperature well, and warmed up much more quickly to the desired setpoint in the morning! Assuming this remains consistent, I’d say this is “perfect” behavior for me.
- However, the other rooms didn’t behave very differently from the previous firmware – they were in no hurry to warm up the rooms to the morning setpoint, and the overnight temperature was ~0.5-1°C lower than the overnight setpoint. I suspected that disabling load balancing may have had something to do with that, so I re-enabled it in the morning, and re-ran the adaptation run for good measure, and it seemed to do the trick and get the radiators warming up more quickly. - UPDATE: all TRVs now behave well after changing my script to send the external temperature to each Ally every 5 minutes, instead of whenever there’s a temperature change. I reverted to disabling load balancing for my rooms with a single radiator, and they still work well.
Major question:
I’m even more confused about how the “load balancing” feature works now. I have noticed that the load_estimate_radiator value reported in the thermostat cluster seems to change over time, but is something that the TRVs calculate on their own (as it’s not a writable value), and I don’t see any mechanism for it to include any data from the other TRVs. So, I don’t see any way to tell the TRVs whether or not there are other radiators in the room…
1 Like
Quick question, have you touched this value?
In addition, are you still using the following for external sensors?
Automation
- id: '1612470219880'
alias: TEM04 - Update External Temp - Bedroom
description: ''
trigger:
- platform: state
entity_id: sensor.bedroom_air_temperature
condition: []
action:
- service: script.bedroom_temp_follow
data: {}
mode: queued
max: 10
Script:
bedroom_temp_follow:
alias: Bedroom Temp Follow
sequence:
- service: zha.set_zigbee_cluster_attribute
data:
ieee: 84:2e:14:ff:fe:60:9c:05
endpoint_id: 1
cluster_id: 513
attribute: 16405
cluster_type: in
value: '{{ (states("sensor.bedroom_air_temperature") | float * 100) | round(0)}}'
mode: single
That value is precisely what your temperature sensor script sets. 
The ID in hex 0x4015 = 16405 in decimal.
1 Like
Yes, I’m still using a similar script and automation.
1 Like
Beautiful! And finally I have one stubborn TRV that doesn’t want to pull the new firmware. I suppose I force it through the same interface. Can you tell how, exactly?
with Z2M I am not seeing any new settings, maybe I need to wait for an update.
And finally I have one stubborn TRV that doesn’t want to pull the new firmware. I suppose I force it through the same interface. Can you tell how, exactly?
All of mine pulled the firmware just fine. I read that e.g. Ikea and Hue devices can be encouraged to pull a firmware update, through the cluster OTA → cluster command: image_notify, so maybe that would also work for the Ally.
I’m not aware of any new settings per se, but the radiator_covered setting was previously not connected to any actual functionality, and now should give better results when supplying an external temperature measurement.
i have updated my thermostat via ssh - and all went fine, but HA still show old firmware version 1.08
how do I change it ?
i use deconz
Go to Configuration → Integrations and in the context menu (3 dots) on the deCONZ tile select Reload.
thanks, but it dont work - I think I have to do it in ex. vnc viewer, but dont know where.
Danfoss updated their cluster specification, which provided an important new clue as to how to handle the external temperature data when the new radiator covered feature is enabled:
0x4016 [radiator covered] TRUE: At least every 30 minutes but not more often than every 5minutes @ every 0,1K change for covered radiators (after 35 minutes the function is disabled and goes back to standard mode) The value -8000 disables the function
In my case, when the room’s temperature stabilizes, the external temperature sensors may not push an update for >35 minutes since there’s no temperature change to report. This apparently ends up disabling the use of the external sensor! Then the internal sensor (likely rather warm) prevents the valve from opening until the temperature in the room drops substantially.
I instead now simply push the external temperature reading every 5 minutes with the following script automation. While this may impact battery life slightly, I figure it can’t be so terrible given that the TRVs are reporting their data quite frequently anyway, so what’s another few bits of data transmission?
alias: External Temperature Bedroom
description: ''
trigger:
- platform: time_pattern
minutes: /5
condition: []
action:
- service: zha.set_zigbee_cluster_attribute
data:
ieee: [redacted]
endpoint_id: 1
cluster_id: 513
attribute: 16405
cluster_type: in
value: '{{ (states("sensor.bedroom_temperature") | float * 100) | round(0)}}'
mode: single
I’m pretty happy with the performance in all of my rooms now! They now heat up to the desired setpoint within a reasonable time and maintain it well.
1 Like
As far as load balancing when there’s 2+ radiators in the same room, it seems that the way to do it would be to read the “load_estimate_radiator” cluster attribute from each of the TRVs in a particular room, compute the mean, and then push it back to each TRVs’ “Load Radiator Room Mean” cluster attribute. I don’t have enough experience to script up that sequence without doing a lot of research, but seems that it would make sense to push the load mean along with the temperature updates. (I get the impression that the load estimate changes about as quickly as the room temperature, but ZHA doesn’t preserve the attribute history out of the box, so I can’t fully confirm that.)
Interesting progress! So no automation anymore, simply that script for each TRV?