Researched from current Home Assistant documentation on October 18, 2026. This is a configuration walkthrough with illustrative forecast examples, not a tested Tara installation or a weather-provider accuracy comparison. The cover is an illustrative generated scene.

Get the forecast first, then make the decision

A Home Assistant weather forecast automation needs three steps: run at a chosen time, request the forecast, and use the returned information in the following action. Start with a message you can inspect. Add device control only after designing a separate routine for that device.

An entity is one item Home Assistant tracks, such as weather.forecast_home. Seeing “Sunny” on that item tells you its current condition. Seeing tomorrow’s icons in its weather card does not mean tomorrow’s forecast is stored in the same state. The Weather documentation distinguishes these values.

The example below uses an existing hourly weather forecast. At 7 a.m., it checks forecast periods beginning between 7 a.m. and 7 p.m. and leaves one readable result in Home Assistant. It also reports absent or incomplete information. There is no sensor purchase, custom integration, AI service, or paid notification service in this walkthrough.

A response variable is simply a named result that later steps in the same run can read. Here, that result is called forecast_reply. You do not need to create a template sensor just to use it once each morning. Put any check of this result after the forecast action; the automation’s top-level Conditions section runs before the result exists.

1. Check the provider and the exact weather entity

  1. Open Settings → Devices & services → Entities and find your weather entity. Copy its full ID, including weather..
  2. If you need a provider, add Meteorologisk institutt (Met.no) from Add integration. It offers hourly and daily forecasts without an API key. Confirm the location and elevation instead of accepting an incorrect home location.
  3. Use that entity’s documentation to confirm hourly support. Some providers offer different forecast types or omit fields.

Met.no’s integration documentation describes the setup and its cloud-polling connection: Home Assistant periodically retrieves data from an internet service. The decision runs on your Home Assistant server, but fresh forecasts still require the provider and internet access. Free access does not make the forecast local.

2. Request a forecast without changing a device

Open Home Assistant’s Actions tool. Depending on your installed release, it may appear under Developer tools or Settings → Tools. Choose Weather: Get forecasts, your exact weather entity, and Hourly. Perform the action.

You can use this in the Actions tool’s YAML editor after replacing the example entity ID:

action: weather.get_forecasts
target:
  entity_id: weather.forecast_home
data:
  type: hourly

Expected result: a response grouped under that same entity ID, containing a forecast list. Inspect several entries for datetime and condition. This reads forecast data; it does not operate your lights, heating, windows or irrigation. See the forecast action reference.

If the request fails, fix the provider, entity ID or forecast type before continuing. If a response lacks condition values, the rain-condition example cannot interpret those periods. Do not substitute a daily forecast into the hourly example and expect the same time window.

3. Add the morning rain-check automation

In Settings → Automations & scenes, create a new empty automation. Open its menu and choose Edit in YAML. Paste the complete example below, replacing weather.forecast_home on the weather_entity line. This belongs in one automation’s editor, not at the top of configuration.yaml.

The rule looks for the rain-related condition names rainy, pouring, lightning-rainy and snowy-rainy. It does not use a rain-probability threshold. A “no rain condition” result can still include snow, hail, wind or other hazards.

Swipe sideways to read the full code.

alias: Morning forecast rain check
description: A forecast reminder inside Home Assistant; no device control.
triggers:
  - trigger: time
    at: "07:00:00"
conditions: []
actions:
  - variables:
      weather_entity: weather.forecast_home
      forecast_reply: {}
      window_start: >-
        {{ as_timestamp(now().replace(minute=0, second=0, microsecond=0)) }}
  - action: weather.get_forecasts
    target:
      entity_id: "{{ weather_entity }}"
    data:
      type: hourly
    response_variable: forecast_reply
    continue_on_error: true
  - variables:
      forecast_rows: >-
        {{ forecast_reply.get(weather_entity, {}).get('forecast', []) or [] }}
  - variables:
      rain_report: >-
        {% set start = window_start | float %}
        {% set ns = namespace(periods=0, rain=0, missing=0, bad_time=0) %}
        {% set rain_codes = ['rainy', 'pouring', 'lightning-rainy', 'snowy-rainy'] %}
        {% set other_codes = ['clear-night', 'cloudy', 'fog', 'hail',
          'lightning', 'partlycloudy', 'snowy', 'sunny', 'windy',
          'windy-variant', 'exceptional'] %}
        {% for row in forecast_rows %}
          {% set stamp = as_timestamp(row.get('datetime'), none) %}
          {% if stamp is none %}
            {% set ns.bad_time = ns.bad_time + 1 %}
          {% elif start <= stamp < start + 12 * 3600 %}
            {% set ns.periods = ns.periods + 1 %}
            {% set condition = row.get('condition') %}
            {% if condition in rain_codes %}
              {% set ns.rain = ns.rain + 1 %}
            {% elif condition not in other_codes %}
              {% set ns.missing = ns.missing + 1 %}
            {% endif %}
          {% endif %}
        {% endfor %}
        Window: {{ start | timestamp_custom('%a %H:%M %Z') }}
        to {{ (start + 12 * 3600) | timestamp_custom('%a %H:%M %Z') }}.
        {% if ns.rain > 0 %}
          Take a raincoat: {{ ns.rain }} returned forecast period(s) include rain.
        {% elif ns.periods == 0 or ns.missing > 0 or ns.bad_time > 0 %}
          Forecast incomplete or unavailable. Check your weather app.
        {% else %}
          No rain condition in {{ ns.periods }} returned forecast period(s).
          This is not an all-clear; check for gaps and other weather hazards.
        {% endif %}
        Reviewed {{ ns.periods }} period(s); {{ ns.missing }} without a usable
        condition; {{ ns.bad_time }} row(s) with an unreadable time.
  - action: persistent_notification.create
    data:
      notification_id: morning_forecast_rain_check
      title: "Weather check — {{ now().strftime('%b %d, %H:%M') }}"
      message: "{{ rain_report }}"
