Here’s an example that may help clarify things:
This triggers on all state and attribute changes:
trigger:
- platform: state
entity_id: weather.home
This only triggers on state value changes:
trigger:
- platform: state
entity_id: weather.home
to: # null 'to:'
my home_hourly forecast attribute has 4644 characters including blanks. Seriously, is it worth it? How many forecasts do you have? We are talking 10KB tops. And to make this change, special action for templates was introduced just to synchronously get data that we have asynchronously right now. And we still need that forecast state to discover state changes for future weather.
Are you here to just argue or find a solution? There’s already talks of long term solutions to get the information directly from a template without an action.
I’m just passing on the rationale I have learned from the developers I was not involved in the decision.
Personally I run HA on highly over specified hardware and fast internet and see no noticeable improvement from these or other changes like moving to LTS graphs instead of state graphs (even though I have many dashboards that are heavy with fast updating data graphs).
However, Home Assistant is supported for single board computers with much less computing power and not everyone is blessed with 100MB/s+ internet speeds.
This is why the changes are being made. To make home assistant a better experience for everyone, even those on low end hardware and internet.
To (potentially) add an aspect to the conversation, packed into a question:
For ESPhome I currently use the text_sensor with the attribute: option to pull in forecast data for my hallway display.
text_sensor:
- platform: homeassistant
id: outside_weather
entity_id: weather.home
internal: true
- platform: homeassistant
id: owm_forecast
entity_id: weather.openweathermap
internal: true
attribute: forecast
(details in How to "clone" a weather entity into a template sensor, with less datafields? - #6 by Lakini)
This is a single step, and then I pull the needed infos from that sensor inside ESPhome via JSON extraction. I don’t have to setup anything on the HA side for this, besides the weather entity itself.
With the forecast attribute being removed, would I then have to setup an additional automation in HA that occasionally pulls the forecast data and writes it into a template sensor? Or is there a new way of interacting with ESPhome with this new approach that I didn’t stumble into yet?
I understand what a state is. Look
< template TemplateState( < state weather.home = partlycloudy; temperature = 25.6, temperature_unit = °C, humidity = 52, cloud_coverage = 25.8, pressure = 1026.7, pressure_unit = hPa, wind_bearing = 45.9, wind_speed = 7.9, wind_speed_unit = km / h, visibility_unit = km, precipitation_unit = mm, forecast = [{
'condition': 'partlycloudy',
'datetime': '2023-09-07T10:00:00+00:00',
'wind_bearing': 45.9,
'temperature': 25.6,
'templow': 17.4,
'wind_speed': 10.8,
'precipitation': 0.0,
'humidity': 52
}, {
'condition': 'partlycloudy',
'datetime': '2023-09-08T10:00:00+00:00',
'wind_bearing': 192.5,
'temperature': 25.4,
'templow': 14.6,
'wind_speed': 9.4,
'precipitation': 0.0,
'humidity': 58
}, {
'condition': 'partlycloudy',
'datetime': '2023-09-09T10:00:00+00:00',
'wind_bearing': 45.2,
'temperature': 24.5,
'templow': 13.9,
'wind_speed': 12.2,
'precipitation': 0.0,
'humidity': 64
}, {
'condition': 'sunny',
'datetime': '2023-09-10T10:00:00+00:00',
'wind_bearing': 160.5,
'temperature': 25.7,
'templow': 13.9,
'wind_speed': 10.8,
'precipitation': 0.0,
'humidity': 56
}, {
'condition': 'partlycloudy',
'datetime': '2023-09-11T10:00:00+00:00',
'wind_bearing': 278.1,
'temperature': 26.8,
'templow': 16.9,
'wind_speed': 7.9,
'precipitation': 0.0,
'humidity': 49
}, {
'condition': 'cloudy',
'datetime': '2023-09-12T10:00:00+00:00',
'wind_bearing': 161.1,
'temperature': 27.1,
'templow': 16.5,
'wind_speed': 7.9,
'precipitation': 0.0,
'humidity': 46
}
], attribution = Weather forecast from met.no, delivered by the Norwegian Meteorological Institute., friendly_name = Forecast home @ 2023 - 09 - 07T10: 49: 15.543991 + 02: 00 > ) >
Your example is wrong because you assume that when forecast changes something also changed on weather. So which attribute was that? Plain weather polling makes it change state or what? There’s no magic in there and you sound like it’s rocket science.
I’m here to make a point that forecast is not ephemeral or not important data. It’s a state of weather exactly the same as current weather state.
That’s it. Thank you for discussion.
And as a personal side note, some time ago we had an argument about template trigger sensors not keeping it’s state after restart. I was saying it’s bad and it should not work that way. You said it’s just how it is and was arguing it’s the best we can get. Fast forward couple of months and we have template triggers with restored values. Because it’s reasonable to have that. Hope it will also be reasonable to have forecast state some day.
The first option.
It is not wrong. State objects, especially weather update on a polling frequency. The polling frequency for them is either 5 minutes or on the hour (depending on the integration). All attributes on these change regardless of said frequency for the current conditions. The forecast will only update at most once an hour (if you’re using hourly). It does not dynamically change like you think it does, it never has, it has always been limited. Especially on the daily forecasts like you’re showing above, which are only grabbed once a day.
You are not losing any resolution.
Yes, trust me, I notice the trend when talking with you. Just keep in mind that information providers (me) are not the ones who made the decision, nor are they the ones who will make a future decision. We are in the feature request section. Anyone can add something to the software in the future. At the time of the argument, I’m sure what I said was the best we could get. That’s the thing about the future, it’s unpredictable.
So you do you and allow me to make my reasonable points about decisions already made or future decisions that may or may not consider my input.
And thanks for clarification about the weather state - that’s the kind of information I could seek here from you since it’s not easily accessible without reading the code. Personal opinions about things you think I know or think is useless to anybody. Cheers.
Most probably I’m too stupid as well. Can you give one attribute which would trigger the state trigger if the state is as before and only the attribute would have been changed/updated, which are not available anymore.
The quote to the docs are clear (and known) it would trigger even if only state attribute change. But this attribute wich might be change is not there anymore. Or/Wich is another attribute of e.g. weather.home, which changes 1:1 currently when the forcast attribute would trigger, so that your examples would work as expected. BTW thanks for them! 
… here for me only technical interest. I can live with a periodical trigger as well but ofc would like to know, why your eyamples would work without periodical trigger, wich I always want to avaiod.
So I am stuck, and I must be stupid as hell…
I have built this summer an e-paper display for the weather forecast of the next 5 days. I had more than a hard time to get the Waveshare 4.2in 3-color display working on ESPhome, finally pulling in from someone else the patched ESPhome display code that won’t make it’s way into HA ESPhome.
Now I have this big chunk of template code to get the forecast data into my display. What should/must I do to keep my display working after 2024.xyz??
- trigger:
- platform: time_pattern
seconds: 0
minutes: /1
sensor:
- name: e-paper display data
unique_id: e_paper_display_data
icon: mdi:wallpaper
availability: "true"
state: "OK"
attributes:
weather_condition_now: >
{% set cond_now = states('weather.dwd_weather_buchholz') %}
{% if states('sun.sun') == 'below_horizon' %}
{% if cond_now == 'sunny' %} night {% elif cond_now == 'partlycloudy' %} night-partly-cloudy {% else %} {{ cond_now }} {% endif %}
{% else %}
{{ cond_now }}
{% endif %}
weather_temperature_now: >
{{ states('sensor.outdoor_environment_temperature') | round(1) }}
weather_templow_today: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[0].templow | round(0) }}
weather_temphigh_today: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[0].temperature | round(0) }}
weather_rain_today: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[0].precipitation | round(1) }}
weather_rain_prob_today: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[0].precipitation_probability | round(0) }}
weekday_today: >
{% set weekday_long = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', 'Freitag', 'Samstag', 'Sonntag'] %}
{{ weekday_long[now().weekday()] }}
today_date: >
{{ now().date() }}
weather_condition_1: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[1].condition }}
weather_templow_1: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[1].templow | round(0) }}
weather_temphigh_1: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[1].temperature | round(0) }}
weather_rain_1: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[1].precipitation | round(1) }}
weather_rain_prob_1: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[1].precipitation_probability | round(0) }}
weather_day_1: >
{% set days = ['MO', 'DI', 'MI', 'DO', 'FR', 'SA', 'SO'] %}
{{ days[as_timestamp(state_attr('weather.dwd_weather_buchholz', 'forecast')[1].datetime) | timestamp_custom('%w') | int -1] }}
weather_condition_2: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[2].condition }}
weather_templow_2: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[2].templow | round(0) }}
weather_temphigh_2: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[2].temperature | round(0) }}
weather_rain_2: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[2].precipitation | round(1) }}
weather_rain_prob_2: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[2].precipitation_probability | round(0) }}
weather_day_2: >
{% set days = ['MO', 'DI', 'MI', 'DO', 'FR', 'SA', 'SO'] %}
{{ days[as_timestamp(state_attr('weather.dwd_weather_buchholz', 'forecast')[2].datetime) | timestamp_custom('%w') | int -1] }}
weather_condition_3: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[3].condition }}
weather_templow_3: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[3].templow | round(0) }}
weather_temphigh_3: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[3].temperature | round(0) }}
weather_rain_3: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[3].precipitation | round(1) }}
weather_rain_prob_3: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[3].precipitation_probability | round(0) }}
weather_day_3: >
{% set days = ['MO', 'DI', 'MI', 'DO', 'FR', 'SA', 'SO'] %}
{{ days[as_timestamp(state_attr('weather.dwd_weather_buchholz', 'forecast')[3].datetime) | timestamp_custom('%w') | int -1] }}
weather_condition_4: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[4].condition }}
weather_templow_4: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[4].templow | round(0) }}
weather_temphigh_4: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[4].temperature | round(0) }}
weather_rain_4: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[4].precipitation | round(1) }}
weather_rain_prob_4: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[4].precipitation_probability | round(0) }}
weather_day_4: >
{% set days = ['MO', 'DI', 'MI', 'DO', 'FR', 'SA', 'SO'] %}
{{ days[as_timestamp(state_attr('weather.dwd_weather_buchholz', 'forecast')[4].datetime) | timestamp_custom('%w') | int -1] }}
weather_condition_5: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[5].condition }}
weather_templow_5: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[5].templow | round(0) }}
weather_temphigh_5: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[5].temperature | round(0) }}
weather_rain_5: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[5].precipitation | round(1) }}
weather_rain_prob_5: >
{{ state_attr('weather.dwd_weather_buchholz', 'forecast')[5].precipitation_probability | round(0) }}
weather_day_5: >
{% set days = ['MO', 'DI', 'MI', 'DO', 'FR', 'SA', 'SO'] %}
{{ days[as_timestamp(state_attr('weather.dwd_weather_buchholz', 'forecast')[5].datetime) | timestamp_custom('%w') | int -1] }}
I am really annoyed (to not use another word) now about this decision
Please read petro’s follow up post, [PETITION] Don't delete the forecast attribute - #222 by petro
Add an action section to your existing Trigger-based Template Sensor that calls the new weather.get_forecast service.
The service call reports its results in response_variable which can then be referenced by your templates in weather_temperature_now, weather_temphigh_today, etc.
For examples, refer to the documentation or up above in this topic.
There are many months between now and March 2024 so it’s possible that there may also be other ways to do it by then.
Assuming you make the suggested changes and if my understanding is correct, starting with version 2024.3.0, that Time Pattern Trigger will poll your weather provider every minute.
That seems excessive so you may wish to reconsider the choice of frequency.
Ofc read this before. Sorry, I cannot see the attribute there which would change. Or get your answer wrong.
Exampe
temperature: 26.7
temperature_unit: °C
humidity: 47
cloud_coverage: 0
pressure: 1021.5
pressure_unit: hPa
wind_bearing: 105.7
wind_gust_speed: 29.9
wind_speed: 14.8
wind_speed_unit: km/h
visibility_unit: km
precipitation_unit: mm
forecast:
- condition: sunny
would currently change to
temperature: 26.7
temperature_unit: °C
humidity: 47
cloud_coverage: 0
pressure: 1021.5
pressure_unit: hPa
wind_bearing: 105.7
wind_gust_speed: 29.9
wind_speed: 14.8
wind_speed_unit: km/h
visibility_unit: km
precipitation_unit: mm
forecast:
- condition: cloudy
Everything (visible) is same as before, all other attributes and the state.
So what and why would trigger
trigger:
- platform: state
entity_id: weather.home
without the change of forecast?
afaik the trigger would only trigger on any change (state and attributes) and not on any update (regardless of any change), wouldn’t it?
if you have a binary_sensor that tells you when your battery is low, but it also has an attribute for battery level. E.g.
state: off
attributes:
battery_level: 95
If you have a trigger that is
- platform: state
entity_id: binary_sensor.xyz_battery_low
it will trigger when the attribute battery_level changes or when the state changes. Both are part of the state object. Any change on the state object will cause the trigger to fire when you do not include to, from, etc.
The docs say that it looks at the state object when you only provide an entity_id. So any attribute change, property change, or state change, will cause it to trigger.
See this post for more info on state objects
EDIT: Weather entities have a ton of attributes that can change that will cause a trigger.
lastly, as a sidebar, there also were talks about adding a forecast trigger during beta, similar to the calendar event trigger. There was no pushback against this idea, so anyone is welcome to make it happen.
Most probably because of my English, we are talking about different things. I understand your example. It would trigger, because battery_level is changing.
But can you have a look at my example above (which contains all current attributes of my weather.home) and explain why it would trigger without forcast attribute (which is the only one which would change in this example)? This (and only this) is what I don’t understand.
because weather entities have a ton of attributes that are gathered from the normal (non-forecast) calls that are more frequent than the forecast calls.
My example shows all attributes which I can see in dev tools. Because of that my question. There are no more tons of other attributes (and even this would then not a technical reason but only the assumption/hope that anything else would change). Therefor my question which attribute of e.g. met.no would change and trigger 100%?
I don’t care about the usecase, Nor pushing it back. Don’t have a clue why a technical question to understand background is pushed in this direction now.
I only want to understand it, why it is technically the case that it is 100% triggering without the forecast-attribute-upate (if state and the other attributes in my example stay as before). If you are sure, why it is not possible to explain it?
If the answer is: No not 100%, but only in assumption that everything else will >95% change at least in between and therefor trigger, completely fine, but then the ultimateness in the answers above that it will trigger by design and not only by hope is perhaps not right from a programming point of view.
Im not sure what you mean, but in your example the condition: changed from “sunny” to " clouded" , maybe a “hickup” or not relevant to your context, but every hour the next coming “forecast-condition”, will become “current-condition” etc , but that will always occur, regardless if the forecast is an Attribute to “Current-Entity”, but if it’s currently build so the this/these changes “wipe the table” so to speak, and write the whole thing again, Current + All Attributes, not ( -1"old/staled" + 1 “new” ) all states(attribute.state) changes every hour , no matter what .
Im not a programmer, and i know ofcause not much about the functionality within HA and its components, And the DB type ( time-serie ) but the State here is the conditions, not the “datetime”, which in this case i would find most logic in a forecast