Recommended settings for master thermostat

[stomko11]

I am trying to configure master thermostat. Looking at examples in the repo, it seems that master settings are bit different from satellites. I am trying to figure out what would be the recommended setting depending on satellite setting. I have 7 satellites, using underfloor heating with long reaction time. Here is one of examples:

- platform: multizone_thermostat
  name: living_room
  unique_id: living_room
  sensor: sensor.living_room_temperature
  filter_mode: 2
  room_area: 50
  initial_hvac_mode: "heat"
  initial_preset_mode: "none"
  precision: 0.5
  heat:
    entity_id: switch.underfloor_heating_living_room
    min_target_temp: 17
    max_target_temp: 28
    initial_target_temp: 20
    extra_presets:
      "Away 20": 20
      "Away 17": 17
    passive_switch_duration: 
      hours: 20
    passive_switch_opening_time:
      minutes: 7
    proportional_mode:
      control_interval:
        seconds: 180
      pwm_scale: 100
      pwm_threshold: 5
      pwm_duration:
        hours: 2
      PID_mode:
        kp: 100
        ki: 0.003
        kd: -220000
  sensor_stale_duration:
    hours: 12
  passive_switch_check: true
  passive_switch_check_time: "23:15"
  restore_from_old_state: False
  restore_parameters: False
  restore_integral: False

[vindaalex]

- platform: multizone_thermostat
  name: living_room
  unique_id: living_room
  sensor: sensor.living_room_temperature
  filter_mode: 2
  room_area: 50
  initial_hvac_mode: "heat"
  initial_preset_mode: "none"

  # to be honest: I think it only affects step size for temperature but could also affect actual temperature display
  # best to try with 0.1 first and later test 0.5
  precision: 0.1

  heat:
    entity_id: switch.underfloor_heating_living_room
    min_target_temp: 17
    max_target_temp: 28
    initial_target_temp: 20

    # removed the white spaces, as precaution. (I'll do a test later this week if spaces will give issues)
    extra_presets:
      Away_20: 20
      Away_17: 17

    # from what I've read a run each month should be sufficient
    passive_switch_duration: 
      months: 1
    passive_switch_opening_time:
      minutes: 3

    proportional_mode:

      # PID update each 30 min should be sufficient
      control_interval:
        minutes: 30
      pwm_scale: 100
      pwm_threshold: 5

      # pwm cycle of 1 hour is probably a good start point. 
      # Longer might limit nesting and responsiveness
      pwm_duration:
        hours: 1

      # Have these settings already been used? kp and kd (but less) seems quite large.
      # alternative could be kp: 20 ; ki: 0.003, kd: -150000
      PID_mode:
        kp: 100
        ki: 0.003
        kd: -220000

  # shorter sensor stale would avoid too long operation without knowledge of the actual room state
  sensor_stale_duration:
    hours: 5

  passive_switch_check: true
  passive_switch_check_time: "23:15"

  # first start clean without using old data
  restore_from_old_state: False
  restore_parameters: False
  restore_integral: False

# MASTER, this synchronises and coordinates the satellites valve opening
- platform: multizone_thermostat
  name: master # used name is overruled to master to assure satellites can find it
  unique_id: mz_master

  # start master off and manually start after reboot for safety
  initial_hvac_mode: "off" 

  initial_preset_mode: "none"

 # TODO FILL SUM OF FLOOR AREA OF HEATED ROOMS
  room_area: 142 

  # be careful for the master stuck switch check
  # depending the configuration it could trigger the heating or cooling device to start
  passive_switch_check: False

  precision: 0.1 # I think not relevant here. stepsize of set point

  # show detail control output (use only for config 
  # or debug to avoid log size issues)
  detailed_output: False

  # configuration for heating mode
  heat:

    # TODO FILL YOUR RELAY HERE
    entity_id: switch.main_valve

    extra_presets:
      Away_20: 20
      Away_17: 17

    # configuration required for master
    master_mode:

      # TODO FILL YOUR LIST OF ROOMS HERE
      satelites: [living, sl1]

      # nesting routing at first start with balanced and experiment later with other options (continuous)
      operation_mode: "balanced"

      # minimum percentage of master room size of rooms with open valves. 
      # used for nesting (scheduling of opening and closing of satellites)
      lower_load_scale: 0.2

      # any change from satellite would trigger a nesting check. Not a re-nesting but only 
      # minor pwm duration shift are taken into account
      control_interval:
        hours: 1

      # cycle interval for pwm. 
      pwm_duration:
        hours: 1

      # scale wherein pwm operates. Thus here is operates between 0-100 where 0 is 
      # valve closed and 100 valve open the whole pwm cycle
      pwm_scale: 100

      # number of steps in pwm scale. a resolution of 50 and pwm scale 100 results in stepsize 2
      pwm_resolution: 50

      # only open valve when pwm requirement is above threshold
      pwm_threshold: 4

      # percentage of pwm_scale to open when a proportional valve requires heat.
      # avoids for proportional valves too short opening of master valve
      min_opening_for_propvalve: 0.15

  # first start clean without using old data
  restore_from_old_state: False # restore changes made via service calls
  restore_parameters: False # yaml config is overrulled by services modified settings 
  restore_integral: False # PID integral restored to continue with previous pid setpoint

