Condiciones y choose: consigue que la automatización decida

Este artículo puede contener enlaces de afiliado. Si compras desde estos enlaces, el precio para ti es el mismo y la tienda me paga una pequeña comisión que ayuda a mantener Tecnoyfoto.

Albert BarnosellEditor y responsable de Tecnoyfoto

← Capítulo 4 · Índice del curso

La automatización del capítulo anterior enciende la luz cada vez que se abre la puerta. Cumple exactamente su requisito, pero en una casa real probablemente no querremos el mismo comportamiento al mediodía, por la noche o cuando no hay nadie.

Vamos a hacerla crecer por etapas. Primero añadiremos condiciones para que solo continúe cuando sea de noche y haya alguien en casa. Después veremos qué ocurre cuando una condición no se cumple. Finalmente utilizaremos choose para expresar varios resultados posibles sin introducir todavía plantillas Jinja.

La diferencia entre trigger y condición será el centro del capítulo. Ambos pueden observar estados, pero no hacen el mismo trabajo: el trigger responde a un cambio y abre una ejecución; la condición mira la situación actual cuando esa ejecución ya ha comenzado.

Del requisito simple al requisito condicionado

Nuestra automatización actual se puede resumir así:

Cuando se abra la puerta, enciende la luz.

El nuevo requisito es:

Cuando se abra la puerta, enciende la luz si es de noche y hay alguien en casa.

La puerta continúa siendo el acontecimiento que inicia la automatización. La noche y la presencia no tienen que ocurrir en ese instante exacto; son dos hechos que deben ser ciertos cuando se abre la puerta.

Por tanto, separamos:

• Trigger: la puerta cambia de cerrada a abierta.
• Primera condición: el modo nocturno está activo.
• Segunda condición: hay alguien en casa.
• Acción: encender la luz.

El laboratorio permite cambiar ambas condiciones manualmente mediante:

input_boolean.course_night_mode
input_boolean.course_someone_home

Sus entidades principales son:

binary_sensor.course_night
binary_sensor.course_someone_home

Utilizamos controles virtuales para poder probar todos los caminos a cualquier hora. En una instalación real podrías comprobar sun.sun, una medición de luminosidad, una franja horaria o una combinación adaptada a la vivienda.

Añadir dos condiciones de estado

La automatización queda así:

alias: "Curso YAML - Iluminar entrada de noche"
description: >-
  Enciende la luz al abrir la puerta cuando el modo nocturno está activo
  y hay alguien en casa.
triggers:
  - trigger: state
    entity_id: binary_sensor.course_front_door
    from: "off"
    to: "on"
conditions:
  - condition: state
    entity_id: binary_sensor.course_night
    state: "on"
  - condition: state
    entity_id: binary_sensor.course_someone_home
    state: "on"
actions:
  - action: light.turn_on
    target:
      entity_id: light.course_living_room
mode: single

conditions contiene una lista de dos mapas. Home Assistant los evalúa en orden cuando el trigger ya ha iniciado la automatización.

Varias condiciones significan AND de forma predeterminada

Las dos condiciones deben ser verdaderas:

course_night está on
Y
course_someone_home está on

Si cualquiera devuelve falso, Home Assistant detiene la ejecución antes de las acciones. No necesitamos escribir una clave and porque una lista normal de condiciones ya aplica este comportamiento.

La tabla completa de casos ayuda a verlo:

Solo la última combinación satisface las dos condiciones.

Una condición no espera a que algo suceda

Este es uno de los errores conceptuales más frecuentes. Imagina que se abre la puerta de día. El trigger inicia la automatización, pero binary_sensor.course_night está off. La condición falla y la ejecución termina.

Si cinco horas después llega la noche, aquella ejecución no se reanuda. La condición no estaba esperando. Solo tomó una fotografía de la situación en el momento en que fue evaluada.

Para que una automatización se inicie cuando llega la noche, la noche tendría que formar parte de sus triggers. Eso describiría otro acontecimiento:

Cuando empiece la noche, haz algo.

