Heat-curve compensation — any ideas/plans?

[altruizine]

For context, a “heat curve” is what regulates the temperature of hot water flowing through a radiator-based heating system. This temperature usually depends on the outside temperature, and potentially on other parameters that define the curve's coefficients and offsets, and perhaps on the time of day. As an example, here's my apartment house's central boiler's heat curve, as depicted in its manual:

(AT = outside temperature, VT = flow temperature at central boiler, RT = offset; e.g., with Curve 5 enabled and offset set to 0, at an outside temperature of 0 °C, flow temperature will be 53 °C.)

This matters because each cycle, VT tries to calculate which fraction of energy it should dissipate into the room. However, energy dissipation of a radiator depends proportionally on the difference between radiator temperature and room temperature.

So, if VT does not take radiator temperature into account, dissipation will be systematically too low or too high, leading to set temperatures not being reached or to overshoot. The systemic error can be very large. In the example above, if VT's coefficients have been determined at 0 °C but outside temperature climbs to 10 °C, energy output at an approximate room temperature of 20 °C will be (38–20)/(53–20) = ~55 % of what VT expects.

Ideally, VT would either allow taking the heat curve into account and compensating for it, or, offer a control algorithm that works independently of the heat curve.

I'm not sure how feasible the latter (heat-curve-agnostic algorithm) is; I think not even the new PI controller that's currently in development can abstract away from expected energy fraction. So I'm going to focus on the former (use heat curve) for now.

What would be a good way to configure a heat curve in VT? My current thinking is that the user could provide a script that computes the scale value based on the heat curve (the 55 % in the example above, or its inverse, 1 / 55 % = 183 %). VT would call that script to scale the demand it has computed before passing it to the respective TRV controller.

Is such an approach feasible at all? Can an integration call a user script, and how would it deal with all its failure modes?

For fun, I have implemented such a script for the above heat curve, but haven't put it to use yet. (It implements the heat-curve computation based on quadratic-curve coefficients I have reverse-engineered from the curve graphics with the help of our little AI friends.)

This script takes demand, inside/outside temperatures, heat loss (offset) and a curve selector as arguments and returns heat-curve-adjusted demand. This assumes that the user supplies the latter two values to VT, but I guess it would be best to not burden VT with them and keep them local to the script.

I plan to integrate this script into my experimental virtual valve (described in my comment here) at first, where I'll need to reverse-compute the energy demand from the valve position, scale it, and then recompute the valve position.

Please let me know what you think!

Paging @jmcollin78 @KipK

[jmcollin78]

Thank you for this @altruizine , we will have a look ! It seems fine for me.

[KipK]

I kinda like the idea of external script.
This would allow to have a database of different scripts per referenced device made by community.

[jmcollin78]

external scripts are callable from an integration with this kind of code:

await hass.services.async_call(
    "script",
    "turn_on",
    {
        "entity_id": script_entity_id,
        "variables": {
            "temperature": 21,
            "outdoot_temp": 0.3,
            ....
        },
    },
)

it seems also possible to get back some value.
So it seems a good idea. The script to use should respect to a interface contract (a list of parameter) and is configurable in the ConfigFlow (in a kind of expert mode to avoid too much complexity for most users).

Then with the import/export feature proposed by @bontiv (see: #1806) it will be possible to associate a device type to a script. VTherm should propose default scripts.

This seems a good idea., to solve this non-linearity that seems to be an issue for algorithm.