[stomko11]

Thanks. I was confused about example here: https://github.com/vindaalex/multizone-thermostat/blob/refactor/examples/multizone%20thermostat%20-%20explanation.yaml

This one had PID_valve_mode configured even for master. But your example above does not have it. So I have removed it. I have configured dummy switch for now, just to compare actual behavior vs. what would master thermostat do. Once it looks OK, I will switch that and adjust my automation.

I am wondering if there are any good recommendations, such as for different types of heating, what would be recommended starting values for PID mode. I know it took me quite a while to set that for my house.

[vindaalex]

The 'pid valve' was a bit of a try-out but currently intginknit more disrupts the control than improves. Probably in one of the next releases I might remove it.

Note when you configure the master it will schedule the satellites when to open. The duration itself is not altered by the master. So the heat pump relay is now indireclty triggered by your automation routine instead of the thermostat itself. So both should more or less the same behavior.

Regarding PID recommendations, I think with the input of users gradually some guidance can be made. It will depend on quite some parameters, like:

• electric or water based heating system
• radiator/floor/air heat transfer
• capacity of the heating system
• building heat loss

[stomko11]

Thanks for responses. In regards to pwm_duration, with 1 hour setting, I get behavior when zone valve opens for 5 minutes and closes, and that cycles every hour. With pwm_duration set to 2 hours, that period was at least 10 minutes. 5 minutes is too low given the fact that it takes 2-5min just to open valve. Is there any setting where I could force minimal cycle duration to 10-15 minutes, without changing pwm_duration?

[vindaalex]

You could try to increase the pwm_threshold : the control_output needs to rise above pwm_threshld / pwm_scale * pwm_duration before the valve is opened. Downside when pwm_threshold is too high is that the room temperature could drop further before heating starts, thus larger temperature oscillations.

[stomko11]

So I have been running with master for few days now, and noticed this evening weird behavior - as you can see in picture, after 19:30 there was no longer demand for heat, yet master stayed on.

Not sure why would that be. Here is my master configuration:

- platform: multizone_thermostat
  name: master_thermostat
  unique_id: master_thermostat
  initial_hvac_mode: "heat"
  initial_preset_mode: "none"
  room_area: 190
  passive_switch_check: False
  precision: 0.5
  detailed_output: false 
  heat:
    entity_id: switch.heat_pump_switch
    extra_presets:
      "Away 20": 20
      "Away 17": 17
    master_mode:
      satelites: [living_room, guest_room, bathroom, office, kids_room, master_bedroom, master_bathroom]
      operation_mode: "balanced"
      lower_load_scale: 0.2
      control_interval:
        hours: 1
      pwm_duration:
        hours: 1
      pwm_scale: 100
      pwm_resolution: 50
      pwm_threshold: 4
      min_opening_for_propvalve: 0.15
  restore_from_old_state: False
  restore_parameters: False
  restore_integral: False

[vindaalex]

Hm, strange indeed. In seems that it triggered to switch on again by the 2 'ON' marks next to each other. Could you enable debug for the 'multizone_thermostat' via services and post the log when it happens again?

edit: debug for multizone_thermostat

[vindaalex]

One additional questions.

Are you still running the master climate parallel to your own automation routine which checks the satellites and based on that turns the master on? Could this one have triggered the 2nd time master on? You might be able to see the trigger at the history of the switch?

[stomko11]

I looked at it, and it does seem like my automation triggered exactly at 19:30:00 twice within second. I am suspecting that maybe thermostat decided to turn off intentionally because of no heat was required, and at exactly that time, it turned on again. My automation is scheduled to run every /5 minutes and basically just says - if switch is ON, send switch.turn_on again to prevent fail safe to kick in. In any case, I have changed schedule to be less frequent and not every 5 minutes, and I have increased auto-off on switch to ±40 minutes. I will keep monitoring that behavior as this was the only time i saw it going mad so far.

[vindaalex]

Did you continue monitoring and have any additional feedback? I've released a new version and updated the examples with more explanatory notes. Please re-open if you have any comments