There’s a more concerning issue with the removal of this attribute that needs to be thought out. I’ll most likely create a discussion about this and potentially spearhead the change itself (if approved). But with the current service, it’s not possible to get multiple forecasts (or calendar events) into a single template without an incredible amount of work. The only way it’s possible ways to do this at the moment is with custom events & template entities or publishing to MQTT topics and retrieving the data once it’s all collected via an MQTT trigger to a template entity.
2 Likes
Then why’d you ask what it even means…
1 Like
I don’t think this petition will stop the change. The overall goal with attributes in home assistant is to get large footprint attributes out of the database. This is partly why events were never an attribute on calendar entities.
I do believe we can come up with another solution (potentially 1 line template solution), that replicates the behavior.
1 Like
Call it a “rhetoric” Question
Because:
Currently, it’s up to the integration. If the integration caches the data, then it’s cached (and then retrieved from the service call). If the integration decides to make the service call retrieve the data live, then it’s live.
I’m not sure why you even have this question, that much has already been answered. You call the current service and it responds with data in the response variable. This system has been in HA since 2023.7.
By calling the service and using the response data. The only ‘hole’ at the moment is getting this information into template entities. Automations and scripts have a solution that works without issue.
1 Like
Hi,
Cleaning up data models in older code is fun - I used to spend happy hours re-formatting code and finding stuff to fix. The repeated issue is change management - i.e. communicating and supporting the impact of the change on others. Like the 2023.8 changes to the Entity Naming Standards and dev blog post on MQTT naming, the code change is simple, but communicating is, well, harder…
The ideal would be to use the beta to get ahead of the change, and constructively offer updated usage docs to the community. If the change really breaks stuff without reasonable workarounds, the feedback needs to be to devs and PRs.
Custom cards have been mentioned as one use case, but can we collect the other likely impact areas and think about them now?
I suspect a lot of folk use templating with text to speech or notifications for messages.
Use case - Weather in a message string for text to speech or notifications
Uses templating to build up a text string to be read out, (or could be sent as a notification message) such as in an alarm clock:
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') }}
So what’s the way to do this after 2024.03 when the change is depreciated?
Adding a service call into the automation to refresh the forecast data isn’t terrible, but getting the data into the string? Just a different {{ template entity }} to extract the state from?
The regular refresh could be added back with a manual template trigger entity:
- trigger:
- event: start
platform: homeassistant
- platform: event
event_type: event_template_reloaded
- platform: time_pattern
# change time pattern as needed - weather likely more than once a day
hours: 05
minutes: 05
unique_id: 1234567890
sensor:
- name: Refresh Weather
<add service call to Weather>
My guess is the real issue here is the impact on the weather provider’s API of several hundred thousand HASS installs calling their server regularly by default, rather than by a configured decision.
2 Likes
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…