[PETITION] Don't delete the forecast attribute

Feature Requests
300

That’s exactly right (for both the get_forcasts change as well as the hourly change). Users that have a few automations with value template elements that were set up entirely through the UI, like this one:

{{ (states.weather.home_hourly.attributes.forecast[3].temperature) | float < 16 }}

… are now not having their heating come on in the morning :cold_face:

And they are rather irritated because the removal of other features (like the counter.configure service) have alerted me with notifications for months, so I was prepared for the breaking change.

I have spent two hours yesterday and another three this morning, trying to find out what the best way forward for me is, and unless I learn multiple complex skills at the same time, I cannot solve this.

Yesterday, I performed the update. My dashboard complained about weather.home_hourly not being available, which I found odd, but when I edited it to weather.home for the time being, there was a new toggle between “daily” and “hourly”, which restored the exact functionality (a fairly smooth experience overall for something considered a breaking change).

This morning, my heating did not come on. In case it is interesting to those that have not been novice users for a long time, here’s my thought process:

  1. Oh. My heating has not come on this morning. Weird.
  2. The automation has not run today. The conditions do not seem to be met. That is odd since it is freezing outside. The value template (as quoted above) is not matching.
  3. The weather.home_hourly entity is still gone. I have previously enabled it manually, the update must have undone that. Huh. No, it is really gone, including the previously-disabled one.
  4. Hm. Others have the same issue.
  5. There are examples in the help, but I am not sure where to put them. Using “Example template sensor using get_forecasts” from the help in a template helper does not appear to be working. It displays as “Unavailable” and states “This template does not listen for any events and will not update automatically.”, which does not seem right.
  6. There are other code snippets offered as ideas but I also do not know where to insert them (can they be put in one or multiple places inside the UI or do I need to edit the configuration files?), or they do not work, even if I account for the renaming of weather.get_forecast.

Overall, I do agree with @FloatingBoater:

Could I ask that someone skilled could point me to the bare minimum of skills I need to learn, please? I am happy to put the work in, but filtering out what concepts I need to build an understanding of (with all the changes that play into this situation) is an insurmountable task for a relative beginner.

1 Like
301

I’ve posted two worked examples not 20 posts above…

You might want to change type: hourly to type: daily.

302

Thank you, and I did see and read this post, but it did not help me much, I am afraid.

That is entirely on me. As I said, I am clearly lacking the overall structural understanding of how to adapt all the examples, which is why I asked for help to gain further understanding in the areas needed.

What I need is a condition to use inside an automation to verify that the temperature in four hours is forecast to be less than 16 degrees.

I currently use a value template for it (as quoted above), and your working example is no direct substitute for that, if I understand correctly.

303

This trigger based template sensor may help you.

You can paste that into your configuration.yaml, with template: before the first line, like:

template:
- trigger:
    - platform: time_pattern
      minutes: "*"
...

Then just change weather.stuttgart_echterdingen to your weather entity, and the other references to Stuttgart-Echterdingen or stuttgart_echterdingen to suit you.

Run a config check and then reload your templates (or restart HA).

1 Like
304

Hi all!

I’m trying to understand templating by copying and editing what I find around the community :slight_smile:

I’m trying to get the temperature and humidity each hour so that I can use it with some messages, I’m using Met.no weather forecast.

This is my template code that is not working:

- unique_id: test_meteo
  trigger:
    - platform: time_pattern
      hours: /1
  action:
    - variables:
        weather: weather.forecast_casa
    - service: weather.get_forecasts
      target:
        entity_id: "{{ weather }}"
      data:
        type: hourly
      response_variable: response
    - variables:
        forecast: "{{ response[weather].forecast }}"
        start: "{{ now().year ~ '-0' ~ now().month ~ '-0' ~ now().day ~ 'T' ~ now().hour ~ ':00:00+00:00'}}"
  sensor:
    - name: my_meteo
      unique_id: my_meteo
      state: >
        {{ forecast | selectattr('datetime', '==', start) | map(attribute='datetime') }}
      attributes:
        temperature: "{{ forecast | selectattr('datetime', '==', start) | selectattr('temperature') }}"
        humidity: "{{ forecast | selectattr('datetime', '==', start) | selectattr('humidity') }}"

The result is that sensor.my_meteo has state = unknown and there aren’t the attributes temperature and humidity

Could someone help me please? :slight_smile:

thanks!

305

Thank you, @Tinkerer, that was an excellent flight level and very helpful in this specific instance.

For the next person running into this, here is a more detailed rundown of what I did to fix my automations:

  1. Here is the precise code I inserted into configuration.yaml:
