So firstly, i’m pretty sure this is working though i’m not 100% it actually turns off the heater when it gets to the right temperature… can someone sanity check it and tell me if there is a better way to acheive this?
Basically what i want is, if the time is after 6pm and before 7am and the room temperature drops below 16 degrees, i want the heater on… if it’s between those times and the temperature is above 17… then i want it to turn off…
the logic definately works with regards to the input boolean… what i’m not 100% on is the time conditions and if i’ve done them right… i’ve read stuff about people saying when it rolls over midnight something breaks…
oops, missed that.
I assumed the heater was tied to the boolean input somehow, and because of that I have the input logic backwards.
So you have a couple of options here. Because your input_boolean has the opposite logic of the heater, you can add another action for the heater to the automation like this:
I don’t care for this approach because it duplicates too much logic.
The other option is to change the semantic of your boolean to something like “bedroom too cold”
Then, you can have one action that turns on both by simply adding a second entity_id like this:
thank you… i’ll have a play with these and see which works best!
the reason i used the input boolean was prior to actually controlling the heater, i had it sending me a push bullet notification… and this resulted in a notification every time the temperature changed in the slightest…
i think i can actually drop the input_boolean completely with your way as if it tries to turn on the switch multiple times, it’s really not an issue as it just wont do anything… (i hope)
I don’t know how you use the input_boolean, but it occurs to me that this value is directly related to the value of
{{states.switch.heater.state}} so it should be possible to eliminate it all together, and simply refer to the switch state.
this is what i’ve gone with… it’s not exactly what i was after as i wanted the heater on if it’s under 16 and off if it’s over 17 just to give a bit of a buffer and cool down time… however i’ll test and see how it goes :
You can, but you don’t need to.
The automation will never TRIGGER when the thermostat is 16 or 17 or in between those two values.
As a result, by the time you get to the condition, if the value is not greater than 17, then it will by definition be less than 16.
So, since i put this in… the temperature hasn’t actually dropped below 16 however i am seeing triggers in the log and i “think” they are it going above 17 and deciding to turn off… even though it wasn’t on in the first place…
That’s not a big deal as such, but it would be nice to know if it thought it needed to turn on or off… is there any way to find out what logic it deemed appropriate?
First, there is no logic to prevent a “turn off” event if the device is already off.
To add it, we have to know the state strings the device use. For this example, I’m going to assume the device has state “on” if it is on.
So to add a condition that we only want to turn the heater off if it already on, we would change the service template to :
{% if (sensor.bedroom_temperature > 17) and( states.switch.heater.state == ‘on’))%}
But this presents a problem because we have two conditions that might not have been met, it is no longer true that if the condition is false we have a for sure < 16 state so we have to add another condition to the else clause as well:
{% elif (sensor.bedroom.temperature < 16) and (states.switch.heater.state == ‘off’)%]
{%endif%}
I’m not sure what happens in the case where no service is called though???