Add templating support for mqtt device automation triggers

[jbouwh]

Proposed change

When attaching mqtt device triggers allow limited templating based on the trigger_variables. This helps to setup automations using blueprints because the discovery_id can be put into a variable.

https://community.home-assistant.io/t/wth-why-cant-i-use-mqtt-device-triggers-in-a-blueprint/482219/22

Type of change

• [ ] Dependency upgrade
• [ ] Bugfix (non-breaking change which fixes an issue)
• [ ] New integration (thank you!)
• [x] New feature (which adds functionality to an existing integration)
• [ ] Deprecation (breaking change to happen in the future)
• [ ] Breaking change (fix/feature causing existing functionality to break)
• [ ] Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #106412
• This PR is related to issue:
• Link to documentation pull request: https://github.com/home-assistant/home-assistant.io/pull/30793

Checklist

• [x] The code change is tested and works locally.
• [x] Local tests pass. Your PR cannot be merged unless tests pass
• [x] There is no commented out code in this PR.
• [x] I have followed the development checklist
• [x] I have followed the perfect PR recommendations
• [x] The code has been formatted using Ruff (ruff format homeassistant tests)
• [x] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• [x] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• [ ] The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• [ ] New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• [ ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• [ ] I have reviewed two other open pull requests in this repository.

[home-assistant[bot]]

Hey there @emontnemery, mind taking a look at this pull request as it has been labeled with an integration (mqtt) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of mqtt can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign mqtt Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[Misiu]

I've applied the change to my system (2024.1.2) and tested it with the below blueprint:

blueprint:
  name: Ikea Tradfri Dimmer as Shutter Remote (Zigbee2MQTT)
  description: |
    Control a shutter with an Ikea Tradfri Dimmer over Zigbee2MQTT

    Press on I button to open the shutter, it the shutter is opening it will stop.
    Press on 0 button to close the shutter, it the shutter is closing it will stop.
  domain: automation
  input:
    remote:
      name: Remote
      description: IKEA Tradfri Dimmer remote to use
      selector:
        device:
          integration: mqtt
          manufacturer: IKEA
          model: TRADFRI ON/OFF switch (E1743)
    cover:
      name: Shutter
      description: The shutter to control
      selector:
        target:
          entity:
            domain: cover
            
  
trigger_variables:
  input_remote: !input remote
  input_cover: !input cover
  input_discovery_id: "{{ device_entities(input_remote)[0].split('.')[1].split('_')[0] }}"

trigger:
  - platform: device
    domain: mqtt
    device_id: !input remote
    type: action
    subtype: "on"
    discovery_id: "{{ input_discovery_id }} action_on"
    
  - platform: device
    domain: mqtt
    device_id: !input remote
    type: action
    subtype: "off"
    discovery_id: "{{ input_discovery_id }} action_off"
    
action:
- choose:
  - conditions:
    - '{{ trigger.payload == "on" }}'
    sequence:
    - service: >
        {% if is_state(input_cover.entity_id, 'opening') %}
          cover.stop_cover
        {% else %}
          cover.open_cover
        {% endif %}
      target: !input cover
  - conditions:
    - '{{ trigger.payload == "off" }}'
    sequence:
    - service: >
        {% if is_state(input_cover.entity_id, 'closing') %}
          cover.stop_cover
        {% else %}
          cover.close_cover
        {% endif %}
      target: !input cover
mode: restart

Everything works as expected

[jbouwh]

That sounds very nice. I think I'll add you blueprint example to the documentation page.

[Misiu]

The action part can be optimized for sure, but feel free to use the blueprint in any way you want :) Thank you for adding the posibility to use templates, nice improvement!

[jbouwh]

The action part can be optimized for sure, but feel free to use the blueprint in any way you want :) Thank you for adding the posibility to use templates, nice improvement!

@Misiu abount the templating. Would it be needed to be able to have templates on type and subtype or is is enough to have a template for discovery_id only.

[Misiu]

@jbouwh for my current use case (the blueprint) from above, I need just discovery_id. The rest is hard coded in triggers.

Maybe a Jinja functuon that for a given device would return that value world be better? Especially if we could use it in trigger_variables.

[Misiu]

I'll check that tommorow. It should work for trigger_variables? Before I had to call template inside trigger. Or does that part stays the same?

[jbouwh]

I'll check that tommorow. It should work for trigger_variables? Before I had to call template inside trigger. Or does that part stays the same?

It should work as you tested in the first place. The only thing is that only discovery_id allowed templating now. You can still use device_attr.

[emontnemery]

I'm marking this as draft since there's another idea to drop the discovery_id from MQTT device triggers

[jbouwh]

Superseded by #108309