Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automations override generic thermostat Away temperature #20154

Open
b4dpxl opened this issue Jan 16, 2019 · 13 comments
Open

Automations override generic thermostat Away temperature #20154

b4dpxl opened this issue Jan 16, 2019 · 13 comments

Comments

@b4dpxl
Copy link

@b4dpxl b4dpxl commented Jan 16, 2019

Home Assistant release with the issue:
0.85.1

Last working Home Assistant release (if known):

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

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

Description of problem:
I use automations to change the target temperature of my generic thermostat during the day. Setting away_mode changes this to the away temperature, but the next automation override this temperature. This means that away mode is not useful, as it will only last until the next scheduled change, and when turned off will revert to the originally stored temperature. The documentation states: "The away mode changes the target temperature permanently to a temperature reflecting a situation where the climate device is set to save energy. This may be used to emulate a “vacation mode”, for example." In order to use this for a vacation mode, it would also be necessary to disable all the relevant automations, or add a condition to check for away mode being on. However, this will also mean that the temperature will revert to what was stored when away mode was enabled, not the desired temperature for the current time.

Setting the temperature when away mode is active should update the stored temperature, not the target temperature.

Example:
Assuming an away_temp of 14'C and this schedule:

  • 08:00 - 20'C
  • 10:00 - 17'C
  • 17:00 - 20'C

Setting away mode at 09:00 changes the temperature to 14'C. At 10:00 this changes to 17'C, but away mode is still active. Disabling away mode at 12:00 sets the temperature to 20'C, not 17'C.

I want to be able to use away mode when the house is empty during the day. As a work around I've added a Condition to check the state of away mode when setting the temperature, but as mentioned this reverts the temperature back to the pre-away mode target, not the current desired target. It also over complicates the automations, as it's not possible to simply enable and disable away mode as people come and go using presence tracking.

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

 - platform: generic_thermostat
    name: Home
    heater: switch.sonoff_thermostat
    target_sensor: sensor.lounge_temperature
    away_temp: 14
    min_temp: 5
    max_temp: 22
    min_cycle_duration: 
      seconds: 5

- id: heating002
  alias: heating_morning
  trigger:
    platform: time
    at: 08:00
  condition:
  - condition: template
    value_template: "{{ states.climate.home.attributes.away_mode == 'off' }}"
  action:
  - service: climate.set_temperature
    data_template:
      entity_id: climate.home
      temperature: "{{ states('input_number.morn_temp') | float }}"

Traceback (if applicable):


Additional information:

@b4dpxl

This comment has been minimized.

Copy link
Author

@b4dpxl b4dpxl commented Jan 16, 2019