En nuestro requisito, el acontecimiento relevante continúa siendo abrir la puerta. La noche solo decide si la acción es apropiada en ese momento.

Esta diferencia puede resumirse así:

Trigger: observa un acontecimiento y abre una ejecución.
Condición: consulta la situación actual dentro de esa ejecución.

Una condición puede comprobar cuánto tiempo lleva cumpliéndose

Que una condición no espere no significa que solo pueda mirar el valor actual. Con for también puede comprobar cuánto tiempo lleva una entidad en ese estado:

conditions:
  - condition: state
    entity_id: binary_sensor.course_hallway_motion
    state: "off"
    for:
      seconds: 30

Cuando Home Assistant evalúa este bloque, comprueba dos cosas: que el sensor esté off y que lleve así al menos treinta segundos. Si solo lleva veinte, la condición falla inmediatamente. No espera los diez segundos restantes y tampoco reanuda esa ejecución cuando se cumplen.

Por tanto, for no transforma la condición en una espera. Solo añade una pregunta sobre la duración del estado en el instante de la evaluación. En el proyecto final utilizaremos este matiz para evitar que un apagado de seguridad actúe justo después de terminar el movimiento.

Probar las cuatro combinaciones

Antes de añadir más lógica, prueba sistemáticamente la tabla anterior.

Para cada caso:

1. Cierra la puerta virtual.
2. Apaga la luz.
3. Ajusta course_night_mode y course_someone_home.
4. Abre la puerta.
5. Comprueba la luz y abre la traza.

Cuando una condición falle, la traza debería mostrar dónde se detuvo el recorrido. Eso no es un error de ejecución. Es el comportamiento previsto.

Si pulsas Ejecutar acciones, Home Assistant omite triggers y condiciones y puede encender la luz incluso cuando es de día. Para probar condiciones debes provocar el trigger real o iniciar la automatización mediante una herramienta que permita respetarlas.

Utilizar la noche real: estado del sol, hora o luminosidad

El interruptor nocturno del laboratorio es reproducible, pero «es de noche» puede significar cosas distintas en una vivienda.

Estado del sol

Home Assistant mantiene la entidad sun.sun. Una condición habitual es:

- condition: state
  entity_id: sun.sun
  state: "below_horizon"

Será verdadera desde la puesta hasta la salida del sol. No requiere escribir una plantilla.

Franja horaria

Si la regla doméstica depende de una hora y no de la luz exterior:

- condition: time
  after: "22:00:00"
  before: "07:00:00"

La ventana cruza medianoche. after incluye la hora inicial y before excluye la hora final.

Sensor de iluminación

Un sensor de lux puede reflejar mejor la oscuridad real en una entrada concreta, pero requiere comprobar su valor y elegir un umbral adecuado para esa instalación.

Ninguna opción es universalmente superior. La pregunta correcta es qué significa «de noche» en el requisito real. Durante el curso mantendremos binary_sensor.course_night porque nos permite controlar las pruebas y concentrarnos en la estructura.

Cuándo necesitamos OR

Supongamos que queremos encender la luz cuando sea de noche o cuando un sensor de luminosidad indique oscuridad. Una lista normal exigiría ambas cosas. Para aceptar cualquiera de ellas necesitamos una condición OR explícita.

conditions:
  - condition: or
    conditions:
      - condition: state
        entity_id: binary_sensor.course_night
        state: "on"
      - condition: numeric_state
        entity_id: sensor.example_illuminance
        below: 20

La condición exterior es de tipo or. Dentro contiene otra lista bajo conditions. Basta con que una condición interior sea verdadera.

No utilizaremos este sensor ficticio en el ejercicio porque no forma parte del laboratorio. El fragmento muestra cómo leer la estructura cuando el lenguaje natural cambia de «y» a «o».

Conviene escribir primero la regla en una frase y marcar sus conectores:

Hay alguien en casa Y (es de noche O hay menos de 20 lux).

La jerarquía lógica debería aparecer también en YAML. Si agrupamos mal las condiciones, podemos crear una configuración válida que responda a otra regla.

