Alert2 is a Home Assistant component that supports alerting and sending notifications based on conditions and events. It's a retake on the original Alert integration.

• New features
• Installation
• Setup
• Description
• Configuration
• Generator patterns (Advanced)
• Front-end UI
• Service calls
• Python alerting

• Native event-based alerting. No need to approximate it with conditions and time windows.
• Template conditions. No need for extra binary sensors. Also means the logic for an alert is in one place in your config file, which makes it easier to manage.
• Snooze / disable / throttle notifications. Handy for noisy sensors or while developing your alerts.
• Persistent notification details. In your HA dashboard, you can view past alert firings as well as the message text sent in notifications.
• Custom frontend card. Makes it easier to view and manage recent alerts.
• Hysteresis. Reduce spurious alerts as sensors fluctuate.
• Template notifiers. Dynamically specify who gets notified.
• Generator patterns. Dynamically define multiple similar alerts, with wildcard support.

Suggestions welcome! Start a Discussion or file an Issue.

Setup is done through editing your configuration.yaml file.

1. Add the following line to configuration.yaml:

    alert2:
   

   The Configuration section, below, has details on what else to add here.

2. Restart HomeAssistant

Alert2 supports two kinds of alerts:

• Condition-based alerts. The alert watches a specified condition. It is "firing", aka "on", while the condition is true. This is similar to the existing Alert integration. Example: a temperature sensor that reports a high temperature.

• Event-based alerts. The alert waits for a specified trigger to occur and is "firing" for just that moment. Example: a problematic MQTT message arrives.

Configuration syntax and examples are in the Configuration section. Here is an overview:

Condition alerts can specify a condition as a template or entity name. The alert is firing when the condition evaluates to true.

An alert can also specify a threshold dict that includes min/max limits and optional hysteresis. If a threshold is specified, the alert is firing if the threshold is exceeded AND any condition specified is true.

Hysteresis is also available via the delay_on_secs parameter. If specified, the alert starts firing once any threshold is exceeded AND any condition is true for at least the time interval specified. This is similar in motivation to the skip_first option in the old Alert integration.

Event alerts may be triggered either by an explicit trigger option in the config, or by a service call to alert2.report. An event alert can also specify a condition as a template or entity name. The alert fires if it is triggered AND the condition evaluates to true.

Each alert maintains a bit indicating whether it has been ack'd or not. That bit is reset each time the alert fires. Ack'ing is done by clicking a button in the UI (described below) or calling the alert2.ack service. Ack'ing stops reminder notifications (see below) and is indicated visually in the UI. The alert2.unack service is also available.

Notifications are sent when an event alert fires, when a condition alert starts or stops firing, and periodically as a reminder that a condition alert is still firing. You can optionally request that notifications be sent at the end of periods when notifications where snoozed or throttled if there was any alert activity in the interval. This is via the summary_notifier config option. We recommend setting summary_notifier to be notified when e.g., throttling ends.

Each notification by default includes some basic context information (detailed below). An alert can also specify a template message to be sent each time the alert fires. That message is sent out with notifications and also is viewable in the front-end UI. Condition alerts can also specify a done_message to be sent when the alert stops firing.

There are a few mechanisms available for controlling when and whether notifications are sent.

• reminder_frequency_mins - this config parameter specifies how often reminders are sent while an alert continues to fire. May be a list of values (similar to the repeat option in the old Alert integration).

• throttle_fires_per_mins - this config parameter throttles notifications for an alert that fires frequently. It affects all notifications for the alert.

• Ack'ing an alert prevents further reminders and the stop notification for the current firing of a condition alert. For both condition and event alerts, ack'ing also prevents any throttled notification of previous firings of the alert. Unack'ing an alert will restart notifications for a condition alert if it is still firing.

• Snoozing notifications for an alert prevents any notifications from current or future firings of an alert for a specified period of time. The start of snoozing also implicitly ack's the alert.

• Disabling notifications for an alert prevents any notifications until it is enabled again. Snoozing & disabling affect only notifications. Alerts will still fire and be recorded for reviewing in your dashboard.

The text of each notification by default includes some basic context information that varies based on the type of notification. That information may be augmented with the message or done_message options. Notification text looks like:

• Event alert fires: message text prepended with name (or friendly_name) of alert.

    Alert2 boiler_ignition_error: `message`
  