A very quick look suggests it might be as simple as changing the async_set_temperature method in climate/generic_thermostat.py. But I might be missing something.

    async def async_set_temperature(self, **kwargs):
        """Set new target temperature."""
        temperature = kwargs.get(ATTR_TEMPERATURE)
        if temperature is None:
            return
        if self._is_away:
            self._saved_target_temp = temperature
        else:
            self._target_temp = temperature
        await self._async_control_heating(force=True)
        await self.async_update_ha_state()```
@gadolithium

This comment has been minimized.

Copy link

@gadolithium gadolithium commented Jan 19, 2019

Same issue already opened here #17432. The fix is a one liner, someone with JS skillz anywhere ?

@b4dpxl

This comment has been minimized.

Copy link
Author

@b4dpxl b4dpxl commented Jan 19, 2019

#17432 seems slightly different, related to the wrong temperature being restored at start. This is related to an automation overriding the "permanent" away temperature when in away mode. I've tested the code I posted above in a custom component and that seems to fix this issue. I'll look into #17432 and create a PR for this in the mean time.

@b4dpxl

This comment has been minimized.

Copy link
Author

@b4dpxl b4dpxl commented Mar 1, 2019

Here's a very simple example to demonstrate the issue:

Assume this is the desired heating schedule. With generic_thermostat, this has to be achieved with automations AFAIK:

  1. Automation 1: sets the temperature to 18C at 8am, during the day
  2. Automation 2: sets the temperature to 12C at 10pm, overnight

When you go on vacation, enable away_mode; this sets the temperature "permanently" to the configured temperature of 10C, to prevent freezing, etc.

At this point, without putting conditions in the automations to check the away_mode, or disabling the automations, the automations will still change the temperature in accordance with the schedule. This is practically and functionally wrong, and completely negates the purpose of away_mode. Furthermore, using a condition in automations to not adjust the temperature when away_mode is set could also cause the temperature to be set to an undesired temperature when away_mode is removed. For example:

  1. away_mode is set at 7am: stored temperature is now 12C
  2. away_mode is turned off at 2pm: the target temperature is set to 12C, when it should be 18C according to the schedule described above.
@Misiu

This comment has been minimized.

Copy link
Contributor

@Misiu Misiu commented Apr 25, 2019

@awarecan any updates? I think the behaviour described by @b4dpxl is the desired one.

@b4dpxl

This comment has been minimized.

Copy link
Author

@b4dpxl b4dpxl commented Jul 7, 2019

With climate 1.0 on the horizon, there's obviously going to be no progress on this. There have also been comments made about generic_thermostat being a legacy/historic thing. At this point I'm tempted to wait for climate 1.0, see if it resolves the issues, and if not fork generic_thermostat into (I believe) the more appropriately named virtual_thermostat, and look to resolve some of the issues with the current component. This may even involve a rudimentary scheduler.

@Misiu

This comment has been minimized.

Copy link
Contributor

@Misiu Misiu commented Jul 22, 2019

@b4dpxl as commented here the problem still exists.

@awarecan any updates on this?

@b4dpxl

This comment has been minimized.

Copy link
Author

@b4dpxl b4dpxl commented Jul 22, 2019

@Misiu have you tried 0.96 then? I've not updated yet. Originally I'd considered adding a "set_scheduled_temperature" to handle this issue, but...

Integrations are only allowed to represent functionality that is present in the API.

@Misiu

This comment has been minimized.

Copy link
Contributor

@Misiu Misiu commented Jul 22, 2019

@b4dpxl not yet. I see a lot of issues with the climate in 0.96. I see no point to update when he thing I need still doesn't work as expected.
I'm waiting for a new PI, so I might give this a try on another instance.
The worst part is that devs don't want to even hear about fixing this.

@b4dpxl

This comment has been minimized.

Copy link
Author

@b4dpxl b4dpxl commented Sep 14, 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:

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.

@DB-CL DB-CL mentioned this issue Oct 17, 2019
6 of 7 tasks complete
@stale

This comment has been minimized.

Copy link

@stale stale bot commented Dec 13, 2019

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.

@stale stale bot added the stale label Dec 13, 2019
@b4dpxl

This comment has been minimized.

Copy link
Author

@b4dpxl b4dpxl commented Dec 13, 2019

This is still unresolved.

@stale stale bot removed the stale label Dec 13, 2019
@scacace

This comment has been minimized.

Copy link

@scacace scacace commented Dec 24, 2019

Related issue where hvac_mode off must be set in configuration.yaml because if heat is specified the Away mode setting is not being respected and runs at "none" hot setting, after HA Restart. Even tile has to be toggled a few times...Found a workaround by creating an Automation for home assistant start that marches through a series of initialization setting, ending in temperature and preset_mode as away. that works . The environment is HA generic thermostat with ecobee4 sensor controlling a Shelly1 wired into hotwater system 24V Tyco Valve and transformer, using REST local control. The small zone just did not warrant another smart thermostat. I am amazed it works even near the transformer through floors.

alias: "CoatRoom Reset on HA Start"
trigger:
platform: homeassistant
# Event can also be 'shutdown'
event: start
action:
- service: climate.set_preset_mode
data:
entity_id: climate.coat_room
preset_mode: 'away'
- service: climate.set_hvac_mode
data:
entity_id: climate.coat_room
hvac_mode: 'off'
- service: climate.set_preset_mode
data:
entity_id: climate.coat_room
preset_mode: 'away'
- service: climate.set_temperature
data:
entity_id: climate.coat_room
temperature: '50'
- service: climate.set_hvac_mode
data:
entity_id: climate.coat_room
hvac_mode: 'heat'

@DB-CL DB-CL mentioned this issue Feb 13, 2020
10 of 20 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

7 participants
You can’t perform that action at this time.