Las condiciones generales solo permiten continuar o detenerse

Con las condiciones superiores, la automatización tiene dos resultados posibles:

Todas se cumplen → ejecuta actions.
Alguna falla → termina sin ejecutar actions.

Esto es suficiente cuando solo existe una respuesta útil. Pero imaginemos una necesidad más completa:

• Si se abre la puerta de noche y hay alguien en casa, encender la luz.
• Si se abre de noche y no hay nadie, crear una alerta persistente.
• Si se abre de día, no hacer nada.

Ya no queremos que una condición general descarte todos los casos excepto uno. Queremos entrar en las acciones y escoger una secuencia según la situación. Para eso utilizaremos choose.

choose: varias ramas, una sola elegida

La automatización puede escribirse así:

alias: "Curso YAML - Responder al abrir la puerta"
description: >-
  Decide qué hacer al abrir la puerta según la noche y la presencia.
triggers:
  - trigger: state
    entity_id: binary_sensor.course_front_door
    from: "off"
    to: "on"
conditions: []
actions:
  - choose:
      - alias: "De noche y con alguien en casa"
        conditions:
          - condition: state
            entity_id: binary_sensor.course_night
            state: "on"
          - condition: state
            entity_id: binary_sensor.course_someone_home
            state: "on"
        sequence:
          - action: light.turn_on
            target:
              entity_id: light.course_living_room

      - alias: "De noche y sin nadie en casa"
        conditions:
          - condition: state
            entity_id: binary_sensor.course_night
            state: "on"
          - condition: state
            entity_id: binary_sensor.course_someone_home
            state: "off"
        sequence:
          - action: persistent_notification.create
            data:
              title: "Curso YAML - Aviso de entrada"
              message: "Se ha abierto la puerta de noche y no hay nadie en casa."
    default: []
mode: single

La lista superior conditions está vacía porque no queremos detener la automatización antes de escoger una rama.

Dentro de actions hay un elemento de tipo choose. Este contiene una lista de opciones. Cada opción empareja:

• conditions: cuándo puede utilizarse esta rama.
• sequence: qué acciones ejecuta si es elegida.

Home Assistant recorre las opciones en orden y ejecuta la primera cuyas condiciones se cumplen. Después sale de ese choose; no continúa probando las ramas posteriores.

Los alias de las ramas explican la intención

alias: "De noche y con alguien en casa"

Este alias no cambia el resultado. Hace que la configuración y la traza sean más fáciles de interpretar. En una rama con varias condiciones, el alias debería resumir la situación completa, no repetir únicamente la primera condición.

default es el camino alternativo

default: []

default se ejecuta cuando ninguna opción coincide. Aquí contiene una lista vacía, por lo que abrir la puerta de día no produce ninguna acción.

Podríamos omitir default. Lo mostramos para que la decisión quede explícita. En otros casos contendrá una secuencia real equivalente a «si no se cumple nada de lo anterior».

choose selecciona la primera coincidencia

El orden importa cuando las condiciones de dos ramas pueden cumplirse simultáneamente. Una condición muy general colocada primero puede impedir que se alcance otra más específica.

En nuestro ejemplo las ramas se excluyen porque course_someone_home no puede estar a la vez on y off. Si diseñaras:

1. Una rama para «es de noche».
2. Otra para «es de noche y hay alguien».

La segunda nunca se alcanzaría cuando la primera estuviera antes, porque «es de noche» ya habría coincidido. La regla más específica debería ir primero o las condiciones deberían rediseñarse.

Trigger ID: distinguir qué acontecimiento inició la automatización

En el capítulo anterior creamos una automatización para abrir la puerta y otra para cerrarla. Podemos reunirlas cuando pertenecen a una misma responsabilidad y utilizar identificadores de trigger.

triggers:
  - trigger: state
    entity_id: binary_sensor.course_front_door
    from: "off"
    to: "on"
    id: "opened"

  - trigger: state
    entity_id: binary_sensor.course_front_door
    from: "on"
    to: "off"
    id: "closed"

