Reviving OpenWeatherMap forecast entities using templates

HomeAssistant 2024.7 removed the OpenWeatherMap integration’s forecast sensor entities.

As I use them in several automations that I would prefer not to alter, I emulated the old sensor.openweathermap_forecast_* entities using template sensors that update once per minute from the integration’s cached data.

Assuming that your weather entity is weather.home and you did not alter the friendly names or entity IDs of the sensors, this template will fully replace them:

template:
  - trigger:
      - platform: time_pattern
        minutes: /1
    action:
      - service: weather.get_forecasts
        data:
          type: daily
        target:
          entity_id: weather.home
        response_variable: daily
    sensor:
      - name: OpenWeatherMap Forecast Cloud coverage
        unique_id: openweathermap_forecast_cloud_coverage
        state: "{{ daily['weather.home'].forecast[0].cloud_coverage }}"
        unit_of_measurement: '%'
      - name: OpenWeatherMap Forecast Condition
        unique_id: openweathermap_forecast_condition
        state: "{{ daily['weather.home'].forecast[0].condition }}"
      - name: OpenWeatherMap Forecast Precipitation
        unique_id: openweathermap_forecast_precipitation
        state: "{{ daily['weather.home'].forecast[0].precipitation }}"
        unit_of_measurement: mm
        device_class: precipitation
      - name: OpenWeatherMap Forecast Precipitation probability
        unique_id: openweathermap_forecast_precipitation_probability
        state: "{{ daily['weather.home'].forecast[0].precipitation_probability }}"
        unit_of_measurement: '%'
      - name: OpenWeatherMap Forecast Pressure
        unique_id: openweathermap_forecast_pressure
        state: "{{ daily['weather.home'].forecast[0].pressure }}"
        unit_of_measurement: hPa
        device_class: pressure
      - name: OpenWeatherMap Forecast Temperature
        unique_id: openweathermap_forecast_temperature
        state: "{{ daily['weather.home'].forecast[0].temperature }}"
        unit_of_measurement: °C
        device_class: temperature
      - name: OpenWeatherMap Forecast Temperature Low
        unique_id: openweathermap_forecast_temperature_low
        state: "{{ daily['weather.home'].forecast[0].templow }}"
        unit_of_measurement: °C
        device_class: temperature
      - name: OpenWeatherMap Forecast Time
        unique_id: openweathermap_forecast_time
        state: "{{ daily['weather.home'].forecast[0].datetime }}"
        device_class: timestamp
      - name: OpenWeatherMap Forecast Wind bearing
        unique_id: openweathermap_forecast_wind_bearing
        state: "{{ daily['weather.home'].forecast[0].wind_bearing }}"
        unit_of_measurement: °
      - name: OpenWeatherMap Forecast Wind speed
        unique_id: openweathermap_forecast_wind_speed
        state: "{{ daily['weather.home'].forecast[0].wind_speed }}"
        unit_of_measurement: m/s
        device_class: wind_speed

Delete the original, now orphaned entities or rename them and their IDs, put the snipped above into your configuration.yaml, let it check for correctness and reload template entities, and you should be good to go again.

A slightly more comprehensive guide in English and German can by found here:

That’s not how service: weather.get_forecasts works. It only checks a cache that the normal sensor update interval populates from the API. So your sensor is unneeded to mitigate this perceived issue.

Same thing occurs whenever you view a weather card in a dashboard. The data is loaded from cached memory, not the API.

1 Like

Thanks for clarification. I updated the guide accordingly.

Rather than triggering every minute (even when there has been no change) a much more efficient trigger would be:

  - trigger:
      - platform: state
        entity_id: weather.home

This will only trigger if the state or attributes of your weather entity change.

1 Like

Thanks for the hint, though the forecasts are not part of the entity’s attributes, neither is a timestamp of the last update to the cache, so this would only trigger if there is change to the current weather between two updates.
Of course the current weather will change regularly, as temperature, humidity, … change over time, but it would be at least theoretically/potentially error prone.
Maybe a combination of state trigger plus time_pattern trigger at a longer interval is the way to go.

Go to Developer Tools → States and copy the attributes shown for your weather forecast entity (right hand column) and paste them here. There should be a timestamp.

1 Like

I assume you mean the weather entity, weather.home created by the OpenWeatherMap integration, not my weather forecast entities, which are templates.
I checked weather.home’s attributes before, but there is nothing looking even remotely like a timestamp:

temperature: 17
apparent_temperature: 16.7
dew_point: 12.3
temperature_unit: °C
humidity: 74
cloud_coverage: 75
pressure: 1017
pressure_unit: hPa
wind_bearing: 240
wind_speed: 1.84
wind_speed_unit: km/h
visibility_unit: km
precipitation_unit: mm
attribution: Data provided by OpenWeatherMap
friendly_name: OpenWeatherMap
supported_features: 3

Yeah ok that’s not good. You should probably open an issue for that integration. It needs a timestamp attribute so you don’t have to keep polling it for updates.

1 Like

I opened issue #121595 for this earlier. Let’s see whether it gets implemented.

1 Like