I had slight different logic for heater. I think I made mistake hiding code in section:
Anyway I will try to think out something. 
Ah didn’t see the code. You can modify this to work and you won’t have the non-trigger issue that I described:
Step 1: Use sensor.date_time. You may need to add it to your configuration.
Step 2: Use this template
binary_sensor:
- platform: template
sensors:
start_car_heat:
friendly_name: Car Heating flag
value_template: >
{% set temperature = states('sensor.yr_temperature') | float %}
{% set time_now = states('sensor.date_time') %}
{% set ts_now = as_timestamp(strptime(time_now, '%Y-%m-%d, %H:%M')) %}
{% set midnight = states('sensor.date_time').split(',')[0]+', 00:00' %}
{% set ts_midnight = as_timestamp(strptime(midnight, '%Y-%m-%d, %H:%M')) %}
{% set departure_time = ts_midnight+7*60*60 %}
{% set increment = 60*60 %}
{% if temperature > 5.5 %}
{% set multiply = 0 %}
{% elif 5.5 >= temperature > -5 %}
{% set multiply = 1 %}
{% elif -5 >= temperature > -10 %}
{% set multiply = 2 %}
{% elif -10 >= temperature > -15 %}
{% set multiply = 3 %}
{% else %}
{% set multiply = 4 %}
{% endif %}
{% if multiply == 0 %}
{{ False }}
{% else %}
{{ (departure_time-increment*multiply) <= time_now <= departure_time }}
{% endif %}
This should trigger anytime between your multiplied time and your departure time if the time is between that window.
1 Like
Neat! Thank you a lot
Only one little adjustment on this small part:
should be
{{ (departure_time-increment*multiply) <= ts_now <= departure_time }}
I am also wondering if this would not overload RPi running every minute 24x7. There are some heavier string split operations and etc. I think I will implement additional check to check if this is “expected car heating period”.
Thanks again!
1 Like
It might. Not sure how you can make a sensor that updates every 15 minutes though. If you have any sensor that updates in a period of 15 minutes, you can remove the references to sensor.date_time and sensor.time and use now(). Just make sure you attach the 15 minute update sensor to the template using the entity_id field.
I was thinking about really simple solution. Execute all of our logic in this if
{% if "03:00" <= states('sensor.time') <= "07:00" %}
Else return false. Maybe I whould also add check if car automation pre-heating automation is enabled
I couldn’t fully understand that “sensor pdates every 15 minutes” thing due too my little experience with HA :-).
You can’t compare strings like that. greater than or less than does not work on strings the way you think it does. That’s why we have to convert them to timestamps. For example 9 > 10 as strings.
Yep I know that. But time strings in time format without /am should be good afaik. The thing that there,that I didn’t know how to convert them to stamps 
So the ‘heavy’ string manipulation isn’t going to overload your pi. It’s the number of fires. This will still be an issue if you ‘simplify’ it as well. The time difference between the 2 operations wouldn’t even be noticeable.
Basically, there’s no point in simplifying it. You’re still going to have the same amount of work being done because string manipulation doesn’t take up many bites.
Ok thank you for this information. I really thought that I can optimize this by bringing one additional root IF clause. Which would prevent running all string date manipulations conversions and etc. Seems like I don’t understand how it works on a lower level then
The action of running the process is essentially the same. You’re still running a process, that’s the root cause of any load. String manipulation of a few bytes of information isn’t going to break the bank if you add a few more bytes. If you add megabytes, then yes, lowering it will be a priority.
I was thinking about CPU load which is affected by all variable manipulations, assignments and comparisons. In this binary variable case running every minute we should not have any troubles. But if later we would have 20-50 similar binary variables? It could make a difference IMHo
yes but in that case you’re going from 1 process to 20-50 processes… I’ll use weights as an analogy. The process is like an elephant and the string manipulation is an ant. If you add 50 ants onto the elephant, it’s not going to make a difference when you have 50 elephants with 50 ants verse 50 elephants with 1 ant. That’s how little processing power string manipulation takes. Now if you are in the millions of ants, that makes a difference. But we are talking 10 extra lines of code which is maybe 500bytes at most. The elephant’s the problem. Get where I’m going with this?
So all sensors (even physical) are similar elephants? ln that case I would stop worrying about performance, as I strongly believe that HA is optimized to handle a great bunch of sensors even on a pi.
Yeah, the sensors are the elephant.
You should worry about it, but the way to limit it’s load is by reducing the number of listeners at any time. I.E Automation triggers, sensor templates, etc. Time based listeners like this one can increase the load substantially. Personally, I avoided them all together on my pi.
So basically we came back to conclusion, that this approach is still a suspect for load increase? Any other ways achieving same result?
If I would use this binary sensor only as a condition (instead of a trigger) for automation based on time trigger which would run on 4 times: 03:00, 04:00, 05:00 and 06:00. Will it be less resource hungry?
I still cannot understand what you meant by that sensor which updates every 15 minutes 
No, because the binary sensor is updating minutely. If you have a sensor that updates once an hour, you can use that to cause the updates on the binary sensor. Then remove all references to entity_ids in the binary sensor.
If you use the value_template from the binary sensor as a condition, then yes that will reduce the load a ton.
This is a version that uses now(). Also, probably want to trigger it at 1 minute past the hour to ensure it’s inside your timespan.
- condition: template
value_template: >
{% set temperature = states('sensor.yr_temperature') | float %}
{% set ts_now = as_timestamp(now()) %}
{% set ts_midnight = as_timestamp(now().replace(hour=0).replace(minute=0).replace(second=0).replace(microsecond=0)) %}
{% set departure_time = ts_midnight+7*60*60 %}
{% set increment = 60*60 %}
{% if temperature > 5.5 %}
{% set multiply = 0 %}
{% elif 5.5 >= temperature > -5 %}
{% set multiply = 1 %}
{% elif -5 >= temperature > -10 %}
{% set multiply = 2 %}
{% elif -10 >= temperature > -15 %}
{% set multiply = 3 %}
{% else %}
{% set multiply = 4 %}
{% endif %}
{% if multiply == 0 %}
{{ False }}
{% else %}
{{ (departure_time-increment*multiply) <= time_now <= departure_time }}
{% endif %}
1 Like
So whole automation could be time triggered (example at 03:01 04:01 05:01 06:01) and above template could added to thats automation condition?
So no more fake binary sensors which would have separate process and do calculations every minute 24x7?
Yep, exactly.
You could in theory use a time trigger to and have this run every 15 minutes. So it would just be this automation running 24/7 w/ it firing every 15 minutes.
Cool! Then I am going to use it as my final solution.
I don’t know how to thank you for such effort put brainstorming here with me. Thanks a million!
1 Like
Thanks a lot guys!
I’ve used the templates above, but for some reason the turn-off part which I added in the action queue won’t execute? What am I doing wrong?
alias: Turn on car heater every weekday morning based upon temp
description: ''
trigger:
- platform: time
at: '04:01'
- platform: time
at: '04:31'
- platform: time
at: '05:01'
- platform: time
at: '05:31'
- platform: time
at: '06:01'
- platform: time
at: '06:31'
- platform: time
at: '07:01'
- platform: time
at: '07:31'
condition:
- condition: template
value_template: >
{% set temperature = states('sensor.temperature_11') | float %} {% set
ts_now = as_timestamp(now()) %} {% set ts_midnight =
as_timestamp(now().replace(hour=0).replace(minute=0).replace(second=0).replace(microsecond=0))
%} {% set departure_time = ts_midnight+8*60*60 %} {% set increment =
60*60 %} {% if temperature > 5.5 %}
{% set multiply = 0 %}
{% elif 5.5 >= temperature > 0 %}
{% set multiply = 0.5 %}
{% elif 0 >= temperature > -2 %}
{% set multiply = 1 %}
{% elif -2 >= temperature > -5 %}
{% set multiply = 1.25 %}
{% elif -5 >= temperature > -10 %}
{% set multiply = 1.5 %}
{% elif -10 >= temperature > -15 %}
{% set multiply = 2 %}
{% else %}
{% set multiply = 3 %}
{% endif %} {% if multiply == 0 %} {{ False }} {% else %} {{
(departure_time-increment*multiply) <= ts_now <= departure_time }} {%
endif %}
action:
- type: turn_on
device_id: aecb4102f6d83939ef7be9ddb9b0d4f5
entity_id: switch.30214007c82b96597ec4
domain: switch
- condition: time
after: '08:15:00'
weekday:
- mon
- tue
- wed
- thu
- fri
- type: turn_off
device_id: aecb4102f6d83939ef7be9ddb9b0d4f5
entity_id: switch.30214007c82b96597ec4
domain: switch
mode: single