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.
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.
Thanks for sharing.
I modified the script to avoid the external timer.
The technique is to add an internal delay and the restart mode.
So either the delay expires and the temperature is sent again, or a temperature is received and then the automation restarts.
I also added a temperature offset.
And I converted it to zha-toolkit, which is not necessary, but then I can add it as an example there.
Maybe the automation should not send the temperature after 150 minutes or more, because that is more a failsafe. By sending an old temperature, the TRV might suppose it is too cold, while in reality it is too hot.
So I’ll likely remove the long delay.
You may update the original blueprint if you like to avoid relying on zha-toolkit.
I have been pondering about this and might add an automation to turn HEAT to off when the boiler is off as well.
Any suggestions if I should go with Radiator Covered or Uncovered mode? My radiators are NOT covered, but I understood if setting the TRV to Radiator Covered, it will rely only on the external remote temp sensor. Or do you guys have a better experience with the built-in “learning” algorithm, which relies on both sensors?
Here is about two weeks worth of uncovered remote temperature setting - and I think there is an issue since Nov 15 at about 13:00 because the temperature then suddenly drops.
The remote temperature is in magenta/purple - it’s temperature is offset by 0.5°C to the real temperature so I send it corrected by 0.5°C to the valve.
Orange is the setpoint and blue is the temperature measured by the valve.
The peak on Nov 11 is when the valve was removed for a short while to see if another radiator was mounted correctly - so that is body heat. Also at that time, the “boiler” wass off.
These last 3 days, when the remote temperature repoting is apparently dysfunctionnal.
I find it very hard to claim that with the remove temperature sensor it does a very good job, but when regulating the local temperature it is pretty much perfect.
Edit: the remote temperature update was not working because I cleaned up my automations and I deleted the working ones - recreating the automating from the blueprint makes it work again.
I’ll probably be turning my boiler on or of depending on whether or not at least one TRV is requesting heat.
I updated the remote temperature automation so that when the 30 minutes have passed, the temperature sensor value is incremented with 0.001 °C.
That way, when the sensor value is reported again, HA will see that as a change, and therefore trigger the automation.
The increase by 0.001°C does not trigger the automation itself as it is running at that time and it is in the “single” mode.
‘zha_toolkit.ha_set_state’ was just added to zha_toolkit, so that makes zha_toolkit a requirement with this method.
EDIT: I checked my logs and a temperature is sent to the TRV about every 30 minutes (no earlier than 30 minutes and generally less than 33 minutes).
Hello guys,
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?
Quite a lot of people are having problems with ally thermostats becoming unresponsive in z2m. See https://github.com/Koenkk/zigbee2mqtt/issues/13478
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.
1 Like
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.
1 Like
Hi Loui,
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.
Hope this helps
1 Like
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.
EDIT:
Covered mode is more satisfactory ad the last few days suggest. The regulation is closer to the setpoint:
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!!! ]