Variables en plantillas de YAML

Revisión técnica: 27 de octubre de 2026. Esta es una guía complementaria procedente del curso anterior, no un capítulo numerado del nuevo. Para seguir el itinerario, consulta el curso actual de YAML en Home Assistant.

Las variables permiten reutilizar datos y construir mensajes, pero hay que identificar qué programa las interpreta. YAML almacena la estructura; no evalúa por sí mismo expresiones. En esta revisión se han retirado los ejemplos que presentaban $(var1) o un ternario con ? como capacidades nativas de YAML o de Home Assistant.

YAML, variables y motor de plantillas

En un documento YAML genérico, una cadena como "$(url_base)/endpoint1" es simplemente texto salvo que la aplicación tenga una función documentada que la procese. No basta con crear una clave llamada variables:. Home Assistant, Ansible, Docker Compose y otras herramientas tienen reglas diferentes: no mezcles sus sintaxis.

Ejemplo 1: una variable en un script de Home Assistant

Este ejemplo corresponde al YAML de un script individual en su editor, no a un archivo completo de configuración:

alias: "Aviso con variables"
sequence:
  - variables:
      habitacion: "salón"
      objetivo: 21
  - action: persistent_notification.create
    data:
      title: "Objetivo de confort"
      message: "Temperatura objetivo del {{ habitacion }}: {{ objetivo }} °C"

La acción variables pone valores a disposición de los pasos posteriores en ese contexto. La plantilla del mensaje lee esos valores con Jinja. No crea variables globales compartidas con cualquier automatización. Para valores persistentes que puedas cambiar desde la interfaz, estudia los ayudantes adecuados en lugar de esperar persistencia de una variable del script.

Ejemplo 2: construir una URL

alias: "Construir una URL de ejemplo"
sequence:
  - variables:
      url_base: "https://example.com/api"
  - action: persistent_notification.create
    data:
      title: "URL de ejemplo"
      message: "{{ url_base }}/endpoint1"

Esto muestra la cadena calculada; no realiza una petición HTTP ni configura una integración. Se utiliza un dominio de ejemplo. Un campo de una integración que no admita plantillas no empezará a admitirlas por escribir llaves en él.

Ejemplo 3: elegir un valor según el entorno

alias: "Elegir un nombre de ejemplo"
sequence:
  - variables:
      entorno: "desarrollo"
  - action: persistent_notification.create
    data:
      message: >-
        {{ "prod_db" if entorno == "produccion" else "test_db" }}

El condicional pertenece a Jinja. No es el operador ternario de otros lenguajes ni una declaración real de base de datos de Home Assistant. Mantener claros el alcance y la finalidad evita copiar un ejemplo didáctico como configuración operativa.

Tipos de datos, secretos y límites

Las variables pueden contener números, textos, booleanos, listas y mapas según el contexto. Los datos de entidades pueden llegar como texto o con estados unknown y unavailable; comprueba y convierte los valores antes de compararlos. No utilices un cero por defecto si podría desencadenar una acción peligrosa.

Para credenciales en configuraciones YAML compatibles de Home Assistant existe !secret; no conviertas contraseñas en cadenas públicas dentro de scripts de ejemplo. secrets.yaml organiza los secretos, pero no los cifra y debe protegerse junto con sus copias de seguridad.

Cómo probar los ejemplos

Comprueba primero la expresión en el editor de plantillas y después el script en un entorno controlado. Revisa su traza y las acciones que realmente ejecutaría. Un validador YAML solo comprueba una capa: no demuestra que existan las entidades, que un campo acepte Jinja o que la lógica sea correcta. No pegues secretos en validadores online.

Continúa con la distinción entre YAML y Jinja del curso actual. Esta URL queda conservada hasta revisar la publicación del nuevo capítulo de variables.