Automations in Home Assistant: How They Work

An automation is a rule that executes actions when an event occurs and certain conditions are met.

The ultimate goal of all the network infrastructure, servers, and protocols we have set up is precisely this: that the house makes decisions for us.

To achieve this level of autonomy, we need to program the logical engine of our server. In Home Assistant, autonomous behavior is governed by a system of strict rules called Automations.

At the software architecture level, the core of Home Assistant operates as an event-driven system. This means it is constantly listening to an internal event bus. To interact with this bus, automations are always divided into three fundamental blocks: Triggers, Conditions, and Actions.

If we master the boolean logic of these three blocks, we can program virtually any useful behavior for the home.

Triggers: The Start of Execution

The Trigger is the event that “wakes up” the automation. It is the spark that tells the system: “Hey, something just happened, go evaluate this rule.”

An automation can have multiple triggers, and they always work with OR logic. If trigger A or trigger B occurs, the automation starts.

There are dozens of trigger types, but the most important ones from a technical perspective are:

• State: The most commonly used. It fires when a specific Entity changes state. For example, when a door sensor (binary_sensor) changes from off (closed) to on (open). We can even specify how long that state must persist using the for attribute (e.g., “if the door has been open for more than 5 minutes”).
• Numeric State: Unlike the previous one, this evaluates a mathematical threshold. It fires when a sensor’s value crosses a boundary upwards or downwards. For example, “when the power consumed by the washing machine drops below 5W” (a signal that it has finished).
• Time / Time Pattern: Triggers based on the system clock. It can be an exact time (14:30:00) or a repetitive pattern (cron) like “every 5 minutes”.
• Sun: Based on the astronomical calculation of sunrise or sunset, even allowing an offset (e.g., “45 minutes before sunset”).
• Webhook / MQTT: Advanced triggers that react when Home Assistant receives an external HTTP request (a POST to a specific URL) or a message on a topic of our MQTT broker.

Conditions: The Logical Filters

Once the Trigger has launched the automation, the execution flow passes to the Conditions block.

Conditions act as a filter or logical gate. Their job is to evaluate the current state of the house and decide whether the automation should proceed to the actions or stop and abort immediately.

Unlike triggers, multiple conditions are evaluated by default with AND logic: all must be true to continue.

Common types of conditions:

• State: Checks if an entity is in a specific state at that precise moment. (E.g., Is the TV off?).
• Zone: Evaluates a user’s geolocation. (E.g., Is the user ‘Luis’ within the ‘Home’ zone?).
• Logical Blocks (and, or, not): Allow us to build complex boolean expressions. We can nest an OR block inside the general AND to say: “Proceed if it is night, AND (someone is in the living room OR the alarm is disarmed)”.

Actions: What Home Assistant Should Do

If the trigger starts the process and the conditions are true, the system executes the Actions block. This is where we physically alter the environment or send notifications.

An action usually consists of executing an operation provided by an integration. In older tutorials, you will see the term “call a service”; the current interface and documentation refer to actions.

• light.turn_on / light.turn_off: Turns lights on or off. Allows passing parameters (data) like brightness, color, or transition time.
• switch.turn_on: Activates a generic relay.
• notify.notify: Sends a push message to our mobile phone.
• delay: Pauses the code execution for the specified seconds before moving to the next action.

Anatomy of an Automation in YAML

The interface allows building automations visually and saves them in YAML format inside automations.yaml.

Knowing how to read this code gives us much more control over the logic. Let’s look at a classic and robust example: Turn on the hallway light if motion is detected, but only if it’s night, and turn it off after 2 minutes.

alias: "Lighting: Hallway Auto Night"
mode: restart # Execution mode (explained below)

# 1. TRIGGERS
triggers:
  - trigger: state
    entity_id: binary_sensor.hallway_motion
    to: "on"

# 2. CONDITIONS
conditions:
  - condition: state
    entity_id: sun.sun
    state: "below_horizon" # Only if it's night

# 3. ACTIONS
actions:
  - action: light.turn_on
    target:
      entity_id: light.hallway_light
    data:
      brightness_pct: 30 # Turn on at 30% to not blind
  
  - delay:
      minutes: 2 # Wait 2 minutes
      
  - action: light.turn_off
    target:
      entity_id: light.hallway_light

Execution Modes

In the code above, we included a fundamental parameter that is often overlooked: mode: restart.

What happens if the sensor detects motion, turns on the light, starts counting the 2-minute delay, and at minute 1, someone walks through the hallway again (triggering the automation again)?

Home Assistant defines several concurrency modes:

• single (Default): If the automation is already running (counting the delay), it ignores the new trigger. The light will inexorably turn off after 2 minutes from the first event.
• restart: If a new trigger occurs, it cancels the current execution and starts over from the beginning. This is the correct mode for motion lights, as it resets the 2-minute timer to zero.
• queued / parallel: Queues the executions or runs them in parallel threads (useful for mass notification systems).

Traces: See What Actually Happened

When an automation doesn’t do what we expected, we shouldn’t start changing things randomly. Home Assistant saves execution traces that allow you to see step-by-step which trigger activated, which conditions were evaluated, and at which action the flow stopped.

This is especially useful when we have multiple conditions. Often we think “the automation didn’t trigger”, but actually it did trigger and stopped because a condition returned false. And of course, without looking at the trace, we start changing YAML like moving furniture in the dark.

It also helps enormously to give them very descriptive names. An alias like Hallway night with motion is understandable at a glance. One like Light 3 forces you to open the automation every time you want to tweak something.