jmcollin78 / versatile_thermostat

A full featured Thermostat for Home Assistant: presets, window, motion, presence and overpowering management
MIT License
346 stars 38 forks source link

Scheduler overrides open window state #584

Closed LazyT closed 1 month ago

LazyT commented 1 month ago

Version of the custom_component

6.4.1.beta1

Configuration

My VTherm attributes are the following:

hvac_modes: off, heat
min_temp: 7
max_temp: 35
target_temp_step: 0.1
preset_modes: none, frost, eco, comfort, boost
current_temperature: 22.3
temperature: 10
hvac_action: idle
preset_mode: frost
is_on: true
hvac_mode: heat
type: null
is_controlled_by_central_mode: false
last_central_mode: null
frost_temp: 10
eco_temp: 17
boost_temp: 24
comfort_temp: 21
frost_away_temp: 10
eco_away_temp: 15
boost_away_temp: 22
comfort_away_temp: 19
power_temp: null
target_temperature_step: 0.1
ext_current_temperature: 15.7
ac_mode: false
current_power: null
current_power_max: null
saved_preset_mode: frost
saved_target_temp: 10
saved_hvac_mode: null
motion_sensor_entity_id: null
motion_state: null
power_sensor_entity_id: null
max_power_sensor_entity_id: null
overpowering_state: null
presence_sensor_entity_id: person.thomas
presence_state: on
window_state: on
window_auto_state: off
window_bypass_state: false
window_sensor_entity_id: binary_sensor.k_kontakt_fenster_offnung
window_delay_sec: 0
window_auto_enabled: false
window_auto_open_threshold: null
window_auto_close_threshold: null
window_auto_max_duration: null
window_action: window_frost_temp
security_delay_min: 60
security_min_on_percent: 0.5
security_default_on_percent: 0.1
last_temperature_datetime: 2024-10-26T12:40:29.724229+02:00
last_ext_temperature_datetime: 2024-10-26T13:19:23.385859+02:00
security_state: false
minimal_activation_delay_sec: 10
device_power: 1
mean_cycle_power: null
total_energy: 0
last_update_datetime: 2024-10-26T13:21:19.603412+02:00
timezone: Europe/Berlin
temperature_unit: °C
is_device_active: false
ema_temp: 22.33
is_used_by_central_boiler: false
is_over_climate: true
start_hvac_action_date: null
underlying_climate_0: climate.k_thermostat_thermostat_3
underlying_climate_1: null
underlying_climate_2: null
underlying_climate_3: null
auto_fan_mode: auto_fan_none
current_auto_fan_mode: auto_fan_none
auto_activated_fan_mode: null
auto_deactivated_fan_mode: null
auto_regulation_use_device_temp: false
friendly_name: VT-K
supported_features: 401

Describe the bug

Scheduler overrides the window open state and underlying starts heating (like #537).

I'm trying to:

VTherm should be controlled by scheduler to set eco/comfort preset but respect the window sensor open/close state.

And I expect:

If the scheduler kicks in it should set the VTherm preset. But if VTherm detects an open window it should not set the underlying to start heating.

But I observe this:

Scheduler sets new preset for VTherm, Window is detected as open, underlying thermostat starts heating with new preset.

Close and open the window sets the underlying correct back to frost (or off).

BTW: since 6.3.0 the version is not increased. Under integration it shows 6.3.0 and under HACS 6.4.1? So I'm not sure what is correct.

I'm new to HA and VTherm so maybe I configured something wrong. But until the scheduler kicks in everything works as expected...

Thanks!

jmcollin78 commented 1 month ago

Hello @LazyT,

Thank you for the complete report ! I have all information to do a complete response at the first time.

I just answered exactly the same case today. This is because you choose to only change the preset when open window is detected. I see that in your state:

window_action: window_frost_temp

If I ignore the preset change from Scheduler, the preset will be restored to the value BEFORE window was detected as open and you will not be satisfied more.

I have to make a choice:

  1. I accept the preset change and sometimes, it will turn off a heater while the window is open but the preset is correctly changed and when the window will close, the user will be happy with the temperature,
  2. I refuse the preset change and when you close the window the VTherm will stay to the old preset and the user will be not happy with temperature.

I choose the 1. which seems to be not frequent and generate less unsatisfaction from a user point of view.

Note: I cannot use the save_preset attribute because it is used potentially in other context and some side effect are still possible.

I hope you understand.

I close the issue as I will not fix it. Don't hesitate to reopen if you think I'm wrong