Preset not displayed on panel, disappears from popup when mode is selected

[mat1990dj]

So I can't get the presets to work.
This is how my config looks:
- platform: dual_smart_thermostat initial_hvac_mode: "off" name: Kitchen heater: switch.hvac_w_heat cooler: switch.hvac_y_cool target_sensor: sensor.kitchen_temperature min_temp: 60 max_temp: 80 target_temp: 70 cold_tolerance: 1 hot_tolerance: 0 min_cycle_duration: seconds: 5 keep_alive: minutes: 10 away_temp: 65 eco_temp: 67 comfort_temp: 70 anti_freeze_temp: 60 precision: 1
When restarting HA, the card looks like that (no presets):

When opening the popup, the presets show up, but don't work:

As soon as I select heating, presets dissappear:

[dinostapler]

Same issue. Pretty disappointing, had to switch back to generic thermostat

[alvarocarrera]

This is because the thermostat does not recover the previous state when it starts up, instead it is set in the "no mode" mode and sets the temperature to whatever is specified in the yaml configuration. This was mentioned in the last pull requests made by @ollo69 a few days ago, and I am sure that the main maintainer @swingerman known this issue.

For sure, I would like to add this feature too. Now, I have an automation that makes some decisions and configure every dual thermostat every time HA starts, but if the last state (target temperatures, mode and preset_mode) would be restored I would be really happy. :)

If any contributor (@ollo69 or @swingerman or me, if I find some time...) tries to attack this issue/feature request, I could help a bit if required. :)

Anyway, @dinostapler I think this thermostat if this feature is added, is much better than the generic thermostat if you have a heat/cool air conditioner as heater/cooler.

[alvarocarrera]

Even more... I found the key lines of code that make this possible in climate.py (lines 390-428). I will develop a bit during the weekend. :)

[ollo69]

@alvarocarrera,

I'm working on this past days, I think I will release a PR tonight or tomorrow. Just to avoid to make job 2 times...

[dinostapler]

You guys are great. Thanks!

[swingerman]

@dinostapler @alvarocarrera
Please check v0.7.0 and let us know if the issue is fixed.
Thanks a lot @ollo69 !

[alvarocarrera]

Unfortunately, now it is not working for me, I will keep in v0.6.7:

1. I use heat_cool mode in all my thermostats (there are heatl/cool air conditioner machines), and it is said: "N.B. Presets are not available for heat_cool mode." why? 😢 So... not works, it is a pitty. But, only for understanding, @ollo69 why presets are not available for heat_cool mode? It generates some error?
2. The min_cycle_duration (which is a great feature for the health of this kind of machines, to avoid short cycles) is not working at all in v0.7.0. This is a real issue. The previous one is only a lack of features. But this is important to solve.

So I will keep in v0.6.7 by now.

Maybe the easier way this could be solved is adding a property in the yaml configuration with a list of preset you want in your thermostat, i.e.:

presets: 
  - home:
      - target_temp_high: 26
      - target_temp_low: 20 
  - away:
      - target_temp_high: 28
      - target_temp_low: 18 
  - eco:
      - target_temp_high: 25
      - target_temp_low: 19
  - anti_freeze:
      - target_temp: 10

This would be the initial configurations that would be set up with the initial_hvac_mode. Later, when restored, it will ignore the temps but uses the presets names to enable the presets in the HA thermostat configuration.

@swingerman @ollo69 what do you think about this proposal?

[ollo69]

1. I use heat_cool mode in all my thermostats (there are heatl/cool air conditioner machines), and it is said: "N.B. Presets are not available for heat_cool mode." why? 😢 So... not works, it is a pitty. But, only for understanding, @ollo69 why presets are not available for heat_cool mode? It generates some error?

Preset just define 1 temperature, heat_cool need 2. For this reason preset are not available in heat_cool mode. I don't understand how in 0.6.7 preset was working in heat_cool mode

2. The min_cycle_duration (which is a great feature for the health of this kind of machines, to avoid short cycles) is not working at all in v0.7.0. This is a real issue. The previous one is only a lack of features. But this is important to solve.

What is exactly the issue in min_cycle_duration? I tested it and was working for me, and the only change that I apply was related to cool mode where a check was missing.

Maybe the easier way this could be solved is adding a property in the yaml configuration with a list of preset you want in your thermostat,

Yes, I agree with you, in this way preset could work also for heat_cool mode because we have the 2 temperature needed for this mode.

[alvarocarrera]

Preset just define 1 temperature, heat_cool need 2. For this reason, preset are not available in heat_cool mode. I don't understand how in 0.6.7 preset was working in heat_cool mode

Indeed I was using the preset mode as a "label", when it changes, automation set the temperature properly to low/high values. So, it is true that the thermostat "was not working with low/high" configuration. I was changing them with external automation (depending on preset, time/electricity cost in real-time). For instance:

• if we are at home:
  • the electricity is cheap:
    • increase target_temp_low (heat) a lot (i.e. 22). (useful during the winter)
    • decrease target_temp_high (heat) a lot. (i.e. 25) (useful during the summer)
  • the electricity is expensive:
    • increase target_temp_low (heat) a bit. (i.e. 20) (useful during the winter)
    • decrease target_temp_high (heat) a bit. (i.e. 27) (useful during the summer)