Code Example (no longer functional) 
template:
  - trigger:
    - platform: time_pattern
      minutes: "*"
    - platform: homeassistant
      event: start
    - platform: event
      event_type: event_template_reloaded
    action:
      - service: weather.get_forecast
        target:
          entity_id: weather.home
        data:
          type: hourly
        response_variable: hourly_forecast
      - service: weather.get_forecast
        target:
          entity_id: weather.home
        data:
          type: daily
        response_variable: daily_forecast
    sensor:
      - name: "Weather Hourly"
        unique_id: home_hourly
        state: "{{ states('weather.home') }}"
        attributes:
          temperature: "{{ state_attr('weather.home', 'temperature') }}"
          dew_point: "{{ state_attr('weather.home', 'dew_point') }}"
          temperature_unit: "{{ state_attr('weather.home', 'temperature_unit') }}"
          humidity: "{{ state_attr('weather.home', 'humidity') }}"
          cloud_coverage: "{{ state_attr('weather.home', 'cloud_coverage') }}"
          pressure: "{{ state_attr('weather.home', 'pressure') }}"
          pressure_unit: "{{ state_attr('weather.home', 'pressure_unit') }}"
          wind_bearing: "{{ state_attr('weather.home', 'wind_bearing') }}"
          wind_gust_speed: "{{ state_attr('weather.home', 'wind_gust_speed') }}"
          wind_speed: "{{ state_attr('weather.home', 'wind_speed') }}"
          wind_speed_unit: "{{ state_attr('weather.home', 'wind_speed_unit') }}"
          visibility: "{{ state_attr('weather.home', 'visibility') }}"
          visibility_unit: "{{ state_attr('weather.home', 'visibility_unit') }}"
          precipitation: "{{ state_attr('weather.home', 'precipitation') }}"
          precipitation_unit: "{{ state_attr('weather.home', 'precipitation_unit') }}"
          forecast: "{{ hourly_forecast.forecast[:5] }}"
      - name: "Weather Daily"
        unique_id: home_daily
        state: "{{ states('weather.home') }}"
        attributes:
          temperature: "{{ state_attr('weather.home', 'temperature') }}"
          dew_point: "{{ state_attr('weather.home', 'dew_point') }}"
          temperature_unit: "{{ state_attr('weather.home', 'temperature_unit') }}"
          humidity: "{{ state_attr('weather.home', 'humidity') }}"
          cloud_coverage: "{{ state_attr('weather.home', 'cloud_coverage') }}"
          pressure: "{{ state_attr('weather.home', 'pressure') }}"
          pressure_unit: "{{ state_attr('weather.home', 'pressure_unit') }}"
          wind_bearing: "{{ state_attr('weather.home', 'wind_bearing') }}"
          wind_gust_speed: "{{ state_attr('weather.home', 'wind_gust_speed') }}"
          wind_speed: "{{ state_attr('weather.home', 'wind_speed') }}"
          wind_speed_unit: "{{ state_attr('weather.home', 'wind_speed_unit') }}"
          visibility: "{{ state_attr('weather.home', 'visibility') }}"
          visibility_unit: "{{ state_attr('weather.home', 'visibility_unit') }}"
          precipitation: "{{ state_attr('weather.home', 'precipitation') }}"
          precipitation_unit: "{{ state_attr('weather.home', 'precipitation_unit') }}"
          forecast: "{{ daily_forecast.forecast[:5] }}"

(This code is based on the mentioned GitHub post and will work without any changes needed as long as you are using the weather.home entity.)

Above code example does no longer work since it still uses the weather.get_forecast service call, which has been deprecated. See my post below for the updated, working version of this code.

This should create an entity sensor.weather_hourly (and also an entity sensor.weather_daily), which should contain the following:

temperature: 5.7
dew_point: -0.7
temperature_unit: °C
humidity: 63
cloud_coverage: 0
pressure: 1016.4
pressure_unit: hPa
wind_bearing: 97
wind_gust_speed: null
wind_speed: 18
wind_speed_unit: km/h
visibility: null
visibility_unit: km
precipitation: null
precipitation_unit: mm
forecast: 
- condition: sunny
  datetime: '2024-03-08T11:00:00+00:00'
  wind_bearing: 98.8
  cloud_coverage: 0
  temperature: 7.4
  wind_speed: 19.4
  precipitation: 0
  humidity: 59
- condition: sunny
  datetime: '2024-03-08T12:00:00+00:00'
  wind_bearing: 96.2
  cloud_coverage: 0
  temperature: 8.6
  wind_speed: 22
  precipitation: 0
  humidity: 54
