HASmartThermostat
HASmartThermostat copied to clipboard
ScratMan
Heating turns on even though current temp is already high
Could you please help me tune this thermostat? It keeps tuning on even though the target temp is quite lower than the current one. Here's my current configuration:
keep_alive:
seconds: 60
kp : 75
ki : 0.0001
kd : 70000
Hi, your temperature sensor is returning a lot of measurements, generating a lot of 0.1°C steps separated by short periods of time. The derivative part of the PID will interpret this as fast transient, as D = -Kd * di / dt
You should use the sampling_period parameter to sub-sample the temperature, with 5, 10 or 15 minutes.
Thx. Around midnight I tried setting sample_period to 5 minutes. Here's how it looks now. Looks better. Do you think there's anything else I could try?
It looks much better. Now maybe adjust the min_cycle_duration according to your heating system (electric can be short, 1 or 2 minutes, boilers need 5 or 10 minutes), to avoid switching too often. Then you'll have something more stable to adjust the gains.
Ok. I set that to 5 minutes and now switching isn't too often. However, it still switches on when the target temp is lower than current. :(
That's the effect of the derivative gain Kd. As it's large, if your temperature decreases by 0.1°C with 5 minutes elapsed from the last sample, you'll have D = -Kd * di / dt = -70000 * (-0.1 / 300) = 23.33. The error (target - current temperature) being ~ -0.5°C with Kp = 75, the P = Kp * error = 75 * 0.5 = -37.5. Depending on the value of integral I, the -0.1°C delta may trigger the heating. Start by dividing the derivative gain Kd, maybe 30000 could be more adapted.
Edit: and you may clear the integral part using the dedicated service, so it doesn't take too long to adapt to new gains.
I changed Kd to 30000 and I was monitoring the thermostats this period, trying also to understand how all this works. Still, I have the same issue and trying to figure out why. I have two questions...
- Even though I changed kd in configuration.yaml, the core.restore_state file still has the previous value (70000). Is this a problem?
- How is the output used exactly? Is it that when it's negative the heating switch will stay off and when it's positive it will turn on and the amount of time it will turn on is proportional to the max output value of previous readings? i.e. if the output is 40 and it's the maximum value ever returned then it will stay on 100% of the sampling period but if it's 20 it will stay on 50% of the sampling period?
I changed Kd to 30000 and I was monitoring the thermostats this period, trying also to understand how all this works. Still, I have the same issue and trying to figure out why. I have two questions...
- Even though I changed kd in configuration.yaml, the core.restore_state file still has the previous value (70000). Is this a problem?
Yes, on the recent releases, the gains are automatically restored from last know state after a restart, so you can't change them by the YAML, and your kd remained at 70000 in HA. You should use the smart_thermostat.set_pid_gain service to change the gain values. The settings in the YAML file are used only at first start after creation of the thermostat, and in case of HA database crash or deletion. So once you found the best settings by tuning with the service, you should write the final values in the YAML configuration to save them in case of HA DB crash.
- How is the output used exactly? Is it that when it's negative the heating switch will stay off and when it's positive it will turn on and the amount of time it will turn on is proportional to the max output value of previous readings? i.e. if the output is 40 and it's the maximum value ever returned then it will stay on 100% of the sampling period but if it's 20 it will stay on 50% of the sampling period?
Which output are you talking ? the PID output ? it's a percentage to control the modulation, 0 is Off, 10 is On 10% of the PWM period.
Thx again! Looking much better again. What I see now is that switch turns on a few times while already at the setpoint and results again in some overshooting. Part of the reason for overshooting in the picture might also be because the sun is rising and so is the external temperature, however, these actuations marked in red seem a bit too much, don't they?
It's difficult to say, you should monitor the three pid_p, pid_i and pid_d attributes to see which one is toggling the heater and know which gain to adjust.
@ScratMan @bamnoru Hello, we can observe, in "heat" mode the particular situation that Integration calculation stop to subtract when control output = 0 (thus when negative P value is dominant) this lead day by day to an unbalanced growth of I value that is the main reason of "fat" heat calls generated by small errors. On your point of view, is this a side effect of the anti wind-up function or is another bug in pid controller?
@Stefano0042 the integral is made to act when the system is settled, that means when it just regulates by heating slowly to compensate the losses. You should consider the I part as a memory that remembers the losses of your house. If you keep integrating while above the target (due to sunny days for example), you will erase this memory and then without sun the system will take a long time to integrate again.
If your system keeps heating due to high integral while temperature is above target and not decreasing, it's rather due to a too low kp.
@ScratMan yes you are right, in fact this is the only counter-strategy applied to fight with, currently my KP gain is quite high = 88, but it has also a counter effect, thus will reduce the "area" of regulating with negative error that will erode the accumulated I value. So we have to accept it as is.. :)
@ScratMan it seem there is an intrinsic unbalancing factor in this algorithm, "I" will become soon or late a "disturb" in the system, and no more a strategy of error containments. An unbalanced "+area -area" summation. So I 'm going to change the PID controller locally, is a matter of personal interpretation at the end , I would prefer a suffering system than an overshooting one, or at least I will try to do that, I have a quite solid thermo technical background, but not an equal python skill.
@bamnoru @Scratman hey, what have you (we) done up to now is a really good example of productive collaboration. Has been recently demonstrated that a team of collaborative people will act more successfully than the action of a single one.
@bamnoru @ScratMan @papadi I'm currently doing some tests. If they will be of some values they will land into a commit.
@Stefano0042 the Brett Beauregard's blog about PID development may be of interest for your study : http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/
It shows with some examples the impact of different approaches, and explains why the code is like it is.
@ScratMan @bamnoru if we are facing a problem we have to search for a different solution, bamnoru provided a good example when he spotted the bug in "sampling_period", I love that attitude.
The most pertinent classification for this sub-type of PID PWM meant for gas (condensing) boiler plant is "chrono-proportional", is far away from burst firing PWM (e.g. LED control, electrical-heater resistive load ecc.., ) in this particular "distortion" we have to consider many factors, few of them really relevant. 1) the total duration of the PWM and 2) min_cycle_duration, as we have to protect the boiler from to many on-off daily insertion we have to live side by side with temperature oscillations, especially in case of low mass inertial systems, in this case a well tuned Kp gain and non invasive Ki/Kd gains, will do the job as best as they can, is of interest the final consideration of Andrea Nydegger the "father" of this components today in his almost full tech. maturity.
After (not easy) tuning operations I am very satisfied with the smart_thermostat.
I can get an error within +/- 0.2 ° C (in the absence of major "noise" such as window openings, etc.).
The only my concern is about the number of starts of the (gas) boiler. I have set PWM to 30 minutes and min_cycle_duration to 5 minutes, therefore I can have up to 48 ON/OFF cycles per day. (The mean of ON/OFF cycles are 38 per day).
I have no experience of commercial thermostats with "TPI" technology, I don't know if they are less "hard" in terms of ON / OFF cycles.
Has anyone experience with commercial "TPI" thermostats?
Has anyone experience with commercial "TPI" thermostats?
I also own two Netatmo thermostats with 3 valves, here is the curve of one thermostat that controls my underfloor heating, it's zone 2 from my gas boiler.
@bigbread59 Hi Pasquale, on my side PWM is 60 min and min_cycle_duration is 15 min (electro-thermic Zone valve itself opening/closing time is about 2...3 min) I run two instances of HAsmartT (radiators and floor heating on 2 different zone) acting on the same boiler, to minimize the boiler stress I voluntary generate an oscillations of +-0.5 °C on the radiator zone (the inertial mass is so light on the loft). For sure the lifespan of ignition/heat exchangers/pump will be shortened by an elevated number of daily insertions, flow water temperature (boiler output) is also a questionable argument, as delta T° is the main stressing factor.
@Stefano0042 Very interesting approach!
How is an oscillation of +/-0.5 ° C generated in the radiator area?
I only have cast iron radiators, room by room I have a temperature delta of 2.5 ° C. I am evaluating the TRV devices. Furthermore, my house has very poor thermal insulation.
My "case study" is to optimize comfort / gas consumption / boiler life.
@ScratMan Looking your Netatmo thermostat behaviour I can say that I prefer your smart_thermostat ;-)
@bigbread59 +-0.5 is only the result of a sequenced parametrization by approximation. TRV and 24h boiler service is for sure an optimal solution, TRV will modulate the air temperature in every room by eliminating T. oscillations and with proper T. level room by room . On the floor heating zone HAsmart fit much better, so I have a picture close to the @ScratMan TPI Netatmo with large free heat during lunch and dinner hours but with a better controls option for sure than Netatmo, I'm currently running few test more. So I would say HAsmart is in the best category of his type, we can be proud of that!
@Stefano0042 @ScratMan
So I would say HAsmart is in the best category of his type, we can be proud of that! Fully agree!!!
With the Netatmo valves in the bedrooms, the boiler is switched on and off many times a day. But regulation is correct.
The Smart Thermostat is still in active development, I'm working on adding outdoor temperature compensation to the PID, it seems to work pretty well at the moment. The next step would be to be able to use this outdoor temperature to modulate the power of the heater when possible (by modulating a valve opening, or water temperature), and then the PID would modulate the heat request time.
I wish I could tame this! Target temperature is consistently below current and still it turns on! :(
Look at the pid_p, pid_d and pid_i attributes using apex chart card or template sensors, I bet the D is triggering the heater due to fast -0.1°C transient with short dt. I'm adding a 'pid_dt' attribute in the next release to monitor the sampling rate of the sensor.
Do you use a sampling_period setting ?
Maybe https://www.home-assistant.io/integrations/filter/ could help with spikes so PWM gets more stable readings?
@ScratMan @bamnoru Allowing PI windup at control_output=0 (just below in init.py line 144) will not add a significant improvement, so after few days of testing I decided to revert back.
144 if self._out_min <= self._last_output < self._out_max and \
But:
- reducing boiler flow temperature (power output) will limit air convection motion in favors of radiant heat.
- increasing water flow rate in the radiators (will lower Delta T but will enlarge a bit the thermal inertia mass in steel tubulars radiators)
- eco T reduction (-0.5°C from comfort T)
- Kp reduction
- T indoor filtering
- shortening of eco periods (more thermal inertia charging in the house concrete)
- min_cycle_duration: 20min
- pwm: 1h
- adeguate sampling period parameter
is possible to obtain a significant improvement in terms of T oscillations still with an optimal condensing/boiler duty cycle.
Final consideration: oversized cast iron radiators with bigger thermal inertia mass will fit better with this kind of advanced on-off control as PWM is. Radiant panel emitter is a good target model to be used as inspiration. Indoor temperature filtering as suggested by @krzysztof-magosa, were necessary, I'm using a math average modeling on a grouped T sensors. Min cycle duration as both limiter/expander and not only as expander, but yes, it is a personal flavor. We have to consider Thermostatic Radiator Valve and modulating boiler with strong min power/max power ratio (rangeability) to be able to close follow TRV modulation, as an optimal alternative solution.