mode: single

What the code does: it anchors the window to the start of the current local hour, then compares timestamps over twelve elapsed hours. That keeps a 7:00 forecast entry inside a run that starts a second after 7:00. It ignores periods outside the window and reports unreadable timestamps. Home Assistant’s weather entity reference defines the forecast timestamps and condition names.

The message counts returned periods, not guaranteed hours of coverage. An hourly provider can return a short list, gaps, or duplicate entries. Even twelve entries do not prove twelve distinct hours. The example therefore never declares the whole window dry. It also cannot tell when the provider originally issued a forecast from its future timestamps alone. The date and time template guide explains the timestamp conversions used here.

continue_on_error lets the message step run after a recoverable forecast-action error, using the initially empty response. It does not repair invalid YAML or a broken template. Such errors still need inspection in the automation’s trace, the step-by-step record of a run. This follows the action error-handling documentation.

The final action creates a persistent notification: a message in Home Assistant’s notification panel. It does not send a phone push alert. Reusing the same notification ID updates that one message, and its title shows when this check ran. The notification documentation explains that behavior. The check time is not the forecast’s issue time.

4. Read the result against a worked example

Suppose the check runs at 7 a.m. and these are the only entries returned. Times below are expressed in the home’s local time for readability. These are invented example inputs for explaining the calculation, not measured weather data.

Swipe sideways to read all columns.

Period beginsConditionHow the example treats it
6 a.m.RainyOutside the window; excluded.
7 a.m.CloudyOne period checked; no rain code.
9 a.m.RainyOne rain period.
NoonMissingOne period checked, but its condition is unknown.
3 p.m.PouringOne more rain period.
7 p.m.RainyAt the end boundary; excluded.

Expected message: take a raincoat; two returned periods include rain. Four periods were reviewed, one without a usable condition. The missing noon value does not erase the positive rain evidence. Equally, those four entries cannot describe every hour of the day.

If both rain entries become “Cloudy,” the missing noon condition produces “Forecast incomplete or unavailable.” If all four entries have known non-rain conditions, the result says only that none of those four periods has a rain condition, and warns about gaps. An empty list also produces the incomplete/unavailable message. These counts describe forecast entries, not the number of hours it will rain or the amount of rainfall.

5. Rehearse once, then check the scheduled run

  1. Save the automation and use its Run actions command. Open Home Assistant’s notification panel. Expect one weather-check message with the current check time and a window beginning at the current hour.
  2. Open the automation’s Traces view. Select the forecast action and inspect its returned variables, then compare the timestamps and conditions with the reported count. Running it at noon checks noon through midnight; it does not pretend it is 7 a.m.
  3. Run it once more. Expect the existing message to update. Do not unplug a device or change the weather entity’s state to force a rain result.
  4. Keep the automation enabled and confirm its next 7 a.m. run. Check Home Assistant’s configured time zone if the schedule is wrong. Manual execution verifies the actions, not the scheduled trigger.

To stop the exercise, disable this new automation and dismiss its notification. If Home Assistant is off at 7 a.m., this simple schedule does not catch up later. It will run at the next scheduled time; you can run its actions manually after startup. Home Assistant’s trigger documentation explains why a trigger reacts at a specific moment.

For a phone reminder, first verify your phone’s notification action independently, then adapt the final message action to that exact phone. If delivery fails, use the phone notification troubleshooting guide. Keep the forecast check and the delivery problem separate.

When the result is missing or surprising

Swipe sideways to read all columns.

What you seeCheck firstNext step
Weather card works, but the forecast template is emptyWhether the template reads an old forecast attributeRequest the forecast action and read its response in later actions.
Response exists, but the example finds no rowsThe exact key above forecastMatch weather_entity to the actual entity ID, including its suffix.
Hourly request is rejectedProvider support for that forecast typeUse a supported hourly provider, or design a separate daily check.
Incomplete message or a failed runResponse list, missing conditions, and trace errorsRepair the data source or template; do not replace missing values with zero rain.
A 7 a.m. message remains after an outageThe date in the notification title and latest traceRun the check manually after recovery. An old message is not proof that today’s schedule ran.
It rained despite a non-rain resultReturned period coverage and the provider’s own forecastTreat this as a planning aid. A forecast is not a rain sensor at your house.

Requesting the forecast again does not necessarily obtain a newly issued prediction: integrations can cache data. Do not add a loop that calls the action every few seconds. For a local observation at the property, the weather-station comparison explains a different data source and its hardware requirements.

Common questions

Can I use rain probability instead?

Yes, if the provider supplies precipitation_probability for the periods you need. Check the response first. It is a percentage, while precipitation is an amount with a unit. A missing probability is not zero, and probabilities from successive hours should not be added together.

Do I need a template sensor?

Not for this once-per-run message. Consider one when you also need a reusable forecast value on a dashboard or as a trigger elsewhere. Keep a separate plan for refreshing that value; copying a response into a sensor does not make it update by itself.

Can this close a roof or stop watering?

This example only creates a message. A roof needs its manufacturer’s obstruction and weather safeguards; a forecast reminder cannot replace them. Watering also needs a policy for missing weather data and any independent schedule. Use the irrigation rain-delay guide for that separate decision.

If you want household routines planned together, Tara’s home automation kit for coordinated local routines explains the service approach. Identify which inputs still depend on the internet before deciding how each routine should behave during an outage.