Sure? Here it is metno, but I’m pretty sure that I never added it and that it was there directly after installation years ago.
And I doubt, that 80% of all installations all added it by chance all manually.
That may have been the default at the time. It may be the default integration now. Regardless, that integration would need to cache the forecast. Caching forecast is not a requirement. It’s done in accuweather because there is an api per day limit.
But if the weather card with the default weather provider now only show only an error message instead of a cached forecast, it is really a disadvantage.
Beside that I think, that is not a good idea to call the forecast service online now every display of the weather card.
Ok? Make a feature request for that integration.
… and because for this I ofc wanted to doubleck before that it is not only a problem here, but
a. not cached for the default weather integration and different to all who mentioned this function at the beginning of the change and
b. that (with cached integration, as you mention) a card with
- type: weather-forecast
forecast_type: daily
show_current: true
show_forecast: true
entity: weather.home
would use this and still show a state nd forecase (as before) even if the internet connection is just not there on_display of a dashboard with this card. Is this the case with your weather integration?
No idea, I don’t use weather cards. I just use things for automation purposes.
might be real peculiar, but I think it’s fair to ask ourselves why we are fuzzing about this…
I had setup the complete replacement with the get.weather_forecasts for all of my weather integrations, and did heavy templating on them.
After which I realized, those data points were in fact hardly used by me (looking at the Dashboard), or by the other backend configs. Ok, I had a apexcharts card using 3 details (min/max/rain) but other than that?
So, as an experiment, I decided to comment all of that and try and live with the core functionality of the current weather integration, use only 2 weather forecast cards and see if I could live with that. Whether I would really miss the previously so abundantly available data in my system.
Would the existing more-info forecast on those cards suffice.
Guess asking the question is answering it… I dont need it, and I havent looked back ever since I disabled them. yes, the more-info currently suffices. Making the weather info in my HA config ultimately easy.
Again, not arguing against the PR/FR here, just an honest reflection.
1 Like
Don’t get, what you want to say. Good, you don’t need it, but as said,
The new way is now calling the web-service in fact every time the weather card or a dashboard with it is displayed, what is really the opposite to every other argument (data/webcall-thrift) here for several other topics (scan_interval, …)
And for those (forecast-e-ink-displays, weather-card on dashboard, automation and scripts with forecast data, warnings) they all need the forecast, most of them rebuilding them and then have them again as before in the attributes and state machine.
Beside, that the weather card is not showing anything anymore on internet drop (which is unfortunately often here the case) I’m completely fine with the removement and the services and to rebuild mine, etc. But to I really expected, that this and met.no is using a cache for this purpose
sorry…
I guess this: I’d be surprised if all of the responders actually need the forecast attribute.
or is it like what I felt before: I want to keep things like they were.
And if you really do need it, it’s 1 step extra, and explained over and over again, so, nothing left to discuss there either.
Sure, it’s a bit more complex than before, and sh/could have been done more community friendly.
Now it’s gone though, nothing we can do?
ofc that is a very valid observation. is there an open issue/fr for that? Wouldn’t that be more useful to focus on (if not already happening in the architectural discussions)
1 Like
Sure, it’s a bit more complex than before, and sh/could have been done more community friendly.
Now it’s gone though, nothing we can do?
Users can continue to voice our need for clear examples/documentation that are regularly maintained and updated. I am a software developer and have experienced nothing but problems attempting to get a weather forecast from the US National Weather Service (NWS) integration. A few months ago, I updated a voice assistant automation, and it was working as expected again. Now, it’s no longer working, and the only clue I have from the automation traces is a cryptic response:
Executed: June 25, 2024 at 07:49:03
Error: Service call requested response data but did not match any entities
Perhaps someone could explain this message is too generic, and doesn’t provide any cause or diagnosis of the error.
Look in your logs, the text logs. Not the UI logs. The context is always there.
I see what you mean about the UI logs. They provide very little useful information. 
Logger: homeassistant.helpers.script.trigger_update_coordinator
Source: helpers/script.py:2001
First occurred: 07:30:00 (12 occurrences)
Last logged: 08:25:00
Trigger Update Coordinator: Error executing script. Error for call_service at pos 1: Service call requested response data but did not match any entities
So, you’re recommending to SSH into the system and grep/tail/view the actual Linux log files? Although I am a software developer, and well-versed in Linux, with respect to Home Assistant, I am an end user. I do not think it’s unreasonable to expect more helpful/useful error responses from the HA GUI logs.
Use File-Editor or what ever ( I.e Settings/system/Logs ! ) to analyze your logs
Very Convenient if You are " An End-User " …Since 2019
I encourage you to look around the interface before getting upset and posting here. Scroll down on the log page and use either of the buttons to view the text logs.
Please post the YAML of your first service call in the automation that’s erroring.
1 Like
I made a write-up about the main problems with having any data in a service (including the weather forecast data) and possible solutions the home assistant team could implement. Would love for anyone here to add to or verify anything I said or vote if you agree.
Hi Folks!
Can you please give me advice to make this work:
action:
- service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.pirateweather
response_variable: pirate-valasz
- service: input_number.set_value
data_template:
entity_id: input_number.weather_pirate_esso_esely
value: "{{ pirate-valasz['forecast'][0]['precipitation_probability'] }}"
change - to _ in both places.
1 Like
Also, weather.get_forecast has been deprecated, you need to use weather.get_forecasts:
action:
- service: weather.get_forecasts
data:
type: hourly
target:
entity_id: weather.pirateweather
response_variable: pirate_valasz
- service: input_number.set_value
data_template:
entity_id: input_number.weather_pirate_esso_esely
value: "{{ pirate_valasz['weather.pirateweather']['forecast'][0]['precipitation_probability'] }}"
1 Like
I never find it out alone, thank you guys!
Once again, surprised on a cold wintery morning where the heating did not come on. This time, I could have known better, because I knew weather.get_forecast would be deprecated.
Change 1: Use correct service weather.get_forecasts
Since this post, weather.get_forecast has been deprecated, so if you need this now, you will have to change both service calls from service: weather.get_forecast to service: weather.get_forecasts.
Change 2: Adapt template for dictionary format returned by weather.get_forecasts
This will result in the following error messages in the log, since get_forecast returns a dictionary object, which is different to how get_forecast used to return the forecast information:
* Error rendering state template for sensor.weather_hourly: UndefinedError: 'dict object' has no attribute 'forecast'
* Error rendering state template for sensor.weather_daily: UndefinedError: 'dict object' has no attribute 'forecast'
To do so, you need to change
forecast: "{{ hourly_forecast.forecast[:5] }}"
into
forecast: "{{ hourly_forecast['weather.home'].forecast[:5] }}"
and
forecast: "{{ daily_forecast.forecast[:5] }}"
into
forecast: "{{ daily_forecast['weather.home'].forecast[:5] }}"
The updated code, as taken from my configuration.yaml, now looks like this:
template:
- trigger:
- platform: time_pattern
minutes: "*"
- platform: homeassistant
event: start
- platform: event
event_type: event_template_reloaded
action:
- service: weather.get_forecasts
target:
entity_id: weather.home
data:
type: hourly
response_variable: hourly_forecast
- service: weather.get_forecasts
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['weather.home'].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['weather.home'].forecast[:5] }}"
Happy heating 
2 Likes