Home Assistant 2026.10 ya permite crear termostatos por plantilla

Cuando un dispositivo llega a medias

En un homelab es bastante habitual integrar un equipo que expone datos y controles, pero no una entidad útil de alto nivel. Puede darte un sensor de temperatura, un switch para activar la refrigeración y un número para cambiar la consigna, pero no un termostato que reúna todo eso. El resultado es una colección de entidades dispersas, difícil de mostrar en un dashboard y todavía más incómoda de usar desde automatizaciones. Home Assistant 2026.10 incorpora entidades climate basadas en plantillas para resolver precisamente ese hueco.

La novedad no sustituye una integración bien mantenida ni inventa capacidades que el dispositivo no tenga. Lo que hace es construir una interfaz coherente encima de entidades existentes, declarando de dónde sale cada estado y qué acciones se ejecutan al cambiarlo. Para una bomba de calor, un aire acondicionado expuesto de forma incompleta o unos ventiladores de rack, eso puede ser suficiente para recuperar una experiencia normal de termostato. También permite que las automatizaciones trabajen contra una sola entidad climate en lugar de conocer los detalles de cada switch, sensor o número.

Una capa de control para el rack

La idea es sencilla: el sensor aporta la temperatura actual, un number guarda o controla la consigna y uno o varios switches representan el estado del sistema. La entidad de plantilla enlaza esas piezas y expone modos HVAC válidos, por ejemplo off y cool. Al modificar la temperatura desde el dashboard, Home Assistant ejecuta la acción configurada en set_temperature; al cambiar el modo, ejecuta set_hvac_mode.

El siguiente ejemplo asume que existe un sensor de temperatura, un número que controla la consigna real del equipo, un switch que habilita la refrigeración y otro que refleja si los ventiladores están funcionando. No crea entidades físicas nuevas: hay que sustituir los identificadores por los de cada instalación. La disponibilidad evita presentar como operativo un termostato cuando faltan sus datos esenciales.

template:
  - climate:
      - name: Refrigeración del rack
        availability: >
          {{ has_value('sensor.rack_temperature')
             and has_value('number.rack_target_temperature') }}
        current_temperature: >
          {{ states('sensor.rack_temperature') | float }}
        target_temperature: >
          {{ states('number.rack_target_temperature') | float }}
        temperature_unit: "°C"
        min_temperature: 20
        max_temperature: 35
        target_temperature_step: 0.5
 
        hvac_modes: "{{ ['off', 'cool'] }}"
        hvac_mode: >
          {{ 'cool'
             if is_state('switch.rack_cooling_enabled', 'on')
             else 'off' }}
        hvac_action: >
          {{ 'cooling'
             if is_state('switch.rack_fans', 'on')
             else 'off' }}
 
        set_hvac_mode:
          - action: >
              switch.turn_{{ 'on' if hvac_mode == 'cool' else 'off' }}
            target:
              entity_id: switch.rack_cooling_enabled
 
        set_temperature:
          - action: number.set_value
            target:
              entity_id: number.rack_target_temperature
            data:
              value: "{{ temperature }}"

Con esa definición, el dashboard puede tratar la refrigeración como una entidad climate normal: muestra la temperatura actual, la consigna y el modo disponible. La consigna no queda duplicada en un helper: se lee desde el number ya ofrecido por la integración y se actualiza con la acción number.set_value. Eso es importante porque mantiene una única fuente de verdad y evita sincronizaciones innecesarias entre entidades.

También se puede configurar desde la interfaz

No hace falta escribir YAML para el caso básico. La documentación de Template permite crear la entidad desde Helpers, definiendo nombre, temperatura actual, acción HVAC, modo HVAC, modos disponibles, temperatura objetivo y las acciones que deben ejecutarse al cambiar el modo o la consigna. Para una primera prueba, la UI es una forma razonable de comprobar qué datos expone realmente el dispositivo.

YAML sigue teniendo sentido cuando la entidad necesita más detalle o debe vivir junto a la configuración del homelab. La plataforma admite, además de temperatura y modos HVAC, modos de ventilador, presets, oscilación y humedad, siempre que se definan las plantillas y acciones correspondientes. No conviene declarar opciones por decorar la interfaz: cada modo publicado debe representar una capacidad que el hardware pueda ejecutar y cuyo estado se pueda conocer de forma fiable.

La letra pequeña importa

Esto no es un controlador PID ni un sistema de regulación automática por sí mismo. Una entidad climate de plantilla traduce estados y peticiones de cambio hacia otras entidades; si el dispositivo no regula la temperatura internamente, la lógica de encender y apagar ventiladores tendrá que existir en una automatización aparte. Conviene añadir histéresis, tiempos mínimos de marcha y parada, y condiciones de seguridad antes de controlar carga eléctrica real con un simple umbral.

También hay que distinguir entre el modo solicitado y la acción actual. En el ejemplo, hvac_mode dice que la refrigeración está habilitada, mientras que hvac_action informa de si los ventiladores están funcionando en ese momento. Mezclar ambas cosas produce dashboards engañosos: un equipo puede estar en modo cool y permanecer en idle mientras la temperatura esté por debajo de la consigna.

Otro punto delicado es la calidad de los datos de origen. Si un sensor devuelve unknown, unavailable o una lectura errónea, no debería terminar activando un relé sin límites. La plantilla de disponibilidad reduce parte del problema visual, pero no sustituye protecciones del propio equipo, alertas de temperatura alta ni mecanismos de apagado seguro.

Una mejora pequeña con impacto práctico

Esta función me parece especialmente útil cuando una integración local está casi completa, pero se queda en telemetría y controles sueltos. En vez de esperar a que alguien implemente una entidad climate específica, puedo crear una capa local, revisable y versionada con el resto de mi configuración. Para el homelab, eso encaja mejor que montar un conjunto de tarjetas, helpers y automatizaciones que esconden la intención real del sistema.

La clave está en mantener el modelo honesto: una plantilla debe describir el comportamiento que ya existe debajo, no simular un termostato donde no hay control ni confirmación de estado. Si las entidades base son fiables y el dispositivo ya acepta una consigna, esta nueva pieza convierte una integración incompleta en algo bastante más manejable. Si no lo son, primero arreglaría la telemetría y las protecciones, y después pensaría en una interfaz bonita.

Fuente: Home Assistant 2026.10 Documentación oficial de Template Climate