• if we are away:
  • the electricity is cheap:
    • increase target_temp_low (heat) a bit (i.e. 19). (useful during the winter)
    • decrease target_temp_high (heat) a bit. (i.e. 28) (useful during the summer)
  • the electricity is expensive:
    • switch off directly

And that is the way I was using presets ignoring the temp set as "away_temp" or "eco_temp". Because every time the preset changed, I reconfigure the low/high target temps with automation. This works during the whole year (winter or summer) without changing any configuration or automation.

What is exactly the issue in min_cycle_duration? I tested it and was working for me, and the only change that I apply was related to cool mode where a check was missing.

I don't know... Maybe it is related to the "non-configuration" of the preset mode, but this morning I tried it and the air conditioner stops in a few seconds (with the min_cycle_duration configured to 1 hour).

[ollo69]

Indeed I was using the preset mode as a "label", when it changes, an automation set the temperature properly to low/high values.

Ok, but this means that for now it is correct to disable this, because preset mode should not just be a "label". It should be clear for you but should confuse most of the users having a preset that simply do nothing.

I don't know... Maybe it is related to the "non-configuration" of the preset mode, but this morning I tried it and the air conditioner stops in a few seconds (with the min_cycle_duration configured to 1 hour).

This should be better analyzed, please provide clear case for this issue (may be open new one). I agree with you that min_cycle_duration is important feature and if really there is an issue it should be fixed.

[alvarocarrera]

Ok, but this means that for now it is correct to disable this, because preset mode should not just be a "label". It should be clear for you but should confuse most of the users having a preset that simply do nothing.

+1. You are right, I was not using the component "as is", and that confuses other users. When I find time I will change the yaml configuration to allow the preset dictionary as input in the proposed format.

This should be better analyzed, please provide clear case for this issue (may be open new one). I agree with you that min_cycle_duration is important feature and if really there is an issue it should be fixed.

+1. I will test it asap. But I think I will not find enough time in the following days (a lot of work). Sorry. 😞

[alvarocarrera]

oh man! thanks a lot! @ollo69 I will test as soon as published. btw, thanks a lot for the ha-smartthinq-sensors component (I browsed your profile hehe), it is super useful too for scheduling my washer/dryer in the cheapest hours of electricity costs.

[alvarocarrera]

I have installed v0.7.1 and I have tested that preset and target temps are properly restored. But I have noticed the following undesired behaviour (or I think it is undesired).

I configure the preset mode "home" as follows:

home:                                                                                                                                                                                             
  target_temp_low: 20                                                                                                                                                                                
  target_temp_high: 26

but if I move any temp in the GUI (for instance: target_temp_low to 21), the thermostat exits preset "home" and returns to preset mode "none". And then, it is restored to "none" default low/high temps (when HA restarts), because it is in "none" when restarted. In other words, "the preset not displayed on panel" as the title of this issue says.

I found the lines responsible for this behaviour in the code (lines 661-662), but I think these lines should be simply deleted. If I change the temperature, I am not changing the preset (I am still at home). But, it depends of what we are understanding as preset (a fixed configuration or a status/label). For anti-freezee, eco or comfort, a fixed configuration has sense. But, for away/home is a status, that could be modified for different reasons.

Summarising, this is a design decision, not a bug/issue. So, we can talk about it. :)

Moreover, I suggest another change/feature (but related), the temperature (target, target_low or target_high) should be restored always, not only if not in configuration YAML. It means the first time I start a thermostat or when I change the preset, the temperature is set as specified in the configuration YAML. But, if I restart HA for any reason, I would like to return my last working configuration (as if nothing would have happened), not to the default one.

[ollo69]

if I move any temp in the GUI (for instance: target_temp_low to 21), the thermostat exits preset "home" and returns to preset mode "none". And then, it is restored to "none" default low/high temps (when HA restarts), because it is in "none" when restarted. In other words, "the preset not displayed on panel" as the title of this issue says.

In my mind, because preset is not just a label but represent a specific temperature or range of temperatures, if I change those temperatures means that that preset is not selected anymore. As you said this are point of view, there are no written rules.

Moreover, I suggest another change/feature (but related), the temperature (target, target_low or target_high) should be restored always, not only if not in configuration YAML. It means the first time I start a thermostat or when I change the preset, the temperature is set as specified in the configuration YAML. But, if I restart HA for any reason, I would like to return my last working configuration (as if nothing would have happened), not to the default one.

In this case I just follow the same rules of HA generic_thermostat, that for me make sense. If the temperatures are in configuration file, it will use those values. If not, it restores from previous state or use default values on first start (min and max generally speaking). I think that this provide more flexibility, because allow the user to choose what to do (always restart with same values or restore previous one). If we always restore, first option is lost.

[swingerman]

I think we should change the current logic.
It feels not handy that if I change to a preset mode and then adjust the target temperatures, the preset mode is gone. The UI is there to make such changes easy, not to go to the yaml configuration.

I am currently going through all features, trying to cover them with tests fully, and I will change this behaviour as such:

• allow modification of the preset mode target temperatures on the UI without changing back to none
• restore these on restart or reload as we expect our smart home to work as it was before any reason for restarting
• apply preset mode temperatures from the yaml only when changing preset modes