Multizone thermostat incl various control options

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:


And this is my config

  heat:
    entity_id: switch.klep_open_gv_achter
    switch_mode: 'NC'
    passive_switch_duration:
      days: 7
    initial_target_temp: 21
    away_temp: 15
    proportional_mode:
      control_interval:
        minutes: 15
      pwm_duration:
        minutes: 30
      pwm_scale: 100
      pwm_resolution: 50
      pwm_threshold: 5
      PID_mode:
        kp: 15
        ki: 0.001
        kd: 6000
      weather_mode:
        ka: 2
        kb: -10

I read an article on the PID settings, but it isn’t reallt clear.

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
pid:
    kp: 35
    ki: 0.05
    kd: -50000
wc:
    ka: 1.75
    kb: -18

You can set these via services which keep the current thermostat running. Note you need to update the config at the end when it is running fine.

  • pid via (i think something like) multizone..set_pid and
  • reset the integral multizone..set_integral (note that this not give a direct result but you have to wait for the next pwm loop)

At the bottom of the example you can pre-fill the service with an example to ease filling in.

I made the modifications.
filter_mode: 2 is used
This is the result (still 21.1 as setpoint)


So it heats up faster now but overshooting…

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.

We’re going in the right direction I guess…


Still some overshoot.
Now should I change pid_d which stays behind, it seems not doing much…
Changed pid_d to -25000.

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.

Could you try the following

filter_mode: 1
pid_i: 0.001

These are the last 12 hours… It seems it should get quicker to the desired temperatue

    PID_values:
      - 35
      - 0.001
      - -25000
...
    ab_values:
      - 1.75
      - -18

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 :slight_smile:
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.

Note that success is not guaranteed :wink:

1 Like

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.

1 Like