New weather forecast template

Really interesting. I compared yours with mine, (I’m using met.no) but it doesnt work :smiley:

The only difference I spotted is a difference response_variable. I use response_variable: hourly and then that very variable when filling the sensor…

attributes:
          forecast: "{{ hourly['weather...

Well, as stated the sensor itself gets the correct data, only when it comes to the template weather, its no longer working. I dont know, I leave it for now and get back to it later, assuming it work is being done in the background (hopefully). Meanwhile, I implemented a workaround.in my environment.
Thank you though!

Thanks, got it working.

We discussed and tested with developer of the custom integration.
He managed to fix the data provided via get_forecasts so now the attribute is in needed format.

For some reason it wasn’t working for me either initially. Something that helped me was to set the trigger interval to every 1 minute to ensure that it was updating fast enough for me to test. Later I changed the trigger to hourly.

With some changes your template works for me. Thank you very much!

Trying to get this to work. Used the code from @odwide /odwide and changes to forecast to daily. The sensor works but the weather template doesn’t include the forecast.

Here’s my code:

  - trigger:
      - platform: time_pattern
        minutes: /1
    action:
      - service: weather.get_forecasts
        data:
          type: daily
        target:
          entity_id: weather.forecast_home
        response_variable: daily_forecast
    sensor:
      - name: Weather Daily Forecast
        unique_id: weather_daily_forecast
        state: "{{ now().isoformat() }}"
        attributes:
          forecast: "{{ daily_forecast['weather.forecast_home'].forecast }}"
    weather:
#      - platform: template
      - name: "Home Weather"
        unique_id: home_weather
        condition_template: "{{ state_attr('weather.forecast_home','condition') }}"
        temperature_template: "{{ state_attr('weather.forecast_home','temperature') }}"
        humidity_template: "{{ state_attr('weather.forecast_home','humidity') }}"
        wind_speed_template: "{{ state_attr('weather.forecast_home','wind_speed') }}"
        wind_bearing_template: "{{ state_attr('weather.forecast_home','wind_bearing') }}"
        forecast_daily_template: "{{ state_attr('sensor.weather_daily_forecast', 'forecast') }}"

what am I missing?

btw; I’m really trying to understand what the HA-devs expect as the way-to-work for this… but I fail. The approach here looks a lot like what we had before we had to move to the weather.get_forecasts service. If I look at the docs, I get the impression you now need to create a separate sensor every attribute in the forecast?

Take a look a my screenshots two days ago. What format do you see for your sensor?

As TriStone says, check the format of the get_forecasts response. It should match what he posted.

Okay… works… I was expecting to see the forecast attributes at the weather entity in the developer section…it doesn’t show up there, but if I open the entity itself the weather forecast does show up… so my bad I guess!

Hi all, my watering template stopped working. i tried fix it using this post, but no success. could someone help me fix it? thank you…
here is my original code:

##    - name: "Sprinkler Total Expected Precipitation"
##      unique_id: 94d772a8-ae21-11ed-afa1-0242ac120002
##      icon: mdi:weather-pouring
##      unit_of_measurement: mm
##      state: >
##        {%- set totalprecipitation = 0 | float -%}
##        {%- set ns = namespace() -%}
##        {%- set ns.totalprecipitation = 0 -%}
##        {%- for daypart in range(0, 7) -%}
##        {%- set precipitation = state_attr('weather.openweathermap', 'forecast')[daypart].precipitation -%}
##          {%- set precipitation_probability = state_attr('weather.openweathermap', 'forecast')[daypart].precipitation_probability / 100 %}
##          {% if precipitation_probability > 0 -%}
##            {%- set precipitation = precipitation * precipitation_probability -%}
##          {%- endif -%}
##          {%- set ns.totalprecipitation = ns.totalprecipitation + precipitation -%}
##        {%- endfor %}
##        {{ ns.totalprecipitation | float | round(0) }}

and now im trying to update it with this one:

- trigger:
    - platform: time_pattern
      hours: /1
  action:
    - service: weather.get_forecasts
#      data:
#        type: hourly
      target:
        entity_id:
          - weather.openweathermap
      response_variable: my_forecast

  sensor:
    - name: "Sprinkler Total Expected Precipitation"
      unique_id: 94d772a8-ae21-11ed-afa1-0242ac120002
      icon: mdi:weather-pouring
      unit_of_measurement: mm
      state: >
        {%- set totalprecipitation = 0 | float -%}
        {%- set ns = namespace() -%}
        {%- set ns.totalprecipitation = 0 -%}
        {%- for daypart in range(0, 7) -%}
        {%- set precipitation = state_attr('my_forecast', 'forecast')[daypart].precipitation -%}
          {%- set precipitation_probability = state_attr('my_forecast', 'forecast')[daypart].precipitation_probability / 100 %}
          {% if precipitation_probability > 0 -%}
            {%- set precipitation = precipitation * precipitation_probability -%}
          {%- endif -%}
          {%- set ns.totalprecipitation = ns.totalprecipitation + precipitation -%}
        {%- endfor %}
        {{ ns.totalprecipitation | float | round(0) }}

Could someone check it and point me pls to the right direction? thank you

1 Like

