I tried to do some tweaking, but seems I do something wrong…
I’m not running a master thermostat yet.
This is the output of the main zone, setpoint temperature was 21.1 degrees:
pwm_out is positive the whole time so it should toggle the switch (from off to on and back off) at least one time per 30 minuten. Do you register and hear activation of ‘switch.klep_open_gv_achter’ ?
The heating is working, that’s no issue, last on was about 10 minutes which is indeed 1/3 of 30 minutes. It just seems the ON time is way to short to reach the setpoint of 21.1 degrees. Current outdoor temp is 0 degrees, so not sure why weather compensation is 8% already.
Ok, good that it is operating. Evaluating your graph shows:
pwm_out: is positive and slowly rising
wc_valve_pos: is positive all the time (approx 30). thus want to heat
pid_valve_pos: starts negative and slowly rises.
pid_i: is negative and very slowly rising
`pid_d’: do not show to respond to dropping temperature
pwm_out is the sum of wc_valve_pos + pid_valve_pos. In the situation when the room temperature is above setpoint and the ‘wc control’ part specifies heat it will result in the pid_i part to compensate that (shown in the graph by the negative pid_i at the start). the pid_i only start to rise when the room temp is below the setpoint. In your case the pid_i might not change quick enough.
Some comments to your config:
kd is positive, I would expect a negative value.
do you use filter_mode ?
I think in you could try the following:
increase kp and ‘ki’ to react more and make more responsive to temp error
the wc might be requesting heat for too high outdoor temp . Changing to
Now the pid_i is the cause of the overshoot. You can seethe pid_i rising fast and dominating component to the pwm_out. the pid_p proportional part (part directly responding to the setpoint and actual room temp) is only responding with approx 20 at max. pid_d is still not contributing.
First step is too reduce pid_i to 0.005. This will result in a slower build-up of the integral. Hereafter, depending its response, the pid_d needs probably adjustment.
It has improved indeed. Floor heating reacts slow so you need almost 12 hours to see the effect of changes.
pid_d is responding to the rate of temperature change (velocity of temperature change). At approx 1hr the temperature is not rising or dropping (velocity=0) however the pid_d is zero at 5hr, thus quite some lag is present. I would recommend to change the filter_mode to 1, this should reduce the lag.
Probably the pid_i is slightly too high as well and changes too fast.
You could try to increase the pid_p with 10 . Probably you will need to increase the pid_d as well, but I would recommend to change one at the time.
The graphs also show that the heat loss is low (takes a long time to cool down) and the floor heating reacts slowly (one of your previous graphs show a pwm peak and the room temperature reaching its peak 6hrs later). Thus this will be a limit how reactive you could make the thermostat. So you probably will not be able to to heat up the room within an hour (or even 2-3hr) or use a significant lower setpoint at night.
@axax many thanks for all this support, you’re a PID wizard
Temperature indeed isn’t changed over night, this isn’t possible with inertion in our system, so it’s always at 21 degrees.
When you say increase pid_d, as it’s negative, you mean -25000 → -20000 for example ?
The pid_d might need to lower, for instance -30000. When you first start with the increase of the pid_p it could result in a oscillation of the room temperature. In such case more extreme pid_d (lower) could help to stabilise it again.
A new version v0.7 has been released including numerous improvements, bug-fixes, new features and some breaking changes. Please see release notes for full details.