Danfoss Ally TRVs (eTRV0103) – opaque control algorithm / slow reaction / can’t control valve opening (Zigbee2MQTT + HA)

Configuration
, ,
1

Hi everyone,

I’m running a custom room-by-room heating control setup in Home Assistant and I’m struggling with the internal control algorithm of Danfoss Ally Zigbee TRVs (eTRV0103). The algorithm feels opaque and I can’t reliably predict or influence it from HA, which causes significant gas consumption in my specific architecture.

My setup

  • Home Assistant + Zigbee2MQTT
  • TRVs: Danfoss Ally eTRV0103 (multiple rooms)
  • External temperature sensors: Sonoff temp sensors (TRVs use external measured temperature, reported consistently)
  • Window/door contact sensors: Philips Hue Secure contact sensor SOC001 (used to detect open windows)
  • Boiler control: gas boiler Saunier Duval Thelia, switched via Shelly 1 Gen4 (dry contact relay)

Zigbee communication is solid: devices are responsive, temps/contact states are received consistently, no obvious network issues.

Control logic (my architecture)

I’m not using a “single central thermostat”. Instead, I use TRV demand signals to decide when to run the boiler:

  • If at least one TRV reports it needs heat (heat_required) and its pi_heating_demand is above a threshold → boiler ON
  • Otherwise → boiler OFF
  • I also implemented a threshold: pi_heating_demand must be > 45% to be considered “real demand”. Under 45% I treat it as effectively 0 (to avoid low-demand micro-cycling / inefficiency).

The problem

The Danfoss TRVs frequently keep the valve partially open for long periods even when the room is already at/above target temperature:

  • Valve stays 15–25% open (sometimes even ~50%) for hours, even when room temp is ~0.5°C above the setpoint.
  • Result: the boiler runs >40% of a day (measured), which is too high for my house and suggests wasted energy.
  • Sometimes, even if I increase the target temperature by 3–4°C above current room temperature, the TRV response is extremely slow: it can take tens of minutes or even hours until the TRV increases demand/opening meaningfully.

From the HA/Z2M perspective, I can’t directly command valve opening (0–100%) and pi_heating_demand appears read-only, so I’m stuck with the TRV’s internal algorithm.

What I’m trying to achieve

My goal is to find a stable equilibrium between:

  • comfortable, stable room temperatures (per-room setpoints)
  • minimal boiler runtime / gas consumption
  • predictable behavior (avoid long periods of low opening that still keep the boiler running)

Questions

  1. Has anyone reverse-engineered or documented how Danfoss Ally eTRV0103 decides pi_heating_demand / valve opening? Any known behavior, smoothing windows, hysteresis, “learning”, minimum opening, etc.?
  2. Is there any way to disable/bypass the internal TRV control algorithm and control the valve opening (or equivalent) directly from HA/Zigbee (even via a custom Z2M converter / raw Zigbee writes)?
  3. If direct valve control is not realistically possible with these TRVs, what Zigbee TRVs would you recommend that:
  • expose a controllable valve position (0–100%), or
  • at least behave in a more “deterministic” / “externally controlled” manner suitable for custom boiler logic in HA?

If it helps, I can share screenshots/logs and entity examples (valve position, pi_heating_demand, temperature readings, etc.). Any guidance or proven setups would be greatly appreciated.

Thanks!

2

Questions 2 & 3.
As far as I know the internals can’t be bypassed. Only fooled by setting high or low set temperatures.
Perhaps there is a model that this is possible, but I doubt it.
There would not be a market for such settings, and those settings in hands of normal users would be devastating.
Thermal actuators are the dumb equivalent to TRVs which can be set to on or off, and more expensive versions has PWM control.
I have not tried one with PWM, only a non PWM with PWM and it didn’t work well enough.
But for us the on/off control of an actuator is enough to control the heat.