Automations: add "enable/disable option" in type "choose" to e. g. enhance the potential of trigger IDs

[e-raser]

One feature request related to the trigger IDs:

INTRODUCTION
One big advantage of trigger IDs is, to reduce the amount of automations basically doing the same thing (e. g. notify someone), but for different objects/devices/entities. I see trigger ID based “generic” automations as “Do same or similar things, regardless of the individual object/device/entity”.

E. g. before trigger IDs:

• Automation 1: Notify me “iPhone battery is fully charged”
• Automation 2: Notify me “iPad battery is fully charged”
• Automation 3: Notify me “Android tablet battery is fully charged”
• …

Now with trigger IDs:

• Automation 1: Notify me “[Device] battery is fully charged”

That´s phenomenal! For this I use trigger IDs as condition in the action part of the automation nested within a choose statement. So basically I combine several automations within a single one. Roughly related to above example here´s the action part of an automation using trigger IDs:

choose:
  - conditions:
      - condition: trigger
        id: device_1
    sequence:
      - service: notify.all_devices
        data:
          ...
  - conditions:
      - condition: trigger
        id: device_2
    sequence:
      - service: notify.all_devices
        data:
          ...
  - conditions:
      - condition: trigger
        id: device_3
    sequence:
      - service: notify.all_devices
        data:
          ...
default: []

PROBLEM
BUT here´s the (biggest, next to limitations when it comes to blueprint based automations) downside:
If I would like to disable one action (here one notification), I need to remove that full code of the automation, maybe even save it somewhere outside Home Assistant as a backup if it´s likely I´ll need it again in the future.
With single, individual automations you could just disable the single automation.

FEATURE REQUEST
Therefore I propose / request this feature:
Add ability to disable options in choose statement. This could be done by adding a checkbox to the UI, similar to what we already have for e. g. service automation.trigger (skip condition).

This way we can benefit from all the pro´s of using trigger IDs without loosing known features (like disabling an automation).

Knowing this is not a UI thing but a logical change, here´s a quick mock-up anyway:

Only other approach (more like a “not so smart” workaround) that came to my mind is to create input_boolean helper entities which are used in every choose option, those helper entities can be enabled/disabled like we do with automations - so I rebuild the native “enable/disable single automation” feature externally, probably with the need for an extra view to not get lost - because I would need A LOT of those helper entities, it would become quite painful really quickly.

[123 (Taras)]

@e-raser

disable one action (here one notification), I need to remove that full code of the automation,

No, that’s unnecessary. Just change the value of id to something else and it won’t be chosen. It’s easily done in the Automation Editor.

[e-raser]

Quick and dirty, I have to admit. But you´re sure that´s intuitive enough so everyone will come to that workaround?

As all the successful efforts in the UI and blueprints and so on show: make it as simple and on the nose as possible for users, not only but especially for beginners.

[123 (Taras)]

@e-raser

but especially for beginners.

Under what circumstances would a beginner require the need to selectively disable parts of a choose?

Based on the hundreds of people I have helped, many beginners aren’t even aware of the purpose of choose, let alone the need to disable bits of it.

[e-raser]

Well probably beginners aren’t even using trigger IDs but stick to blueprints wherever possible. So „beginners“ refers to people starting to use trigger IDs.

And with the same argument you can say „Why would you need the ‚skip condition‘ option in service automation.trigger?“ (see first screenshot in OP).

[123 (Taras)]

@e-raser

And with the same argument you can say …

You chose to avoid answering the question and tried to create a comparison with a completely unrelated feature whose purpose is to address this behavior. There’s no workaround for it so that’s why the feature was added.

In contrast, this has a comparatively limited use-case and a simple workaround.

Anyway, the implementation of this Feature Request depends on attracting the interest of a volunteer developer willing to make the necessary enhancements to Core and Frontend. It also has to be vetted by the development team.

[e-raser]

@123

Anyway, the implementation of this Feature Request depends on attracting the interest of a volunteer developer willing to make the necessary enhancements to Core and Frontend. It also has to be vetted by the development team.

Right. Up to now we only had

• one feature request with a bit of work to describe the problem
• one saying not necessary because you can simply work around it (undocumented)

Let´s see what others think.

[123 (Taras)]

@e-raser

because you can simply work around it (undocumented)

Changing the value of a variable is hardly something that requires official documentation.

FWIW, the odds of implementing a new feature (especially one that requires modification in two repos) are low when there’s an existing, easy way of achieving it.

[e-raser]

@123

FWIW, the odds of implementing a new feature (especially one that requires modification in two repos) are low when there’s an existing, easy way of achieving it.

Seems like they listened. Fantastic Conditions, triggers and actions:

2022.5: Streamlining settings

[123 (Taras)]

Miracles happen.

[Edwin_D]

You could just as easily use boolean input helpers to enable/disable cases. If you name them right, you could probably also template it in an extra condition below the choose. This feature would merely add bloat/complication for something rarely used.

You may also just have described a reason to stick to separate automations because those can be turned on and off. That is how I do it. That is very intuitive and already there.

[e-raser]

@123

Miracles happen.

Useful things happen. Great to see they implemented this. I was only hoping for the actions within choose, but they took care of all actions, triggers and conditions. Rock solid update.

@Edwin_D

You could just as easily use boolean input helpers to enable/disable cases. If you name them right, you could probably also template it in an extra condition below the choose. This feature would merely add bloat/complication for something rarely used.

You may also just have described a reason to stick to separate automations because those can be turned on and off. That is how I do it. That is very intuitive and already there.

Of course I could, that way I could “configure” that using the UI. But as mentioned in Automations: add "enable/disable option" in type "choose" to e. g. enhance the potential of trigger IDs - #9 by e-raser the latest 2022.5 update implemented exactly what I proposed here - solved for me.

[123 (Taras)]

The only reason I used the word “miracle” is because despite the community having over 134 thousand members, only one felt this Feature Request was needed and took the time to vote for it.

In contrast, there are Feature Requests with hundreds of votes that remain unfulfilled. For example, grouping automations is the top request with over 580 votes (dating back to 2019) yet what was implemented was the FR with a single vote (over a span of ~9 months) So, yeah, kind of a miracle.