I tried your automation. Then my heater started turning on by itself. Beware: if your temperature sensor becomes unavailable sometimes, this automation will just turn on your heater when it becomes available again, even if you turned off the thermostat long ago. HA needs to have a failsafe built into the generic thermostat, since these automations can’t keep state.
That’s what the automation is designed to do. Its second trigger is responsible for that. Feel free to change it if it’s not the behavior you want.
It’s only designed for a situation where it assumes you will never turn off your thermostat.
I wrote a better automation to turn off the heater if its sensor becomes unavailable/unknown for more than 10 minutes (this removes most of the need to turn the heater back on, since it won’t trigger on short-lived sensor outages) or if the temperature gets way higher than your desired one for some reason, as an additional failsafe.
It’s not as good as a real failsafe that can keep state, but it’s not too bad. It won’t restore the heater if your sensor is dead for more than 10 minutes (or however long you can change it to), but it also won’t burn down your house by turning on your heater by itself after you’ve manually turned it off just because your sensor went offline for a second.
- id: 'turn_off_generic_thermostat_in_emergency'
alias: Turn off Generic Thermostat in emergency
mode: single
trigger:
- platform: numeric_state
entity_id: sensor.temperature
above: 79
id: high
- platform: state
entity_id: sensor.temperature
to:
- "unavailable"
- "unknown"
for:
minutes: 10
id: unknown
condition:
- condition: state
entity_id: climate.thermostat
state: heat
action:
- service: climate.turn_off
target:
entity_id: climate.thermostat
Such needless drama …
From the ‘needless drama’ playbook: Allowing the temperature to drop below freezing and causing pipes to burst, flooding the house, and drowning the cat. 
It’s possible to restore the entity’s previous state (whatever it might have been). I’ll give you a hint: Store the first State Trigger’s trigger.from_state.state then restore it when triggered by the second State Trigger. Easy peasy.
Hmm I’d say burning the cat is worse than drowning the cat, since it’s easier for a cat to escape from water than fire. Regardless of the fire or the “frozen pipes”, the heater being on will cost you more in electricity in the more possible medium situation.
It’s not possible to access another trigger’s from_state when it’s been triggered by another trigger. So that won’t work
Fortunately both scenarios are avoidable if one uses the hint I provided.
It’s also not what I had suggested.
So how are you going to store the from_state?
Voted, after a failed sensor and a ‘tropical’ night in my bedroom. 
2 Likes