Temperature trigger only works on value crossing

I have an automation that turns on heater when temperature goes below 16 and turns it off when temperature goes above 17.
Now if the current temperature is 18 and heater is turned on, when I turn on this automation, it won’t turn off the heater. But it works fine when temperature reading crosses 17 from below.

Is this behavior by design? If yes, does that mean everytime when I turn on this automation, I will have to manually set all the switches (like the heater) to a working state? Like above case, when I turn automation on, I have to set heater to off if it is already above 17. So that temperature will drop back to 16 and bounce between 16 and 17. If I dont, I am risking the baby room becoming a sauna room…


There are ways to do what you want though.



On the side…using non-full-proof automation around humans that cannot respond if things go haywire is so-to-speak not very smart.

Yeah I wouldn’t use a numeric_state triggger. Use a state trigger. It will evaluate every temperature update. You can exclude that automation from the logs if your don’t want the chatter. It still retains the trace.

1 Like

Have you considered using the Generic Thermostat integration for this purpose?

It will allow you to use a Climate card (or a service call) to set the desired temperature and the integration will operate the heater to maintain the desired temperature. You can use the cold_tolerance and hot_tolerance options to specify the allowable temperature variance for the heater to be turned on/off (with respect to the specified temperature). In other words, they allow to specify the “deadband”.

IMHO, you exactly pinpoint the issue with this kind of automations! Always take in mind that it could go wrong. When used, make it fail-safe as possible and try to add a (separate) stand-alone alarming device.

Just my 2 cents…

Hi thanks for the reply. I don’t see how to do that… Another person asked the same question in the post. So I don’t think it is doable?


There are literally (not figuratively) hundreds of examples of people doing exactly this on the forum, one of which I linked you directly to.

1 Like

How you approach automations like these depends on the nature of the automation. I always feel like there are two kinds:

  1. Don’t mess with this automation. If you interfere, bad things will happen. Like close the water mains if the flood detector goes of. If someone tries to open the water mains again before it is fixed, close it again. Or if the aquarium gets too hot, fish will die.
  2. This automation helps me do things I do not want to do by hand. But the automation may not get it 100% right, so I still like some manual control. I think temperature control is more often one of them: HA might think the temperature is right, but I’m cold so turn the heater on a bit more. Or HA may have turned on the heater, but that is a waste of energy right now.

If you build all automations the way you suggest (keep turning the heater on or off every … minutes), that is great for type 1 automations. But for me, 95% is type 2, and then it is not so great. You’ll get “computer says no” type of situations. You keep turning the heater on, but HA won’t let you.

Type 1 is solved with either time based triggers or “plain” state triggers with no to or from specified, plus a condition. Trigger: the temperature changes. Plus a condition the temp is above or below …

Type 2 is solved with numerical state triggers (temp changes to above) plus additional triggers when needed. The numerical state triggers with above or below also implicate they only fire when going from below to above, as you’ve noticed. So they intervene as little as possible to allow for other types of control too.

But then the other triggers need to be thought of. When might the automation miss the change? You say the automation is sometimes disabled. So it misses any triggers when the automation was disabled. In these cases another trigger is needed: the automation becomes active again. So lets say the automation is off when you are away (there’s also a condition: no one is home), then an extra trigger is needed: Someone comes home.

In practice this means: every extra condition you add that prevents the automation from running requires an extra trigger for when that condition changes to allow the automation again. At the same time, by limiting the triggers to specific events you are interested in, then you also allow for someone to intervene. This is how I build most of my automations. And it makes for a highly automated home that still behaves like any one expects it to.

I think the main issue here is that he somehow got hands of a way too powerful heating device.
If the heating can heat up the room to a sauna then that heating device is not good to have in a childs room.
What if HA breaks? The automation or generic thermostat (a very good suggestion in my opinion) will not turn off the heating.
Or your router breaks and possibly your WiFI controlled heater won’t turn off, or the ZigBee network breaks, Zwave breaks. What ever part it is, it could break and you should not rely on this to function if your child might overheat because of this.

Get a more resonable sized heating in the room so that even if it stays on it will not make it too hot.

That is good advice too. My smart lights have a direct connection with the buttons that work when HA is down. I also have thermostats that keep the set temperature by themselves. HA only controls the set temperature. Worst case scenario, the set temperature does not change.