How to Automate Your Thermostat With the Weather Forecast

Surely there is already a blueprint for this: use tomorrow's weather forecast to choose heat, cool, or eco mode on a Home Assistant thermostat. There is no maintained, provider-neutral blueprint that makes that promise safely. The dependable shape is smaller: retrieve the forecast, store the value in a trigger-based template sensor, and let a choose automation call climate.set_hvac_mode.

There is also a boundary between thermostat-native behavior and this hub-side recipe. A thermostat may anticipate a schedule or compensate for solar gain using its own sensors. Forecast-driven HVAC mode switching belongs in Home Assistant here, where a weather entity can be read and a climate service can be called. Keep vendor scheduling and pre-conditioning rules separate from the forecast automation while you test them.

Start With the Forecast Sensor

The useful part of the official pattern is that weather.get_forecasts returns structured forecast data through a response variable. A trigger-based template sensor can periodically request that data and expose only the value the automation needs. The first forecast item is then available as hourly['weather.home'].forecast[0].temperature in the documented example.[1]

template:
  - triggers:
      - trigger: time_pattern
        hours: "/1"
      - trigger: homeassistant
        event: start
    actions:
      - action: weather.get_forecasts
        target:
          entity_id: weather.home
        data:
          type: hourly
        response_variable: hourly
    sensor:
      - name: Forecast Temperature Next Hour
        unique_id: forecast_temperature_next_hour
        state: >-
          {% set forecast = hourly['weather.home'].forecast | default([]) %}
          {% if forecast | count > 0 %}
            {{ forecast[0].temperature }}
          {% else %}
            unavailable
          {% endif %}
        unit_of_measurement: "°C"
        device_class: temperature

Replace weather.home with your weather entity and confirm the provider's temperature unit before using the result in a condition. The response_variable name, the entity key inside the template, and the requested forecast type must agree. A typo in hourly or weather.home can leave the sensor empty even though the action itself appears in the trace.

This sensor is intentionally coarse. It does not attempt to continuously regulate the room or calculate a perfect setpoint. It creates a stable handoff between forecast retrieval and the climate automation, which makes each side easier to inspect in Developer Tools and in an automation trace.

Recipe 1: Switch HVAC Mode From a Forecast Value

Status: Investigating. The structure below follows the official forecast-response pattern and the community max-temperature approach, but the cited sources do not identify a tested Home Assistant Core version, verification date, or weather provider.[1][2]

alias: Forecast HVAC mode switch
mode: single
triggers:
  - trigger: state
    entity_id: sensor.forecast_temperature_next_hour
  - trigger: time
    at: "06:00:00"
conditions:
  - condition: template
    value_template: >-
      {{ states('sensor.forecast_temperature_next_hour') not in
         ['unknown', 'unavailable', 'none', ''] }}
actions:
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: sensor.forecast_temperature_next_hour
            above: 24
        sequence:
          - action: climate.set_hvac_mode
            target:
              entity_id: climate.downstairs
            data:
              hvac_mode: cool
      - conditions:
          - condition: numeric_state
            entity_id: sensor.forecast_temperature_next_hour
            below: 18
        sequence:
          - action: climate.set_hvac_mode
            target:
              entity_id: climate.downstairs
            data:
              hvac_mode: heat
    default:
      - action: climate.set_hvac_mode
        target:
          entity_id: climate.downstairs
        data:
          hvac_mode: auto

The entity must support the mode you call. Some climate devices expose heat and cool but not auto; others use a different set of supported modes. Check climate.downstairs in Developer Tools before enabling the automation. The thresholds are operating choices, not documented comfort or savings settings, and should be adjusted to the home, season, and equipment.

If the middle range should reduce intervention rather than select auto, replace the default action with the mode your device actually supports, such as eco or heat_cool. Do not assume that a mode name accepted by one thermostat integration exists on another.

Recipe 2: Put the Threshold in a Helper

Status: Investigating. This threshold-helper version follows a community example that uses an input_number and multiple conditions; compatibility still depends on the climate entity and forecast provider.[3]

input_number:
  forecast_cooling_threshold:
    name: Forecast cooling threshold
    min: 15
    max: 35
    step: 0.5
    unit_of_measurement: "°C"
    mode: slider

