Problem
I have a gas fired central heating system with eTRVs on all 6 radiators in the home. The eTRVs send data over RF433. HA and FrontEnd setup all working. However, it is less than ideal.
The issue is in the reporting of data from the eTRVs. The non-modifable firmware sends data every 15 minutes or so. This is a “design feature” aimed at conserving battery power. In this regard it seems to work well - the batteries have been in for 13 months and lost only a small amount of charge. Great! However there is a flaw.
The flaw means that the setpoint for a given eTRV is reached however the eTRV would only send the actual temperature every 15 minutes. This means that by the time the temperature measured by the eTRV is at the setpoint, 15 minutes elapse before the temperature is sent and received into HA. During this time, the boiler remains active and thus continues to heat the radiator. Thus, by the time the temp is received by HA the ambient temp has actually increased to a much higher figure than reported (the setpoint or thereabouts above). The precise figure depends on several factors including but not limited to: Ambient temp, External outside temp, size of radiator, location of rad (lower floor/upper floor), distance from boiler, and so on. Suffice to say that the increase in temperature over the setpoint can be between 1 and 3 Celsius. I need some way of “tuning” each eTRV to account for system behaviour. To be clear, there is no means by which to change the eTRV behaviour and so the focus needs to be on compensating for this within my HA setup. This is where I need your help please.
Current setup
Pi4 running Raspbian (Debian Buster) with a generic RF433 card. All working. In regard to HA, I use the latest core version downloaded from HA site as of 4/1/2021. For simplicity, let us assume please that I have one eTRV. I control this in HA via the native ‘generic thermostat’ component, and use the ‘simple-thermostat’ lovelace card (https://github.com/nervetattoo/simple-thermostat).
As I say, all works fine albeit without said compensation.
Help needed
Is there some sort of algorithm that would work, what is it called (or the theory name), and where might I obtain sample code. I have been referred to hysteresis (and ‘tolerance’ in HA component config) but this isn’t the right resolution. This is because it turns on the heat when the temp drops below the lower-limit (minus a tolerance value) and only turns off when it reaches the upper-limit [setpoint] (plus a tolerance value). So this will actually make my situation worse because the boiler will be commanded “on” for even longer.
I am fine with Python, C/C#/C++, JS, Java so will understand code you may be able to point me to, but I am less conversant with yaml/HA/templating and exchanging data via service calls between HA core and the cards & components - so I will need help on this. But first off, I would appreciate suggestions on suitable algorithmic names/theories and pointers to some code examples ? then will try to work out as best I can posting the config here ( probably not working )
What I have tried
So far, lots. The closest I got was (in PDL):-
CONSTANT heating_tolerance = -0.5;
CONSTANT cooling-tolerance = +0.5;
LET setpoint = 18.0;
DO WHEN UPDATE OF etrv_room_temp
# this is the temp value received from the eTRV.
# note an update might change the temp, but it might not.
# so this is an UPDATE trigger, not a CHANGE.
# i.e. run this code on every update regardless of value.
IF etrv_room_temp >= setpoint - heating_tolerance THEN
{ switch off boiler }
ELSEIF etrv_room_temp <= setpoint + cooling_tolerance THEN
{ switch on boiler }
END IF;
END DO;
This allowed me to set (and adjust) tolerances that would compensate for temperature rises likely to occur within 15mins of reaching the setpoint, by effectively reducing the setpoint and increasing the lower-limit for turning on the boiler. However, and somewhat obviously, this just entered a deadlock in which the boiler iteratively cycled on and off within milliseconds. No, this doesnt work then , needs to be more intelligent (or rather I do!)
Many thanks.