WTH does an automation not look at the condition when triggered manually

[RutgerJoosten]

I have a sunscreen with 2 automations one for open and one for close with a cover stop command after a time delay. In the condition it checks if the screen is already open (or closed).

Then I have a glance card, with 2 buttons, that trigger these automation. When I push the close sunscreen button when the screen is already closed it still runs the action of the automatio and starts the screens motor.

Would be great if the automation always checked the condition (or make it an option, just run the action or run the complete automation, including condition check).

[123 (Taras)]

@RutgerJoosten

make it an option, just run the action or run the complete automation, including condition check

It’s called skip_condition and the default is true.

[Tinkerer (aka DubhAd on GitHub)]

You’re abusing automations for what you’re doing

You’d be far better off using a script, with the conditions in there

[RutgerJoosten]

aha look at that, I didn’t know this one, this is great, thanks! (think this can get closed than )

[RutgerJoosten]

How is this bad?
I never really understood the use of scripts and why/how/when to use them

[123 (Taras)]

Here’s one way to look at it:

• A script is a sequence of actions: do this and that.

• An automation is a script but with triggers and conditions: do this and that only when something happens.

When you use automation.trigger to execute an automation, it skips the automation’s trigger and conditions and just runs the action. So, in effect, you’re using it like a traditional script.

If you regularly need to skip an automation’s trigger and action then it probably should exist as a script, not an automation (I believe that was Tinkerer’s point).

[Mariusthvdb (Marius)]

are you saying this skip_condition is something for regular HA backend automations? Ive always seen that as a dev tool, used when we trigger automation in the service page, to either skip or not skip the condition block?

Surely this is not an automation option we can set in the automation itself? Although Rutger shows that in his topic title (manually) the way he describes his quest might point to regular automations in action…

btw, since it is only available in the dev service page, it might be better if that could be selected with a toggle, (and not as an optional automation parameter) to prevent any misunderstanding about the service in the first place.

So yeah WTH, please give us a skip_condition toggle!

[RutgerJoosten]

Yes it is a regular automation in action. I only wanted to check the condition, but he didn’t at first.
Not only in the dev page.

The service call from the glance card:

tap_action:
      action: call-service
      service: automation.trigger
      service_data:
        entity_id: automation.covers_open_sunscreen
        skip_condition: false <-- Without this line it just run the action, but now whit this line it checks the condition :)

Apparently you can also build a script with a condition check, but I don’t see the adventage of that right now

[Mariusthvdb (Marius)]

@RutgerJoosten

build a script with a condition check, but I don’t see the adventage of that right now

That’s very important indeed. Imagine an automation that sets a framework of actions which depending on several conditions need to be executed or not. If a condition would evaluate to false, the automation would stop there.
Not so using scripts (in an automation). Simply move the condition over to the script and the automation will continue to call its other services, while the script handles the condition.

example:
main automation bit:

    condition:
      - condition: template
        value_template: >
          {{state_attr('sun.sun','elevation') < -3 or
            states('sensor.driveway_buiten_sensor_light_level_raw')|int < 6000}}
      - condition: template
        value_template: >
          {{(now() - trigger.from_state.last_changed).total_seconds() >
             states('input_number.presence_timer')|int}}
    mode: restart
    action:
      - service: script.driveway_outdoors_light_on
      - service: script.notify_driveway_outdoors_light_on
      - wait_template: >
          {{is_state('binary_sensor.driveway_buiten_motion_sensor_timed','off')}}
      - service: script.driveway_outdoors_light_off
      - service: script.notify_driveway_outdoors_light_off

and one of the notify scripts:

  notify_driveway_outdoors_light_off:
    alias: Notify driveway outdoors light on
    sequence:
      - condition: state
        entity_id: input_boolean.notify_developing
        state: 'on'
      - condition: state
        entity_id: input_boolean.notify_motion
        state: 'on'
      - service: notify.system
        data_template:
          title: >
            Ha Rpi4: Driveway outdoors motion
          message: >
            {{as_timestamp(now())|timestamp_custom('%X')}}: Driveway lights turned off lights.

advantage of this is, you can also use the scripts elsewhere. think of them as modules, or building blocks.

[123 (Taras)]

@Mariusthvdb

are you saying this skip_condition is something for regular HA backend automations?
…
Surely this is not an automation option we can set in the automation itself?

[RutgerJoosten]

That is a nice example thanks!
I can see now how you can create some more complex automations with the use of scripts.

My automations are not that advanced (yet)

[frits1980 (Frits)]

I use the “execute” link with an automation often to check if I didn’t make any mistakes with the automation. So wouldn’t it be nice to have another link there “execute with conditions”?

[123 (Taras)]

@frits1980

nice to have another link there “execute with conditions”?

I recall seeing someone had posted this in WTH but I can’t find it now.

[Mariusthvdb (Marius)]

@123

but I can’t find it now.

it’s here: WTH does an automation not look at the condition when triggered manually - #7 by Mariusthvdb

I’ve bold faced it

[123 (Taras)]

That’s one but there was another that requested to add the skip_condition option to the automation’s more-info card.

[Mariusthvdb (Marius)]

hmm, that would be a tricky one. toggling conditions in the backend during realtime operation?
Cant imagine the dev’s to agree on that, what would be the use case for that, given the fact this can now be done in the dev service page.

[123 (Taras)]

I think the desire is to have something like this (mockup I created):

So before clicking EXECUTE the user can decide whether SKIP CONDITIONS is enabled (default) or disabled.

[Cougar]

Maybe just separate “Trigger automation” that just simulates its triggering with evaluation all conditions. Also would be cool to somehow show what conditions matched and what not. And then add “Run actions” that doesn’t check conditions and just runs all actions.

Edit: For complex action lists, it is better to write all actions under a script: and then just call this script from automation. And this script can be added also to UI and executed from there. Still would be helpful to see condition evaluation for debugging purposes (in log?)

[123 (Taras)]

Personally, I don’t think people should even be offered the convenience of triggering an automation from the more-info card. If there’s a burning need to manually trigger an automation (and there shouldn’t be), use Developer Tools > Services > automation.trigger (where skip_condition already exists) … and where admin-level account privileges are required.

If there’s a constant need to manually trigger automations, it probably should exist as a script.

[frits1980 (Frits)]

It’s not a constant need. It’s a need when developing, for me at least. Just to check if your newly added automation works as it should. And if I have problems with creating an automation it could be I want to trigger it about a honderd times in an hour.