Update to generic thermostat breaks existing installs

[borpin]

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:

[borpin]

Is there any chance of this being fixed?

[Santobert]

According to the documentation this element is now called initial_hvac_mode

https://www.home-assistant.io/components/generic_thermostat/#initial_hvac_mode

[borpin]

According to the documentation this element is now called initial_hvac_mode

Indeed it is; the problem is less the name (but that annoys me - why break every installation), but the fact the modes have been changed so there is no auto anymore. i.e. the system is available for use i.e. on, but might not be heating or cooling. This fundamentally changes the nature of the component.

This has obviously been designed by someone who uses both heating and cooling and can not envisage a situation where you would want to turn off your HVAC (i.e. no heating during summer) and also have it on when it is neither heating or cooling (which is what auto did).

[Santobert]

I'm not sure if this helps you, but the current available hvac_modes can be seen here: https://github.com/home-assistant/home-assistant/blob/05ecc5a1355c7af11b5d310470a6171528dc7a2b/homeassistant/components/climate/const.py#L25

Be aware, that hvac_mode_auto is reserved for mechanisms like a schedule, learned behavior, AI or some other related mechanism. User is not able to adjust the temperature here. hvac_mode_heat_cool allows heating and cooling based on a given target temperature. The other modes are self explaining.

[borpin]

Ok so, in my case, I want to use the thermostat component to control my Under Floor Heating (UFH) - I have no mechanical heating. My heating is either off (cannot be switched on no matter what), on (is actually heating) or idle (can be called to heat if the temp falls below the target temp).

What initial mode should I use?

[Santobert]

Based on your explanation I would map your modes as following:

Your modes	hvac modes
off	off
on	heat
heat	heat_cool

The initial hvac mode depends on your need. I would go for heat_cool if that is supported.

[borpin]

But those modes you suggest do not correspond to the valid initial modes of off, heat, cool, which is exactly my point!

You have just proved it for me - thanks.

Be aware, that hvac_mode_auto is reserved for mechanisms like a schedule,

Which is exactly what I want to use it for (the Schedy add on) - so why is it not available as an initial mode?

https://github.com/home-assistant/home-assistant/blob/c58f3a4b4a2e9bc2170ca2e63e5a55c4a8814cf6/homeassistant/components/generic_thermostat/climate.py#L77-L78 This component needs the other modes made available as initial modes (as it used to have). At a minimum, it needs the IDLE mode available as initial mode. Note this mode can be set by the component itself. https://github.com/home-assistant/home-assistant/blob/c58f3a4b4a2e9bc2170ca2e63e5a55c4a8814cf6/homeassistant/components/generic_thermostat/climate.py#L282-L283

[Santobert]

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]

I'm afraid most of this isn't now to you, but I need that time to completely understand the thoughts behind that component. The generic thermostat doesn't support cooling AND heating. So there is no need to support any hvac modes besides off, cool and heat.

[borpin]

[good job I checked - my response will cross yours] I really do not want this to come across as negative - it isn't, HA is brilliant, I'd just love it to work properly :grin:. I run HA in a Hass.io docker and I have not found out how to make and test changes to the underlying code.

It looks like the generic thermostat component is not yet completely prepared for the climate 1.0 feature that introduced hvac_mode and preset_mode instead of operation_mode.

I'm not really clear what the 'Climate 1.0' feature is so cannot comment.

I have no idea why there can't be another hvac mode. Do you see a problem with removing this restriction?

The only issue would be that the other modes are not actually handled.

OK so I have looked through this code again to try and understand it and TBH the logic could do with some improvements :grin:. I could be wrong with my assessment below - I'm happy to be corrected.

AFAICS, the HVAC Mode is only set externally and actually does nothing wrt how the system is controlled. The key variable is the ac_mode. If TRUE the control acts as a cooler, if FALSE it acts as a heater in the _async_control_heating function. The log message (when switching the device on or off) even just refers to a 'heater' though this could be a cooling device being switched depending on the ac_mode variable.

https://github.com/home-assistant/home-assistant/blob/c58f3a4b4a2e9bc2170ca2e63e5a55c4a8814cf6/homeassistant/components/generic_thermostat/climate.py#L312 can set a device into a cooling HVAC mode even if ac_mode is false (i.e. no cooling function). This, of course, makes no difference to the actual operation.

The creation of an _hvac_list attempts to solve some this, but the list is never used.

As an aside, a too_hot and too_cold is created, but if the tolerance is zero, this will flip-flop the system between on and off every time it is called. It needs a just-right condition to do nothing. e.g. ac-mode = false (a heater), _is_device_active = false (i.e. the heater ius currently off) current temp = target temp, tolerance = 0, result is turn_on - that isn't right.

The solution I think is to add a condition where too_hot AND too_cold is true - do nothing.

To answer my question, it seems that it makes no difference what the initial mode is (heat or cool) it is the ac_mode that is the controlling mode.

[borpin]

I think the component needs to have a mode that is OFF (to turn it off completely) HEAT, COOL and HEAT_COOL - these just describe the functionality of the unit or how you want it to act (as a heater, a cooler or both).

It could support both modes.

[borpin]

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]

@Santobert - Version 0.101.2 of HA.

Adding in

    initial_hvac_mode : "heat"

breaks the component and it does not load correctly. The sensor value does not load.

climate:
  - platform: generic_thermostat
    name: "sunroom"
    heater: switch.ufh_heating
    target_sensor: sensor.filteredinttemp
    min_temp: 18
    max_temp: 22
    cold_tolerance: 0
    hot_tolerance: 0
    precision: 0.1
    initial_hvac_mode : "heat"
    away_temp: 16

Removing the initial_hvac_mode means it loads again.

I have the log viewer but no error seem to be generated.

[Santobert]

Please post all related logs here. Not only the lines shown by the log viewer. The generic thermostat wasn't changed in the past couple of weeks so your problem might be something different.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.