New weather forecast template

With the new weather entities and “forecast” being removed, how do we get attribute values with a sensor template now? This template no longer works. I am using the Weatherflow Forecast integration.

 {{state_attr('weather.forecast.stratford', 'forecast')[0].temperature}}

The value appears to be there when I do a daily service call (as shown below), but the template tester returns No element 0.

forecast:
  - condition: lightning-rainy
    datetime: "2023-10-05T05:00:00+00:00"
    precipitation_probability: 40
    wind_bearing: 127
    temperature: 84
    templow: 64
    wind_speed: 6.34
    precipitation: 0.01
  - condition: lightning-rainy
    datetime: "2023-10-06T05:00:00+00:00"
    precipitation_probability: 40
    wind_bearing: 283
    temperature: 75
    templow: 59
    wind_speed: 6.9
    precipitation: 0.11
3 Likes

forecast is not really removed but indeed you’d need to ‘call’ for it, in time the cards themselves will follow. If you need something outside of cards, e.g. for apexcharts, then you can create a separate sensor
Template - Home Assistant (home-assistant.io)

If I create a triggered template sensor this way, I can get the forecast as an attribute to this sensor (e.g. sensor.my_region). But how do I get this into a weather template sensor like before ? The online documentation still has this example:

forecast_daily_template: "{{ state_attr('weather.my_region', 'forecast') }}"

which gives me an error when I use

forecast_daily_template: "{{ state_attr('sensor.my_region', 'forecast') }}"

instead.

1 Like

You need to create a triggered template similar to this for an hourly or daily forecast:

- trigger:
  - platform: state
    entity_id: yourweatherentity
  action:
    - service: weather.get_forecast
      data:
        type: daily
      target:
        entity_id: yourweatherentity
      response_variable: daily
  sensor:
    - name: Weather Forecast Daily
      unique_id: weather_forecast_daily
      state: "{{ now().isoformat() }}"
      attributes:
        forecast: "{{ daily.forecast }}"

Then, you can create your sensor templates from the service data returned from that triggered template like this:

 sensor:
  - unique_id: forecasted_high_temp
    attributes:
      friendly_name: "Today's High"
    state: >
      {{state_attr('sensor.weather_forecast_daily', 'forecast')[0].temperature}}
2 Likes

Thanks for your reply, but this still only gives me a sensor.. That´s not what I need. I need new weather entity. with the forecast data from the online forcast provider but with current temperature / humidity etc. from my own outside sensors.

1 Like

What integration do you get your online weather info from and what integration do you get local sensor data from? I am using the builtin Weatherflow integration for local sensor info from my Tempest weather station and using the custom Weatherflow Forecast integration for forecasts and online only REST sensors. Then the two sensors I detailed previously work to grab the online data and display it in a sensor.

I get weather data from DWD (state owned public german weather service) and my local sensor is an ELV Weather Station. Both work fine. DWD gives me a weather entity which shows up perfectly in a lovelace weather-forecast card but shows estimates for my local temperature / humidity from their weather model. The ELV station gives me severeal sensors for current outside temperature, humidity, wind speed, air pressure etc. What I want is a new weather entity which combines the current data from the weather station and the forecast data from DWD and can be used in a in a lovelace weather-forecast card.

Ah, makes sense now. You could use this example from the WeatherflowMQTT to create your own Weather entity. The example is near the bottom of the page linked. Here is the yaml example as well. Replace sensors with those of your local station as needed.

weather:
  - platform: template
    name: My Local Weather
    condition_template: "{{ states('sensor.hub_hb_00000001_weather') }}"
    # condition_template: "{{ states('tempest_st_00000001_current_conditions') }}" # Local Only Option
    temperature_template: "{{ states('sensor.tempest_st_00000001_temperature') | float}}"
    humidity_template: "{{ states('sensor.tempest_st_00000001_humidity')| int }}"
    pressure_template: "{{ states('sensor.tempest_st_00000001_sea_level_pressure')| float }}"
    wind_speed_template: "{{ ( states('sensor.tempest_st_00000001_wind_speed_avg') | float * 18 / 5 ) | round(2) }}"
    wind_bearing_template: "{{ states('sensor.tempest_st_00000001_wind_bearing_avg')| int }}"
    visibility_template: "{{ states('sensor.tempest_st_00000001_visibility')| float }}"
    forecast_template: "{{ state_attr('sensor.hub_hb_00000001_weather', 'hourly_forecast') }}"

