Building blocks for automation triggers

[farmio]

Describe the feature

I think it would be great if we had some basic building blocks for automation triggers so that users can easily create useful automations and debug them with ease.

Some example building blocks I could imagine include:

• Debouncer / Trigger maximum x times per timeframe (once per hour / day etc.)
• At earliest (trigger when child triggers, wait if too early)
• At latest (trigger when child triggers, or at given time)

This could prevent filling the automation debugger with traces that don't run any actions due to action conditions that would be used otherwise and thus lead to easier to debug automations.

Use cases

• Debouncer
  Start a hot water recirculation pump for 5 minutes when presence is detected, but only once every hour to save energy

• At earliest
  Open blinds when outside brightness is above 100 lux (numeric state trigger), but not before 6:30

• At latest
  Close blinds when outside brightness is below 100 lux, but latest at 21:00

Current workarounds

Currently a user would need to use helper entities or create complex automations. Examples:

• At earliest

triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.brightness
    above: 100
actions:
  - choose:
      - conditions:
          - condition: time
            before: "06:30:00"
        sequence:
          - wait_for_trigger:
              - trigger: time
                at: "06:30:00"
  - action: cover.open_cover
    target:
      entity_id:
        - cover.kitchen

• At latest / Debouncer

triggers:
  - trigger: time
    at: "21:00:00"
    id: latest
  - trigger: numeric_state
    entity_id:
      - sensor.brightness
    below: 100
    id: dark
conditions:
  - alias: Prevent double execution
    condition: or
    conditions:
      - condition: and
        conditions:
          - condition: trigger
            id:
              - dark
          - condition: time
            before: "21:00:00"
      - condition: and
        conditions:
          - condition: trigger
            id:
              - latest
          - condition: numeric_state
            entity_id: sensor.brightness
            above: 100
actions:
  - action: cover.close_cover
    target:
      entity_id: cover.bedroom

Both of these are not very user-friendly and took me, a HA integration developer since 8 years, a whole afternoon to figure out when moving schedule-automations from a different system (where this was a 3-click action) to HA. I can only imagine how hard this would be to accomplish for a HA beginner not used to find and understand answers in community forums 🙃

Anything else?

No response

[BBE-FR]

As a workaround you can play with trigger and conditions in another way, keeping in mind that there is no limitation to use the same test both in the triggers and in the conditions.

example for the "At earliest" (In plain text):
triggers:

• at 6:30
• when brightness goes over 100

conditions:

• after 6.30
• when brightness is over 100

actions

• open cover

In yaml:

triggers:
  - trigger: numeric_state
    entity_id: sensor.brightness
    above: 100
  - trigger: time
    at:"06:30:00"
conditions:
  - condition: time
    after: "06:30:00"
  - condition: numeric_state
    entity_id: sensor.brightness
    above: 100
actions:
  - action: cover.open_cover
    target:
      entity_id:
        - cover.kitchen

This is enough to launch the automation as you wanted. (at 6.30 the automation will launch and stop if light not above 100, when light reaches 100 the automation will launch and be stopped if too early). The cover will only be open when light above 100 and after 6:30.

Same kind of logic can be used for the "at latest" case keeping in mind the basis for automation:

• any trigger will launch the computation
• ALL conditions needs to be true to continue running through the actions.

Thus in plain text the "at latest" is even simpler, the first trigger triggers the automation, then it is done...:
triggers:

• light below 100
• time 21:00

conditions

• none

actions:

• cover close

Note: if you really want to avoid the double execution when light goes down before 21:00, you have multiple solution:

• add a cover open condition (to test the result of the automation was not performed)
  or you can change the trigger on time to a trigger on template:

triggers:

• light below 100
• template {(time after 21:00) AND (light above100)} is true

Thus the second trigger will only be raised if the first was not used.

Exemple of a template trigger:

triggers:
  - alias: light on and room empty for 15min
    trigger: template
    value_template: >-
      {{(states('group.lights') == 'on') and
      (states('binary_sensor.room_occupancy') == 'off')}}
    for:
      hours: 0
      minutes: 15
      seconds: 0
conditions: []
actions:[]

Debouncer is more tricky.

• I would do it with an additional timer as a first guess, but somebody may have a smarter solution.
• Another option could be to add a delay at the end of the actions. This would "block" other execution if you choose the mode "single" for your automation.

[farmio]

Thank you very much for your suggestions!
The scope of this feature request was to have a simple and user friendly way to accomplish building basic automations. Imho "simple" or "user friendly" ends when one of these things is required

• templates
• additional helper entities
• repetition / synchronisation (eg. defining the same time value in trigger and conditions)
• unit testing due to uncertainty (eg. will a trigger firing at: 6:30:00 meet a condition after: 6:30:00 - due to milliseconds or whatever)

[BBE-FR]

No offense. I am part of the people supporting this FR...

I was just reacting on the way you performed your workaround to propose simpler way (imho) to do them (for example without the wait for trigger which can be a burden in case of restart).

My answer was not at all to challenge the need.

Especially I agree that template is difficult for beginner, already afraid by YAML... Thus triggering by template could be made more accessible with logical building blocks like for conditions (AND, OR, NOT for example). (but I would still tend to prefer template which are more compact and thus more readable... personal opinion...)

The rest of the argumentation is for me more questionable. It is for me not that much complex to repeat a trigger in the condition or add a little bit of margin if unsure (condition could be after 6:29 in the example without any arm).
Same for external helper, for some automation it can be required. At some point you cannot always avoid complexity.

For me the complexity is that people have difficulties to really understand the way HA automations runs:

• triggers : any triggers will start the automation
• conditions: all conditions needs to be fulfilled to launch the actions (at the time of the trigger)
• actions: only then actions can be run (and even contains conditions/triggers blocks...)

beginners or people coming from other platforms may have difficulties to understand that:

• multiple triggers are allowed, including triggers that may not run the actions depending on conditions.
• the condition need to be true at the time of the trigger, and the automation will not "wait for the condition to be true" to run the actions