The Automation Audit: Finding Rules That Fight

Section 1: Why do good automations fight each other? (Introduction)

An automation audit finds the rules that fight each other before they fail in public: duplicate triggers, conflicting schedules, missing conditions and rules nobody remembers. List them, trace each one, and delete or merge what overlaps before the next season.

The porch light turns on at sunset. It also turns off at 9 p.m. For a month it works. Then a second automation arrives — “turn on the porch light when the doorbell sees a person” — and one evening the light comes on at 8, goes off at 9, and comes back on at 9 when a delivery driver walks up. Nothing is broken. Two rules are doing exactly what they were told.

A second example: the “away” routine turns off the lights and sets the thermostat to eco. The “arrival” routine turns them back on. Then a presence automation, added later, decides the house is empty for ninety seconds because both phones dropped off the Wi-Fi, and runs “away” while someone is sitting on the couch.

This is the most common failure in a mature smart home, and it is not a hardware problem. It is a design problem that appears only after the fifth or tenth automation, when rules that were written months apart start touching the same devices at the same time. The routines guide covers designing a single rule; this one is about the set. The system has no concept of intent. It runs the rules in whatever order the platform decides, and the last one to write the state wins.

The fix is an audit: a short, repeatable review of every rule, its trigger, its conditions, and its competition. It takes an hour the first time and fifteen minutes every quarter. This guide covers the conflict types, the inventory, the test method, and the fixes that do not require rewriting everything. For the wider automation picture, start with the Automation hub.

Section 2: What do automation conflicts look like?

Most fights fall into six patterns. Once you can name them, they are easy to spot.

Same-time contradiction

Google’s own automation help calls this out directly: an automation that turns the lights off at 6 p.m. and another that turns them on at 6 p.m. will both run, and the result depends on timing. The platform is warning you that intent does not exist in the scheduler.

State fight

Two rules that set a thermostat, a brightness, or a volume to different values will produce whichever value was written last. That is not a tie; it is a race. If both rules are legitimate, one needs a condition or a priority.

Platforms do not offer a priority setting in the way a programmer would expect. The usual fix is to make one rule conditional on the other’s outcome: the “evening dim” rule runs only if the room is occupied, or the “away” rule runs only if every phone has been gone for five minutes. The condition is the priority.

Re-trigger loop

The subtle one. A motion sensor turns on a light; the light reports its new state; a second automation listens for that state and runs a scene; the scene changes the light again. The system is not infinite, but it can oscillate for a while and fill the log with noise. The tell is a burst of repeated events at the same timestamp.

Shadowed rule

A broad rule — “everything off at midnight” — is easy to write and easy to forget. It will quietly cancel a specific rule that a guest or a night-shift worker relies on. The fix is an exclusion list, or a specific rule that re-applies its state after the broad one runs. Neither is elegant; both are honest about the overlap. Specific rules should win over broad ones, or the broad one should exclude the devices the specific rule owns.

Stale condition and duplicate owner

A condition that depends on presence, a phone, or a cloud service can be wrong without anyone noticing. A duplicate rule in a second app is worse: both run, both notify, and neither knows about the other.

Section 3: How do you inventory every automation?

You cannot audit what you cannot see. The first step is a list, not a change.

For each automation, record six things:

In Alexa, the list is under More, then Routines. In Google Home, it is the Automations tab. In Home Assistant, it is Settings, then Automations. Each editor shows the trigger, the conditions, and the actions, although the summary is often shorter than the reality.

Most platforms can show this. Home Assistant lists automations with their triggers and conditions, and its troubleshooting documentation points to the trace as the first place to look when something behaves unexpectedly: the trace shows which trigger fired, which condition passed, and which action ran. Alexa and Google show the event, conditions, and actions in their routine editors, even if the summary is less complete.

Write the list down, in a document or a spreadsheet. The act of writing it is where half the conflicts become obvious: two rules with the same trigger, three rules touching the same lamp, a “goodnight” that exists in two apps.

A worked example. The living-room lamp has four owners: the sunset rule turns it on, the goodnight rule turns it off, a motion rule turns it on at 20 percent when someone walks in after dark, and a physical switch turns it on manually. Four rules, one device. The audit question is not “which is wrong?” but “what should happen when two of them are true at once?” The answer is usually a condition: the sunset rule should not fire if the lamp is already on, and the motion rule should not fire while the goodnight scene is active.