• Condition alert fires: message text prepended with name (or friendly_name) of alert. Default message is "turned on" if no message specified. Alert name omitted if annotate_messages is false

    Alert2 kitchen_door_open: turned on
  

• Condition alert reminder that it's still on:

    Alert2 kitchen_door_open: on for 5m
  

• Condition alert stops firing: done_message text prepended with name (or friendly_name) of alert. Default message is "turned off after ..." if no done_message specified. Only done_message text is sent if annotate_messages is false. Setting annotate_messages to false may be useful for notification platforms that parse the message (such as the "clear_notification" message of the mobile_app platform)

    Alert2 kitchen_door_open: turned off after 10m
  

• Either event or condition alert fires and exceeds throttle_fires_per_mins. Message is prepended with "[Throttling starts]", which can not be overridden with annotate_messages:

    [Throttling starts] Alert2 kitchen_door_open: turned on
  

• Throttling ends for event or condition alert that specified throttle_fires_per_mins and summary_notifier was specified. Message includes information on what happened while the alert was throttled:

    [Throttling ends] Summary: Alert2 kitchen_door_open: fired 10x (most recently 15m ago): turned off 19s ago after being on for 3m
  

You can specify which notifiers are used for alerting via the notifier and summary_notifier config options. They may be a single notifier, a list of notifiers, a template resolving to a list of notifiers, or the name of an entity whose state is a list of notifiers. See Notifier Config section, below.

During HA startup, HA initializes notifiers independently of the rest of HA. So notifiers may not be ready even when HA declares that it has fully started. Alert2 will automatically defer notifications during startup if a notifier does not yet exist. notifier_startup_grace_secs controls the length of the startup grace period.

You may also specify a YAML notify group. We recommend setting defer_startup_notifications if you choose to use a notify group. The issue is that HA may initialize the notify group early during startup, before the member notifiers are ready. And Alert2 can not see which member notifiers are ready. So Alert2 may notify a group with missing members, resulting in an internal error in the notify component. To avoid this, you can list your group names in defer_startup_notifications which will defer any notifications to those notifiers until notifier_startup_grace_secs has passed.

The current recommended way to notify groups is to create an entity, such as a template entity (e.g. sensor.high_pri_group), and set the members of the group as the state of the entity (example in Notifier Config section, below). Alert2 will then automatically defer notifications to notifiers in the group that do not yet exist during startup, without having to set defer_startup_notifications.

Alert2 does not yet support Notify Entity Groups, but open an discussion and request the feature if interested.

Alert2 automatically defines an alert, alert2.error. It fires and will notify you of problems in your configuration file as well as if Alert2 internally encounters a problem, such as a notifier that does not exist. If you don't want to be notified of errors like these, an option, skip_internal_errors, is available. One reason this alert is important is because if Alert2 itself encounters a problem, you may stop receiving alerts for things you do care about. So in a sense, this alert is at least as important as your most important alert.

alert2.error may be configured. See example in the Tracked section, below. If you specify a notifier that doesn't exist for alert2.error itself, then it falls back to persistent_notification.

Alert2 installs a HA global handler to detect internal tasks that die and fires alert2.error. So you may see it fire for problems outside of Alert2.

Alert configuration is done through the alert2: section of your configuration.yaml file. There are three subsections: defaults, alerts, and tracked.

We recommend that your config specify at least the following parameters:

alert2:
  defaults:
    notifier: foo # notifier name to use for most alerts
    summary_notifier: foo # notifier to use for summaries (e.g. when throttling ends)
    throttle_fires_per_mins: [ 10, 60 ] # throttle notifications for any alert that fires
                                        # more than 10x in 60 minutes

The following are all optional.

Example:

 alert2:
   skip_internal_errors: true
   notifier_startup_grace_secs: 60
   defer_startup_notifications: mygroup
   defaults:
     ...

The defaults: subsection specifies optional default values for parameters common to every alert. Each of these parameters may be specified either in this subsection or over-ridden on a per-alert basis.

Example:

 alert2:
   defaults:
     reminder_frequency_mins: 60
     notifier: telegram
     annotate_messages: true
     throttle_fires_per_mins: [ 10, 60 ]

Note reminder_frequency_mins or throttle_fires_per_mins may be specified as a list using a YAML flow sequence or on separate lines. The following two are identical in YAML:

    reminder_frequency_mins: [ 10, 20, 60 ]
    reminder_frequency_mins:
      - 10
      - 20
      - 60

