Add scripts and data-templating to alerts

[jhenkens]

Proposed change

Alerts are a great tool for easy repeating notifications of things that need to be done. Occasionally, cases come up where users need more functionality than is currently given. In my case, I wanted to be able to have a templated subtitle:

alert_script:
  garage_doors_open:
    name: Garage Doors Open Alert
    done_message: All garage doors have been closed
    entity_id: binary_sensor.garage_doors_open
    state: "on"
    repeat: 10
    can_acknowledge: true
    skip_first: true
    message: >
      {% set entities = states.cover
        | selectattr('state','match', 'open')
        | list | map(attribute='name') | map('replace', " Sensor", "") | join(", ") %}
        Please check {{ entities }}.
    notifiers:
      - default
    data:
      subtitle: >-
        {% if states('sensor.garage_doors_open_count') | int(0) > 0 %}
        {{ states('sensor.garage_doors_open_count') }} garage doors have been left open!
        {% endif %}

Other's have wanted to be able to call scripts from alert, so they can do things like TTS calls (ex1, ex2). Calling a script gives effectively infinite possibilities for the notification message, or other actions, and was my initial implementation to solve this problem. As far as I am aware, alert integrations are the only place that specifically requires a notify object. Introducing a notify that calls a script would be another solution (aka, a template_notify), but it seemed cleaner to me to add the ability for an alert to call a script directly.

After getting script calling working, I realized I should just add templating support to the data (or data_template, which I copied the logic from the rest integration). Both are included in this PR. I can split if needed, or eliminate one half if desired.

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)
• 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 #
• 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
• I have followed the perfect PR recommendations
• 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.
• 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]

Hey there @home-assistant/core, @frenck, mind taking a look at this pull request as it has been labeled with an integration (alert) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of alert 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 alert Removes the current integration label and assignees on the pull request, add the integration domain after the command.

[jhenkens]

@frenck I know the guidance is to have one feature per PR, this one has two - data templating for notify via alert and script calling from alert. Let me know if you have any thoughts as to which one is more valuable if you'd only like one or the other (or if you'd like both, but would like them separate). Either solves my issue. I know there are some other PRs (#99413 and #92039) and I wasn't sure if this was waiting on those, or just slipped by with the rush of Hacktoberfest and your holiday time in September!

[MartinHjelmare]

Thanks for the PR!

The core team has discussed this PR. We don’t want to expand the alert integration any further. Our future plans for this integration is to replace it with blueprinted automations. Once we have evolved our blueprint feature we plan to deprecate this integration.

Thanks for your willingness to contribute!

[jhenkens]

Understood, thanks for sharing the roadmap. I'll isolate this into a HACS Integration until that time, and watch the release notes (I presume I'll start getting deprecation warnings on Alert!).

[aheath70]

With the decision to deprecate, are we making assumptions about how people use this? I don't use it to trigger alerts in the traditional sense (eg. emails to other "notifiers"). I use it along with auto-entities to display warnings, errors, etc. in the Lovelace interface that a user can easily ackownledge as a known condition. There is no way that I could do this with an automation without creating a whole heap of logic and additional helper entities.