How to migrate from weather integration approach to new weather.get_forecast service?

[Michael_K001 (Michael Klaas)]

I have a beginner question on the migration path for conditions in automations using the weather forecast data.
The setting:
To automate my window blinds I use the weather forecast (cloudy, sunny, …) and the forecast temperature as a condition when running automations. All automations where created via UI and therefore the attributes for the weather entities could be selected in German.
That all worked fine, but if I understand the documentation of the 2023.9 update correctly, this will stop working with the weather.get_forecast service in the future.

I’m not sure that I fully understand on how to migrate to the new service approach.

I created a new template sensor:

- trigger:
    - platform: time_pattern
      hours: /1
  action:
    - service: weather.get_forecast
      data:
        type: hourly
      target:
        entity_id: weather.forecast_home
      response_variable: meine_vorhersage
  sensor:
    - name: Meine_Wettervorhersage_stuendlich
      unique_id: Meine_Wettervorhersage_stuendlich
      icon: mdi:weather-cloudy
      state: "{{ meine_vorhersage.forecast[0].condition }}"

Then I used the state of this sensor in the conditions in my automations.
But …
Do I have to create a seperated template (trigger) sensor for each value I want to extract (like temperature or another forecast)?
Is there a way to do this via UI or is YAML the only way?
And as the template sensors are not translated in the UI, the state value is only available in English (‘sunny’ instead of ‘sonnig’) - which means I have to translate all conditions manually hoping to have the correct translation?
This seems a quite complicated process to use weather data in automations, is there an easier way to set this up?

[123 (Taras)]

Configure your Trigger-based Template Sensor like the example shown in the documentation.

Trigger-based handling of service response data

It stores the entire result of weather.get_forecast in a forecast attribute. Afterwards, you can access whatever you want from the forecast attribute’s value.

[Michael_K001 (Michael Klaas)]

Thank you, the sensor is displaying all the forecast data :-).
But when I try to use the state of the sensor in an automation I cannot see any attributes and the available states are only ‘unknown’ or ‘not available’. (If I check the state of the sensor manually, I can see all the data.)

[123 (Taras)]

If you created the example in the documentation, the sensor’s state is a datetime value.

To access the sensor’s forecast data, use the state_attr() function.

[Michael_K001 (Michael Klaas)]

Thanks - it was my bad. I had to change the attributes to the once I wanted and not collect the whole forecast there. It works now!

[123 (Taras)]

You’re welcome!

Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps users find answers to similar questions.

For more information about the Solution tag, refer to guideline 21 in the FAQ.

[mrpetermatyas (warning)]

Dear all, Taras,

I do not know why I get this error message when HA starts:

TemplateError('UndefinedError: 'daily' is undefined') while processing template 'Template<template=({{ daily.forecast }}) renders=4>' for attribute 'forecast' in entity 'sensor.weather_forecast_daily'
20:13:51 – (ERROR) Template
Template variable error: 'daily' is undefined when rendering '{{ daily.forecast }}'
20:13:51 – (ERROR) helpers/template.py - message first occurred at 20:13:51 and shows up 2 times
Error while processing template: Template<template=({{ daily.forecast }}) renders=2>
20:13:51 – (ERROR) helpers/template.py

This is my config:

template:
  - trigger:
      - platform: time_pattern
        hours: "/1"
    action:
      - service: weather.get_forecast
        target:
          entity_id: weather.home
        data:
          type: daily
        response_variable: daily
  - sensor:
      - name: Weather Forecast Daily
        unique_id: weather_forecast_daily
        state: "{{ now().isoformat() }}"
        attributes:
          forecast: "{{ daily.forecast }}"

It seems, it works well btw.

Thank you!

[ValMarDav]

Hi, I use this template too and I don’t have this error. But with the new version of the weather.get_forecasts service (with an s) it no longer works because there is a header that is added to the result. Does anyone know how to solve this problem?

Before with weather.get_forecast

After with weather.get_forecasts

[Olivier1974 (Olivier Toussaint)]

Just add the name of the forecast provider in the name like so:

daily['weather.forecast_shawinigan_sud'].forecast

[mrpetermatyas (warning)]

I think I have different issue. I just would like to use a very basic forecast card.

