Go ahead, you won’t be bothered with my questions, with above Answers, you could might aswell told me to shut up ( which would not be the first time you indirect answers people that way )
The real issue is simply large data in the database that stems from entities with tons of attributes. It’s why calendar entities never got an events attribute. The decision to stop doing this was made years ago, and it’s finally being moved across the system now that service calls return data.
If you’re going to be overly upset with my comments, yes you can keep quiet. Otherwise we can actually have a discussion about filling the gaps with this change before the attribute is completely gone.
1 Like
Interesting - so instead of pulling and storing daily, hourly, current, etc, one reason for adding ‘specify what type of forecast you want’ is that only that specific data is returned / updated / stored in the db?
I’m not running the beta, so reading too much into beta release notes might be rather unfair, but I wonder if it is easy to set relative time periods (e.g. ‘next 4h’, not absolute ‘Forecast Thuis’ as in the temp screen shot).
Not sure I understand your question. Maybe my previous comment answers your question.
I can tell you, I use accuweather which requires you to specify what forecast type you want (daily, weekly, hourly, etc), during the integration setup.
When you make the service call, that does nto match the integration setup, the service fails.
This means the integration is caching the data and presents it when the service is called.
This will differ from integration to integration. Accuweather has a cost behind it, so more api calls eats through your #/calls per day. It makes sense for an integration like this to cache the data.
1 Like
Sort of - I’ve used several automation platforms, and some provided many ‘global variables’ which were always magically current (e.g. date, time of day, etc), and rather considered the ‘default’ weather forecast entity in the same way.
Something has a timed job to get and cache the forecast, but it was default and invisible (and I’m learning, cached a lot of data in the db, most of which was never consumed…).
It sounds like the accuweather integration is more like the 2024.03ish future but includes configured timed jobs to update just what you have configured.
With accuweather, can you simply include a configured weather entity in a template like {{ weather.home }}, or is there more marshalling of data required?
I’m trying to see if an automation might need to include an explicit service call to update with a likely pause for the RPC, then do some processing to get the result into a string like my example use case.
Well, yes, I don’t think you know the current change. The way to do this after the removal of the attribute will be…
# retreiving the data (which is cached or not, doesn't matter), and setting it to the variable "hourly"
- service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.home
response_variable: hourly
# using the data via the "hourly" variable.
- service: tts.google_say
data:
entity_id: media_player.1234
message: >-
Good morning. It is {{ now().hour}} {{ now().minute }} and the forecast is {{
states('weather.home') }}
The hourly forcast is ...
{% for hour in hourly.forecast %}
....
{% endfor %}
That is (of course) if we don’t add a method to get the data directly in templates. Currently variables in automations are limited by variable scope. I.e. you can’t access a variable created in a if action, outside the if action. Same goes for variables accessed in repeat actions. The variable can only be accessed during that single repeat. So getting multiple forecasts or events will be challenging, and it’s a gap (In my opinion) that needs to be addressed.
As a sidebar, the same logic above can be applied for getting calendar events, which was never an attribute. I believe @123 has a post somewhere that has code showing how to do that.
EDIT: example forecast data plopped into the response variable
forecast:
- datetime: "2023-09-01T11:00:00+00:00"
cloud_coverage: 8
precipitation_probability: 0
uv_index: 6
wind_bearing: 308
condition: sunny
temperature: 76
apparent_temperature: 82
templow: 55
wind_gust_speed: 10.38
wind_speed: 5.78
precipitation: 0
- datetime: "2023-09-02T11:00:00+00:00"
cloud_coverage: 58
precipitation_probability: 3
uv_index: 6
wind_bearing: 231
condition: partlycloudy
temperature: 83
apparent_temperature: 82
templow: 64
wind_gust_speed: 19.57
wind_speed: 9.2
precipitation: 0
- datetime: "2023-09-03T11:00:00+00:00"
cloud_coverage: 6
precipitation_probability: 3
uv_index: 6
wind_bearing: 261
condition: sunny
temperature: 86
apparent_temperature: 89
templow: 68
wind_gust_speed: 12.68
wind_speed: 9.2
precipitation: 0
- datetime: "2023-09-04T11:00:00+00:00"
cloud_coverage: 2
precipitation_probability: 6
uv_index: 6
wind_bearing: 254
condition: sunny
temperature: 91
apparent_temperature: 93
templow: 66
wind_gust_speed: 17.27
wind_speed: 12.68
precipitation: 0
- datetime: "2023-09-05T11:00:00+00:00"
cloud_coverage: 11
precipitation_probability: 11
uv_index: 6
wind_bearing: 270
condition: sunny
temperature: 90
apparent_temperature: 96
templow: 67
wind_gust_speed: 11.5
wind_speed: 8.08
precipitation: 0
2 Likes
As also mentioned above, i haven’t got as far as i wanted with my HA system, so currently only using the weather-integration(s) for weather-forcast, Don’t have a bunch of services/scripts/templates/automations with references to these attribute, so i’ll just wait until the new solution is in place.
I did “followed” the re-arrange/optimization of the DB, few year ago, when it was decided to reduce attributes in “state-table” , where some got upset that they should belong a “glob” , i did mention the huge amount of “attributes” in i.e weather-entities, as-well as in some(alot) “Camera-entities” , and regardless that these “attributes” are easily read in UI, i did find it obvious that they actually should be “dumped” in a glob … ( Even thou the “cost” of this in some situations was additional specific entities, either made by the integration, or user(template.sensor)
Newbie with own complete weather station and different weather sources; very disappointing as I was hoping to teach myself over my holidays all the code to take apart weather attributes /arrays! The existing weather platform is a bit of a jigsaw if you want to do anything smart. I will have to buy a sci-fi book now! 
Nearly 24% of users employ the Weather integration yet only 16 people (so far) have voted against the removal of the forecast attribute.
My crystal ball predicts a spike in Weather-related support requests next month and even more next March.
Don’t it always seem to go
That you don’t know what you’ve got 'til it’s gone
They paved paradise, put up a parking lot
6 Likes
Thx for the reminder 
Thanks - that helps a lot to understand the changes. 
And extra thanks for adding a {% for... %} loop to iterate over the hourly forecast members - rather neat syntax I’ve not had to use (yet…).
- Looks like by default, there is no background updating of the weather entity, so explicit service calls are needed in automations that use forecast data.
- This change has the advantage of reducing the amount of data that is retrieved from weather providers, network traffic, and the amount of updates that are made to the database at the cost of extra steps to make weather service calls which are more specific.
- The service call to
weather.get_forecastmight be cached or need time for an API call, so it’s probably best to place it at the start of an automation that interacts with users (such as using several blocks of TTS where a gap might be noticed). Probably not a big issue, but I’ll try some tests.
If I’ve understood it correctly, Kendell’s original challenge was how to update dashboards where as well as making the weather service call, extra processing (generate images? create HTML for icons?) is needed.
For the dashboard use-case:
- Could a state change trigger on the weather entity spot a background update (if there are any?) and run any extra processing needed for a dashboard?
- Would a manual template trigger entity to regularly update the weather entity (like my attempt above), and also the processing work?
It seems different weather service calls behave differently, with some configuring background updates/ cacheing in integration set-up, but some not. The logical progression of this change could be a unified API for weather services, but that’s real speculation.
Again, I’m trying to anticipate questions that might arise after the release so thanks all for your help, patience, and apologies if I’m missing your points…
That’s half true, that depends on the integration. That’s what I’m referring to when I talk about cached data vs accessed data. Accuweather caches the data, other integrations may get the data live.
True:
False:
Potentially True, again, depends on the integration.
I think this is all semantics and we are saying the same thing. I’m not sure though. Just clarifying.
I’m not sure where he’s getting that idea, but the weather card and more info card for weather still updates fine. I think (he can correct me if I’m wrong) that he’s specifically talking about updates from template entities (or markdown card) into the frontend that use forecast attributes. I.e. a very specific (valid) use case.
So as I understand this change to limit number aff calls (some providers have limited number of allowed free API calls) we will need to automate data fetching and using templates store retrieved data in sensors. So anyhow this will go into DB… not sure how this will help to reduce size…
Maybe I’m not making it clear enough, but the change has nothing to do with number of api calls. It has everything to do with the attribute containing large amounts of data and a decision that was made years ago to reduce attributes on entities.
Integrations can decide how many api calls they make based on how they create the integration.
1 Like
Based on this example, for periodically retrieving Calendar Events and storing them in the attribute of a Trigger-based Template Sensor, here’s the same thing for a Weather Forecast (untested because I am not running the beta of 2023.9).
In this example, an automation periodically gets the hourly weather forecast and transfers it to a Template Sensor. Afterwards, you can access the forecast’s details directly from the Template Sensor.
Automation
Create an automation that uses a Time Pattern Trigger to retrieve the forecast every hour and then posts it via a custom Home Assistant Event named weather_forecast_hourly.
alias: Get Weather Forecast Hourly
description: ""
trigger:
- platform: time_pattern
hours: /1
condition: []
action:
- service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.home
response_variable: hourly
- event: weather_forecast_hourly
event_data:
hourly: "{{ hourly}}"
mode: single
Trigger-based Template Sensor
Create a Trigger-based Template Sensor that uses an Event Trigger to receive the hourly forecast, via weather_forecast_hourly, and reports it in an attribute named forecast. The sensor’s state simply reports the time when the sensor was updated.
template:
- trigger:
- platform: event
event_type: weather_forecast_hourly
sensor:
- name: Weather Forecast Hourly
unique_id: weather_forecast_hourly
state: "{{ now().isoformat() }}"
attributes:
forecast: "{{ trigger.event.data.hourly.forecast }}"
You can access the sensor’s forecast attribute in the usual manner:
{{ state_attr('sensor.weather_forecast_hourly', 'forecast') }}
5 Likes
truly elegant.
Must confess I dont see what this will bring the system, as these attributes are now stored in the DB (they weren’t before) and restored upon restart (which is a top feature of the trigger based templates, dont get me wrong now)
one might argue the update frequency is more controllable with this, but that is about it as far as I understand the impact now.
The goal of this thread really needs to divert from “why was this done” to “what can we do to replicate the behavior in templates without the mess above posted by 123”.
3 Likes
This I dont understand. The template trigger posted by 123 is simple and anything but a mess? I would have imagined the core devs to have envisioned something like this, and added it to the release notes accompanying the announcement of the deprecation of the forecast attribute
It’s a mess because it’s a work around to replicate past behavior inside a template. What he posted is a viable solution if nothing else is done, however, I don’t think its a good solution long term.
As more and more responding services get added, this question will come up with higher frequency. We can avoid this all together with an added feature to the template engine.
3 Likes