Automation loop and conflict check

Two automations can listen for the same door and then send the same cover in opposite directions. The one that runs last wins, and the trace looks fine if you only open one of them. This integration reads automations and scripts, including ones that came from blueprints, and posts what it finds under Settings → System → Repairs. It does not turn devices on or off, and it does not edit YAML.

A sensor that has stopped reporting is sensor watchdog. An integration that needs a reload is self-healing integration reload. A list of what is still unavailable after an outage is offline devices report. This one is about automations arguing with each other.

What problem it solves

You want a warning when a new automation can loop with one you already have, or when two of them set the same entity to different states from the same trigger, before you notice it on a device.

How it works

The integration is a service. It does not add a device you can unplug. After setup it checks on Home Assistant start, a few seconds after you save an automation or a script, and again every 6 hours. The action automationscheck.run checks immediately and returns the findings.

1. Conflict — two automations share a trigger and, in the same situation, set one entity to two different values. A cover one closes and one opens is the usual case. The repair names both automations, the entity, both values, and the shared trigger.
2. Loop — automation A changes something B listens to, and B changes something A listens to. The repair lists the chain.
3. Self-trigger — one automation changes an entity its own trigger listens to, so it can run again immediately.
4. Unknown trigger id — a condition checks a trigger.id that no trigger in that automation defines. That branch never runs.
5. Trigger without effect — a trigger starts the automation, and no branch matches that id.

Conditions count. An action that only runs when a mode helper is away does not conflict with one that only runs when it is home. A trigger to: home means the helper is home now. A from: means it is no longer that value. Options on an input_select are read, so a sync that only looks circular is dropped when no single option can fire both sides. Actions after a delay or wait, and triggers with different for: times, are not treated as simultaneous. A script an automation calls is part of that automation. Blueprints are expanded and checked like any other automation.

The Findings sensor on the Automationscheck device is the count of findings you are showing. Attributes are errors, warnings, notes, checked, skipped, last_check, and findings. Notes stay off the repair list unless you turn on “Also show notes as repairs.” Disabled automations are skipped unless you turn on “Also check disabled automations.” A repair you already understand can be ignored in the Repairs panel. Ignoring it does not delete the automation.

Targets that are templates, other than {{ trigger.entity_id }}, are not predicted. Areas, devices, and labels are not expanded. Template conditions count as unknown, so they do not rule a conflict out. Scenes are not read. A finding is a prompt to look, not a verdict. Sometimes both actions are what you wanted.

Hardware notes

• No new device. HACS, then the custom repository, then the integration. The repository URL stays in HACS. Do not paste a token into a repair or a dashboard.
• Notify. Optional. Companion, or any notify service, if you want a push when the count leaves zero. The sensor is enough if you only look at Repairs.
• What it cannot see. UI automations are included once Home Assistant has loaded them. A package that fails to load is skipped with the rest of the broken config, and the skipped attribute is the count of automations the checker could not parse.

Snippet

The check itself is the integration. This optional automation only notifies. The sensor entity id follows the device name Automationscheck and the entity name Findings.

trigger:
  - trigger: numeric_state
    entity_id: sensor.automationscheck_findings
    above: 0
action:
  - action: !input notify_service
    data:
      title: "Automation check"
      message: >-
        {{ states('sensor.automationscheck_findings') }} finding(s).
        {{ state_attr('sensor.automationscheck_findings', 'errors') }} errors,
        {{ state_attr('sensor.automationscheck_findings', 'warnings') }} warnings.

A manual run, which also returns the list:

action: automationscheck.run

Setup outline

1. In HACS, add https://github.com/uekala/automationscheck as a custom integration repository. Install Automationscheck. Restart Home Assistant.
2. Settings → Devices & services → Add integration → Automationscheck. Leave both options off for the first run.
3. Open Settings → System → Repairs. A clean config shows nothing from this integration. The Findings sensor should be 0 after the first check.
4. Save any automation. Within a few seconds the sensor should refresh. last_check moves even when the count stays 0.
5. Optional: import the notify automation and point it at your notify service. Raise the count on purpose with two test automations that set one input_boolean in opposite directions from the same helper, confirm the conflict repair, then delete the tests.

Troubleshooting

• No Findings sensor. The integration entry is not loaded, or the restart after install was skipped. Check Settings → Devices & services, then the logs for automationscheck.
• A loop you can see is missing. The chain goes through a scene, a template entity id, or an area target. Those are outside what this version resolves. Read the two automations yourself.
• A conflict you do not believe. The conditions did not separate the two actions. A template condition is treated as unknown, so it will not save you. Add a state condition the checker can read, or ignore the repair if the overlap is intentional.
• Disabled automations show up. The option to include them is on. Turn it off. They do not run, so they do not collide.
• Notes flooded Repairs. “Also show notes as repairs” is on. Notes are uncertain. Turn that option off and keep errors and warnings.
• You wanted a list of offline devices. That is offline devices report. This integration does not look at unavailable.

Credits

Based on Automationscheck. That integration builds a trigger-and-action graph from automations and scripts and reports conflicts, loops, self-triggers, unknown trigger ids, and triggers with no effect as repairs. This write-up is an original overview of that check, plus an optional notify when the Findings count leaves zero. The integration still does not change your automations.