The alerts: subsection contains a list of condition-based and event-based alert specifications. The full list of parameters for each alert are as follows:

Alert names are split into domain and name. The reason is partly for semantic clarity and also for future management features, like grouping alerts by domain.

An event-based alert specifies a trigger, and fires when the trigger fires, as long as an optional condition is also true. Example:

alert2:
  alerts:
    - domain: boiler
      name: ignition_failed
      trigger:
       - platform: state
         entity_id: sensor.boiler_failed_ignition_count
      condition: "{{ (trigger.from_state is not none) and (trigger.to_state is not none) and (trigger.from_state.state|int(-1) > 0) and (trigger.to_state.state|int(-1) > 0) and (trigger.to_state.state|int > trigger.from_state.state|int) }}"
      #   can be an entity name, e.g.:
      # condition: binary_sensor.boiler_enabled
      message: "{{ trigger.from_state.state }} -> {{ trigger.to_state.state }}"

There are a few different forms of condition-based alerts. The simplest is an alert that just specifies a condition. It is firing when the condition is true. The condition can be either a template or an entity name. Example of an alert to detect when the temperature is too low:

alert2:
  alerts:
    - domain: thermostat_fl2
      name: temperature_low
      condition: "{{ states('sensor.nest_therm_fl2_temperature')|float <= 50 }}"
      message: "Temp: {{ states('sensor.nest_therm_fl2_temperature') }}"
      
    - domain: thermostat_fl1
      name: temperature_low
      condition: binary_sensor.nest_therm_fl1_temperature_too_low
      message: ...

Notifications include by default context information, so the resulting text might be:

Alert2 thermostat_fl2_temperature_low: Temp: 45

An alert can alternatively specify a threshold with hysteresis. So the previous temperature-low alert could be specified with hysteresis as:

alert2:
  alerts:
    - domain: thermostat_fl2
      name: temperature_low
      threshold:
        value: sensor.nest_therm_fl2_temperature
        #  can be a template. e.g.
        # value: "{{ states('sensor.nest_therm_fl2_temperature') }}"
        minimum: 50
        hysteresis: 5
      message: "Temp: {{ states('sensor.nest_therm_fl2_temperature') }}"

This alert would start firing if the temperature drops below 50 and won't stop firing until the temperature rises to at least 55. A corresponding logic applies when a maximum is specified. Both minimum and maximum may be specified together.

A condition may be specified along with a threshold. In this case, the alert fires when the condition is true AND the threshold value is out of bounds. delay_on_secs is another form of hysteresis that may be specified to reduce false alarms. It requires an alert condition be true or threshold be exceed for at least the specified number of seconds before firing. Note on a corner case: the count of seconds for delay_on_secs does not reset if the value switches instantaneously from exceeding the minimum to exceeding the maximum.

Alerts may pass additional data to the notifier which is convenient for notification platforms such as mobile_app. Example:

alert2:
  alerts:
    - domain: cam_basement
      name: motion_while_away
      condition: "{{ (states('sensor.jdahua_basement_motion') == 'on') and
                     (states('input_select.homeaway') in [ 'Away-local', 'Away-travel' ]) and
                     ((now().timestamp() - states.input_select.homeaway.last_changed.timestamp()) > 5*60) }}"
      notifier: mobile_app_pixel_6
      title: "test title"
      data:
        group: "motion-alarms"

The notifier parameter can take a variety of different values. The basic usage can specify a single notifier or list of notifiers, or an entity whose state is a list of notifiers:

      # Single notifier
      notifier: telegram_1

      # List of notifiers (native YAML)
      notifier:
      - telegram_1
      - telegram_2

      # List of notifiers (YAML flow sequence, identical to list, above)
      notifier: [ telegram_1, telegram_2 ]

      # List of notifiers as a string.
      # Will be interpreted as python literal, so inner quotes needed.
      notifier: "[ 'telegram_1', 'telegram_2' ]"

      # Entity whose state is a list of notifiers (as a string)
      # for example, if sensor.my_notifier_list has state: "[ 'telegram_1', 'telegram_2' ]"
      # you might say:
      notifier: sensor.my_notifier_list