- condition: sunny
  datetime: '2024-03-08T13:00:00+00:00'
  wind_bearing: 97.5
  cloud_coverage: 0
  temperature: 9.4
  wind_speed: 23
  precipitation: 0
  humidity: 52
- condition: partlycloudy
  datetime: '2024-03-08T14:00:00+00:00'
  wind_bearing: 108.1
  cloud_coverage: 17.2
  temperature: 9.9
  wind_speed: 25.2
  precipitation: 0
  humidity: 50
- condition: sunny
  datetime: '2024-03-08T15:00:00+00:00'
  wind_bearing: 103.3
  cloud_coverage: 0
  temperature: 9.6
  wind_speed: 22.3
  precipitation: 0
  humidity: 51

friendly_name: Weather Hourly
  1. In automations, change the value template. Where I previously had this:
{{ (states.weather.home_hourly.attributes.forecast[3].temperature) | float < 16 }}

I changed into this:

{{ (states.sensor.weather_hourly.attributes.forecast[3].temperature) | float < 16 }}

Note: I had to both change weather to sensor (because the above code does provide an entity of the type sensor while the previous entity was of the type weather) and home_hourly to weather_hourly (because the above code specifies the unique_id as weather_hourly).

Another way would be to use state_attr() as strongly suggested in the documentation:

{{ state_attr('sensor.weather_hourly','forecast')[3]['temperature'] | float < 16 }}

If you test the condition inside automations, please note that if you are running “Test” on a condition while it is disabled, the test will always fail. This did cost me the better part of an hour to figure out.

  1. Save the file, check the syntax, restart Home Assistant.
306

If you do not mind me asking, what is the best way to understand where yaml code may be inserted?

Here is why:

I used to always insert them into the configuration.yaml file.

More recently, there have been a number of breaking changes where configuration in configuration.yaml is being deprecated and subsequently even being ignored (in favour of configuration through the UI). I also noticed more helper types are being made available in the UI.

That led me to believe that the code you told me to insert into configuration.yaml could also be inserted through the use of a template type helper.

However, that does not appear to be the case. How do I tell apart what should work?

307

Try the solution I outlined above, it will provide you with temperature and humidity as well. Do make sure you change weather.home in the code if needed. I believe you might be using weather.forecast_casa.

Should you need more than five hours, increase the number 5 for the home_hourly sensor

forecast: "{{ hourly_forecast.forecast[:5] }}"

as explained on GitHub.

308 
- unique_id: test_meteo
  trigger:
    - platform: time_pattern
      hours: /1
  action:
    - variables:
        weather: weather.forecast_casa
    - service: weather.get_forecasts
      target:
        entity_id: "{{ weather }}"
      data:
        type: hourly
      response_variable: response
    - variables:
        forecast: "{{ response[weather].forecast }}"
        start: "{{ today_at('00:00') }}"
  sensor:
    - name: my_meteo
      unique_id: my_meteo
      state: >
        {{ forecast | selectattr('datetime', '==', start) | map(attribute='datetime') | first }}
      attributes:
        temperature: "{{ forecast | selectattr('datetime', '==', start) | selectattr('temperature') | list }}"
        humidity: "{{ forecast | selectattr('datetime', '==', start) | selectattr('humidity') | list }}"
309

The documentation tells you where to put the yaml. Every single yaml integration has this information in the integration pages on the integration page.

The UI template integration only supports very basic template sensors and template binary_sensors. You can’t put in full configurations like you’re doing.

FYI, you should take a look at this page to understand the difference between yaml and jinja, which is probably what tripped you up in the first place.

1 Like
310

Thank you, @petro! I understand why it did not work, but do let me elaborate on where my confusion stems from, and why I think there is room for improvement.

Could it be that this information is not on every single page? Here is where I looked:

I opened the Weather integration page, then scrolled to the Examples section. There is an example named “Example template sensor using get_forecasts”.

It contains the following code:

template:
  - trigger:
      - platform: time_pattern
        hours: /1
    action:
      - service: weather.get_forecasts
        data:
          type: hourly
        target:
          entity_id: weather.home
        response_variable: hourly
    sensor:
      - name: Temperature forecast next hour
        unique_id: temperature_forecast_next_hour
        state: "{{ hourly['weather.home'].forecast[0].temperature }}"
        unit_of_measurement: °C

(I could have probably easily adopted that code to return forecast[3] and that would have helped me to solve my challenge on my own.)

But the documentation does not state whether this code can be used through the UI template integration and without the additional knowledge that the UI

there is no way for a novice user to recognise that this qualifies as “full configurations” and/or that this code needs to be placed in configurations.yaml to work.

