Delay_on versus trigger + for - what's the difference?

Configuration
1

What is the difference between using a delay_on vs trigger + for. Is there anything glaringly obvious that distinguishes them that I’m idiotically missing? Or something more subtle around perhaps restart behavior, etc? Thanks.

For example (you can assume that sensor.foo returns integers rather than floats in practice)

- trigger:
    - platform: numeric_state
      id: above
      entity_id:
        - sensor.foo
      above: 0
      for: "00:01:00"
    - platform: numeric_state
      id: below
      entity_id:
        - sensor.foo
      below: 1
  binary_sensor: 
    state: "{{ trigger.id == 'above' }}"

versus

-  binary_sensor: 
    state: "{{ states('sensor.foo')|int(0) > 0 }}"
    delay_on: "00:01:00"
2

In the examples you posted there isn’t a whole lot of difference. They would have some differences following restart, but those differences could be eliminated by adding a restart trigger and additional templating to the trigger-based sensor or by setting up an availability template for the state-based sensor.

1 Like
3

Thanks.
So why have two was to accomplish the same thing?
Is it just a matter of convenience as the delay_on approach tends to be much simpler to express the intent?

4
  • delay_on existed long before triggers were introduced.
  • You can do many things with triggers.
  • You can do one thing with delay_on.
1 Like
5

There are almost always multiple ways to accomplish anything in Home Assistant… usually it is just legacy functions being maintained.

Trigger-based template sensors have only been around for a few years. Prior to that we used to accomplish a similar function by using an automation to save a value to one of the input helpers (which can still be done).

Often when setting up a trigger-based template sensor you aren’t using the same entity in both the trigger and template.

1 Like
6

Got it, thanks guys.
Nor sure which answer to mark as the solution