Trigger an automation when an integration sends a repair

I would like to trigger an automation when a specific third-party integration sends a repair, such as the need for reconfiguration/login. Unfortunately I cannot base my automation only on sensors with Unavailable value, because sometimes they go in that state without requiring a new login.

I’ve tried creating this one to monitor when the integration named vw_eu_data_act fails:

alias: Integration check
description: ""
triggers:
  - trigger: template
    value_template: >-
      {{ issues().values() | map(attribute='issue_id') | select('search','vw_eu_data_act') | list | length > 0 }}
conditions: []
actions:
  - action: rest_command.ha_notify_error
    data:
      description: Authentication error
mode: single

… but it never triggers!

However, if I paste the template {{ issues().values() | map(attribute='issue_id') | select('search','vw_eu_data_act') | list | length > 0 }} into the template editor, it correctly prints true or false depending on the presence of the repair.

So what’s wrong here? Why the automation never triggers even if the template seems good?

For a Template trigger to fire, it’s rendered value must change from false to true… if it starts a true, it’s not going to fire until you clear the repairs and another one comes along.

Yes, of course. But the problem is that I have “repaired” the integration and it breaks every couple of weeks, while the automation doesn’t trigger (and thus doesn’t generate a flow to examine).

Now it’s like this:

Make a binary sensor template out of the expression. Add it to the recorder and use it to trigger the automation. This way you can see it change to false and to true (or not).

I think the problem may stem from the fact that your template doesn’t reference any states or use now(), so it only updates on restart or reload… this kind of thing is obscured bu the template editor, because it re-renders every minute on its own.

The easiest fix would be to switch to a time pattern trigger set to an interval that is appropriate to your needs and move the template to a condition.

Thanks, good idea, will try to add one also for troubleshooting reasons.

Mmm, interesting! I didn’t know that there was such a requirement.

This is perfectly doable, as once the integration requires the reconfiguration, a manual operation is needed. But how can I run the action only once? If there will be a time pattern trigger, with the template condition that evaluates to true when the repair is necessary, it will retrigger next time. I could disable the automation after its first run, but then I’ll need to remember to enable it again…

Running it just once with a time pattern trigger is difficult, but throttling the execution of the actions for a certain time period is pretty easy:

  - alias: Prevent automation from running more than once per hour
    condition: template
    value_template: |
      {{ this.attributes.last_triggered | default(as_datetime(0), 1) < now() - timedelta(hours=1) }}

If you prefer the action to run just once, your best option is to go with Pete’s suggestion, but make it a trigger-based template binary sensor.

This seems to have the same issue that the classic template. I went to Settings > Devices and services > Helpers tab and created a new helper by choosing Template and then Binary sensor. When I pasted the expression above, it showed the correct state but this message appeared below:

This template does not listen for any events and will not update automatically.

And it’s true: I had to edit the template for the binary sensor to update its value. So the problem is in the template expression that doesn’t refer to any event… Any other suggestion?

You need to use a trigger-based template binary sensor… or you may be able to cheat it in the Helper by using now(), which will cause it to update once a minute…

EDIT: Just tested it, and it does work in the Helper.

{% set now = now() %}
{{ issues().values() | map(attribute='issue_id') 
| select('search','vw_eu_data_act') | list | length > 0 }}

Actually it was better: simply adding {% set now = now() %} in the automation trigger template solved the issue, without even using the binary sensor (which can be useful for troubleshooting if anyone wants).

Thanks!