Allow templates for enabling automation triggers, conditions and actions

[farmio]

Currently an automation trigger can be disabled by setting enabled to false.
https://www.home-assistant.io/docs/automation/trigger/#disabling-a-trigger
So can conditions and actions, although it is not documented for yaml (but it is what happens when "Disable" / "Enable" is used in the automation editor).

automation:
  trigger:
    - enabled: false
      platform: ...

Allowed values are booleans, numbers and strings ("on", "off", "true", "false", etc.) https://github.com/home-assistant/core/blob/5aabb2a920ab3810e6fcdec4de4e8698b22a960f/homeassistant/helpers/config_validation.py#L1651

For Blueprints, it would be nice to be able to disable a specific items based on an input (or its default value if nothing is set by the user).

blueprint:
  name: Dependent disable
  domain: automation
  input:
    required_input:
      name: Required
    optional_input:
      name: Optional
      default: false
    binary_input:
      name: Use action
      selector:
        boolean:

trigger_variables:
  _optional_input: !input optional_input

trigger:
  - platform: mqtt
    topic: !input required_input
  - platform: mqtt
    topic: !input optional_input
    enabled: "{{ not _optional_input == False }}"
    # or maybe even simpler without trigger_variable
    enabled: !input optional_input

action:
  - service: system_log.write
    enabled: !binary_input
    data:
      level: info
      message: "{{ trigger }}"

To achieve this, the enabled key would have to allow limited templates

vol.Optional(CONF_ENABLED): vol.Any(boolean, template),

and evaluate these in async_initialize_triggers() https://github.com/home-assistant/core/blob/65230908c6bd7b9f2dac6e8de41b7bd27d28d1be/homeassistant/helpers/trigger.py#L313

and according methods for condition and action.

While, for conditions and actions, we could support full templates, enabled is still restricted to limited templates. This fits for the intended use case of templating based on blueprint inputs. For other needs, users can already use and in conditions or if in actions that provide full templates.

PR for implementations:

• trigger: Allow templates for enabling automation triggers core#114458
• condition: Allow templates for enabling conditions core#117047
• action: Allow templates for enabling actions core#117049

[SirGoodenough]

You would need to take into account more that an MQTT trigger though. By using the actual input as the flag, this would be hard as there are so many options. MQTT triggers happen, but there are state and target and all the things.
If you could add an enabled flag or attribute to the input creation side, then just be able to read that below, that might work.

Also most inputs are NOT triggers.

As far as is this useful, yes, it has come up as a question a few times. People end up putting a dummy helper in there or something lame. I usually try to code around it when I can by asking for a more general trigger and templating in the conditions things that might not be there. Not everyone has trained themselves to think a few steps ahead.

[farmio]

Thanks for your answer!

Please note that this is not about MQTT specifically (I have personally never used that integration, but thought it would give a good example). Any trigger could be en/disabled by this.

Also, one could create an extra input (eg. binary), or a trigger variable etc. to use it in enable: (but nothing dynamic like state since it is only evaluated on loading).

[SirGoodenough]

Yes like use me or ignore me, a binary for the enable is all you would want.

[jbouwh]

MQTT triggers take a type, subtype and the device_id as options. It should be possible to use them in a blue print.
See also: https://community.home-assistant.io/t/wth-why-cant-i-use-mqtt-device-triggers-in-a-blueprint/.
In a blueprint you can use a device selector to select the device you want.

[emontnemery]

This is a nice addition, let's do it!

[frenck]

Closing as it was implemented.