[BUG] Danfoss Ally valve: Slow actuator response [solved already in other solutions]

Describe the bug The problem is well described here: https://community.home-assistant.io/t/danfoss-ally-valve-slow-actuator-response-solved/254939

So if you issue a new temperature target setpoint for the thermostat using HA+ZHA the thermostat uses the internal PID mechanism to control the valve which results in slow (and sometimes unexpected) valve control movements.

To Reproduce Steps to reproduce the behavior:

1. Go to your Danfos Ally thermostat connected using ZHA
2. Change the desired temperature
3. Watch the pi_heating_demand changing over time (far to slow)

Expected behavior The pi_heating_demand should change much faster

Screenshots

Additional context The issue is already fixed in deconz (https://github.com/dresden-elektronik/deconz-rest-plugin/pull/4408) as well as in the Koenkk/zigbee-herdsman-converters (https://github.com/Koenkk/zigbee-herdsman-converters/pull/2592)

So mainly the solution is well described in the official document (https://assets.danfoss.com/documents/176987/AM375549618098en-000101.pdf):

The zigbee coordinator needs to send a Setpoint Command including the HeatingSetpoint itself aswell as a bitmask (enum8 set to 1) to circumvent the thermostats PID mechism.

Based on that I started to read carefully all instructions of the zha quirks because I wanted to sort out if I can create a custom zhaquirk (based on https://github.com/zigpy/zha-device-handlers/tree/dev/zhaquirks/danfoss) fixing this issue.

While I already identified that I need to add a custom output cluster in the replacement (and I guess for that I also need to add the thermostat output cluster to the signature itself?) I didn’t find any good example (first I thought the tuya custom quirks were good to understand but I honestly gave up) on how to understand:

1. how do I implement a custom command in the quirk?
2. (in this specific case) how can I access the occupied_heating_setpoint sent by HA+ZHA to the thermostat (which is based on the solution above an int16)
3. how can I create a custom command like “setpointType (enum8) + HeatingSetpoint (16bit)” where the HeatingSetpoint is occupied_heating_setpoint from 2) and the setPointType is set to 1 (the final command input needs to be masked in hex I guess)?

Also just to recap how it works: ZHA is using the climate.py integration in HA and calls the function

async def async_set_temperature(self, **kwargs):
        """Set new target temperature."""

which eventually calls (in the case of the Danfoss Ally):

            elif self.hvac_mode == HVAC_MODE_HEAT:
                success = await thrm.async_set_heating_setpoint(
                    temp, self.preset_mode == PRESET_AWAY
                )

which is implemented in core/homeassistant/components/zha/core/channels/hvac.py

so there in normal operation the following code should be executed:

        if not await self.write_attributes(data):
            self.debug("couldn't set heating setpoint")
            return False

That’s where I got lost to find the appropriate calls into zigpy and how the zha quirks overwrite the zigpy code to be executed (or is this assumption already wrong?).

Any help appreciated. Surely you also can fix this yourself if you think this is faster than to teach me 😉 (because I won’t have time within the next 3 weeks). If you fix it yourself I can learn from your implementation to be able to handle such requests myself in the future.

[Stefano0042]

Normally it takes a couple of days before the Ally is properly learning the room response.

[albalaing]

I have been using the Popp for quite some time and it works exactly the same as the Danfos. Danfos updated it to 1.08 by downloading the firmware from the support page and using ZHA. I had no problem