Youāre asking about a volunteer, if they know about it. I have no idea.
It will, please learn what a state object is. Also understand that there are other attributes still available on weather entities that are included on state objects. All which will trigger that trigger.
1 Like
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:'
3 Likes
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.
1 Like
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.
3 Likes
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.
6 Likes
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.
4 Likes
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
1 Like
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.
NOTE
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.
EDIT
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.
3 Likes
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.
2 Likes
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.
1 Like