You can also specify a template that evaluates to either single notifier, a list of notifiers or to a single entity name that contains a list of notifiers

      # The template can resolve to a single notifier
      notifier: "{% if states('binary_sensor.is_away')|bool %} mobile_app_a
                 {% else %} mobile_app_b {% endif %}"
      
      # It can resolve to a list of notifiers
      notifier: "{{ [ 'notifier_a', 'notifier_b' ] + [ 'notifier_c', 'notifier_d' ] }}"

      # It can resolve to the name of an entity that has a notifier or list of notifiers
      # as its state.
      #
      # Suppose you have two entities, one with notifiers to use when away and another
      # to use when home.
      # say sensor.away_notifiers has state "[ 'notifier_a', 'notifier_b' ]"
      # and sensor.home_notifiers has state "notifier_c"
      # you could dynamically switch between them with:
      notifier: "{% if states('binary_sensor.is_away')|bool %} sensor.away_notifiers
                 {% else %} sensor.home_notifiers {% endif %}"

      # Or say you want to conditionally notify a 3rd notifier, "mobile_app_josh":
      notifier: "{{ [ 'telegram_1', 'telegram_2' ] +
                    ( [ 'mobile_app_josh' ] if states('binary_sensor.is_away')|bool else [] ) }}"

A technical note on quoting and lists of notifiers:
Templates evaluate to a string, even if they have a list inside. An entity's state also produces a string. Alert2 detects lists in such strings by evaluating the string as a python literal and seeing if a list results. So notifiers in such lists need to be quoted or the eval mechanism will think you're trying to name a variable.

An example of using an entity as an Alert2 native group. Handles alerts fired during HA startup better than "notify groups".

template:
  - sensor:
      - name: my_group
        state: "[ notifier1, notifier2 ]"
        # OR could be:
        state: "{{ [ 'notifier1', 'notifier2' ] }}"
alert2:
  alerts:
    - domain: test
      name: motion_while_away
      condition: ...
      notifier: sensor.my_group

The tracked config subsection is for declaring event alerts that have no trigger specification and so can only be triggered by a service call to alert2.report. Declaring these alerts here avoids an "undeclared alert" alert when reporting, and also enables the system to restore the alert state when HomeAssistant restarts.

Any of the above event alert parameters may be specified here except for message (since alert2.report specifies the message), trigger and condition.

The alert2.error alert may be configured here.

Example:

alert2:
  defaults:
    reminder_frequency_mins: 60
    notifier: telegram
  alerts:
    ...
  tracked:
    - domain: alert2
      name: error
      reminder_frequency_mins: 20
      ...
    - domain: dahua
      name: side_porch_fault

We recommend setting a value for the default notifier or configuring alert2.error in the tracked section of the config so that alert2 error notifications will go somewhere you wish.

As described above in early_start, alerts by default don't start being monitored until HA fully starts. This is to reduce template errors during startup due to entities not being defined yet. However, the downside is that if some problem prevents HA from fully starting, none of your alerts will be monitored. To prevent this, we provide a binary_sensor entity, binary_sensor.alert2_ha_startup_done, that turns on when HA has fully started. That entity also has an attribute, start_time, that is the time the module loaded. Together you can use them to alert if HA startup takes too long as follows:

alert2:
  alerts:
    - domain: general
      name: ha_startup_delayed
      # test against 'off' so we don't trigger during startup before binary_sensor has initialized
      condition: "{{ states('binary_sensor.alert2_ha_startup_done') == 'off' and
            (now().timestamp() - state_attr('binary_sensor.alert2_ha_startup_done', 'start_time').timestamp()) > 300 }}"
      message: "Starting for last {{ (now().timestamp() - state_attr('binary_sensor.alert2_ha_startup_done', 'start_time').timestamp()) }} seconds"
      early_start: true

If you have high-priority alerts, you might consider setting notifier to be a high-priority notifier and summary_notifier to be a low-priority notifier.

Also, alert2 entities are built on RestoreEntity, which backs itself up every 15 minutes. This means, alert firing may not be remembered across HA restarts if the alert fired within 15 minutes of HA restarting.

EXPERIMENTAL - news of changes will posted at https://community.home-assistant.io/t/alert2-a-new-alerting-component

Generator patterns let you create multiple, similar alerts dynamically, and can be based on a wild-card search of entities. Here's an example of a generator watching for battery_plus entities reporting a low battery:

