danieltwagner
commented
7 months ago I came up against this today where the temperature didn't update for a couple of hours and the components happened to net out to zero, so the system stopped heating before reaching the set point.
Initially I liked your solution and was going to implement it, but upon thinking about it more this would imply that the derivative is only ever valid for (at most) one pwm cycle, as with the next cycle we'd compute the new derivative based on no change, zeroing out the derivative. Given the slow reaction time of the system, this would effectively mean the derivative becomes ineffective. It is also not clear how this would work outside of pwm mode as there is no obvious point at which to take in additional samples.
The sampling_period parameter does accomplish a similar thing, namely you can enforce a window (say, 15 minutes) during which new values are rejected, and where with each new sampling period the integral is recomputed (thereby zeroing the derivative). While pwm window stretching means this isn't always a perfect match for your request, it is pretty close.
However, I think for this to be effective the derivative computation might need to be more involved so that we can update it continually and see e.g. a derivative spike during one cycle and then gradual tapering off over time, rather than zeroing it completely with the next cycle that observes a constant temperature...
Is your feature request related to a problem? Please describe. This proposal solves the issue that some temperature sensors update in seconds and others in several minutes, even hours if the temperature doesn't change. This issue produces calculations that either the controller doesn't act on them or leaves some components (like the derivative) unchanged in the case of some sensors. As an example, when the temperature falls from setpoint to e.g 0.1°C the derivative is calculated. Some sensors do not update their value in case the temperatures don't change. This leaves the derivative part intact leading eventually to an error.
Describe the solution you'd like Have another option to perform the calculations just before starting the heating cycle.
Describe alternatives you've considered For fast sensors setting the sample time is mandatory. For slow sensors, you can wait for sensor updates. Both look wrong since multiple calculations can occur without the controller acting in between.