My gas central heating system has TRVs fitted to the radiators. The TRVs can take upto 5 minutes to respond to a ‘set target temperature’ command from the generic thermostat card, and upto 5 minutes to report the actual temperature. So a 10 minute turn around from ‘set target temp’ and ‘report actual temp’.
As a consequence, my boiler fires up, cuts out when its internal max run-time is reached, fires back on (because the demand for heating from my HA setup is still on), switches off and back on again.
The net result is longer than needed boiler on time and thus in some rooms on the upper floor , the heating is higher than the set temp for the TRV. This is because the lag turnaround time means the boiler continues to fire when the actual temp is probably at the set temp - it is just that the set temp took 5 minutes to read and the actual temp has taken another 5 minutes to report.
The heating comes on in the morning when it is around 16C at the moment. One the system is up and running - say by noon - this phenomena is far less worse and not too bad. It’s just really in the mornings things are bad. I suspect that this is a combination of excessive boiler run-time and ambient heat build up through the morning as the sun increasingly shines through windows.
Is there any way some form of automation or calibration in HA can be applied to smooth out the heating operation.
Hi, I don’t really understand your setup but I can offer a couple of suggestions which might help you trouble-shoot the problem (I assume your TRV setup uses something like Zwave to communicate with HA and that the main issue appears to be the speed of response of the communications with the smart valves).
When you say that the boiler fires up then cuts out, this may be the high temperature cutout of the water circulating around the radiator loop i.e. the water is at the max temperature e.g. 60C but the TRV’s have not yet opened to “consume” the hot water being provided (this max temperature is normally adjustable within limits at the boiler). You could test this by feeling the pipe on the upstream side which would be hot and the pipe on the downstream side would be cold (meaning that the hot water is available but the TRV is not letting it through).
The Generic Thermostat has a min_cycle_duration parameter that you can adjust to prevent the thermostat in HA from turning on/off too often. You could experiment with this to see if it helps.
Also if you are using the climinate.set_temperature service to turn the heating on in each room then perhaps you could leave the thermostat set at say 21C and use the climate.turn_off & climate,turn_off services instead. It might just be that this could save you the first 5min delay to transmit the new setpoint to the TRVs.
Thank you kindly for your reply. You seem to know what you are talking about.
Apologies, my setup is RF433Mhz TRV network, Raspberry Pi 3b as the HA server with 433Mhz board on. 4x Energenie MiHome TRVs.
Yes, the boiler cut-out is kicking in and this is as expected. I have a heat gun meter and the feed circuit is at around 58-62C depending which rad I measure… A check of the boiler manual confirms cut out on the feed at 60C. The difference between boiler feed and return - measured at the boiler - is 14C. No issues here I reckon?
The issue is as you say, the delay in the hardware/software from energenie control. It’s a way of reducing battery draw in the TRVs and network comms. It is at its lowest setting (10mins round trip). This is the issue. The boiler continues to fire because the HA generic thermostat is demanding heat because the TRVs are 10mins - at min , sometimes 15mins - behind. Therefore the room temp is 22C but the TRV+generic thermostat are reporting 19.5C. By noon, the room is 23C - way to warm and a waste of energy.
Actually, I made a mistake. I use simple-thermostat not generic thermostat:
Does this have a cycle time and how might I configure it Mark?
Also, what is climate.turn_on/turn_off and how does this differ to climate.set_temp in relation to your proposal. What would the system effect be?
It looks like the Simple Thermostat is just a lovelace card so it does not have any cycle time associated with it.
I had assumed that you were using the Generic Thermostat in HA which supports a cycle time but I now think that your thermostat logic must be in the TRV’s i.e. you just send them a setpoint and they compare this to the local temperature and decide whether to open or close the valve.
I had a brief look at the manual which shows the following remote control options:
Maybe you could try the option to open the valve fully and see whether this works immediately or whether this also has a delay.
Unfortunately I don’t think I am going to be able to help however I did come across some other posts where people have experienced similar issues e.g. the May 10 post in the first link below:
Yes Mark, it is the way the TRVs work. up-to 5min for RX (setpoint) to be read, 5mins for the TX to be sent (actual temp). Infact, any RX and TX is the same. Any command sent, any report received, all takes the same time. As I say, its to reduce battery power consumption.
An open valve command can take 5mins to be received and then actioned (TX not needed). Not sure therefore how or if this would be beneficial.
Devices and loveace cards aside, how might I code up a script or automation Mark that would help to lessen the effects I am getting?,
How about sending the setpoint to the TRV’s then waiting 5 minutes before sending the command to turn the boiler on. I assume that you must have an existing automation that sends the temperature setpoints via the MiHome Gateway and also controls the boiler firing based on on/off times that you set?
With regard to the TRV’s being slow to update HA then you could bypass these by using a different temperature sensor that does not have such a large delay (e.g. the Aqara Zigbee ones). However I am not so sure this is such a big a problem i.e. whether HA thinks it takes a room 1 hour or 1 hours 5 minutes to heat up. Also as the TRV’s are controlling the radiators locally then the fact that there is a delay updating HA should not really matter.
Unfortunately as I don’t have Energenie then it is hard for me to offer any specific advice, the best thing might be to review the two threads I included above and message those people directly as it sounds like they have already been through some of the same issues.
I don’t want any more sensors when I’ve paid 125 quid for the TRV kit.
Picking up on your 5min lead time before sending ‘on’ to switch.boiler , the problem here, is that when the time controlled first switch-on occurs (7am) , the boiler must come on immediately. after about an hr , the house rooms are up to temp, but because of the lag times across all TRVs, HA is requesting more heat for about another half hr. grrrr
That seems strange. Lets’ consider the point at which the room achieves it’s desired temperature then there is a delay of 5min for the room temperature to get back to HA at which point it can cancel the demand for heat. I don’t understand why there is a delay of 30min.
Could you perhaps post the yaml for the assoicated automation and climate entity as I still don’t understand your setup.
Sorry if I’m not explaining very well; there is a lot going on here and the setup does not appear to be straight forward so difficult to explain.
Let’s use a real-world scenario as an example:
Target temp set by HA thermostat (setpoint on a lovelace thermostat card). Target temp = 21C.
Boiler switch is set to OFF (default).
Automation turns on at 0700. ambient temp is 17C.
Systems sends ‘report temp’ command to the TRV.
At least 10mins delay (command to be sent and the reply received from the TRV - both MQTT).
System compares actual temp (reported by TRV) with target temp.
If actual < target temp (21C) then system sets/maintains boiler switch to ON, then loop BACK to step 3.
Boiler turned off (target temp 21C reached) , however the ambient temp is usually by now around 22.5C but TRV has reported 21C.
The system continues to monitor TRV actual temp reports, looking for a drop below the target temp (21C).
Half hour after boiler switch off the TRV is now reporting 22.5C (which was the ambient temp about half hr ago). However the ambient temp is now actually around 21C and dropping. But the system state believes the temp to be 22.5C.
A further half hour later (1hr after boiler switch off) the ambient temp has fallen to around 20C. We need more heat. But the TRV is reporting around 21.5C (still above target temp of 21C).
Another half hour later (1.5hrs after boiler switch off) the system gets a 19.5C report from the TRV and the boiler correctly kicks in. However, it’s been 1.5 to 2 hrs with a coldish room.
Loop back to step 3.
The synch is all out and needs compensating for. The scenario above is an instance. Other instances can be longer or shorter in terms of time the system is out of sync - it all depends on the outside world temp and weather. But the above example is an overall average experience I would say. I stress that the timings (half hr, 1.5, 2hrs) is an average, it can be less, can be more - dependant upon outside climate.
I cannot compensate in the TRV hardware or the way the TRV linux software executable interface works. That is why I am seeking to understand if/how an algorithm or automation/scripts might help in HA.
The phenomena is only really bad in the morning and I guess this is because the entire house needs brining up to temp from around 17C and we get nice warm room after about an hour then a coldish room for 1.5-2 hrs as per item 10 above. The phenomena isn’t so bad once upto around 19.5C but it still leaves cold rooms for a while but not as bad as first thing in the morning.
All of this is due to the lag and cycle times between sending commands from HA through OEM software and over another 433MHZ RF stack , to the TRV , and for the return trip. If commands and reports were sent/received within seconds of requesting, then I’m sure it wouldnt be so bad. But then the 2x1.5v AAA batteries would deplete quickly I guess.
I will upload the yaml later when home but it isnt anything complex, it merely implements the above.
The TRV reported temperature will not reflect the room temperature as it is too close to the radiator. You do really need a room sensor for that. However ‘standalone’ the TRV regulation will work OKish.
In your feedback loop you will have to apply an offset to the TRV based on if the temp is rising or falling (heating or not). If rising you want to cut the heat early (lower temp) and if falling you want to start the heating early (higher temp). You will have to play around with just what offsets give you the best room experience.
Room temperature control is all about offsets, overshoots and long time constants … it’s not an on/off mechanism
Assuming a correct flow rate (not too fast) could also measure flow and return temperature at the boiler to see how much heat was being removed by open radiators … to create demand switching.
Thanks for taking the time to document all that Daz, that makes it much eaiser to get my head around. The way you have described it me reminds me of a Mars rover and the 20 minute delay for radio waves to travel back to earth, there’s no way they can wait for a picture of an obstacle to come into view and then expect to manually steer around it. What they have to do is give the rover a certain amount of autonomous local control to take account of the “dead time” delay.
Coming back to your setup is there any reason why your timer automation cannot just turn on the boiler from say 07:00 to 09:00 and then again in the evening at say 17:00 to 22:00 (or you could revert to an old style stat on the wall in the hall that turns the boiler off when the house is up to temperature - this would eliminate some of the deadtime if you don’t want to buy more sensors). I thought the TRV’s would be similar to the manual thermostatic valves where you dial-in the temperature and they open/close based on the local room temperature. Whatever you end up doing you need to “decouple” the boiler control from the TRV temperature reporting.
@xAPPO has added some further suggestions. This touches on what they would do in industry if they are trying to control a process with significant deadtimes i.e. they would build a model to predict how the system responds then use this in the control software to minimise the overshoots.
I’ll have a look at your automations when you get time to upload them.
BTW, you could get a Zigbee temperature sensor and a USB dongle for around a tenner. This would give you scope to expand your system with door/window swicthes, motion detectors, remotes etc.
Well Mark, I could do, but I’m not one for giving up and buying more hardware before a software fix can be tested, seems a bit hasty to me (and more money!). But, once I’ve sorted this out, I will look into those devices you kindly link to. May I ask if these are better than Z-Wave, cost/performance? I have a Z-Wave system for my Danfoss 2ch Switch used to mode the Central Heating / Hot Water (Boiler). Its works perfectly. Could I add Z-Wave devices or am I better off with Zigbee and if the latter, would it work alongside my Z-Wave stick plugged into the Rasp.Pi ? BTW , Zigbee uses 2.4GHz which is already packed in this household with about 7 WiFi devices on the 2.4GHz frequency. Z-Wave also travels through my 3 storey house quite well.
@xAPPO I think you have it. This is hysteresis is it not? I think my previous “Cosy Home” thermostat mentioned this in the documentation. It would add 0.3C to the TRV reported temp on the way up (heating), and 0.5C on the way down (cooling). I guess the rads get up to temp quicker than they cool down?
Is this sounding about right? Problem here is that the TRVs have a resolution of 0.0001 on the way down (so that’s ok), but only 1.0 on the way up (er oops!). Don’t ask me why, I’m finding these things more crap by the day. I think what I might try is 2x input_select on a card that I can use, one value to be added on the up, one to be subtracted on the down. My impression is that the boiler will cycle (On/Off) more often but on each ‘On’ cycle it won’t be on for as long. At the moment there’s about 2 hrs between cycles and load duration (‘On’ time) is about half hr. So a duty cycle of 25%. I guess as an initial stab, I would like to see a load time of 15mins every hour. So same duty cycle, same cost, but improved operation = improved efficiency = improved mean room temp = comfort !. I shall see where that leaves me. I’ll try this when I’m home.
Several issues at play in addition to the (now well versed) duty cycle, load and lag times.
Climate entity was set for 0.5 tolerance on the up and down. I changed this to 0.1.
Climate entity resolution in input (actual ambient) temperature was 1.0. I changed this to default (0.3).
TRV to HA interface comms is over MQTT. My Raspbian linux systemd service that was running my MQTT broker was failing and restarting and failing and restarting and … you get the idea. This was due to a log file rotation not executing and thus consuming all log quota. I added the service unit to log rotation and lowered the logging verbosity.
Unnecessary automation duplicating MQTT commands sent to TRV. Removed automation.
VOILA!
Now I have a more efficient and comfortable home.
The paradox here is that the delay in the send/receive TRV commands (10mins min) actually has a benefit because it prevents short cycling the boiler; the effect is that warming up of rooms reaches the the target temp and then the much slower cooling down is buffered such that the boiler is not switching on and off quickly at or around the target temp. Anyway, not a good explanation but it all works fine now.
