Technically, that script is a standalone automation simply triggered every 5 minutes by a clock function, but right, I’m no longer triggering when the temperature changes. Probably a combination of both strategies would be a tiny bit more optimal – i.e., send data when the temperature changes or otherwise at least every 30 minutes to prevent relapsing to use of the TRV’s onboard sensor.
1 Like
Gotcha, I will test it out and report my findings.
Hah, I was too tired to see it was an automation and not a script.
So I have added the automations, and paused the old ones, and their associated scripts. Let’s see how it goes. 
Same. Only one my thermostat works like that. It occurs every 2 days I suppose.
Debugged a bit in z2m and it really don’t answer on z2m commands but sends messages that it’s alive. Also have no clue what to do. Maybe it’s buggy TRVs and better to replace it by the warranty. Not decided yet.
Have you tried to fully reset it and add in z2m again?
@Ramblurr thank you for sharing.
{{ (states("sensor.dining_motion_sensor_temperature") | float * 100) | round(0)}}
This instruction provides me next output:
Failed to call service script/1639522561818. Value 2182.0 for Office Thermostat external measured room sensor is outside valid range 0.0 - 100.0
From my point of view seems Ally converter was changed and now asks for usual temp like 21, 22 and so on.
I’d recommend you to use the method described in post 98. It is confirmed to work by @BikeViking and me.
1 Like
there was a change in Z2M that makes the -8000 value no longer work, there was a change within Herdsman but you won’t see it until the next update.
1 Like
@hello-world are you using zha or zigbee 2 Mqtt? Maybe zigbee2mqtt translates the values internally?
Thank you. Of course I can wait.
I am using zigbee2mqtt. From my point of view zigbee2mqtt supports that value but HA wishes only two-digits temp value.
I have quite strange thing with ota on one Danfoss Ally TRV. Only it says that no updates. How to force this process?
Same question here.
I am starting to get some weird behaviour:
I got 2 radiators in the same room, both following an external sensor, with your suggested automation.
Radiator Covered is set to 1, Load Balancing enabled and adaption_run_control.
Sometimes, I got only 1 of the radiators actually heating, while the other having the valve off. If I bump up the set temperature with a couple of degrees, both of the radiators help.
Maybe you guys called to the vendor? Tried to replace/repair under warranty?
@bjorn.sivertsen My room with 2 radiators is performing OK without any special handling, but I think that’s just by chance. As I wrote above, I think that computing the Load Radiator Room Mean and pushing that number back to the TRVs is likely the way to properly implement it. But, the radiator load isn’t directly exposed in ZHA yet, and apparently there’s no such thing as a zha.get_zigbee_cluster_attribute service even though there’s a zha.set_zigbee_cluster_attribute service!
So, I don’t have an easy way to test that idea. But maybe (for now), you can try manually setting the proper room mean on both TRVs and see if that helps? The problem is that I think the radiator load reported by each TRV changes over the day, so that value may need frequent updating.
@BikingViking Is the pi_heating_demand attribute of the valve not the load of the radiator? Maybe that number averaged over a sensible period for all radiators in the room should be pushed back to both?
As I understand it, the pi_heating_demand corresponds to the % open of the valve, which is not quite the same thing (and is bounded by 0-100). My load estimate right now, for example, is 302.
Also, I just realized that the mean load attribute doesn’t show up in the “manage clusters” in ZHA anyway. But maybe it can still be set in a YAML script, like we do here for sending the extetnal temperature…
@BikingViking where you able to create a group with both thermostat in the room? I am trying on my end (in Z2M) and I am getting an error. The Ally guide does state that radiaors should be grouped together in order to be controlled at once so it should be feasible
edit: so after doing some research this seems to be a hardware limitation. Not sure if we can simulate the group within HA (change settings in one place and affect multiple TRV at once.)
edit2: I have found GitHub - daenny/climate_group: Home Assistant Climate Group which allows to group multiple TRV together but we would need some Ally specific enhancements to share the temperature from a sensor and the average load.
@Charlie-R, indeed I’m using that climate group method to make it easier to set the same temperature for each TRV in the same room. But, I think it doesn’t handle the case where the setpoint is manually adjusted by turning the TRV.
Sending the same external temperature to 2+ TRVs is easy enough with a minor adjustment to the basic script. But as I noted above, to truly replicate the Ally’s group functionality, continuously updating the radiator load mean is probably the last missing piece, but I have no idea how to program it.
Hello guys,
This is my first post here.
I’ve Ally TRV and Ally gateway. Just now I had installed HA on my TrueNas server.
I’d like to buy some usb zigbee connector, and then some “opened window” sensor, and temperature sensor. Would You recommend me some devices to be working with Ally TRV and the module described in this topic?
Thanks in advance
BR
Jacek