alert2:
  alerts:
    - generator_name: low_bat
      generator: "{{ states.sensor|selectattr('entity_id','match','sensor.*_battery_plus')
                                  |map(attribute='entity_id')
                                  |list }}"
      domain: battery
      name: "{{ genEntityId|regex_replace('sensor.(.*)_battery_plus', '\\\\1') }}_is_low"
      condition: "{{ state_attr(genEntityId, 'battery_low') }}"
    #
    # or, slightly more succinctly using entity_regex()
    #
    - generator_name: low_bat
      generator: "{{ states.sensor|entity_regex('sensor.(.*)_battery_plus')|list }}"
      domain: battery
      name: "{{ genGroups[0] }}_is_low"
      condition: "{{ state_attr(genEntityId, 'battery_low') }}"
    #
    # or, with an explicit list of names
    #
    - generator_name: low_bat
      generator: [ 'dev1', 'dev2', 'dev3' ]
      domain: battery
      name: "{{ genElem }}_is_low"
      condition: "{{ state_attr('sensor.'+genElem+'_battery_plus'), 'battery_low') }}"
    

Suppose there are three battery_plus entities:

sensor.dev1_battery_plus
sensor.dev2_battery_plus
sensor.dev3_battery_plus

Then any of the above generators will create three condition alerts:

alert2.dev1_is_low
alert2.dev2_is_low
alert2.dev3_is_low

where alert2.dev1_is_low will fire if the "battery_low" attribute of sensor.dev1_battery_plus becomes true, and similarly for the other two alerts.

Here's how the first generator, above, is working:

1. generator specifies a template.
2. The template starts with the set of all sensor entities, filters for those whose entity_id matches the regex, and returns the list of matching entity_ids.
3. Alert2 creates an alert for each entity_id in the list. That entity_id is made available to all template config fields via the genEntityId variable. domain, name, and friendly_name also accept templates for generator alerts.
4. A sensor will also be created, sensor.alert2generator_low_bat, whose state will be the number of alerts created by the generator. This is useful for verifying that the generator is producing the expected number of alerts.

The second generator example, above uses the entity_regex filter. Using that filter makes available to all template config fields the variable genEntityId with the entity_id as well as the variable genGroups with the regex groups that matched.

The third generator lists strings that are not entity_ids. In this case, those strings are available as genElem to template config fields and genEntityId is not defined.

See the Reference section below for a complete list of possibilities.

generator config field specifies a list of objects. An alert is created for each object. If that object is a string and the string is an entity_id, then it is put in the variable genEntityId. If the string is not an entity_id, then it is put in the variable genElem. If the object is a dictionary, then the keys of the dictionary are defined as variables. entity_regex() returns a list of dictionaries with genEntityId and genGroups as keys.

As a fallback, for any object in the list, the variable genRaw is defined as the object.

Generators track HA entity life cycles and so will dynamically create or destroy alerts as the set of entities changes. Technical note: by default in HA, using "states|" or "states.sensor|" in a template causes the template to be reevaluated every time the state of any entity in HA changes. For generator templates, we change this behavior so it only updates on entity life cycle events (to reduce unnecessary re-renderings).

Last implementation detail: templates actually render to strings. So "{{ [ 1, 2 ] }}" renders to the string "[1, 2]". Alert2 internally does a literal_eval to convert the string back into a list.

Really last implementation detail: any templates specified for domain, name, or friendly_name are evaluated only when the generator creates a new alert - i.e. so you can't change the name of an alert on the fly.

generator can take multiple forms. Each is a list of some sort, and an alert is created for each element of the list.

    # A native YAML list.
    # genEntityId is defined to be each element in the list if the element is an entity_id
    # genElem is defined otherwise.
    # genRaw is defined to be each element regardless.
    generator: [ foo1, foo2 ] # YAML flow sequence
    generator:
       - foo1
       - foo2

    # A template evaluating to a list of strings.
    # genEntityId is defined to be each element in the list if the element is an entity_id
    # genElem is defined otherwise.
    # genRaw is defined to be each element regardless.
    generator: "{{ [ 'sensor.foo1', 'sensor.foo2' ] }}"

    # A template evaluating to list of dictionaries
    # The keys of the dictionary are available as variables in all Alert2
    # template fields
    # genRaw is defined as the raw dictionary object.
    generator: "{{ {'a':'foo'}, {'a':'bar'} }}"

entity_regex is a filter function that consumes a list of entities, filters them and generates a list of dictionaries. It has the following signature:

entity_regex( find_regex, ignorecase=False )

find_regex specifies the regex test to apply to the entity_id of each entity. For each entity that matches, the output list includes a dictionary that maps "genEntityId" to the matched entity_id and genGroups to the list of regex groups (using match.groups())

