core: Invalid restored state of generic thermostat in AWAY mode

Home Assistant release with the issue:

0.87.1

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

OpenWRT/Virtualenv

Component/platform:

https://www.home-assistant.io/components/climate.generic_thermostat/

Description of problem:

HASS can’t restore last state of generic thermostat when away_mode was set to True. Actually, after the restart of HASS we have away_mode = True but target_temp is used instead of away_temp

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

- platform: generic_thermostat
  name: Cabinet Floor
  heater: switch.cabinet_heater
  target_sensor: sensor.cabinet_floor_temperature
  min_temp: 20
  max_temp: 25
  target_temp: 23.5
  away_temp: 20
  ac_mode: false
  cold_tolerance: 0.01
  hot_tolerance: 0
  keep_alive:
    minutes: 30
  initial_operation_mode: "auto"

The issue appeared after this commit https://github.com/home-assistant/home-assistant/commit/5c3a4e3d10c5b0bfc0d5a10bfb64a4bfcc7aa62f#diff-c3adb9f4cba8997d9148dc1a780f3276 by @armills

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 30 (11 by maintainers)

Most upvoted comments

Guys, I have to say that THERE are people who use generic_thermostat. Even more, I’m quite happy with it for the last 3 months or so. And I know some people who say it works fine and restores changed temperature settings after restart - not quite, all those people DO NOT use away_mode.

Yes, the away_mode thing itself is a bad side of it. It is not designed to store changed temperature in that mode - even if you turn away_mode on, change temperature, turn off and back on, you’ll get the default value of away_temp from your climate: section. Weird. It does not restore correct temperature if restarted with away_mode enabled - you’ll end up with away_mode enabled AND target temperature set. If you don’t put away_temp in your config, you’ll have no away_mode. If you put it there, it won’t be saved between HA restarts for obvious reasons.

I wrote some automation to save all parameters of the component on its state change to input_xxx and then restore them on HA start. That works fine, but does not help if I want to preserve changed temperature if I enable away_mode and change it (as described above).

I had a discussion about it with @awarecan and have to say I’m not very optimistic about the future of the component and this Issue in particular as apparently nobody cares about it. Here is even worse example of the current state of affairs.

akasma74 on Mar 12, 2019

As the issues are still present in 0.98 (I skipped 0.96/0.97), and there seems to be some general apathy towards generic_thermostat, I’ve forked it into a new virtual_thermostat custom component:

https://github.com/b4dpxl/virtual_thermostat

It’s working so far for me. The only thing it doesn’t help with is changing the away_temp dynamically, but that’s not something I want. I don’t want people to be able to override it from the UI, they should disable away instead. I think this should also resolve this problem.

b4dpxl on Sep 14, 2019

ivankravets on Jan 26, 2021

It means that people don’t use this project seriously. Just to play with ON/OFF buttons. The architecture is also bad, components (plugins) are mixed with the core code. Every week we have new releases. I gave up to update it… Why we can’t have CORE engine and integration API with plugins/components marketplace?

ivankravets on Mar 12, 2019