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 %}
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!
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