Condition-triggered actions are the basic model

What it is

The basic building block of smart-home and multi-device automation is trigger-action programming (TAP): when some condition holds, then perform some action. "At sunset, turn on the living-room lights"; "when everyone leaves, switch off the appliances"; "when humidity drops below 40%, start the humidifier" — every automation is one fill-in-the-blank instance of that sentence.

It is a form of programming: users are writing programs for their systems, with the syntax compressed into a couple of dropdown selections. That is why it is both the most accessible form of automation (no control flow, no loops, no variables) and an inheritor of every program's troubles — rules interact, conflict, and break, with the bill arriving only at run time.

Why it happens

TAP became the default model because it reduces programming to three components already in the user's vocabulary: events (from sensors or platform channels — sunset, arrival, motion), an optional condition qualifier, and actions (device commands). All three map onto existing world knowledge; no computational concept needs introducing.

One level deeper, the rule sentence reuses the causal format people already use to explain everyday behaviour. "If it rains, bring the laundry in" is a reasoning pattern people carry; TAP merely swaps the agent from person to system. Learning TAP is not learning a new grammar — it is learning which sensor signals can be cited, which is where the real learning burden and most cross-platform differences live.

The model's ceiling is embedded in the same sentence: one rule describes a mapping from one trigger scenario to one action sequence. How rules combine, whose instruction wins on conflict, what happens when an action changes a state another rule watches — none of this is within the expressive range of any single rule. The basic model structurally defers complexity to run time.

Studying it

TAP has an established in-the-wild research line:

• Ur et al.'s 2014 CHI study surveyed IFTTT users' actual rule sets: the overwhelming majority were single-trigger, single-action forms concentrated in syncing and notification routines; multi-trigger and multi-action combinations were rare. Ordinary users spontaneously operate at the bottom of the model's expressive range.
• Dey et al.'s 2014 CHI work (iCAP) explored a low-barrier TAP tool anchored to physical space, tying triggers and actions to the user's own devices and sensors — a test of how far "no abstract computational concepts" can go.
• Huang and Cakmak (2015) compared representations of TAP and found that semantic descriptions of triggers and actions (beyond device-event lists) significantly reduced rule-authoring errors.

The staple method is rule-corpus analysis: collect real rule sets from platforms or research deployments and analyse trigger-source distributions, action distributions, rule complexity, and device-sharing. Such data both characterises the model empirically and feeds predictions about conflicts and scale. One methodological caution: platform corpora are channel-supplied — a trigger source's popularity may reflect platform promotion rather than demand.

Where it stops holding

• TAP is an accessibility-expressiveness trade-off, not the end of automation design. Temporal ordering (A before B), cross-rule state references, and "otherwise" branches all exceed the basic sentence; platforms patch holes by piling on special-case syntax (delays, condition groups), and each patch raises the learning cost.
• The simplicity of real rule sets is avoidance, not sufficiency. Simple rules dominating says the model is friendly at entry — and that complex needs are silently abandoned. Users do want sequencing; they fail to express it and stop trying. Reading "most rules are simple" as "simple rules are enough" yields the wrong product conclusion.
• A rule's lifetime is bound to the platform channel. Trigger sources are services the platform supplies; when a service changes or shuts down, rules die silently — an ecosystem problem worth one structural note here.

Applying it

• Expose all automations as one kind of rule object: whatever the creation path — voice, wizard, template — everything lands in a single inspectable rule model. The user's mental inventory should hold one category, "automations".
• Prefer signals devices already produce for triggers (presence, door contact, illuminance) over platform-exclusive channels; on the action side, batch to device groups ("switch off all lights").
• Name rules in outcome language, not configuration language: "lights off when away" beats "motion sensor A triggers → light group X off".
• How to check: have long-term users restate the trigger and action of one of their own rules; rules with high restatement-failure rates are the ones heading for misattribution and misuse.

Related

• Same group: Z5.01.2 Behaviour becomes unpredictable as rule count grows · Z5.01.3 Rules must be viewable, pausable, and deletable
• Nearby: Z5.02 Rule conflicts · Z5.04 Ways of expressing orchestration · Z4.06 Building scenes and automations
• Search terms: trigger-action programming · end-user programming · IFTTT · smart home automation