and the log says…yes…you should use the new service
Logger: homeassistant.components.template.weather
Source: helpers/config_validation.py:890
Integration: Template (documentation, issues)
First occurred: 17:38:05 (12 occurrences)
Last logged: 18:10:37
The 'forecast_template' option near /config/_my/weather/cards.yaml:0 is deprecated, please remove it from your configuration
The 'forecast_template' option near /config/_my/weather/cards.yaml:18 is deprecated, please remove it from your configuration
The 'forecast_template' option near /config/_my/weather/cards.yaml:35 is deprecated, please remove it from your configuration
The 'forecast_template' option near /config/_my/weather/cards.yaml:52 is deprecated, please remove it from your configuration
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.
I 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.
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.