That being said, I actually asked because people post a lot of code snippets in the forum, and usually do not mention whether there is a constraint of where they will work. Take the example mentioned earlier: I tried it in the UI, because that looked like it should work. It does not, and there is no guidance to the user that the UI is severely limited.

311

Thanks now it works :wink:

312

Thanks! I will try it and change something about the values :wink:

313

Yes, it’s implied that it goes into configuration.yaml as-is. All examples are under the assumption that you place them into configuration.yaml unless otherwise specified. And in many cases, it will just say “it goes in configuration.yaml”.

Because you can’t put any yaml into the UI (outside automation/script yaml mode in UI). The UI is for UI adjustments, not yaml adjustments. This is why I linked the difference between jinja and yaml above. You can’t put yaml into the UI but you can put Jinja into the template fields in the UI.

And that’s why you should use the documentation as full examples and treat all posts on the forums as “potentially old or incomplete information”. His post is showing an automation or script action section.

314

Once more, thank you @petro, for tying together the lose ends of my understanding!

I now understand why you posted the links before, thank you for clarifying your intention.

Here is what tripped me up: I did already understand the difference between yaml and Jinja. Missing from my understanding was that a template helper will only accept a much smaller subset of what is stored inside a “full” configuration.yaml template entry.

That used to be the assumption under which I worked, but I stopped being so sure about the implied meaning when I sensed a shift to the UI. I have thought about where this feeling came from and I think this makes little sense from a more advanced perspective. It came from the following two, independent factors:

  1. functionality that was previously configuration.yaml-only is increasingly incorporated into the UI, occasionally with a push to prefer UI, and
  2. some of my integration’s configuration that were previously configuration.yaml-only are being moved to the UI, with removing configuration.yaml support entirely.

In conjunction, they gave me the impression that there was an overall shift from configuration.yaml to the UI, so I expected new UI items to have the intent of replacing the existing configuration.yaml way of doing things.

With the additional knowledge from this conversation, I understand now that there is no such overall shift and that general rule is standing as strong as always.

Agreed. I always prefer the documentation over a forum post from any user with an unknown proficiency level for that exact reason.

In this instance however, it was difficult to find the right starting spot in the documentation, as the documentation does not aim to provide a solution to my question. The documentation is trying to convey the fact that forecasts are no longer available as attributes, but can be retrieved through a service call.

The mismatch between what the documentation conveys (there will be no more attributes) and my question (how do I get attributes back) is so vast that the documentation was simply not helpful for me to determine the best next step.

All that being said, I am well aware of the tremendous amount of work that goes into maintaining the documentation on the level that you do provide it, and I truly appreciate all of it. All I wanted was to point out that the documentation is – by design – not going to be a guide through the complicated change processes ahead of everyone.

If there was one thing that I could suggest going forward, it would be to extend the alerts inside HA going out for deprecated functionality. This would greatly increase the time that users have to adopt before the breaking change occurs.

315

it’s already a 6 month period, that isn’t enough?

316

Apologies, I was not expressing myself all too clearly here.

If I observed the current behaviour correctly, it alerts of upcoming service call depreciations. For example, I have received the following alerts in the past:

  • The counter configure service is being removed
  • Detected use of deprecated service weather.get_forecast

The removal of attributes does not appear to be checked for and alerted about, though.

While I do understand there are good reasons for this change in data architecture, and I do not oppose it at all, I am conscious that for many users with automations their removal will be of similar impact as the removal of service calls, hence my suggestion.

317

so how do you make something like this now work?

        properties:
          "text": >
            {%- if not is_state('weather.barb_s_place_hourly','unavailable') %}
            {%- set update = states('sensor.date') %}
            {%- set midnight = now().replace(hour=0, minute=0, second=0, microsecond=0).timestamp() %}
            {%- set event = as_timestamp(strptime(state_attr('weather.barb_s_place_hourly','forecast')[1]['datetime'], '%Y-%m-%dT%H:%M:%S%z', default='2020-01-00T00:00:00+00:00')) %}
            {%- set delta = ((event - midnight) // 86400) | int %}
            {%- if delta == 0 %}
            Today
            {%- elif delta == 1 %}
            Tomorrow
            {%- endif %}
            {{- event | timestamp_custom(" %-I %p") }}
            {%- endif %}
318

Try using the solution I posted above, and then also change weather.barb_s_place_hourly to sensor.weather_hourly in both places inside your code.

319

The code above is the original way.

I have been playing with the service calls and templates but can’t seem to get it to work in developer tools.
Even using the exact example code on the weather documentation in get errors about hourly.
I will keep poking around