Multiple rules can issue contradictory commands to the same device

What it is

Two rules, each perfectly reasonable, can issue opposite commands to the same device at the same moment: "turn on the living-room lights at sunset" and "turn off all lights when nobody is home" both hold on a winter evening when everyone happens to be out — one says on, the other off. This is a rule conflict, a structural product of the multi-rule model, not an authoring error.

Conflict must be judged at the command level, not the intention level: rules with aligned goals but opposed paths also conflict ("switch lights off for energy saving" versus "switch lights on when motion detected", alternating in a corridor people cross); rules with unrelated intents sharing an action device likewise converge into contradictory commands. What users feel is "the device doesn't listen" or "it works sometimes" — few trace the symptom back to a pair of rules on their own.

Why it happens

The root is overlap in trigger-condition space. Each rule's condition is a region in a multi-dimensional space (time, presence, sensor values), and regions written by different authors necessarily intersect in the real world — because each designer sees only their own rule, and nobody owns the joint intersection.

Conflict then surfaces only at the device where actions converge. Rules are evaluated independently: rule A fires, rule B fires, each dispatches its command, and the system never notices it has dispatched a contradiction — the contradiction is exposed only when the device must decide which command to obey. This is why conflicts are invisible at creation time: authoring interfaces show rule semantics (reasonable), not command timing (conflicting).

A third layer: overt conflicts are rare; covert ones are everyday. Head-on collisions within the same millisecond seldom happen; the common form is a staggered tug-of-war — A turns the light on, two minutes later B's condition also holds and turns it off, and A's next evaluation cycle turns it back on. The user sees a device switching itself on and off, never suspecting a loop of two rules underneath.

Studying it

• Conflict detection research: work applying static analysis and model checking to smart-home rule sets enumerates rule pairs whose conditions can co-hold and classifies them by whether their actions oppose — yielding how theoretical conflict rates grow with rule count and device sharing.
• Rule-corpus analysis: run conflict detection over real rule sets and measure the share of overlapping pairs — the method of Ur et al.'s 2014 IFTTT corpus (distributions of trigger sources and action targets) extends directly, since those distributions determine the structural possibility of conflict.
• User attribution experiments: show participants a "device toggling by itself" symptom and the underlying rule pair, and measure spontaneous conflict discovery rates and the level of prompting needed. This paradigm quantifies how invisible conflicts are — worth knowing before any repair.

One methodological caution: fix the operationalisation of "conflict" in advance — opposite commands (on/off), opposing parameters (22° vs 26°), and semantic conflict with identical commands have different consequences and remedies; pooling them yields a meaningless conflict rate.

Where it stops holding

• Not every conflict is a defect to eliminate. Some "conflicts" are deliberate redundancy: a safety rule's "keep lit even when unoccupied" overriding an energy rule's "lights off when empty" is exactly the right precedence — the problem is not that a conflict exists but whether its resolution matches intent.
• Covert is not the same as sporadic. Same-instant conflicts are rare, staggered tugs-of-war common; part of the latter's signature (repeated switching) belongs to trigger debouncing, whose remedies (time windows, hysteresis) address repeated firing, not opposing commands — the two often co-occur but can be treated separately.
• Few rules does not mean no conflicts. Two rules sharing a device with co-holdable conditions suffice; the most common household conflicts involve exactly two or three rules.

Applying it

• Run a conflict pre-check before saving a new rule: intersect its condition range with existing rules on the same device, and on non-empty overlap say "this rule may fire together with 'lights on at sunset' on winter evenings when everyone is out" — concrete scenario language, not "potential conflict detected".
• Conflict warnings should preview the verdict: state at creation time which rule wins a simultaneous trigger, rather than revealing it through behaviour at run time.
• Record suppressed and overridden commands at run time so every conflict leaves a trace.
• How to check: inject a "multiple rules co-hold" test at the target device and verify the outcome matches the declared precedence; then compare one week of real multi-rule triggers per device against the user's count of "it doesn't listen" episodes.

Related

• Same group: Z5.02.2 Priority and arbitration must be explicit · Z5.02.3 Conflict outcomes must be traceable to specific rules
• Nearby: Z5.01.2 Behaviour becomes unpredictable as rule count grows · Z5.06 Time windows and debouncing · Z6.01 Control conflicts between people
• Search terms: rule conflict · smart home automation · trigger-action programming · conflict detection