Custom sensor in configuration.yaml vs time pattern automation, which has less load (in case it matters)

Configuration
1

For a RPI4 config with just a few lights and switches, is there any preference in implementing a time/temperature dependent automation through either a template based sensor or through a time based automation?

The idea of having a couple of automations fire of every minute 24/7 made me move towards the solution based on sensors, but I might very much be fooling myself that this would imply a lower load on the system as a whole. Or, considering that there are only(?) som 20-30 automations in the system mainly turning on/of lights morning evening, it might just not matter at all.

The sensors would be defined in configuration.yaml

  - platform: template
    sensors:
      mv_duration:
        friendly_name: "Block heater duration, seconds"
        value_template: "{% set tempdeg = states('sensor.north_temperature') | float %}
{% set mv_tid = ((-0.5 * tempdeg) + 30) | int %}
{% if tempdeg > 10.0 %} {% set mv_tid=0 %}{% else %} {% set mv_tid = (mv_tid * 60) | int %} {% endif %}
{{ mv_tid }}"

  - platform: template
    sensors:
      mv_departure:
        friendly_name: "Block heater, start time"
        value_template: "{{ (as_timestamp(states('input_datetime.mv_test'))|int - states('sensor.mv_duration')|int) | timestamp_custom('%a %H:%M') }} "

and the last sensor could then be used in automation to trigger on

{% set departure_time = as_timestamp(states('sensor.mv_departure')) %}
{% set time_now = as_timestamp(states('sensor.date_time_iso')) %}
{{ time_now >= ( departure_time - 900 ) }}

The alternative is to have a time pattern based automation, eg every minute, evaluating the first template as part of its action logics, as discussed in

2

There are pros and cons to both.

You need to consider the context of what the automation is doing and the number of trigger points.

The post you quoted was just an extreme example of people’s obsession to reduce everything to ‘one’ automation. There are seldom good reasons to do so and often many for keeping the separation.
If I wrote this today I’d go for for a binary_sensor.

I have generally moved towards the binary sensor for two primary reasons.

Concentrating all the logic in one binary sensor means that yes you are evaluating 1/min but the overhead of adding a second trigger is negligible and a third trivial. More significantly all this is internal to HA and so just consume cpu time and memory space (quite easily remedied by buying a faster processor or moving from a RPi 3 to a RPi 4 etc.)

Having the binary_sensor means that i can trigger from both the positive and negative edges of it in a single automation but maintain the clear and concise logic in the sensor. Doing it this way also saves the most critical resource, the transport of the command - be that via ethernet (especially WiFi), zigbee, Z-wave or whatever.
Continually sending out ‘switch.switch_on’ every minute (in the example above) consumes these resources (bandwidth) that you can never get back with a ‘bigger stick’ .

When I was on a RPi 3, moving to binary_sensor and testing templates for speed, meant that I reduced cpu load from 5% to 2%

3

Thank you @Mutt for sharing.

The main reson for starting to have second thoughts were another related discussion by @petro

which ended up with a lenghty discussion on system impact, where I got the impression that there was a greater penalty on sensors as opposed to time based automtons.

Considering the large numbers of sensors easily introduced by eg the native Andriod app it did not all add up for me.

I’ll look into how/if I can then develop the template sensor furter into a binary sensor.