New weather forecast template

Thanks @petro for the hint with variables

As I couldn’t find this in the documentation I created a helper service to extract the data from the response_variable, this is now no longer required

This snippet will create the the response I had from weather.get_forecast

- trigger:
    - platform: time_pattern
      minutes: "0"
  action:
    - service: weather.get_forecasts
      target:
        entity_id:
          - weather.forecast_66_whitney
      data:
        type: hourly
      response_variable: hourly
    - variables:
        forecast: "{{ hourly['weather.forecast_66_whitney'] }}"

I further changed the forecast variable to

   - variables:
        forecast: "{{ hourly['weather.forecast_66_whitney'].forecast }}"

to get direct access to the forecast array which allowed to drop the first forecast from the forecast.forecast[] sensor templates.

1 Like

This doesn’t work. Sensors all come up blank. And I did change the entity to the service I’m using.

post what you tried because it does work.

  - trigger:
    - platform: time_pattern
      hours: "/4"
    action:
      - service: weather.get_forecasts
        data:
          type: daily
        target:
          entity_id: weather.pirateweather
        response_variable: daily
      - variables:
          today: "{{ daily['weather.pirateweather'].forecast[0] }}"
    sensor:
      - name: "Today's High"
        unique_id: forecasted_high_temp
        state: "{{ today.temperature }}"
        unit_of_measurement: °F
      - name: "Tonight's Low"
        unique_id: forecasted_low_temp
        state: "{{ today.templow }}"
        unit_of_measurement: °F
      - name: "Rain Chance Today"
        unique_id: forecasted_ran_chance
        state: "{{ today.precipitation_probability }}"
        unit_of_measurement: "%"

Tried seeing if it was the service but I could not find another service available that even supports daily forecasts. Accuweather, Openweathermap, and NWS all available from home assistant do not support the getforecasts service in a daily format.

That looks correct, but the entities will be unknown on template reload.

Just an FYI, you are right that NWS does not support daily in the service call, because it doesn’t support daily in general, but NWS does support twice_daily.

1 Like

Maybe i am confused on how this is to be used. If the entities end up unknown, how do I get the forecast data from them?

It triggers every 4 hours. If you want data on startup, add a startup trigger

It’s been well over 4 hours. The entities show no data.

Not sure what to tell you, the code is correct unless you put it in the wrong spot of your configuration. Check for errors in your logs.

I guess that’s what I get for updating.

Just look in the logs for errors, you have to be doing something wrong. There’s no way around that. This is working for me and many other people. Your logs or the entities themselves will show you what’s going on. If you’re unsure, post your text logs and screenshots of the entity.

1 Like

The other thing to try is goto UI->DeveloperTools->Services(tab)
and in the text box fill in something like the following (YAML mode)

service: weather.get_forecasts
data:
  type: daily
target:
  entity_id: weather.pirateweather

Hit the “Call Service” button and see what the response is.

1 Like

Because this is way too complicated (seriously - why not just have forecasts as an attribute in the weather sensor??? Forcing a template for basic functionality is ridiculous), and because several of the answers are flat-out broken, here is a working template sensor for daily and hourly forecasts, using Pirateweather:

template:
  - trigger:
    - platform: time_pattern
      hours: "/4"
    - platform: homeassistant
      event: start
    action:
      - service: weather.get_forecasts
        data:
          type: daily
        target:
          entity_id: weather.pirateweather
        response_variable: daily
      - variables:
          today: "{{ daily['weather.pirateweather'].forecast[0] }}"
    sensor:
      - name: Pirateweather Daily Weather Forecast
        unique_id: pirateweather_forecast_daily
        state: "{{ now().isoformat() }}"
        attributes:
          forecast: "{{ daily['weather.pirateweather'].forecast }}"
      - name: "Pirateweather High"
        unique_id: pirateweather_forecasted_high_temp
        state: "{{ today.temperature }}"
        unit_of_measurement: °F
      - name: "Pirateweather Low"
        unique_id: pirateweather_forecasted_low_temp
        state: "{{ today.templow }}"
        unit_of_measurement: °F
      - name: "Pirateweather Rain Chance Today"
        unique_id: pirateweather_forecasted_ran_chance
        state: "{{ today.precipitation_probability }}"
        unit_of_measurement: "%"
  - trigger:
    - platform: time_pattern
      hours: "/1"
    - platform: homeassistant
      event: start
    action:
      - service: weather.get_forecasts
        data:
          type: hourly
        target:
          entity_id: weather.pirateweather
        response_variable: hourly
    sensor:
      - name: Pirateweather Hourly Weather Forecast
        unique_id: pirateweather_forecast_hourly
        state: "{{ now().isoformat() }}"
        attributes:
          forecast: "{{ hourly['weather.pirateweather'].forecast }}"

