Home Assistant 2026.10 can now build thermostats from templates

When a device integration only gives you the pieces

In a homelab, it is common to integrate hardware that exposes data and controls without offering a useful high-level entity. You may get a temperature sensor, a switch for cooling, and a number entity for the target value, but no thermostat that brings those pieces together. That leaves a scattered set of entities that is awkward to put on a dashboard and even harder to use cleanly in automations. Home Assistant 2026.10 adds template-based climate entities to fill that gap.

This does not replace a properly maintained integration, and it does not create capabilities the hardware does not have. It gives us a coherent interface on top of existing entities by declaring where each state comes from and which actions run when it changes. For a heat pump, a partially exposed AC unit, or rack fans, that can be enough to restore a normal thermostat-like workflow. Automations can also target one climate entity instead of knowing every underlying sensor, switch, and number entity.

A control layer for rack cooling

The pattern is straightforward: a sensor provides the current temperature, a number stores or controls the actual setpoint, and one or more switches represent the system state. The template entity connects those parts and exposes valid HVAC modes such as off and cool. When the temperature is changed from the dashboard, Home Assistant runs the action defined in set_temperature; when the mode changes, it runs set_hvac_mode.

The example below assumes a temperature sensor, a number entity that controls the device target, a switch that enables cooling, and another switch that reports whether the fans are currently running. It does not create physical entities, so the entity IDs need to be replaced with the ones from the actual installation. The availability template prevents the thermostat from appearing operational when its essential data is missing.

template:
  - climate:
      - name: Rack cooling
        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 }}"

With that in place, the dashboard can handle rack cooling as a regular climate entity: current temperature, target value, and available mode are all in one place. The setpoint is not duplicated in a helper; it is read from the number entity already provided by the integration and updated through number.set_value. Keeping one source of truth matters because it avoids a second layer of state synchronization.

The basic setup is available from the UI

YAML is not mandatory for the basic case. Template lets you create the entity from Helpers in the interface, where you can define its name, current temperature, HVAC action, current mode, supported modes, target temperature, and the actions used when mode or target values change. For an initial test, the UI is a practical way to validate the data actually exposed by the device.

YAML remains useful when the entity needs to live alongside the rest of the homelab configuration or needs more detail. The platform can also model fan modes, presets, swing modes, and humidity, provided that the matching templates and actions are defined. I would not add those controls just to make the card look more complete: every exposed mode should map to something the hardware can actually do and report reliably.

The important limitations

This is not a PID controller or an automatic temperature-control system on its own. A template climate entity translates states and requested changes into other entities; if the device does not regulate temperature internally, the fan control logic still needs to exist in a separate automation. Before using simple thresholds to switch real loads, I would add hysteresis, minimum on and off times, and safety conditions.

It is also important to separate the requested mode from the current action. In the example, hvac_mode means cooling is enabled, while hvac_action reports whether the fans are actually running at that moment. Treating both as the same thing makes dashboards misleading: a device can be in cool mode while remaining idle because the temperature is already below the target.

Source data quality is another concern. If a sensor becomes unknown, unavailable, or simply reports a bad reading, it should not end up turning on a relay without limits. The availability template helps with the visible state, but it is not a replacement for device-level protections, high-temperature alerts, or a safe shutdown plan.

A small feature with a practical payoff

I find this most useful when a local integration is nearly there but stops at telemetry and disconnected controls. Rather than waiting for somebody to implement a dedicated climate entity, I can create a local layer that is reviewable and versioned with the rest of my configuration. For a homelab, that is cleaner than building an opaque combination of cards, helpers, and automations that hides the actual intent of the system.

The key is to keep the model honest: a template should describe behavior that already exists underneath it, not pretend there is a thermostat where there is no control loop or state confirmation. When the base entities are reliable and the device already accepts a target value, this feature turns an incomplete integration into something much easier to operate. When they are not reliable, I would fix telemetry and safety first, then worry about a nicer interface.

Source: Home Assistant 2026.10 Official Template Climate documentation