It’s things like these that make me wish there was somewhere a website with lots of (Jinja/Python/YAML) code and user could click anywhere and you could see a small tooltip explaining what that thing does. For example, your explanation with this example would have been perfect for that 
Yeah, but it would need someone like @petro to do it, and his contention is that it’s just jinja wrapped python (true) but it would be nice to have a site with standard examples for various template usages.
Instead “these are just things we pluck from the hedgerows of experience”.
And I also think that petro has enough on his plate 
And you’d be amazed at how differently some people attack the same problems with different approaches, and we learn new wrinkles all the time
1 Like
you don’t need to include the zero [:5] is the same
Jinja is based on python, don’t know if it’s a wrapped version of it.
I’ve read that Jinja was created for print formatting, so given it’s usage in HA
I think it’s used to pass python up to the sandbox for evaluation
Hence ‘jinja wrapped python’
This is a fairly well educated guess - but it’s still a guess
Yeah, it’s meant to serve up information to static forms, like a webpage. Pretty much why it’s used in HA.
So here is my version
automation:
- alias: 'Turn Car Heat On'
initial_state: on
trigger:
platform: time_pattern
minutes: '/1'
condition:
- condition: template
value_template: "{{ states('sensor.sonoffth3_am2301_temperature') | float < 2 }}"
action:
- service_template: >
{% set timenow = as_timestamp(now()) %}
{% set hr = states('input_number.alarm_clock3_hour') | int %}
{% set mn = states('input_number.alarm_clock3_minute') | int %}
{% set settime = as_timestamp(now().strftime("%Y-%m-%d " ~ '{0:0=2d}:{1:0=2d}'.format(hr, mn) ~ ':00')) %}
{% set starttime = settime - (3*60*60) %}
{% set slot = (starttime <= timenow < settime) %}
{% set tempdeg = states('sensor.sonoffth3_am2301_temperature') | float %}
{% set mins = 160 - (tempdeg * -16) %}
{% set heatrqtm = starttime + mins * 60 %}
{% set heat = slot and timenow >= heatrqtm %}
{% if heat %}
switch.turn_on
{% else %}
switch.turn_off
{% endif %}
entity_id: switch.sonoffpow3_2
Given me another 5 Mins and I’ll add some comments to explain it.
You will NEED to test this as it looks okay to me but I only have the template editor to test it as I have no actual entities suitable.
automation:
- alias: 'Turn Car Heat On'
initial_state: on
trigger:
platform: time_pattern
minutes: '/1'
condition:
# this condition just stops the automation if your temp is 2° or higher, adjust as you see fit (cuts down on further processing)
# Note: I also considered parsing the start and stop times here but it was nearley as much processing required as is in the service template
# Note2 : the '>' is not required for a single line template but then it does require quotes
# Note3 : Note that the quotes are double on the outside and single within
- condition: template
value_template: "{{ states('sensor.sonoffth3_am2301_temperature') | float < 2 }}"
action:
- service_template: >
{# This is a jinja comment and will be ignored by the interpreter #}
{# ALL the below is indented more than it needs to be to show the comments more clearly #}
{# This next line (all comments will be as this) gets the time RIGHT NOW and stores it as a HUGE number that has both date and time #}
{% set timenow = as_timestamp(now()) %}
{# this gets your input number hour (input_datetime is much easier) and stores as a number in hr #}
{% set hr = states('input_number.alarm_clock3_hour') | int %}
{# this gets your input number minute and stores as a number in mn #}
{% set mn = states('input_number.alarm_clock3_minute') | int %}
{# this sets your 'settime' as a huge number and stores in settime #}
{% set settime = as_timestamp(now().strftime("%Y-%m-%d " ~ '{0:0=2d}:{1:0=2d}'.format(hr, mn) ~ ':00')) %}
{# as we've already done most of the work we just subtract 3 hours from the set time to start our evaluation #}
{% set starttime = settime - (3*60*60) %}
{# this tests to see if we are 'in' the 'slot' #}
{% set slot = (starttime <= timenow < settime) %}
{# this gets the temperature (as a float, as that will aid in resolution) #}
{% set tempdeg = states('sensor.sonoffth3_am2301_temperature') | float %}
{# this gets the minute offset from the start based on the temperature #}
{% set mins = 160 - (tempdeg * -16) %}
{# given the 'offset' we now have a new 'start time' calculated, based on temperature #}
{% set heatrqtm = starttime + mins * 60 %}
{# this tests that we are (now) in the 'slot' and 'that switch on time' is in the past #}
{% set heat = slot and timenow >= heatrqtm %}
{# this uses the last evaluation to determine if we switch 'on' or 'off' #}
{% if heat %}
switch.turn_on
{% else %}
switch.turn_off
{% endif %}
entity_id: switch.sonoffpow3_2
Note: the above code is bulky and could easily be slimmed down, but this way it’s easier to maintain and when you come back to it in 5 years you’ll spend less time scratching your head saying “What the hell does that do ?”
Note: slimming it down is not the same as optimising it. Petro is a specialist at optimising stuff so he may come back with some suggested changes.
Now, Lets see what @Burningstone has to say ? (ie is it concise enough ?) {Edit: it’s 27 lines, the same as burnings but mine switches off if the temperature rises and at the end of the slot. I could also make it shorter but readability would suffer )
Edit: note it will switch on (assuming it’s cold enough) every minute, this is not a problem for switches and lights etc because it doesn’t turn them off first so the switch will not even notice.
You could ‘condition test’ to see if the switch was ‘on’ and required ‘on’ OR ‘off’ and required ‘off’ but that would have to go in the condition and again that’s a LOT of additional and unecessary processing.
Edit2: the ‘formula’ is based on a 3 hour assessment period and an assumption that the max we need is 3 hours and the minimum is 20 mins at 2 degrees (1.25° means NO heating, 160 - (1.25 * -16) = 180 so it wont even be considered)
2 Likes
Didn’t read all of it yet, but your value template is missing one curly brace at the beginning and at the end 
1 Like
Eh ! Where ? But I wouldn’t be surprised 
I did find a mistake, its a pair of curlies on the condition but is there another ???
This:
Should be this:
"{{ states('sensor.sonoffth3_am2301_temperature') | float < 5 }}"
snap !
10 char min
Gilean,
Also note that this automation does not use your sensor, the values are taken direct from your input numbers.
As I said it took a while to get these conditioned as meaningful timestamps (petro said the same)
Input datetime’s are much easier
Wow, great work! As I have two cars, I thought I could try this one instead for one of them, and leave the previous code (for now) for the other half’s car as it seems to work! 
But if I understood right, this is solution to problem where temperature goes up and down within three hours and prevents the situation when heater should be turned on but it doesn’t.
But how does this work?
… and there you explained the part that was not clear to me I was thinking that where are those fixed temperatures that determine how much early you need to start heating, but seems like it’s pretty dynamic! Although I am not sure about those calculations here… Say it’s 2 degrees. 160 - (2 * -16) = 160 - ( -32) = 192 minutes? And say it’s -2 degrees. 160 - (-2 * -16) = 160 - 32 = 126. And your example, 1,25 degrees, would be 160 - 20 = 140? Did you mean + instead of - ?
Good point, didn’t notice that. But to me it’s just the same, as that sensor.alarm_clock3_time is there only to make the frontend show the full time instead of separate hour and minute
So 192 minutes after the start evaluation is 12mins after it should finish, so it won’t turn on (we already established that 1.25 (or more) degrees means no action given this formula)
Well 128 actually, but that’s 128 minutes after start time so 52 minutes of heating
1.25 degrees is 160 - (1.25 * -16) == 160 - (-20) ==160 + 20 == 180
So no, I meant what I said.
You may need to plot this in excel or something
X = temperature from say - 12 to + 5
And this needs to give you minutes before set time
I assumed 180 at - 10 going to 20 minutes at - 2 (and then drawing a straight line through those points)
But then these numbers need to be converted to mins added to start time, this works out at the formula I gave, but this is just a working example, tweak it to suit you.
1 Like
This is amazing, great job! I love how you made this simple automation smarter and fuel saving at the same time with only a few lines of code, and also commented very well. Highly appreciate posts like this, you went the extra mile, massively optimized the automation and all this “just” to help someone here on the forum. Kudos to you!
1 Like
You flatter me.
The ‘persons’ helped here were Gilean, ‘you’ and ‘ME’ with an emphasis on the ME.
I enjoy solving puzzles and this was a good one
Though @Gilean now has me wondering about my formula as I just did that in my head and now I’m starting to doubt it as not all the bricks are in neat rows !
Damn, I’m gonna have to draw some graphs 
so you may have a point Gilean
Edit: AND if anyone can improve on this I would welcome such as I’ll learn even more (everyday should be a school day ! )
Ah yes, now I get it! Actually I don’t need to tweak that formula at all since it seems to work the way I want, only better! I like the fact that heating time increases in linear way instead of hard-coded steps at certain temperature points! I think it works and it’s almost bedtime here so I set my alarm_clock3 at 07:00, the heater is not plugged (as I am working from home tomorrow), but I can see from recorder when exactly my sonoff has triggered and what kind of outdoor temperature there has been at that moment. Exciting 
Your formula is totally fine. I quickly put this into Excel, hope you can read it. Green = heat, red = don’t heat.
Hahaha ! Guess what I’ve been doing for the last 15 minutes ?
Doing the exact same thing though I plotted a graph of temp (on a 0.1 resolution) against minutes.
Yeah, my formula worked, but I really shouldn’t do stuff like that in my head, hence why I had doubts
So I assume you’d have tackled this in appdaemon. And as such would probably have a lot of similarities ??? (never played with it).
It would be interesting to hear your comparative views.
My main aim with any of these is to achieve the desired result using as little power as possible (I hate waste, and power = CO2 )
@Mutt, I marked your code as solution because it did work! So thank you a lot! Well, not initially as I had commented out platform time_date as I thought it would not be needed here, but after taking that part back in, it started to work! So, I set up my alarm_clock to 9:50 (when I was supposed to leave), and now when I look at my logs, the heater switch has turned on at 9:06, and the outdoor temperature was -1,5C. And the switch has turned off at 9:50 as expected. So, my car would have been pre-heated for 44 minutes. Not sure if that proves the math right or wrong, but at least the heating time seems more or less right
And, with this code I don’t need extra automation to switch off the heater as this one takes care of that as well
1 Like
Eh ! Where did I use that ?
The only platform I thought I’d used was the time pattern trigger (needed for it to fire)
All my code was explained and necessary.
The solution ? Not sure this should take the solution away from @Burningstone as he addressed the problem as stated in the title, having said that I’m conflicted as the better solution (again until someone points out a mistake or improvement) is the variable timing one, And others visiting the thread should use that but I’m not invested too much so what do you and burning think ?
-1.5 * -16 is 24, 160 - 24 = 136, 180 - 136 = 44 so the arithmetic agrees
If you need a quadratic equation instead of a linear one we could do that too but I’d have no idea how you’d get the data
Gilean, maybe you should change the title of the thread to something like “Variable Car Preheating for Morning Use” as that is more what you wanted and covers more of the bases. ???