Most of the other things posted in this thread are missing ['weather.pirateweather'] (or whatever your weather sensor is) as a lookup in the map on the forecast variable, and of course trigger-based templates are effectively impossible to debug outside of trial and error.

I would love to see this as an attribute in the weather domain. Home Assistant updates are supposed to make accessing information easier, not harder. I understand that the Home Assistant project prefers breaking changes to having legacy code stick around, but the fact that something as basic as “is it going to rain in the next 2 hours?” requires multiple nested templates when it used to be relatively straightforward is IMO ridiculous.

13 Likes

The forecast attribute was deliberately removed as part of a general initiative to minimize the use of attributes. Its removal was announced last September (2023).

The examples in this topic are several months old and predate the change of service call (last December) from weather.get_forecast (singular) to weather.get_forecasts (plural). That’s why the older examples use the response_variable without an explicit reference to the weather entity (because it could only contain data for a single weather entity whereas now it can be more than one).

1 Like

I think your reply here just proved my point.

“Several months old” (not even a year, this topic is barely 6 months old at time of posting) and it’s gone through several breaking changes to the point where most of the information is incorrect? And who knows if my reply will even be correct in 2-3 months. The speed of breaking changes is ridiculous.

I’ve been using HASS since 2016, and I even contributed integrations myself (I am the original author of the Todoist integration, way back when). The fact that it’s been 8 years and the speed of breaking changes means I’m still looking up basic things like “how to write a template sensor” (since all my old template sensors broke) is silly. I’m a programmer as well, and I prefer being able to open an IDE and look at everything in one spot rather than having to pick through a bunch of GUI windows.

Removing attributes is something I can get behind… if they are given an easy, built-in, get-it-for-free alternative (e.g. another sensor). Having to make someone write a cryptic template to replace formerly built-in functionality for something as basic as “is it going to rain soon?” is really silly, IMO.

Regardless, this isn’t really the topic for that - I just wanted to provide a working (as of March 2024) template for others, as this page appears near the top of the Google results when someone is looking for how to get Home Assistant to tell you the hourly forecast for use in things like automations.

9 Likes

Two changes; remove attribute, improve service call.

In this particular case, the elimination of the attribute had a grace period of 6 months (ended this month). The service call evolved from handling single to multiple weather entities within the grace period.

Basically, a fairly pedestrian pace for changes and now the older examples in this topic are outdated (the eventual fate of many examples in this forum).

There should be. Check the device in integrations page and enable entities that you want.

An example for this is the accuweather integration. All the forcast information is separated into separate entities.

If that’s not the case for whatever weather integration you’re using, make a feature request for that integration.

The 6 month grace period is both for users and integrations to catch up with whatever the change is. This doesn’t always happen, and in those cases feature requests or issues should be raised.

All the solutions in this thread are band-aides for users to get back the exact same entity they previously had instead of rolling with the changes.

e.g.

1 Like

Alright jumping in on this thread now that 2024.4 is out and the forecast attribute has been removed. I updated a templated weather provider for my use case:

  • Start with a weather entity from the OpenWeather integration
  • Create a template weather entity combining a local sensor with the forecast from OpenWeather
  • Display this new entity in the weather-forecast card

I sorted it out after finding the very helpful debugging thread from @dbs: Debugging templates and service response_variables

template:
  - trigger:
      - platform: time_pattern
        hours: "/4"
      - platform: homeassistant
        event: start
      - platform: event
        event_type: event_template_reloaded
    action:
      - service: weather.get_forecasts
        data:
          type: daily
        target:
          entity_id: weather.daily
        response_variable: daily
    weather:
      name: Local
      temperature_template: "{{ states('sensor.outside_temp') | float(0) }}"
      temperature_unit: "°F"
      humidity_template: "{{ states('sensor.outside_humidity') | float(0) }}"
      condition_template: "{{ states('weather.daily') }}"
      forecast_daily_template: "{{ daily['weather.daily'].forecast }}"

A bit more involved than the previous 8 line template but it works :slight_smile:

Also FWIW, the docs still show the forecast_template option that was removed.

5 Likes

I was unable to call the service weather.get_forecasts for either Accuweather or OpenWeathermap integrations. OpenWeatherMap did support an “hourly” data type. I am now forced to go to a HACS integration Pirate Weather based on code shown above which is working. If the roadmap is to remove attributes that is ok, but the solution to have to create a template sensor in configuration.yaml for Weather forecast is a step backwards and the next release needs to address this.

1 Like