Solved now. There was a bug in the weather integration I use (wrong attribute naming for wind gusts). This caused the weather template to error. Fixed now by the author of the weather integration.

Thanks, Tom could you maybe help me understand the mistake I do, given that I cannot make this thing working. I have a dedicated template.yaml file to which I link to in the configuration yaml and use the follwoing code(s). Unfortunately, none of these sensors give any value back:

My weather entities Daily

  • trigger:
    • platform: state
      entity_id:
      • weather.home
        action:
    • service: weather.get_forecast
      target:
      entity_id: weather.home
      data:
      type: daily
      response_variable: my_daily_forecast
      sensor:
    • name: My Weather Forecast Daily
      unique_id: 1105749b-2241-4f36-8857-72ccaa48abc1
      state: “{{ my_daily_forecast[‘forecast’][0][‘condition’]}}”
      attributes:
      forecast: “{{ my_daily_forecast[‘forecast’] }}”

My Weather Entities Hourly

  • trigger:
    • platform: time_pattern
      hours: /1
      action:
    • service: weather.get_forecast
      target:
      entity_id: weather.home
      data:
      type: hourly
      response_variable: my_hourly_forecast
      sensor:
    • name: My Weather Forecast Hourly
      uniquie_id: 8179e2aa-b3c8-4b24-a6e4-3d45e1a752d9
      state: “{{ my_hourly_forecast[forecast][0][condition] }}”
      attributes:
      forecast: “{{ my_hourly_forecast[forecast] }}”

My weather entities Daily test

  • trigger:
    • platform: state
      entity_id:
      • weather.home
        action:
    • service: weather.get_forecast
      target:
      entity_id: weather.home
      data:
      type: daily
      response_variable: my_daily_forecast_new
      sensor:
    • name: My Weather Forecast Daily new
      unique_id: b821db4f-6245-49ce-a76d-c7903817a948
      state: “{{ now().isoformat() }}”
      attributes:
      forecast: “{{ my_daily_forecast_new.forecast }}”

Any idea what I may doing wrong? Many thanks for your help. Much appreciated.

Does this mean the template weather sensor has code to return the forecast template as a result of the new forecast service? The documentation is not clear on that. If it just feeds the deprecated attribute, it will not be future proof.

1 Like

Correct, it’s going to break when the “forecast” attribute of the integration’s sensor goes away due to changes in background weather polling. A “forecast” key will still be returned by the weather integration when the get_forecast service is called. You’ll need to build a trigger template that calls the weather.get_forecast service and copies the resultant data into this weather sensor template.

Example:


# Update weather every five minutes
trigger:
    # ref: https://www.home-assistant.io/integrations/template#trigger-based-template-binary-sensors-buttons-images-numbers-selects-and-sensors
    - platform: time_pattern
      minutes: "/5"
action:
    - service: weather.get_forecast
      data:
        type: hourly
      target:
        entity_id: weather.openweathermap
      response_variable: owm_hourly_forecast
weather:
    # ref: https://www.home-assistant.io/integrations/weather.template/
    # ref: https://www.home-assistant.io/integrations/template/#weather
    # ref: https://developers.home-assistant.io/docs/core/entity/weather/#unit-conversion
    - name: Weather
      condition_template: "{{ owm_hourly_forecast.forecast[0].condition }}"
      temperature_template: "{{ owm_hourly_forecast.forecast[0].temperature }}"
      temperature_unit: "°F"
      forecast_template: "{{ owm_hourly_forecast.forecast }}" <--- THIS
1 Like

I really thank you for helping out here. It is by no means your fault, but I am a bit frustrated with the half thought out deprecation of the attribute. In it’s current form removing the attribute break things that cannot be fixed as it is now.

A major reason of a weather template sensor is to use it in weather cards. If the weather template cannot implement the service then it defeats the whole purpose. The weather card can only use the service once the attribute is gone. So eventually this will break (if it isn’t broken already).

At the same time, the service was meant to prevent the attribute, and every post about this that I read is all about putting the service call data in an attribute. So we’ll have a service that needs a cache, plus a self made attribute that holds the same data. The official attribute was at least excluded from the recorder by default. Self made attributes won’t be, so the current change will often lead to more recorded data unless people are smart enough to exclude them.