[ValMarDav]

It works, thank you

[duceduc]

hi. can you provide your working sample.

This is my current working sample, but come march 2024 it will break.

template:
# My Weather Entities Daily
  - trigger:
      - platform: state
        entity_id: weather.my_weather
    action:
      - service: weather.get_forecast
        data:
          type: daily
        target:
          entity_id: weather.my_weather
        response_variable: daily
    sensor:
      - name: My Weather Forecast Daily
        icon: mdi:weather-cloudy
        state: "{{ daily.forecast[0].condition }}"
        attributes:
          forecast: "{{ daily.forecast }}"

[123 (Taras)]

The service call’s name is now plural:

weather.get_forecasts

The new service call lets you get the forecast from multiple weather entities. The response_variable’s structure is slightly different so you have to specify which entity’s forecast you want (even if you only asked for the forecast from one weather entity).

daily['weather.my_weather'].forecast

Example

template:
# My Weather Entities Daily
  - trigger:
      - platform: state
        entity_id: weather.my_weather
    action:
      - service: weather.get_forecasts
        data:
          type: daily
        target:
          entity_id: weather.my_weather
        response_variable: daily
    sensor:
      - name: My Weather Forecast Daily
        icon: mdi:weather-cloudy
        state: "{{ daily['weather.my_weather'].forecast[0].condition }}"
        attributes:
          forecast: "{{ daily['weather.my_weather'].forecast }}"

[mrpetermatyas (warning)]

Thank you for your help here.
Let me step back.
As I have the integration here, is the weather service related config still needed?

The only customization what I need, to round the Celsius values on my cards. This was my original config, which became deprecated.

weather:
  - platform: template
    name: "otthon_rounded"
    condition_template: "{{ states('weather.otthon') }}"
    temperature_template: "{{ state_attr('weather.otthon', 'temperature') | round(0, default=-99) }}"
    humidity_template: "{{ state_attr('weather.otthon', 'humidity')}}"
    forecast_template: >
      {% set ns = namespace(z = []) %}
      {% for x in state_attr('weather.otthon', 'forecast') %}
        {% set ns.z = ns.z +
          [{
          'condition': x.condition,
          'precipitation': x.precipitation,
          'temperature': x.temperature | round(0, default=-99),
          'templow': x.templow | round(0, default=-99),
          'datetime': x.datetime
          }] %}
       {% endfor %}
       {{ ns.z }}

[Nerivec]

The deprecation caused me a bit of grief too. I was using it, among other things, to identify “bad weather” in 24h forecast and store that in template “safety” binary sensors, which I would then use to notify me. But since you can’t use forecast attribute in templates anymore (post-deprecation)…

I devised a new method. State/attribute changes on weather entity will run get_forecasts, identify the same as before, and notify me if needed; no more template sensors, everything’s in one automation.
Be sure to change the timedelta in the last_triggered condition to whatever you want, if you reuse this automation.

[123 (Taras)]

@Nerivec

But since you can’t use forecast attribute in templates anymore…

It’s still available. It will be removed in March.

With this change, the forecast attribute of the weather entity is deprecated, and will be removed in Home Assistant Core 2024.3.

[ValMarDav]

Here is the definition of my new template. I don’t use the same variables, but basically it’s the same code.

template:

# Obtenir les pévisions journalières
          
  - trigger:
      - platform: time_pattern
        hours: /1
    action:
      - service: weather.get_forecasts
        data:
          type: daily
        target:
          entity_id: weather.forecast_shawinigan_sud
        response_variable: previsionsjournalieres
    sensor:
      - name: Prévisions météorologiques journalières
        unique_id: previsions_meteorologiques_journalieres
        state: "{{ now().isoformat() }}"
        icon: mdi:hours-24
        attributes:
          forecast: "{{ previsionsjournalieres['weather.forecast_shawinigan_sud'].forecast }}"

[Nerivec]

I know… but this thread is about migrating, so assuming post-removal support…

[123 (Taras)]

After 2024.3, you can’t use it anymore. Until then, it’s still usable.

[mrpetermatyas (warning)]

Does anyone know what the best practice is here to round the temperature values?
As we can’t use forecast attribute in templates anymore from March.
Thank you!