[PETITION] Don't delete the forecast attribute

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! :+1:

… 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
    - name: e-paper display data
      unique_id: e_paper_display_data
      icon: mdi:wallpaper
      availability: "true"
      state: "OK"
        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.


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.


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
- 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
- condition: cloudy

Everything (visible) is same as before, all other attributes and the state.

So what and why would 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
  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.

1 Like

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


Basically, if you if you have hourly forecast, the [0] item moves into the weather attributes when the hourly will change. I.e it will change. Most of these integrations only update on a polling frequency and the likelihood of the above case is extremely low based on how the data will move through the forecast to the other attributes. I’m sure there are some weather integrations that might be an exception, but most work this way.


Thanks. Then I get it, what you and Tom wanted to point out.

It sounds like there’s only one polling interval per integration. Correct? That is, given a 5-minute interval, it’s doesn’t seem of practical value to do both because it would use up more of a fixed allocation of requests.

This is also something that could be taken into consideration, i.e Requirements upon Weather-integrations/Weather-cards, optional updates intervals, whether it’s template/entity or remote-API-call, … options to set update value, as it’s most often an “individual requirement/need”, which some are using for other entities/devices//automations/templates/purposes. the more one stuff into i.e the DB( State-engine ) , and the more people want in their views, and the more their Recorder “stores” etc, all individual factors, out of control from the Devs.
People have to remind them self, that it all comes with a cost

Ohh well i guess this is just what this Topis is :laughing:

Trying to get my head around these changes.

I like to count how many hours in the next 24 forecasts are going to be over a set point, so I know how many hours to run my air conditioner, which I do in one line of YAML:

To do the same thing now, do I need a trigger: action: and sensor: ?


yes. Or an automation with action and condition. Depending on the use case.

Just make a sensor

- trigger:
  - platform: time_pattern
    minutes: 1 # 1 minute past the hour, every hour
    - service: weather.get_forecast
        entity_id: weather.noosa_heads_hourly
        type: hourly
      response_variable: hourly
  - name: Hours Above Set Point
    unique_id: hours_above_set_point
    state_class: measurement
    unit_of_measurement: count
    state: "{{ hourly.forecast[:24] | selectattr('temperature', '>=', states('input_number.emhass_deferrable3_set_point') | int) | list | count }}"
1 Like

Thanks for your help and the clarification, does seem a bit regressive.

This sucks. (Does this count as signing the petition?)

(I’d type more but I need to allocate that time to re-writing a ton of shit.)

1 Like

That’d be more:

  1. Vote at the top
  2. Be more constructive :stuck_out_tongue: