You have to use this service to get the forecast now:
https://www.home-assistant.io/integrations/weather/#service-weatherget_forecast
You don’t need to if you are only displaying the forecast in the core weather card, it will call the service for you. Other third party weather cards may need to be updated to call the service when they are viewed.
However you don’t need to use that service if you want access to the data as you already have it available in your restful sensor attribute.
This brings us back to my question, how do I create the “response_variable” so I can use the service. Everyone says this must work, but it does not.
service: weather.get_forecast
target:
entity_id: weather.home
data:
type: daily
response_variable: weather_forecast
You.
Don’t.
Have.
To.
All your forecast data is available in your rest sensor for you to use whenever you want. No service call required.
But if you really must, try supplying your weather entity instead of the one provided in the example.
service: weather.get_forecast
target:
entity_id: weather.home_weather_station # <- this is your weather entity
data:
type: daily
response_variable: weather_forecastI think the OP has a bit of a point. If I understand things correctly, he’s using a weather template sensor:
I don’t think the new way of implementing forecasts took that template sensor into account when introducing forecast services. I don’t quite see how that template weather sensor will support the new service call, unless it is going to parse the deprecated attributes to implement the service, which is the world upside down. So the weather template entities will not be compatible with other weather integrations, unless it has a way to implement the service.
The OP can, as you suggested, revert to calling the rest service to get at the forecast, but that won’t be compatible with the weather service call and it won’t use caching as discussed in the other topic (but for a local weather station it probably won’t be a problem).
If I’m rigt then this all means that his weather template sensor won’t be able to drive the weather cards that use the service to get at the forecast, unless as I said before, template weather sensors use the attributes (which are flagged deprecated) to drive the service call, or the template offers a way to implement the forecast service by calling the rest interface.
But maybe the template entities use the attribute to implement the service, even though that is a bit backwards.
Im guessing it parses the supplied forecast_daily/horly_template option, otherwise there would be no point in supplying it.
Yes that’s right, I use the Template Weather Provider Sensor, with this I show the values of my weather stations and enrich the missing information like the forecast with data from Swissmeteo.
Now came release 2023.9 with the note that the way how to include the forecast is changing. Good…I thought I’d take a look at the issue. And that’s where my questions start, how exactly is this supposed to work?
forecast_daily_template:"{{ state_attr(‘weather.my_region’, ‘forecast’) }}"
from the documentation doesn’t work, are certain records missing? If so which ones?
A creation of a new sensor that I can use in the UI for testing purposes to use the service does not work. In different ways I tried to make the sensor visible with the prediction data, nothing works.
Documentation on how to deal with this: there is none. I have so far only 3 different approaches but nothing completed but the error in the log that “forecast_template” must be out of the template.
This just makes it a mystery how to deal with it (until spring).
It’s ok if you forgot something maybe, but then the developers should write it somewhere, something like “template sensors will still be adjusted in the next releases” Or it’s like tom_l writes a magic 
Well, I’ll try tom_l his way.
Yes it does.
You just don’t get to see the data as an attribute. You have to call the service to use it.
Did you try the corrected service I posted?
Have you tried your weather entity in a core weather card?
Do you see the forecast there?
Not yet, the child must go to bed 
core weather card? you mean this?
This a my Template Sensor (with legacy forecast)
When you get a chance update your sensor to use the new forecast option and see if the card changes.
You don’t need to call the service in the card. The card has been updated to do that automatically.
Just put your newly made entity there, the one that has no forecast attribute.
Do you still see the forecast in the card?
Please start a separate topic as opposed to jumping into this one. Answering two different people’s questions in the same topic can get confusing.
What is the template you used in forecast_daily_template?
If that’s the template you used then I suggest you change it to this:
forecast_daily_template: "{{ state_attr('sensor.weatherdatafrom8805wae', 'forecast') }}"
Be sure to execute Developer Tools > YAML > Reload Template entities after making any changes to the configuration of weather.home_weather_station.
After you make the suggested change, post the revised configuration so we can review it.
Oh Shit… 
I have written a huge long text to describe the procedure and at the last screen shot I noticed it, which is actually also not really nice
You have to enable “Daily” and I could swear, because I’ve tried it a dozen times, the part wasn’t showing then. But anyway, it’s there now.
After saving everything is ok
It has not purely coincidentally something to do with the 2023.9.2 update released today?
In any case, thanks for the support, I’ve been dealing with HA for some time and thought myself stupid to make the forecast work. 
So did you keep your existing forecast_template option or did you replace it with forecast_daily_template?
i replace with forecast_daily_template
Good and was it the one I had suggested to you in this post:
forecast_daily_template: "{{ state_attr('sensor.weatherdatafrom8805wae', 'forecast') }}"
(Because you had something else which failed to work)
Yes, it works with it, but as I said that was the first thing I tried, seems the easiest
In which one of your posts did you say that? Because it’s hard to find evidence of it.
Was it in this post where you said you tried it but reported it failed?
In that post, you never explained what kind of template you used.
In a subsequent post you did show the template but it was obviously wrong.
Plus in some posts you mistakenly referred to the option as forcecast_daily_template and it wasn’t clear if that was a typo or if you actually spelled it that way in the configuration.
So in which post did you report trying exactly the same template as what I suggested?
Seems that it did brick my buienradar forcast as the smart home junkie said it is not something he likes, it renders quite a few automations useless, plus my forecast 3rd party cards.
How to get those running again, can I use this service to fill an sensor to run an automation to make a card, pfffff sounds fun, or end of use!
Who comes up with this changes that make things so much harder to work, why not leave running things, running. Same with some integrations in the past, someone thinks they are redundant and scraps them, has there been rounds of asking people what they feel about that. Is there a say in that, it happened too often I feel.
Sorry I think I get a sour piss answer on this it will make someone angry, but things that break running cards, automations and other things happened too often in the past 10 years I use HA.
Sorry Tom_i I guess you do not like this what I say, cause you belong to the people that dream this stuff I know, everything is easy and simple, need no explanation or anything, answer read the blog.
But for things to find in this ever expanding blog, you need the exact phrasing of the problem, you need to search hours through all kind of related but not to point things. Asking is not wanted any more these days, you often get a nasty derogative answer. But Know moderators, buffs and code wonders, we are not all like that, there are a few that needs help.