Cualquiera de los dos triggers inicia la automatización. Los triggers de una automatización funcionan como OR: no deben ocurrir ambos.

Dentro de choose podemos comprobar cuál la inició:

actions:
  - choose:
      - conditions:
          - condition: trigger
            id: "opened"
        sequence:
          - action: light.turn_on
            target:
              entity_id: light.course_living_room

      - conditions:
          - condition: trigger
            id: "closed"
        sequence:
          - action: light.turn_off
            target:
              entity_id: light.course_living_room

La condición trigger no mira el estado actual de la puerta. Compara el identificador del trigger que inició esta ejecución.

Utilizar una sola automatización no siempre es mejor. Si dos comportamientos tienen propósitos, responsables o ritmos de cambio diferentes, separarlos puede hacerlos más claros. Los reunimos cuando la relación mejora la comprensión, no para reducir el número de automatizaciones a cualquier precio.

Ejercicio: unir apertura y cierre con condiciones nocturnas

Construye una automatización que cumpla estas reglas:

1. Cuando la puerta se abre, identifica el trigger como opened.
2. Cuando se cierra, identifica el trigger como closed.
3. Si se ha abierto, es de noche y hay alguien en casa, enciende la luz.
4. Si se ha cerrado, apaga la luz independientemente de la hora y la presencia.
5. En cualquier otro caso, no hagas nada.

Prueba al menos estos caminos:

• Abrir de noche con alguien.
• Abrir de día con alguien.
• Abrir de noche sin nadie.
• Cerrar la puerta con la luz encendida.

La traza debe mostrar qué trigger inició la ejecución y qué rama de choose fue seleccionada.

alias: "Curso YAML - Controlar luz con la puerta"
description: >-
  Enciende la luz al abrir de noche si hay alguien y la apaga al cerrar.
triggers:
  - trigger: state
    entity_id: binary_sensor.course_front_door
    from: "off"
    to: "on"
    id: "opened"
  - trigger: state
    entity_id: binary_sensor.course_front_door
    from: "on"
    to: "off"
    id: "closed"
conditions: []
actions:
  - choose:
      - alias: "Abrir de noche con alguien en casa"
        conditions:
          - condition: trigger
            id: "opened"
          - condition: state
            entity_id: binary_sensor.course_night
            state: "on"
          - condition: state
            entity_id: binary_sensor.course_someone_home
            state: "on"
        sequence:
          - action: light.turn_on
            target:
              entity_id: light.course_living_room

      - alias: "Cerrar la puerta"
        conditions:
          - condition: trigger
            id: "closed"
        sequence:
          - action: light.turn_off
            target:
              entity_id: light.course_living_room
    default: []
mode: single

Qué debes llevarte de este capítulo

El trigger responde al acontecimiento que inicia una ejecución. Una condición comprueba la situación actual cuando esa ejecución ya existe; no espera a que el estado llegue a cumplirse.

Varias condiciones forman un AND de manera predeterminada. Cuando necesitamos aceptar alternativas, utilizamos una estructura OR explícita. Cuando no queremos limitar toda la automatización a un único camino, choose permite emparejar condiciones y secuencias y ejecuta la primera rama coincidente.

Los identificadores de trigger ayudan a reunir acontecimientos relacionados sin utilizar plantillas. No convierten automáticamente una automatización grande en una automatización clara: la agrupación debe responder a una responsabilidad comprensible.

En el siguiente capítulo añadiremos tiempo a las secuencias. Compararemos un retraso fijo con una espera de acontecimiento y veremos qué ocurre si una automatización vuelve a iniciarse mientras la ejecución anterior todavía está esperando.

Continúa leyendo

Siguiente guía relacionada · 13 min de lectura

Tu primera automatización en YAML, línea por línea

← Capítulo 3 · Índice del curso Ya sabemos leer la estructura de un documento YAML y comprobar qué estados y acciones utiliza Home…

Continuar con este artículo↓