Apple Home Automations: How Triggers and Conditions Work

By Matthew Easterday · Published Aug 6, 2026

An Apple Home automation has three parts: a trigger, an optional condition, and an action. When an automation seems broken, a condition that didn’t hold is the usual reason.

The building blocks: trigger, condition, action

The trigger is whatever starts an automation being evaluated: an accessory being controlled, a sensor detecting something, a time of day arriving, or someone crossing the boundary of arriving home or leaving. On its own, a trigger is enough to build a working automation. Pick one, skip straight to an action, and it fires every time the trigger happens.

Conditions sit between the trigger and the action. A condition is a check the Home app runs at the moment the trigger fires: is it currently between 9pm and 6am, is anyone home, is another accessory reading a particular value. If a condition is attached and it isn’t true, the trigger still fires but the action never runs, and the two events look identical from outside the house.

The action is whatever the automation is for: turning on a light, sending a notification, running a scene that sets several accessories at once.

Trigger types: accessory controlled, sensor detects something, time of day, people arriving or leaving

The Home app groups triggers into four categories. Every automation here uses one of them.

An accessory being controlled covers a switch or button changing commanded state, like a BILRESA press. The largest share of what’s running here is a sensor detecting something: a motion or occupancy sensor clearing, a door opening or closing. Time of day handles anything scheduled, whether a fixed clock time or something relative to sunrise and sunset. Arrivals and departures key off the location of the household’s iPhones, firing when the last person leaves or the first one gets home.

Each category has its own quirks in the builder, but the underlying model is the same: something happens, and the Home app checks whether that something matches what this automation is listening for.

Conditions: time range, occupancy/people, another accessory’s current state

Conditions narrow a trigger without changing it. The Home app offers three broad kinds: a time range, whether people are home or away, and the current state of another accessory (including, in some cases, the same accessory that fired the trigger).

Keeping a motion-triggered light from switching on at noon is what a time-range condition is for. An away-only alert needs a people condition, since it can require nobody’s phone to be on the home network before the action runs. The most flexible of the three is an accessory-state condition, because it can point at a different device’s reading entirely (a light sensor, a thermostat mode, another sensor’s occupancy state) and gate the action on that.

The condition is evaluated once, at the instant the trigger fires. It isn’t checked continuously. An automation with a “people are home” condition doesn’t turn itself off when everyone leaves; it just won’t fire the next time its trigger happens while the condition is false.

The hub requirement behind every automation that runs without a phone present

Time-based automations, arrival and departure automations, and any automation gated on an away condition all have one thing in common: they have to run when nobody’s phone is on the network to do the work. That requires a home hub: a device that stays in the house, stays connected, and evaluates automations on its own.

An iPad can no longer fill that role; Apple retired it as a hub option in February 2026 (see what counts as a hub now). If one used to be doing the job here, moving hub duty to an Apple TV or HomePod is what brings automations back. This house runs an Apple TV 4K wired to Ethernet in the living room, plus two HomePod minis elsewhere in the house, any of which can carry hub duty if the others go offline. Losing all of them doesn’t delete an automation, but nothing evaluates it until one comes back online.

Motion-triggered, button-triggered, and other accessory-state automations are less dependent on the hub in one narrow sense: the accessory itself can sometimes wake the automation directly over the local network. In practice, relying on that distinction is a mistake. When the hub is offline, no automation should be trusted to fire, regardless of its trigger type.

Real example: MYGGSPRAY’s occupancy trigger gated by its own light-sensor condition

MYGGSPRAY shows up in Apple Home as two accessories: a Living Room Occupancy Sensor and a Living Room Light Sensor. The automation triggers on Detects Occupancy, gated by a condition on the light sensor’s own reading, set to Drops Below 10 lux. In this room, that threshold corresponds to dusk or curtains drawn.

The action is a Desk Lights automation, a Meross outlet in the living room. In daylight the trigger fires but the light-condition check fails, so nothing happens; after dark both pass and the lights come on.

Real example: MYGGBETT’s away-only door alert

MYGGBETT on the garage’s Hall Door runs a notification rather than a light. The door opening is what starts the automation, but a condition tied to who’s home means the notification only fires while the house is empty.

The alert exists for the second case, the door opening while nobody’s supposed to be home, not for routine use.

Real example: BILRESA buttons mapped to scenes by press type

Two BILRESA dual buttons are in service in this house: one in the bedroom on firmware 1.9.15, one in the living room on firmware 1.8.5. Apple Home lists each as a Switch accessory, and a Matter switch like this exposes single press, double press, and long press as separate events. That means one physical button can drive several different automations depending on how it’s pressed, not just one.

A press is the trigger, a scene activating is the action, and a condition can still gate it.

Troubleshooting an automation that isn’t firing

1. Open Home Settings, then Home Hubs & Bridges, and confirm at least one Apple TV or HomePod reads Connected. Nothing runs without one.
2. Check whether every condition attached to the automation was true at the moment the trigger fired: a time range that doesn’t cover when the accessory changes state, an away condition tested while still standing in the house, a light-sensor threshold set tighter than the room ever gets.
3. Check the accessory itself. A Thread sensor with a weak connection to its border router can report state changes late enough that a tightly scoped condition, like a short time window, has already closed by the time the update arrives.

Matthew Easterday

Runs the homekit.reviews test home, a real mixed Matter/Thread/HomeKit house. Everything reviewed here was set up, paired, and lived with. See how I test →