[PETITION] Don't delete the forecast attribute

Feature Requests
252

Forgive my lack of understanding, but is there any reason HA couldn’t just add a UI drop down menu in the weather integration configuration to select what forecast data is desired (ie high temperatures x5 days) and how often you’d like the forecast data to be refreshed, and keep the truncated forecast data as an attribute instead of using a service call? I’d be fine with twice a day, three times a day, or four times a day refreshes, but I’ll still need to store the relevant forecast data somewhere.

I use the forecast high temperature data in three binary sensor template entities to identify when to open the windows to regulate the indoor temperature with passive air flow. I just moved them from the YAML configuration to the new UI template helper, but it seems I would have to move it back to the YAML to utilize this trigger action template get_weather service call.

I would have to poll the API three times every so often for the same forecast high temperature data instead of pulling it from cache. Although perhaps I could make a new template sensor to get the weather data and store it as attributes for my other binary sensors to reference, similar to the original weather forecast attributes… seems redundant until HA sunsets the original attributes.

I also use the forecast conditions to look for snowfall in the next 48h to warn me in my daily briefing TTS script. It is helpful to know when I come home if it will snow tomorrow so I can wake up early and scrape the frost/ice/snow off the vehicle before I commute to work. I suppose I’d have to use the get_weather service in the automation before this briefing is announced.

253

that’s not how that works, the weather integrations have their own internal caches, it is not calling the api every time.

254

Wait, are you saying the weather data is already cached but the only way to access the cache is through the get_weather service call and not the former attribute?

255

from what I understand it can vary by weather integration, but the weather integration holds the forecast data in an in-memory cache so it does not hit the API every time the service is called

1 Like
256

Hi , I am trying to understand how to use template in an automation that use weather forecast. It does not seem I get the response I am expecting from the automation service call.

The service call in the automation is :
service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.granby_forecast
response_variable: response

The choose function is as follow
conditions:
- condition: template
value_template: ‘{{ response == ‘‘cloudy’’}}’

which fails . Its not possible to debug and see the response from the automation

So testing in developer tool template I have the following:

{% set response = states(‘weather.granby_forecast’) %}
{{response}}
{{ response == ‘cloudy’}}

with result:
cloudy
True

(please note this works very well in the actual automation in the condition field not using the service call as follows: )
condition: state
entity_id: weather.granby_hourly_forecast
state: cloudy
Any clue to help ??

257

The value of the response variable produced by this example:

{% set response = states('weather.granby_forecast') %}
{{response}}
{{ response == 'cloudy'}}

Is nothing like the value of the response variable produced in this example:

service: weather.get_forecast
data:
  type: hourly
target:
  entity_id: weather.granby_forecast
response_variable: response

If you look at the bottom of the page in the Weather integration’s documentation, it shows you what the value looks like. It’s a list where each item in the list represents the forecast for a separate hour (type: hourly) or day (type: daily).

Your Template Condition must specify which item in the list it wants to use and then refer to that item’s condition key.

For example:

- condition: template
  value_template: "{{ response.forecast[0].condition == 'cloudy' }}"
2 Likes
258

Thank you effectively that works .

Might be you can help me further to help myself next time. In the spirit of give me a fish I will be happy for the day , give me a fishing rod and you will make me happy for life.

In debuging in general I try to follow the trace of the error . In this case I wanted to know what is the intermediary value of “response” in the automation call for service . I did check the help page you refer too and tried to use the developper tool template.

With the following :

{% set response = states(‘weather.granby_forecast’) %}
{{ response.forecast[0].condition == ‘cloudy’ }}

Expecting a True value if the response has the same shape as help page suggest , I got UndefinedError: ‘str object’ has no attribute ‘forecast’ .

Any suggestion as to how to see the result of the response variable as provided in the automation as a suspect similar problem might occur for other service call request on other kind of calls .

Agrain gratefully thank you for your time and support .

259

Just use the developer tools services section, you can call the service and it will tell you what the response is

260

You got that error because the template you created is invalid.

You appear to have taken bits and pieces from what I explained and put them together into something that cannot work.

261

Thanks again for you time in replying to above discussion. I did not take bits and piece from your information believe me . I spend many hours before contacting you in testing all kind of alternative in the /developer-tools/template including the solution you provided. Which failed in the /developer-tools/template and I dont understand why??

Interesting I did find a few solution that did work properly in the developper template tool but the result did not in the automation because as you are saying its not the same format as the call service weather forcast.

One of being :
{% set response = state_attr(‘weather.granby_forecast’,‘forecast’) %}
{{ response.condition == ‘cloudy’ }}

My question is in regards to the template developper tool (/developer-tools/template) usage . Is there a way to get the very same response provided by the service: weather.get_forecast in the tool properly. What form should the request be in the tool?

Please, I understant that help page for service: weather.get_forecast at the bottom of the page is providing the format of the service call. To my understanding homeassistant template developper tool is the tool provided to developpers to get to test templates. So I need to be able to get, in the tool, the same result I would get in the automation service call request . Otherwise I cant use that tool. If that was overlook in the developpment of the weather service call , it should be corrected .

So my question is simple . How can I get the same response ( service: weather.get_forcast , entity_id : weather.granby_forecast ) in the template developper tool .

Knowing that the following request is not good then what is :

{% set response = states('weather.granby_forecast') %}
262

The Template Editor is for testing templates. You can’t use it to test service calls and this is a service call:

service: weather.get_forecast
data:
  type: hourly
target:
  entity_id: weather.granby_forecast
response_variable: response
263

Thanks Taras, Fare enough . Noted as this applies to all service calls .