Section 4: How do you find the rules that overlap?

With the inventory in hand, the audit is a set of comparisons.

Sort by trigger

Group the rules by what starts them. The same-time and same-device cases jump out when two rules share a trigger and an action. A simple matrix — rules down the side, devices across the top — shows which devices have more than one owner.

Sort by device

The reverse view catches the shadowed rules. For each device, list every rule that can change it. A lamp with four owners is a lamp that will surprise you.

Read the conditions out loud

“Only when someone is home,” “only after sunset,” “only if the door is closed.” Each condition is a promise about the world. Check whether it is still true and whether it is checked at the right moment: a condition evaluated at trigger time can be false by the time the action runs.

Test one rule at a time

Disable half the automations and run the scenario. If the problem disappears, the conflict is in that half; split again. This is slower than guessing and much faster than guessing wrong. Home Assistant’s testing documentation covers running an automation or its actions manually, which is useful for a single rule but not for finding interactions; the trace is the tool for interactions.

Read the log

If the log is sparse, turn on debug logging for the rules you are testing, not for the whole system; a full debug log is unreadable. The log tells you what actually ran, not what you think ran. Look for a burst of events at the same second, a state that flips twice, or a rule that fires when its trigger should not have been true. The trace is the detailed version of the same story.

Section 5: Can you fix conflicts without rewriting everything?

The tempting response is to delete everything and start over. Resist it. Most conflicts have a small fix.

• Consolidate duplicates. If two rules do the same “goodnight,” keep one. The other is a future bug.
• Add a guard condition. “Turn on the porch light when a person is seen” becomes “…only if the porch light is off.” One condition removes the fight.
• Add a debounce. A short delay or a “last triggered” condition stops a rule from firing three times in ten seconds. Five minutes is usually enough for a door sensor; thirty seconds is enough for a motion light.
• Give the specific rule priority. Exclude the night-light from the broad “all off” rule, or check a manual override flag first.
• Separate the trigger from the action. If a rule listens to a device state that it also changes, it can feed itself. Listen to the sensor, not the output.
• Name rules by intent. “Porch light — sunset on” and “Porch light — 9pm off” are easier to audit than “Automation 3” and “Test 2.”

Record the change in the same document, with a date and a one-line reason. Six months from now, “why does the hall light ignore motion after 11?” is a much easier question when the answer is written down. The if-but-only-if framework is the reference for the condition patterns themselves.

One pattern deserves its own note: the manual override. A motion light that turns off while someone is reading is a rule doing its job badly. A virtual switch — “hold the light on” — that the automation checks before turning anything off gives the human the last word without disabling the automation.

Section 6: What does a quarterly audit look like, and who can skip it? (Conclusion)

1. Print or open the inventory. Add any rule you created since the last audit; delete any you no longer use.
2. Run the conflict checks. Same trigger, same device, same time, duplicate owner. Fix one rule at a time.
3. Test the scenarios that matter. Leaving, arriving, bedtime, and the one routine a household member relies on.
4. Update the document. The audit is only useful if the next one starts from the current state.

The first audit takes an hour; the next takes fifteen minutes, and the one after that takes ten. The audit is a habit, not a project.

A good audit usually ends with fewer rules than it started with. If the count went up, you probably added a workaround instead of fixing the conflict.

Some homes do not need this. If you have three automations, the inventory is a sticky note and the conflicts are unlikely. The audit earns its hour at around ten rules, or the first time a light behaves in a way nobody intended.

A smart home is a small software system. The rules are the code, and like any code, they drift. The audit is how you find the drift before it finds you.

Where to buy

Related reading

• The If-But-Only-If Framework — conditions and guardrails for a single rule.
• Set-and-Forget Automation — designing routines that hold up.
• Notifications That Don’t Become Noise — the alert side of the same problem.
• Automation Fail-Safes — what still works when the network does not.

Sources

• Supported automation starters, conditions & actions — Google Home Help, the conflicting-automation warning checked October 2026
• Troubleshooting automations — Home Assistant, traces and symptom-based debugging checked October 2026
• Testing automations — Home Assistant, running and testing automations checked October 2026
• Create an Alexa Routine in the Alexa App — Amazon, events, conditions and actions checked October 2026