alias: Forecast threshold HVAC mode
mode: single
triggers:
  - trigger: state
    entity_id:
      - sensor.forecast_temperature_next_hour
      - input_number.forecast_cooling_threshold
  - trigger: time
    at: "06:00:00"
conditions:
  - condition: template
    value_template: >-
      {{ states('sensor.forecast_temperature_next_hour') not in
         ['unknown', 'unavailable', 'none', ''] }}
actions:
  - choose:
      - conditions:
          - condition: template
            value_template: >-
              {{ states('sensor.forecast_temperature_next_hour') | float(0)
                 >= states('input_number.forecast_cooling_threshold') | float(99) }}
        sequence:
          - action: climate.set_hvac_mode
            target:
              entity_id: climate.downstairs
            data:
              hvac_mode: cool
      - conditions:
          - condition: numeric_state
            entity_id: sensor.forecast_temperature_next_hour
            below: 18
        sequence:
          - action: climate.set_hvac_mode
            target:
              entity_id: climate.downstairs
            data:
              hvac_mode: heat
    default:
      - action: climate.set_hvac_mode
        target:
          entity_id: climate.downstairs
        data:
          hvac_mode: eco

A helper makes the important decision visible and adjustable without editing YAML. It also creates a new failure mode: a value entered in Fahrenheit will be compared against a Celsius sensor, or vice versa. Normalize both the weather entity and the helper to the same unit before changing the threshold.

Recipe 3: Add Provider Resilience

Status: Workaround, investigating. A community example combines or weights more than one weather source so that one provider outage does not leave the automation without a forecast.[4] The source available for this recipe does not include enough configuration to reproduce its combined entity safely, so the fallback below only prevents an unavailable value from changing HVAC mode.

alias: Forecast HVAC mode with unavailable guard
mode: single
triggers:
  - trigger: state
    entity_id: sensor.forecast_temperature_next_hour
conditions:
  - condition: template
    value_template: >-
      {{ is_number(states('sensor.forecast_temperature_next_hour')) }}
actions:
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: sensor.forecast_temperature_next_hour
            above: 24
        sequence:
          - action: climate.set_hvac_mode
            target:
              entity_id: climate.downstairs
            data:
              hvac_mode: cool
      - conditions:
          - condition: numeric_state
            entity_id: sensor.forecast_temperature_next_hour
            below: 18
        sequence:
          - action: climate.set_hvac_mode
            target:
              entity_id: climate.downstairs
            data:
              hvac_mode: heat
    default: []

For a true multi-provider fallback, first create a separate combined weather entity using the method supported by the relevant integration, then point weather.get_forecasts and the template at that entity. Do not paste NWS-specific fields into a Met.no recipe. Fields such as templow, is_daytime, and a twice-daily forecast structure are provider-dependent; they are not safe generic attributes.

Failure Modes to Check Before Trusting It

The most important diagnostic distinction is whether the forecast retrieval failed or the climate action failed. Check the template sensor state first. If it contains a valid number, inspect the choose conditions and the climate entity's supported modes. If the sensor is empty, changing the thermostat YAML will not solve the problem.

Forecasts also have limited precision. A community report describes divergence of roughly 10°C between forecast and actual conditions in some situations, including the effects of sun and cloud cover.[2] Thermal lag adds another source of error. That makes a forecast useful for choosing a broad mode or frost-protection behavior, but current indoor temperature sensors remain the better input for fine setpoint control. For related entity and free-cooling guards, see the smart thermostat air purifier heatwave setup recipe.

This gives the missing-blueprint request a maintainable answer, but not a universal one. Use weather.get_forecasts to create an inspectable forecast sensor, let choose select heat, cool, eco, or frost protection, and keep indoor sensing responsible for precision. Before enabling it overnight, verify the Core version, provider, units, forecast fields, and climate modes on the actual installation.

References

1. Weather integration — Home Assistant
2. Automation that sets heating and cooling depending on forecast — Home Assistant Community
3. Weather Forecast template — Home Assistant Community
4. One weather entity to rule them all — Home Assistant Community