change to

        {%- set ns = namespace(total=[]) -%}
        {%- for f in my_forecast['weather.openweathermap'].forecast if loop.index < 7 -%}
          {%- if f.precipitation_probability > 0 %}
            {%- set ns.total = ns.total + [f.precipitation * f.precipitation_probability / 100] %}
          {%- else %}
            {%- set ns.total = ns.total + [f.precipitation] %}
          {%- endif %}
        {%- endfor %}
        {{ ns.total | sum | round(0) }}
1 Like

Thanks @mrhand I recommend everyone follow the debugging process from @dbs This breaks it down into some simple steps and it will make everything go so much smoother to troubleshoot the exact format that works for your situation.

I do agree with all the comments that this has become way too complicated to setup some rather simple weather sensors.

3 Likes

I’m confused on how to be using this forecast data / call_service setup.

I’ve got a couple of template sensors, one example below, that used a weather integration and the forecast attribute data.

I have a handful of similar sensors like this, each one doing something slightly different, but each processed / logic applied to the data in the forecast attribute.

How should this be migrated to the new format?

Do I need to create new template / weather template sensors? Or something completely different?

- sensor:
    - name: "Next Dry Laundry Day"
      device_class: timestamp
      state: >-
        {% set forecast = state_attr('weather.tomorrow_io_home_daily', 'forecast') %}
        {% set forecast_days = forecast | selectattr('precipitation_probability', 'lt', 40) | map(attribute='datetime') | list %}
        {{ (forecast_days | first) if (forecast_days | length != 0) else 'None' }}
      attributes:
        temperature: "{{ state_attr('weather.tomorrow_io_home_daily', 'temperature') }}"
        humidity: "{{ state_attr('weather.tomorrow_io_home_daily', 'humidity') }}%"
        wind_speed: "{{ state_attr('weather.tomorrow_io_home_daily', 'wind_speed') }}m/s"
        condition: "{{ states('weather.tomorrow_io_home_daily') }}"
        preceipitation_probability: "{{ state_attr('weather.tomorrow_io_home_daily', 'forecast')|map(attribute='precipitation_probability')|first }}%"
        forecast: >-
          {% set forecast = state_attr('weather.tomorrow_io_home_daily', 'forecast') %}
          {% set forecast_days = forecast | selectattr('precipitation_probability', 'lt', 40) | list %}
          {{ forecast_days }}

You don’t need to modify this sensor, but the weather entity that gives you forecasts. Most likely you’ll need to go through the Rubik’s cube of the trigger-based template sensor that polls and processes the forecast for further consumption.

So I understand correctly. Create a new weather template that captures the forecast data via a service call?

Just modify your existing template, it’s really not as hard as others are making it.

- trigger:
  - platform: homeassistant
    event: start
  - platform: state
    entity_id: weather.tomorrow_io_home_daily
  action:
  - service: weather.get_forecasts
    target:
      entity_id: weather.tomorrow_io_home_daily
    data:
      type: daily
    response_variable: response
  sensor:
    - name: "Next Dry Laundry Day"
      device_class: timestamp
      state: >-
        {% set forecast = response['weather.tomorrow_io_home_daily'].forecast %}
        {% set forecast_days = forecast | selectattr('precipitation_probability', 'lt', 40) | map(attribute='datetime') | list %}
        {{ (forecast_days | first) if (forecast_days | length != 0) else 'None' }}
      attributes:
        temperature: "{{ state_attr('weather.tomorrow_io_home_daily', 'temperature') }}"
        humidity: "{{ state_attr('weather.tomorrow_io_home_daily', 'humidity') }}%"
        wind_speed: "{{ state_attr('weather.tomorrow_io_home_daily', 'wind_speed') }}m/s"
        condition: "{{ states('weather.tomorrow_io_home_daily') }}"
        preceipitation_probability: "{{ response['weather.tomorrow_io_home_daily'].forecast|map(attribute='precipitation_probability')|first }}%"
        forecast: >-
          {% set forecast = response['weather.tomorrow_io_home_daily'].forecast %}
          {% set forecast_days = forecast | selectattr('precipitation_probability', 'lt', 40) | list %}
          {{ forecast_days }}

EDIT: Had typo in preceipitation_probability

2 Likes

Thank you, that’s seems way simpler than many of the other suggestions in this thread.

Yes, it’s really nothing crazy if you’re just trying to replicate an existing template sensor.

Just. Wow. I’m STILL struggling to get decent data out of this INSANE change. When literally 100’s of normal non-developer type folks are struggling with something as a result of a major change like this, you have to be a complete idiot (OR a programmer) to argue the new method is “better”. It’s not.

Comments like “it’s really not as hard as others are making it.” aren’t helpful, they are insulting, deprecating and show complete ignorance wrt to the skill level of others.

This entire weather subsystem seriously needs to be revisited. It’s probably the MOST used part of Home Assistant. Sure the default weather card just works, but going just slightly past that to custom cards, displays like OpenHASP, etc, this is a total clusterf…

I honestly can’t think of a single thing the HA dev team has done in the past that was so completely off base and out of touch with the average user base. Yeah, yeah, database size and all. Sure, I get that, but don’t eliminate the ease of use to getting data out of the system. What exists now plain and simple SUCKS.

Write this off at your own risk. People are getting seriously pissed off.
{{end.of.rant}}

9 Likes

I couldn’t agree more. Created a lot of hassle for me and others!

7 Likes