Template/MQTT weather entities need to implement the service one way or another. From an architectural perspective the move is perfectly sound and logical, but the practicallity suffers as a result here.

1 Like

You’re miss informed. You can get old attribute functionality back with a template sensor and the data will persist.

This posts shows what you do

It’s not a half thought out deprecation. This is a 3-4 year coming deprecation. Entities and attributes are shifting towards devices and entities. You’ll see these types of changes over the coming years.

Mea Culpa. I must apologise as I misunderstood what the weather template entity is doing. My above question was: will the templates for the forecasts generate data for the service calls. I asked that question before, only to be met an answer that I took to be that I should keep using attributes. From that I wrongly assumed the weather templates would still create deprecated attributes too - I misread the above answer and the documentation (which does not describe what the forecast should look like by the way).

I just tested it, and they don’t create attributes. So to answer my own question (in case any one else wonders the same): the forecast templates are used to implement the new forecast services. If you provide them, the template weather entity will work with the new services. I thought they didn’t. So I must agree that is is not half baked - I just misunderstood. Apologies.

For those following along at home, it took me awhile to figure out the new weather.get_forecasts (plural) service format, but now that I have it working, I thought I would share my updated templates:

Automation Trigger Template to get the forecast:

template:
  - trigger:
      - platform: state
        entity_id: weather.forecast_local  # this is my weather provider
    action:
      - service: weather.get_forecasts
        data:
          type: daily  # change to hourly if you want hourly forecasts
        target:
          entity_id: weather.forecast_local
        response_variable: daily
    sensor:
      - name: Local Weather Forecast Daily
        unique_id: local_weather_forecast_daily
        state: "{{ now() }}"
        attributes:
          forecast: "{{ daily['weather.forecast_local'].forecast }}"    # note the array index with the weather provider name. This is what is different with get_forecasts (plural)

Now you can pull values from the forecast array like normal:

template:
  - sensor:
      - name: Local Forecast High Temperature Today
        unique_id: local_forecast_high_temperature_today
        state: "{{ state_attr('sensor.local_weather_forecast_daily', 'forecast')[0].temperature }}"
        unit_of_measurement: °F

I find triger templates difficult to debug, so hopefully others find this useful! Probably should put some checks in for the case where get_forecasts fails, but that is a problem for future me.

6 Likes

my previous reply unfortunately didn’t work properly and needs some more testing

I had to change quite a bit, but has been steady and reliable since.
Old way with template sensor to update forecast data and 3 other sensors populated from that data.

- trigger:
  - platform: state
    entity_id: weather.forecast_stratford
  - platform: time_pattern
    minutes: /10
  action:
    - service: weather.get_forecast
      data:
        type: daily
      target:
        entity_id: weather.forecast_stratford
      response_variable: daily
  sensor:
    - name: Weather Forecast Daily
      unique_id: weather_forecast_daily
      state: "{{ now().isoformat() }}"
      attributes:
        forecast: "{{ daily.forecast }}"

#Smartweather
- sensor:
  - unique_id: forecasted_high_temp
    attributes:
      friendly_name: "Today's High"
    state: >
      {{state_attr('sensor.weather_forecast_daily', 'forecast')[0].temperature}}
    unit_of_measurement: "°F"
  - unique_id: forecasted_low_temp
    attributes:
      friendly_name: "Tonight's Low"
    state: >
      {{state_attr('sensor.weather_forecast_daily', 'forecast')[0].templow}}
    unit_of_measurement: "°F"
  - unique_id: forecasted_rain_today
    attributes:
      friendly_name: "Rain Chance Today"
    state: >
      {{state_attr('sensor.weather_forecast_daily', 'forecast')[0].precipitation_probability}}
    unit_of_measurement: "%"

New way with “integrated” sensors.

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

you can make your templates easier to manage by doing the following.

- trigger:
  - platform: time_pattern
    hours: "/4"
  action:
    - service: weather.get_forecasts
      data:
        type: daily
      target:
        entity_id: weather.forecast_stratford
      response_variable: daily
    - variables:
        today: "{{ daily['weather.forecast_stratford'].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: "%"
5 Likes