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:
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.
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.
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.
My guess is that you did not change the entity_id of the OWM integration instance (in my example weather.home) to fit your configuration. The default name changed several times in the past and might also depend on how you named your home location.
If your entity_id is correct, does the details dialog show a forecast?
One part of the result, that is unclear to me is that the forecast graph doesn’t show the predicted future. I did the code fix around noon today (Aug 5) and now we have a few minutes before midnight.
This is correct, the original forecast entities showed the forecast for the current day, thus instead of showing the current conditions, it is showing percipation totals, maximum and minimum temperatures, … to expect for today. Hence it is normal for it to change over time and converge to a value as time progresses, and to reset to a new value at midnight.
If you want the values to represent the forecasts for tomorrow instead of today, you may change forecast[0] to forecast[1].
Is this still supposed to be working?
I tried the template yaml in the OP but don’t get any values, It won’t update for some reason.
Pretty frustrated over the removal of forecast, all of my TTS scripts that have been disabled during summer/vacation are now non functional =(
@BB9 Yes, it is working well. Most likely the reason for it not working is either you missed to replace all occurrences of weather.home by the entity_id of your OpenWeatherMap weather class entity, or you might have not migrated to the OpenWeatherMap API version 3.0, which OWM requires for all service calls since June 2024.