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
I wouldn’t call it a mess but, I would say it makes it more difficult for less experienced users.
However, using automations to poll services makes me a little uneasy. It just doesn’t feel right.
3 Likes
There’s a PR by @allenporter which allows trigger-based template entities to call services: Extend template entities with a script section by allenporter · Pull Request #96175 · home-assistant/core · GitHub
With that PR, this could all be done within a single trigger-based template sensor, removing the need for the extra automation.
The details in the PR, for example how to export variables from the actions to templates still need to be worked out.
4 Likes
Yes, I probably shouldn’t have said mess. I just used that word for simplicity in that sentence.
Just remembered I use a bunch of apex chart generators on forecast attributes too:
- entity: sensor.solcast_forecast_data
type: line
name: Forecast
color: '#e45e65'
extend_to: now
stroke_width: 2
unit: W
show:
in_header: false
legend_value: false
data_generator: |
return entity.attributes.forecasts.map((entry) => {
return [new Date(entry.period_end), entry.pv_estimate*1000];
});
tbh, who cares about DB size anymore? isnt that a somewhat over articulated aspect nowadays? While phones and watches outgrow the specs from devices at the time this decision was made (not even mentioning the other devices people run HA on), it seems watching DB size decrease has low priority?
so its 1.4 GB. doesnt break the system? while breaking this functionality causes real trouble for the non savvy.
2 Likes
Well, according to that blurb, that’s not a weather entity, so it’s unaffected by this change.
The attribute is staying for 6 months from September. So there’s nothing to delay, we just have six months to merge a PR that solves the problem.
2 Likes
You’re right, it’s not going away immediately. Nevertheless, that PR reduces the aforementioned “mess” by half, thereby making it easier to show users how to get a forecast attribute.
Just a guess but I think it would look something like this:
template:
- trigger:
- platform: time_pattern
hours: /1
action:
- service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.home
response_variable: hourly
sensor:
- name: Weather Forecast Hourly
unique_id: weather_forecast_hourly
state: "{{ now().isoformat() }}"
attributes:
forecast: "{{ hourly.forecast }}"
4 Likes
I think this one could blow up into a real *** storm in this forum, just like the MQTT nameing issue. It never rains but it pours!
(All puns intended!)
2 Likes