Re: Python Plugin: Smart Virtual Thermostat
Posted: Sunday 11 December 2022 17:39
I still very much like the idea of svt, this script version just has some errors and limitations in it's implementation, causing it to improperly 'refine' the ConstC and even more the ConstT values.
For example the code suffers from rounding errors: at some point the code just starts 'bouncing' between large constC values because the calculations are rounded too early and the PID as it is implemented can't recover from this situation.
Also the constT calculation is incorrect because the temperature offset is incorrectly defined as the difference between the outside temperature and the setpoint, whereas the heat-loss depends on the difference between the outside temperature and the actual inside temperatue, which may not be the same as the setpoint.
The next thing that seems to go wrong for a lot of people is when the calculated power goes over 100%, the constC and ConstT calculations are done as if 100% power was applied, whereas in reality the power was applied for more than 100%. This I think is a consequence of ignoring a lot of measurements when the needed power is over 100%, and also ignoring the measurements where the temperature is over the setpoint. I think these periods however need to be considered too, as even though the heater may be off, energy applied during previous cycles can still be delivered into the room(s) by the system.
An improvement I have been working on -but never got to really work correctly- is to keep the re-evaluation period fixed at a 10 minute interval (I found this suggested as a reasonable period by many heating specialists) to make sure the thermostat responds quickly to changes in the room temperature, but the measuring period can be longer or shorter than that based on the characteristics of the room/building/heating system. For this the power calculated must be able to go over 100%: when power >= 100% this just means our heat-source is going to be firing for the full 10 minutes, but still after 10 minutes we're going to re-evaluate the result of our effort so far. When doing this re-evaluation we have to take into account however that we have actually applied only 100% power even if more was calculated; i.e. we need to adjust the power applied accordingly in our constC refinement. For example: if power needed was calculated at time t as 150%, we would have had to switch the heater on for 1,50 * 10 * 60 seconds = 900 seconds. Because we re-evaluate every 10 minutes however, only 600 seconds will have passed at our next time t+1: we have applied only 100 of the 150% = 100/150 = 2/3. The constC refinement will be performed every 10 minutes, but the power applied must be corrected for this shorter period by that factor of 2/3. I am making one assumption here that is not completely true: I am assuming temperature raises and falls linear, which is not the case in real life. If however temperature differences are small enough, it is almost true. So by doing this assumption I make our calculations a lot easier, at the cost of a some precision when the difference between setpoint and actual temperature is large. Since we're mostly going to want our thermostat to keep the temperature close to the setpoint I think we can safely make this assumption. The benefits of doing this change -I think- are: the svt will perform better with a long feedback loop (for example with floor heating) while still responding quickly to outside changes and it can also better refine the constC values (because it takes into the account the periods the heater wasn't on too: the constC will contain a component for both on and off periods). What I wanted to achieve is that the svt always calculates how much power to apply to make sure the temperature is going to be at the setpoint at the next interval t+1, regardless of the actual temperature at time t, the setpoint value or if the heater was on during the previous cycle. i.e. no limitations should be applied on the decision whether to re-calculate needed power nor on whether to refine constC.
For example the code suffers from rounding errors: at some point the code just starts 'bouncing' between large constC values because the calculations are rounded too early and the PID as it is implemented can't recover from this situation.
Also the constT calculation is incorrect because the temperature offset is incorrectly defined as the difference between the outside temperature and the setpoint, whereas the heat-loss depends on the difference between the outside temperature and the actual inside temperatue, which may not be the same as the setpoint.
The next thing that seems to go wrong for a lot of people is when the calculated power goes over 100%, the constC and ConstT calculations are done as if 100% power was applied, whereas in reality the power was applied for more than 100%. This I think is a consequence of ignoring a lot of measurements when the needed power is over 100%, and also ignoring the measurements where the temperature is over the setpoint. I think these periods however need to be considered too, as even though the heater may be off, energy applied during previous cycles can still be delivered into the room(s) by the system.
An improvement I have been working on -but never got to really work correctly- is to keep the re-evaluation period fixed at a 10 minute interval (I found this suggested as a reasonable period by many heating specialists) to make sure the thermostat responds quickly to changes in the room temperature, but the measuring period can be longer or shorter than that based on the characteristics of the room/building/heating system. For this the power calculated must be able to go over 100%: when power >= 100% this just means our heat-source is going to be firing for the full 10 minutes, but still after 10 minutes we're going to re-evaluate the result of our effort so far. When doing this re-evaluation we have to take into account however that we have actually applied only 100% power even if more was calculated; i.e. we need to adjust the power applied accordingly in our constC refinement. For example: if power needed was calculated at time t as 150%, we would have had to switch the heater on for 1,50 * 10 * 60 seconds = 900 seconds. Because we re-evaluate every 10 minutes however, only 600 seconds will have passed at our next time t+1: we have applied only 100 of the 150% = 100/150 = 2/3. The constC refinement will be performed every 10 minutes, but the power applied must be corrected for this shorter period by that factor of 2/3. I am making one assumption here that is not completely true: I am assuming temperature raises and falls linear, which is not the case in real life. If however temperature differences are small enough, it is almost true. So by doing this assumption I make our calculations a lot easier, at the cost of a some precision when the difference between setpoint and actual temperature is large. Since we're mostly going to want our thermostat to keep the temperature close to the setpoint I think we can safely make this assumption. The benefits of doing this change -I think- are: the svt will perform better with a long feedback loop (for example with floor heating) while still responding quickly to outside changes and it can also better refine the constC values (because it takes into the account the periods the heater wasn't on too: the constC will contain a component for both on and off periods). What I wanted to achieve is that the svt always calculates how much power to apply to make sure the temperature is going to be at the setpoint at the next interval t+1, regardless of the actual temperature at time t, the setpoint value or if the heater was on during the previous cycle. i.e. no limitations should be applied on the decision whether to re-calculate needed power nor on whether to refine constC.