Here are some examples intended to match temperature sensors such as sensor.temp_fl1, sensor.temp_fl2 and so forth.

# Default behavior with group present in regex
# genEntityId = sensor entity_id
# genGroups   = ["fl1"] then ["fl2"] ...
generator: "{{ states.sensor|entity_regex('sensor.temp_(.*)')|list }}"

# No regex group
# genEntityId = sensor entity_id
# genGroups   = []
generator: "{{ states.sensor|entity_regex('sensor.temp_.*')|list }}"

Instead of states.sensor, you could use states or states.binary_sensor and so forth in the above examples.

If you wanted to alert on low temperature, but don't want to use entity_regex, you could alternatively say something like:

alert2:
  alerts:
    - generator_name: low_temp
      # genElem will be the entity_id
      generator: "{{ states.sensor|selectattr('entity_id', 'match', 'sensor.temp_.*')
                                  |map(attribute='entity_id')|list }}"
      domain: thermostat
      name: "{{ genEntityId
                |regex_replace('sensor.temp_(.*)','\\\\1') }}_is_low"
      condition: "{{ states(genEntityId)|float < 40 }}"
    #
    # or equivalently
    #
    - generator_name: low_temp
      # genElem will be "fl1", "fl2", ...
      generator: "{{ states.sensor|selectattr('entity_id', 'match', 'sensor.temp_.*')
                                  |map(attribute='entity_id')
                                  |regex_replace('sensor.temp_(.*)', '\\\\1')
                                  |list }}"
      domain: thermostat
      name: "{{ genElem }}"
      condition: "{{ states('sensor.temp_'+genElem)|float < 40 }}"

We recommend also installing the Alert2 UI, which includes a card for compactly viewing and managing Alert2 alerts. It also enhances the information shown in the "more-info" dialog when viewing Alert2 entities.

Without Alert2 UI you can still view and manage Alert2 alerts, but the process is a bit more involved.

Alert2 defines a few new service calls.

alert2.report notifies the system that an event-based alert has fired. It takes two parameters, the "domain" and "name" of the alert that fired. You can also pass an optional message argument specifying a template for a message to include with the firing notification. That domain/name should be declared in either the tracked or alerts section of your config (described above). alert2.report overrides any condition and trigger specified in the event alert declaration.

An example of using alert2.report in the action section of an automation:

    trigger:
      ...
    condition:
      ...
    action:
      - service: alert2.report
        data:
          domain: "boiler"
          name: "fault_{{trigger.event.data.name}}"
          message: "code is {{ trigger.event.data.dData.Code }}"

A few other service calls are used internally by Alert2 UI, but are available as well:

alert2.ack_all acks all alerts.
alert2.notification_control adjust the notification settings.
alert2.ack acks a single alert.
alert2.unack unacks a single alert.

More details on these calls are in the services.yaml file in this repo, or in the UI by going to "Developer tools" -> "Actions".

If you're developing python components, Alert2 is handy for alerting on unexpected conditions. The way to do that is:

1. In the manifest.json for your component, put a dependency on alert2. This is to ensure alert2 has initialized before your component.

    {
        "domain": "mydomain",
        "name": "My Component",
        ...
        "dependencies": [ "alert2" ]
    }                    
   

2. In your component, import alert2 and in async_setup declare whatever event alerts you might want to trigger. E.g.:

    import custom_components.alert2 as alert2
   
    async def async_setup(hass, config):
        await alert2.declareEventMulti([
            { 'domain': 'mydomain', 'name': 'some err 1' },
            { 'domain': 'mydomain', 'name': 'some err 2' },
            ...
        ])
   

3. To trigger an alert, call report(), which takes an optional message argument. E.g.:

    if unexpected_thing_happens:
        alert2.report(DOMAIN, 'some err 1', 'optional message string')
   

The alert2 module also offers a create_task() and create_background_task() method to create tasks. It's similar to hass.async_create_task except it also report()s uncaught exceptions - so your task doesn't die silently. Should only be called from the event loop. Example usage:

async def testTask():
    pass
taskHandle = alert2.create_task(hass, 'mydomain', testTask())
#
# Later on, cancel task if you want
taskHandle.cancel()

If an unhandled exception occurs, alert2 will fire an alert: alert2.mydomain_unhandled_exception. declareEventMulti() automatically declares mydomain_unhandled_exception if you haven't already.