as this is the most active thread regarding the Danfoss Ally I’m going to try my luck here.
I have 3 Popp Zigbee Trv’s which are based on the Danfoss Ally (seems like everything is the same, even the firmware, except of course the logo on the front).
These 3 Trvs are in the same room.
I am controlling them over Z2M with the Sonoff Zigbee USB 3.0 Dongle.
Inspired by this thread I wrote an automation that pushes the value of the external temperature sensor every 30 Minutes to the trv’s. So far so good. The trv’s are all set to “radiator covered” mode.
The problem I am facing is that sometimes one of the trv’s just “decides” to not accept new values anymore. The external temperature attribute is then set to -8000 and the automation can’t change the value. Neither can I manually change this value. If this happens then I also can’t change any other value of the trv, not even the temperature. This only works by manually turning the trv to the wanted temperature.
I know what you’re thinking: the trv’s must be close to out of reach but this isn’t the issue.
The trv’s are placed in the room next to the Home Assistant Raspberry and even report values to Home Assistant but, as I said, I can’t change any values!
After I remove the batteries from the trv and reinsert them the trv responds again. Then I can also change the values again.
This behaviour happens about once per week but because I have three trv’s it is very annoying to always having to “fix” one of them.
Does anyone have a clue what’s happening? Am I missing something obvious here?
Edit: It just occurred to me that you can check if the problem is related to the above issue. When the thermostat stops responding to external temperature you should try to change the set point and see if it changes on the thermostat. If it does not change then it is unrelated to external temperature and more related to the z2m issue above.
In covered mode you should send the temperature every 5 minutes - when nothing is received after 30 minutes, the covered mode reverts to the local temperature.
Also make sure that you FW is up to date.
I am no using Z2M and I can’t say if there is any issue with that.
I have a Sonoff Zigbee USB 3.0 Dongle controlling three Danfoss Ally TRV’s over Z2M. I experienced the same problems you have described. One or more TRV became unresponsive through HA or directly through Z2M. Viewing the TRV’s on the ‘Map’ showed the unresponsive TRV was always directly connected to the coordinator. The TRV’s that remained responsive were connected through a router. Adding an additional router (Ikea - Tradfri) to prevent any of the TRV’s connecting directly through the coordinator solved the problem for me. My TRV’s have been rock solid every since. I can only assume the combination of the Sonoff dongle, Z2M and the Danfoss TRV’s invokes a software bug somewhere.
Thank you so much! That’s what did the trick for me.
I actually noticed that the trv that wasn’t directly connected to the coordinator didn’t have any problems but I didn’t jump to the conclusion that that was the workaround.
I am disappointed with the remote sensing regulation of the Danfoss Ally TRV. Today is very disappointing.
While the setpoint is 18.5°C the actual remote temperature is now 16.9°C. Temperatures dropped about 10°C which could explain that the valve is somewhat puzzled, but it should recover from that and not have the valve open at only 22%.
It was on the spot at 11:30 PM. I checked that the configuration of the TRV is correct and also that it has the correct remote sensing temperature.
This is the short term history.
Over a longer period we can see that it is more or less regulating “good enough”, but it can’t really cope with the changing offset between the temperature measured by the TRV (top curve) and the remote sensor (bottom curve).
The valve is placed at the bottom of this vertical radiator on a wall that faces a wall of my neighbours house and the temperature is sensed at about 2 meters close on a wall that faces the outside.
Note: I am now changing this valve to the “covered” configuration (and send the temperature every 5 minutes) to check how that behaves.
So on Jan 16, I changed to covered mode with remote temperature (from uncovered mode with remote temperature).
The regulation is more acceptable - it can still deviate +/- 0.5°C from the setpoint, but this is less than before - I lowered the setpoint by 0.5°C
The big dip on Jan 18th is related to me opening all the windows.
There’s about 5 hours from tip to tip or dip to dip and it does not coincide with when we’re cooking in the kitchen.
Update: still oscillating around the setpoint - peak-to-peak there is about 8 to 10 hours. Which is better than before where that easily reached 24 hours and whre the extremes were further and longer from the setoint.
have you tried setting algorithm_scale_factor to something higher to see if it smoothes out the occilations? personally I’m still not sure how that setting affects the TRV…
I do not really want to play with these settings.
The documentation says:
Range 1-10 (lower 4 bit allocated to scale factor)
Scale factor of setpoint filter timeconstant (“aggressiveness” of control algorithm) 1=5min(Quick) … 5=30min(Moderate) … 10=80min(Slow)
Bit4=Quick open feature disable.
1=disable. 0=enable
The default is 1, so quick regulation (5 min) and quick open feature enabled.
With regards to that, in practice I do not have the impression that it’s a fast regulation. Making it slower might make things worse.
However, I’ld need to check my old notes on regulation - I think the issue is related to the delay between the change in control and the effect on the measured temperature. I do not remember what the counter mesure for that was - maybe making things slower. However, I’ld expect the valve to kind of manage that because it has “Adaptation control” and the covered bit is set.
Anyway, using covered mode is better for several rooms in my house.
yup, I read the documentation but it’s not clear to me what the effect is… one would indeed think that it’s the delay between valve adjustment (pi_heating) and the effect of the measured temperature but the description “Scale factor of setpoint filter timeconstant” is clear as mud
Given the wording “aggressiveness”, this seems related to the “integration” filter that smoothes out the reaction of the control vs. a change in input. The bigger the integration time constant, the slower the reaction.
However, the higher level documentation indicates that there is only one functionnal level. Which when interpreted literally means there is only one behavior. I suppose that the author meant to say that the aggressive control is either on or off and that settings 1 to 5 are the same, and 6 to 10 also. See this PDF:
I’m thinking the danfoss hub must do some calculations and adjustments and not everything is contained in the TRV itself… I have a hub but have no idea if it’s possible to monitor it’s behaviour
[edit, btw, thanks for that document, it’s alot more informative than just the api doc!!! ]
Something I don’t see widely circulated, but is evident from a couple of Blueprints out there (and my own testing).
You have to multiply the inbound value for external_measured_room_sensor by x100
Therefore, 20c needs to be sent as 2000 etc.
My 20 valves (all set to radiator covered = true) started working perfectly after this. Beforehand, they did not stop heating and the only way to get them to calm down was to set radiator covered back to false.
Thor, bjorn. or someone else please tell me how to implement Thor script and automations if I have more than one Danfoss Ally TRV? In living room I have a Danfoss Ally room sensor and two Danfoss Ally TRV. I would like both heads to read the current temperature indicated by the sensor
Sharing some expérience (again) - the regulation is not very satisfactory with my big/old cast iron radiators. If you ignore the glitch of the orange filling in the graph below (of which the variable edge <>21°C is the temperature fed back to the valve), we can see that there is a considerable delay in the adjustement of the valve opening.
That results in over- and underheating which requires me to cover/uncover myself…
You need to setup an automation for each radiator.and the script presented above would better be adapted to use “fields” that you can use as a parameter.
Personnaly, I use my automation blueprint which proposes fields(parameters), which is reused for every TRVI have.
Note that when you have two TRVs in the same room, you better also update the load balancing which implies that you ensure you get the load of both TRVs, average them and send that back to both TRVs.
There is at least one discussion on this forum,
And you can read more details in this documentation:
I have the following script and automation, but the head heats up until it reaches the set temperature and then turns off even though the temperature on the sensor is a few degrees lower
Script
‘1700560558754’ :
alias: Big room sensor temperature
sequence:
And to redo all my cnofigurations, I call that script in another script that configures all my valves so that i ccan repeat or update the configuration easily (only showing two configurations in my script):
As you sensor does not have a known temperature, no temperature update should be sent to the TRV. That allows the TRV to fallback to its internal sensor (after 3 hours). Setting (=sending) a default temperature would result in an undesired outcome.
Normally this should occur only after a HA restart and disappear once temperatures are received.
The presense of this error message helps remind you that you may have an issue with the sensors or the configuration thereof.
To avoid the error, the script needs to be extended with a test that verifies that the temperature is valid (the zigbee sensor value is set and <> 0x8000, so for that purpose the sensor value default can be signed 16 bit hex 0x8000 or -16384). And when the temperature is invalid nothing should be sent to the sensor.
Possibly even log an error message every hour if this situation lasts for more than one hour.
In the script that I propose, I did not put the effort to avoid the error because:
It is not essential when the sensor is reporting temperatures;
I am quite busy so because of 1., this is not a priority in my schedule…
