I have a climate entity on the generic-thermostat platform.
I have made use of the (only) two presets available in the platform: none and away.
I can select these presets in lovelace but what I find is …
In none preset I set a temperature of 21 - let’s call this setpoint A.
I then select away present and 10.0 is displayed - let’s call this setpoint B. This is correct because away_temp in yaml is set to 10.0
In away mode I increase setpoint B to from 10.0 to 18C
I switch back to none preset and setpoint A is displayed, i.e. 21C
When I switch back to away preset , setpoint B goes back to 10.0.
I want setpoint B to be stateful , so that it ‘remembers’ the previous value set and not keep resetting to 10.0. As in the 10.0C away_temp given in the yaml should be a default ‘bootup’ value only.
yaml:
# MAIN ENTITY
climate:
- platform: generic_thermostat
name: kitchen
heater: input_boolean.thermostat_heater_kitchen
target_sensor: sensor.trv_8206_temperature
target_temp: 18.0
min_temp: 10
max_temp: 23
cold_tolerance: 0.0
hot_tolerance: 0.0
initial_hvac_mode: "off"
precision: 0.1
away_temp: 10.0
input_boolean:
# HEATER DEMAND SWITCH
thermostat_heater_kitchen:
name: "Thermostat heater Kitchen"
automation:
# Send the setpoint to the TRV over MQTT
- alias: Thermostat Kitchen setpoint to TRV
initial_state: true
trigger:
platform: state
entity_id: climate.kitchen
attribute: temperature
action:
service: mqtt.publish
data_template:
topic: '/energenie/eTRV/Command/Temperature/8206'
retain: true
payload: "{{ state_attr('climate.kitchen','temperature') | int }}"
To my knowledge, this is just how generic_thermostat works.
Outside of altering the generic thermostat component to work the way you want it to, I can only see one other option.
Create an input_number to hold the away temp, and also set the “away_temp” in config to something you would never actually use. Then write two automations, one that sets the input number to whatever the away temp is, anytime it changes, unless it’s the number you set “away_temp” to in config. And another that sets the away_temp to whatever is in the input_number, if and only if the away_temp is set to the number you’d never actually use.
There are a few complicated parts to work around in all of that (like the away temp of the climate device not actually being visible to you unless it’s in away mode), but I think this should make the basic gist of the idea clear.
Correct. What you are doing there is changing the setpoint temperature which is independent of the away temperature. That’s why when you switch modes from away to none and back to away it’s the away temperature that is used (not the previous setpoint temperature you set). That’s how a standard thermostat work.
The behavior you want is non-standard. You’re faced with creating a means of altering the Generic Thermostat’s operation (described by swiftlyfalling) or foregoing it and making your own custom thermostat from separate entities and automations.
That’s the issue, …
When selecting away mode, the temp resets to 10C irrespective.
I think the away_temp is a quirk.
Maybe i need to setup the automation as you say and mode the setpoint on a seperate entity.
Ill have a crack tomorrow.
zzzzz now
Right… it’ll reset to 10. But, let’s say 10 is the number you selected that is an away temperature that you will never actually use. So, you have an automation that sees the “10” and immediately sets the temperature to whatever is in the input number. And you have another automation that sees a set temperature of anything OTHER than 10, and immediately store that in the input number.
Basically… it doesn’t do what you want it to do. So, you have to hack around it if that’s what you want. Or rewrite the component yourself.