[PETITION] Don't delete the forecast attribute

Feature Requests
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

320

It will help if you share what you have tried and what your results have been so far.

Without that knowledge, I can only guess, so the first question would be: Do you know whether you have any entity that contains hourly weather information?

You can check in developer tools under „state“ whether you can find any (from your code, I assume you previously had one named weather.barb_s_place_hourly and from my guesswork I assume that is now gone).

Let me know what you find (or do not find), ideally also include more context on what you are experiencing and we will be happy to help.

As a side note, if you are trying some of the suggestions above, and would like to do so in developer tools alone, be advised this might required a multi-step approach as outlined before.

321

Sure I will share more details later but I don’t really remember what I tried because I’m a idiot

I have not been home all day or I would have shared .

The barbs weather {part of met.no} does show the hourly attributes and datetime stamps just like before the changes. I think :face_with_spiral_eyes:
I also have AccuWeather if that is something I can extract hourly forcast from.

I’m not not that up to speed in how to use template with service calls . Not a true geek​:joy::joy:
Once I seen how something is done then I am normally able to learn how to tweek and adjust by using others examples.

Why I was asking for help.
Not a big deal if I can’t get it to work
Just using on a several wall panel to show hourly forecast
Like this (the only old screen shot I could find)

1000001163
1000001163709×1052 229 KB

This is the attributes available showing in developer tools states.

dew_point: 46
temperature_unit: °F
humidity: 82
cloud_coverage: 97.7
pressure: 30.02
pressure_unit: inHg
wind_bearing: 10.9
wind_speed: 4.72
wind_speed_unit: mph
visibility_unit: mi
precipitation_unit: in
forecast:
  - condition: partlycloudy
    datetime: "2024-03-10T19:00:00+00:00"
    wind_bearing: 10.9
    temperature: 51
    templow: 43
    wind_speed: 6.71
    precipitation: 0
    humidity: 82
  - condition: partlycloudy
    datetime: "2024-03-11T19:00:00+00:00"
    wind_bearing: 251.5
    temperature: 56
    templow: 41
    wind_speed: 8.08
    precipitation: 0.04
    humidity: 68
  - condition: cloudy
    datetime: "2024-03-12T19:00:00+00:00"
    wind_bearing: 212.6
    temperature: 53
    templow: 41
    wind_speed: 7.15
    precipitation: 0.16
    humidity: 84
  - condition: partlycloudy
    datetime: "2024-03-13T19:00:00+00:00"
    wind_bearing: 267.1
    temperature: 53
    templow: 32
    wind_speed: 7.83
    precipitation: 0
    humidity: 66
  - condition: partlycloudy
    datetime: "2024-03-14T19:00:00+00:00"
    wind_bearing: 330.8
    temperature: 58
    templow: 45
    wind_speed: 13.17
    precipitation: 0
    humidity: 40
  - condition: sunny
    datetime: "2024-03-15T19:00:00+00:00"
    wind_bearing: 199.6
    temperature: 58
    templow: 41
    wind_speed: 6.03
    precipitation: 0
    humidity: 49
attribution: >-
  Weather forecast from met.no, delivered by the Norwegian Meteorological
  Institute.
friendly_name: Forecast Barb's Place
supported_features: 3

And in service call

1000003488
10000034881344×9051 643 KB

And in entity information

1000003486
10000034861075×2393 245 KB