I just think that not many people look into the forum…
Currently over 228100 registered users of this forum.
Anyway, moot point because the forecast
attribute has been eliminated.
Yes I am registered and found this vote today, despite I rant about this problem before via github and made a forum post here…
I am super busy and just getting around to dealing with this change now… I have a couple of automations/scripts that are pulling old forecast attribute data and erroring out. I’ve known since March they stopped working, but just getting to deal with it now. I’m not super advanced here, so please bear with me. Here is an example of script I have running “Good Morning” that is called by a separate automation.
alias: Good Morning
sequence:
- service: alarm_control_panel.alarm_disarm
data:
code: "XXXX"
entity_id: alarm_control_panel.home_alarm
- service: light.turn_on
data:
brightness_pct: 30
color_name: fuchsia
target:
entity_id: light.kitchen_lights
- wait_for_trigger:
- type: motion
platform: device
device_id: a04404d353f445b4b78b838cc103efaa
entity_id: binary_sensor.presence_8
domain: binary_sensor
- service: media_player.volume_set
data:
volume_level: 0.2
target:
entity_id: media_player.echo_plus
- delay: "00:00:02"
- service: notify.alexa_media
data:
data:
type: announce
message: >-
Good morning! It is currently {{states.weather.thermostat.state}} and
{{state_attr('weather.thermostat', 'temperature')}}. Todays high is
{{state_attr('weather.thermostat', 'forecast')[0]['temperature']}} with
a low of {{state_attr('weather.thermostat', 'forecast')[0]['templow']}}.
Now, get out there and kick ass!
target:
- media_player.echo_plus
mode: single
Obviously the service call to notify.alexa_media at the bottom is erroring.
Can anyone point me in the right direction? From skimming 323 relies here, the answer lies in calling a new get weather service, but then what? And can I do that right in the automation/scripts I have, or is this done elsewhere?
Thanks.
call get forcasts as a service directly before your notify.alexa_media. Store the information in a response variable, then get it out in the message.
Thanks. Regarding the “Store the information in a response variable” part of your guidance, can this be done in the script/automation, or does this require making a Helper/Template?
it’s built into the get_forecast service call,
response_variable: my_variable
then later in whatever template…
my_variable[...
I’m guessing I’m missing something really basic here… Here is an example of something.
action:
- service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.thermostat
response_variable: forecast_daily
- service: notify.mobile_app_iphone_13
data:
title: Morning Flash
message: >-
It is currently {{states.weather.thermostat.state}} and
{{state_attr('weather.thermostat', 'temperature')}}. Today's high is {{
forecast_daily['weather.thermostat']['forecast'][0].temperature }} with
a low of {{ forecast_daily['weather.thermostat']['forecast'][0].templow
}}.
Yes, you are missing your “intentions” , for ones , and there are multiple Answers/solutions above in this Topic, so maybe you also “missed” Reading
You are mixing old “way” with “new” way"
.forecast[0].temperature }}
That should work, is it not?
Nah, not working…
websocket_api script: Error executing script. Error for call_service at pos 1: Error rendering data template: UndefinedError: ‘forecast_daily’ is undefined
140710661310784] Error handling message: Error rendering data template: UndefinedError: ‘forecast_daily’ is undefined (home_assistant_error)
that shouldn’t happen, you’re doing something wrong. Are you trying to test this in the template editor? If yes, it won’t work there. You can only test this by running the script.
I’m testing this directly in an automation, by just running that section.
That should work then. Are you getting an error in your logs from the weather.get_forecasts
service? That would cause forecast_daily
to be undefined, which is what your error is saying.
No error when I run only the get_forecasts section of the automation. Says successfully runs (not sure how to check that?). The error seems to be on the next piece, coming from my service: notify… section.
Can you take a screenshot to show how you’re running it?
You can’t run that single action, you have to run the whole automation.
And there it is… I told you I was missing something really basic. I’m used to testing pieces of an automation or script to isolate where an issue is. Works fine if I run the whole thing now.
Thanks, and sorry for wasting your time. I’ve walked away with a few lessons though
Question to the experts: Is my memory wrong or wasn’t it explained that the return value from get_forecasts service is somehow buffered and not every time triggered e.g. if the build in weather card shows the forecast?
I asked because before the values were stored as known in the attributes. And updated on frequently basis, but still available in the time between.
And on case of lost internet connection, they were still there. And the build-in weather card still shown the forecast.
But now, if the internet connect ion lost, the weather card directy show “the entity is currently not avaiulable”. So a. it seems that there is really a web-get-forecast call every single time I open or refresh or change my dashboar, b. the buffering is not in place (what I have in mind) and c. not good to don’t have any value (even not the last known one) on the dashboard (anymore).
Yes, now one can say “how should HA and the user then know” if the forecast is accurate. But as many ones explained in the change process, that the forecast is changing that rare …at least I would like to see a 5 minute old forecast instead of nothing.
And as said, in the past, between the updates, the values were and stayed in the attributes as well and were shown.
BTW: Even if the state of the weather entity (with attributes) was and is still there on e.g. weather. Home, the weather-card does not show anything anymore (beside the error message above), when the internet connection is lost since 2 seconds. Most probably because of a and b above.