[PETITION] Don't delete the forecast attribute

[arganto]

@petro

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.

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.

[deepcore]

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

[tom_l]

Please read petro’s follow up post, [PETITION] Don't delete the forecast attribute - #222 by petro

[123 (Taras)]

@deepcore

What should/must I do to keep my display working after 2024.xyz??

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.

[arganto]

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?

[petro]

@arganto

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.

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.

@arganto

The quote to the docs are clear (and known) it would trigger even if only state attribute change

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

Last_updated State and last-changed in Lovelace

Ok, so this is where things get funky. You should familiarize yourself with home assistant state objects. This is what home assistant passes around when doing pretty much anything. These state objects contain 8 or so properties. Do not get these properties confused with the devices attributes. These properties are: Field Description state.state String representation of the current state of the entity. Example off. state.entity_id Entity ID. Format: .<object_id>. Example: light.…

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.

[arganto]

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.

[petro]

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.

[arganto]

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.

[boheme61]

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

[petro]

@arganto

No not 100%, but only in assumption that everything else will >95% change at least in between and therefor trigger

Yep.

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.

[arganto]

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

[pocket (Rob)]

@petro

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).

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.

[boheme61]

@pocket

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

[markpurcell]

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: ?

[arganto]

@markpurcell

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.

[petro]

Just make a sensor

template:
- trigger:
  - platform: time_pattern
    minutes: 1 # 1 minute past the hour, every hour
  action:
    - service: weather.get_forecast
      target:
        entity_id: weather.noosa_heads_hourly
      data:
        type: hourly
      response_variable: hourly
  sensor:
  - 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 }}"

[markpurcell]

@petro

Just make a sensor

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

[tarheelz]

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.)

[Tinkerer (aka DubhAd on GitHub)]

@tarheelz

Does this count as signing the petition?

That’d be more:

1. Vote at the top
2. Be more constructive