The automation needs a template format to address the data in two steps, call the service, then apply template to its response. And the template cant be tested in the developer testing tool since service call cant be call from the template developer tool.

Acknowledge

264

Yes, it’s the same suggestion that crzynik made about five posts ago. Use Developer Tools > Services. The data produced by executing the weather.get_forecast service call will be displayed in a separate window below the service call.

1 Like
265

hey you online great Taras . Ya I did that saw the result in the service call. But I was confused with the template results . Kept going between the template and tracing the automation . The service call response was no use to help me pin my bug.

All I am saying is should / could be something to think about since both service call and template be use together in all kind of automation it would be ‘nice’ if populating a response variable to a service call be accessible to template . Could be a global variable like lastServiceCall_response . There is certainly a way to do that since the automation is using the response in a template. That could then be tested in template in any forms or ways.

a suggestion…

266

First, thanks for the info on getting the service call integrated into blueprints, this will help my use case a lot.

This is still a step backwards in performance. I publish several blueprints which leverage weather forecasts to display info on the HASPone touchscreens. Currently, the weather entity is set as a trigger, so whenever new weather info is available, the blueprint runs and sends the new info to the display.

The new approach is worse in two key ways:

  • I now have to poll a service at some interval. Previously, my code only ran when it needed to, now it has to run every minute no matter what.
  • I now have to push the result to the display every interval. Blueprints do not allow me to persist any data, so I have no idea what happened with the last trigger, so now I have to push out the new value with every update cycle.

All of this adds up to making overall performance worse, because I’m stuck polling the service call to find updates instead of just being triggered when (and only when) an actual update happens.

267

You make it worst Luma only if your pooling is lower then the actual service provider refresh rate define above. And if you do it faster then you have a benefit of having your data more accurate. In my case I need the automation to run when sun gets up so it will be improvement

Meanwhile I found a solution to my template testing issue since you cant test service results used in a template. You can do a lot of things with templates and a lot of things can go wrong. So you need to be able to see the final result of you template .

In my case what i got from the service call is in the form
forecast:

  • datetime: “2023-09-18T13:00:00+00:00”
    condition: rainy
    precipitation_probability: 80
    temperature: 13
    …

what I need to define my response variable in the template testing tool is a dictionnary in the form. The following is simplyfied version not including forecast first level :

{% set response = ({“datetime”: “2023-09-18T08:56:48.182385-04:00”,
“condition”: “rainy”,
“precipitation_probability”: 0,
“temperature”: 15,
“templow”: 12}) %}
{{ response.condition }}

with result as expected “rainy”

Afterward I can do what I want with the response .
Hope it helps…

268

I got a weather provider to test the service call and I got the following response:

forecast:
  - datetime: "2023-09-18T00:00:00"
    cloud_coverage: 68
    condition: partlycloudy
    temperature: 23.2
    templow: 18.9
    pressure: 1003.8
    wind_gust_speed: 37
    wind_speed: 18
    precipitation: 0
  - datetime: "2023-09-19T00:00:00"
    cloud_coverage: 69
    condition: rainy
    temperature: 18.5
    templow: 14.8
    pressure: 1006.9
    wind_gust_speed: 52
    wind_speed: 25
    precipitation: 1
  - datetime: "2023-09-20T00:00:00"
    cloud_coverage: 65
    condition: rainy
    temperature: 22.1
    templow: 16
    pressure: 1007.2
    wind_gust_speed: 44
    wind_speed: 22
    precipitation: 1

But as I feel not seeing the forest from the woods, I would like to get help about how I can use this response to update my e-paper weather display.

Currently my e-paper display is fed by a template sensor defined as follow:

- 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] }}

The trigger is only there to fill the attributes. The display decides itself, when to update the display, normally when the current outdoor temperature changes.

How can I test it step by step with the testing tools of HomeAssistant?

269

There are currently two service calls that support the use of response_variable and there are likely to be more in the future. They can’t share a common global variable. Anyway, it’s a moot point because Home Assistant doesn’t support global variables.

The most common way to use the Template Editor to test templates with complex data is the one you have mentioned: simply create a Jinja2 variable containing the data.

This is the technique that’s been used, for example, to test templates with the RESTful Sensor integration as well as any other integration that can receive complex JSON data.

Useful tools:

270 
- trigger:
    - platform: time_pattern
      seconds: 0
      minutes: /1
  action:
  - service: weather.get_forecast
    target:
      entity_id: weather.dwd_weather_buchholz
    data:
      type: daily
    response_variable: current
  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: >
          {{ current.forecast[0].templow | round(0) }}

        weather_temphigh_today: >
          {{ current.forecast[0].temperature | round(0) }}

        weather_rain_today: >
          {{ current.forecast[0].precipitation | round(1) }}

        weather_rain_prob_today: >
          {{ current.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: >
          {{ current.forecast[1].condition }}
        weather_templow_1: >
          {{ current.forecast[1].templow | round(0) }}
        weather_temphigh_1: >
          {{ current.forecast[1].temperature | round(0) }}
        weather_rain_1: >
          {{ current.forecast[1].precipitation | round(1) }}
        weather_rain_prob_1: >
          {{ current.forecast[1].precipitation_probability | round(0) }}
        weather_day_1: >
          {% set days = ['MO', 'DI', 'MI', 'DO', 'FR', 'SA', 'SO'] %}
          {{ days[as_timestamp(current.forecast[1].datetime) | timestamp_custom('%w') | int -1] }}
1 Like
271

That request will not be working from 2024.3 on so you need to add you request into an automation instead of a sensor. and test your new template accordingly as I just show above.