core: Update to generic thermostat breaks existing installs

Home Assistant release with the issue:

0.96.5

Last working Home Assistant release (if known): 0.96.5

Operating environment (Hass.io/Docker/Windows/etc.):

Hass.io on a VM Component/platform:

Generic_thermostat

Description of problem: Removal of the configuration item initial_operation_mode has broken my setup and removed an important operation auto.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

  - platform: generic_thermostat
    name: "sunroom"
    heater: switch.ufh_heating
    target_sensor: sensor.FilteredIntTemp
    min_temp: 15
    max_temp: 22
    cold_tolerance: 0
    hot_tolerance: 0
    precision: 0.1
    initial_operation_mode: "auto"
    away_temp: 16

Traceback (if applicable):

Additional information:

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 15 (6 by maintainers)

Most upvoted comments

Be aware, that hvac_mode_auto is reserved for mechanisms like a schedule, learned behavior, AI or some other related mechanism.

Sorry, just thinking about this - just because the system is in auto, this should not prevent a user deciding that, at this point in time, they want a different target temp. Auto to me means let the component decide what to do (heat cool etc) based on the data passed to it under normal circumstances. If I change the requirements and override a schedule or AI, then the system should automatically decide what action to take to meet the new required target temp.

(Thinking out loud here). I think the thing is that it is a binary switch so can only do one function (as the description says) but there appear to be 2 modes controlling the same thing. I suspect the original intention was to control both heat and cooling functions.

If you assume a binary switch and this is a generic ‘climate’ control (so usable for extract fans, dehumidifiers, heat, cool) and might use environmental parameters other than just temp (e.g. humidity, CO2). At this point, it becomes simply a ‘stat’ (thermostat, humidistat etc) and the important setting is whether it comes on or goes off at the trigger point. So for humidity, it is used when it is too humid (usually). For heating when it is too cold it comes on. For CO2 it comes on when the CO2 is too high. This is basically what the ac_mode does.

HTH

borpin on Sep 10, 2019

Ah now I got it. The generic_thermostat component should adapt a ‘dumb’ climate, that can be turned on or of depending on a temperature. The thermostat can either cool or heat, depending on the configuration of ac_mode. https://www.home-assistant.io/components/generic_thermostat/#ac_mode

You can see this here: https://github.com/home-assistant/home-assistant/blob/c58f3a4b4a2e9bc2170ca2e63e5a55c4a8814cf6/homeassistant/components/generic_thermostat/climate.py#L163 and here: https://github.com/home-assistant/home-assistant/blob/c58f3a4b4a2e9bc2170ca2e63e5a55c4a8814cf6/homeassistant/components/generic_thermostat/climate.py#L165

self._hvac_list contains all available hvac_modes for that device. So the restriction is correct, that the initial hvac_mode has to be in this list. The hvac_action supports off, idle, cool and heat: https://github.com/home-assistant/home-assistant/blob/c58f3a4b4a2e9bc2170ca2e63e5a55c4a8814cf6/homeassistant/components/generic_thermostat/climate.py#L275

hvac_action describes the current action. Idle is used here to show that the device is currently not active, which happens when you unplug the device or something like that.

So back to your problem: I don’t think that the generic thermostat can completely adapt you heater because the thermostat is only able to toggle a switch. https://www.home-assistant.io/components/generic_thermostat/#heater

So your heater should default to heating. The generic thermostat component switches the heater on or off depending on the room temperature. The initial hvac_mode should set to the default mode, that is used by your heater.

Santobert on Sep 10, 2019