I installed 2 Danfoss Ally TRVs and connected then via Zigbee2MQTT, I try to use them with Better Thermostat with external sensor. The problem is that every time I set temp to 19C example and start Heat, it automatically switched off after 2-3 minutes, while temperature is still 17C (See the logs screenshot). I also have the same ingratiation for Aqara TRV and it works fine.
Did somebody face the same problem?
I think Danfoss Ally can only run in target mode with Better Thermostat, so you can not adjust the temperature on the thermostat, neither on the thermostat itself or by commands over the network.
Thanks for the answer, but what does “target mode” mean and why is it a problem in case of Danfoss TRV and not a problem in case of Aqara TRV?
From the logs I see this entry when switch on heating:
Received MQTT message on 'zigbee2mqtt/Bedroom TRV/set/occupied_heating_setpoint' with data '20.5'
And this entry when it is switching off by itself:
Received MQTT message on 'zigbee2mqtt/Bedroom TRV/set/occupied_heating_setpoint' with data '5.0'
I’ve had this thermostat for 3 seasons now and it works very well but I’ve never wanted to work with Better Thermostat. I think it works a lot better with the external sensor without any additional interference. All the more so because it learns over a period of time the temperature reaction to the opening of the valve. It does this quite slowly and gently, unlike the Aqara thermostat. Anyway, I think that aqara has its own very good algorithm.
I also like how the Danfoss Ally looks like in comparison with Aqara, plastic harder, assembling is better and safer from the children point of view. Could you please share with me, how do you use it with HA but without Better Thermostat?
The controls depend on your imagination really. To send the temperature from the external sensor, I used a ready-made automation based on the blueprint
ZHA, Zigbee2MQTT - Danfoss Ally send external temperature to TRV - Blueprints Exchange - Home Assistant Community (home-assistant.io)
If the temperature from the sensor is being sent, check the entities number.
0x50325ffffe57226_external_measured_room_sensor.
The rest are automations, which can be very extensive. There’s a lot in the above thread. In the screenshots, an example of the control panel of my thermostat where the head switches to the appropriate temperatures depending on the time, the open window or whether someone is at home.
I disabled sync with external temp sensor just for simplicity, and integrated it into the general thermostat. But the issue persists, I switch it on, in a minute it automatically switching off 
“Heat required” is turned off, which means that the set point is well below the target temperature. I think a load estimate of 48 is quite low in itself already.
You could read back the target temperature, local temperature and remote temperatures to see how they compare.
You probably have the local temperature and setpoint values in the short-term history - however the remote temperature sent to the thermostat is not something recorded in HA.
Possibly the temperature unit is wrong: the zigbee temperature attribute itself is in hundreths of a degrée - if the setpoint sent is 19.00, it could be rounded downto 19 while it should send 1900.
Here is what I see in the logs when I set 20 degrees.
Received MQTT message on 'zigbee2mqtt/Living room TRV/set/occupied_heating_setpoint' with data '20.0'Received Zigbee message from 'Living room TRV', type 'attributeReport', cluster 'hvacThermostat', data '{"occupiedHeatingSetpoint":2000,"setpointChangeSource":2}' from endpoint 1 with groupID nullMQTT publish: topic 'zigbee2mqtt/Living room TRV', payload:after few minutes and few log entries
Received MQTT message on 'zigbee2mqtt/Living room TRV/set/occupied_heating_setpoint' with data '5.0'
Received Zigbee message from 'Living room TRV', type 'attributeReport', cluster 'hvacThermostat', data '{"occupiedHeatingSetpoint":500,"setpointChangeSource":2}' from endpoint 1 with groupID nullMQTT publish: topic 'zigbee2mqtt/Living room TRV', payload:
I’m looking at the differences between yours and my settings. I can quickly see one about adaptation. I’ll post my screenshots here, maybe you’ll see something more than I do. And that’s my remark about what I’ve noticed. The head reacts to the temperature setting only after some time, much longer than the aqara head.
Clearly, there is an issue with the occupiedHeatingSetpoint which is only 500 or 5°C.
Not all data seems to up up to date as the “pi_heating_demand” is 100, which means that the valve is open at 100%, or heating - but the values are not reported instantly, only according to their report configuration.
500 could very well be the minimum value and result from the setpoint that is sent being the temperature in °C and not that value multiplied by 100.
The source for that temperature is “external” so something that was sent to the thermostat.
Thanks a lot for the screenshoots, I will check 🫡
Yes, as far as I understand 5C means “turn it off”, but I have no idea what may send such a request.
To me it seems strange with the adaption settings. It looks like it is not installed on the valve correctly.
As 5°C is more than 2°C lower than the room temperature, this turns the valve off.
As I understand it this happens when you enable Better Thermostat. So I guess there is a command from Better Thermostat that is not properly converted to the Danfoss thermostat units (which are standard Zigbee units).
You could change the level of the messages for Better Thermostat and Z2M (if possible) so that you can examine the relation between better thermostat and what Z2M sends to the device.
You could also have Better Thermostat change an “input value” and then use that to send the proper value to your valve.
The adaptation feature is one where the thermostat executes a procedure to try to learn how much % it should open the valve to get a certain heating effect. During the adaptation run I observed that the thermostat goes from 0% to 100% in steps of 5% - what I remember from the documentation, one should not change the setpoing during this procedure as it then interrupts that.
I had some trouble reliably starting the adaptation run, but I managed to put together a zha-toolkit script to start the adaption run.
This script will first put the thermostat in “mounting mode” showing a M (or W) on the screen - this mode commands the valve position to fully open so that you can properly mount the thermostat on the valve. Then you have to press the button on the thermostat to confirm that it is mounted. This is detected in the script and it then sets the adaptation control to automatic and initiates the adaptation run.
The valve will work with or without adaptation, but is supposed to regulate better when it has been executed/is automatic. In automatic mode it would do adaptation runs during the night. I do not know if you need to set the proper time for that on the thermostat, but I did so on mine.
Ok, looks like I resolved the issue, it is very strange but anyway. I removed device from Z2M, then reloaded TRV (battery on and off), then connected it again and DID NOT RENAME the device in Z2M and left this hash address name like 0x60b877fffe97b53a, and it helped, it works as expected for both my Danfoss Ally. Maybe it is coincidence, but I honestly don’t know what else I changed, and I also did the reset before but without rename, and it did not help before.
