Add trigger service to template

[balloob]

Breaking change

Proposed change

Add a new service to manually trigger a trigger-based template entity with ability to pass variables.

Also fixes a bug for trigger-based entities without a unique ID Bug fix extracted to #48631

Type of change

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

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

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

• 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.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

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

[balloob]

Removed milestone and moving the bug fix to new PR.

[amelchio]

As a user, it would be nice if this could be rolled into homeassistant.update_entity but I guess that is not so architecturally sound 🤔

Could we at least support homeassistant.update_entity and just error out if the template accesses trigger data? I can see lots of situations where trigger entities will be used to avoid an automation, not using trigger data at all. It would then be nice to not have to remember which way to update.

[balloob]

Right now hitting homeassistant.update_entity for a trigger entity will do nothing. You think it should try to re-render and set itself to unavailable if rendering fails?

[amelchio]

Actually, thinking about it a bit more, I am not quite sure what is being proposed here. Can you provide a use case?

It seems a bit odd for me to support variables in the forced trigger when those are not available to normal triggers but I guess you have something in mind?

You think it should try to re-render and set itself to unavailable if rendering fails?

I don't think it should set unavailable; that value is user controlled. Just treat trigger as an undefined variable.

[balloob]

Just like we pass variables to scripts, you would pass variables to the rendering method. It could be a way to have an automation conditionally update an entity.

[amelchio]

Sure, I understand what the feature does ... just not when that would actually be needed. We shouldn't add features just because they are easy to implement, they should preferably be useful too ;-)

1. Variables are supported if and only if the trigger is trigger: [] because the variables would not be set for any actual trigger, right? I wonder if this is such a big limitation that we are as well off without the variables support in a corner case.
2. The template.trigger itself now seems dubious to me. When is it useful to trigger with synthetic trigger data? The same could be achieved by passing the data in a custom event (which would be fired in a script, so supports variables); is the use case frequent enough that special support is warranted?

So I guess that I am now suggesting to drop this PR entirely and instead support homeassistant.update_entity (which will fail for templates referencing trigger but that is okay).

[balloob]

We can revisit in future