… that’s not true. Only the forecast attribute is removed. That code isn’t accessing the forecast attribute.
1 Like
sorry if I miss interprete this then
action:
- service: weather.get_forecast
target:
entity_id: weather.dwd_weather_buchholz
in my case its
service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.granby_hourly_forecast
using direcly weather.granby_hourly_forecast in the template tool is still permitted but does not provide the same result as the service call . Correct me if I am wrong please.
The only thing that was deprecated was the attribute forecast, all other aspects of the weather entities will remain the same. So states('weather.xyz') will still return the current state of the weather sensor.
I miss understood because he is presenting a forecast in his question
forecast:
- datetime: "2023-09-18T00:00:00".....
While his code is using the actual value of weather . Thanks for correcting me Petro that only the forcast data will be obsoleted.
attributes:
weather_condition_now:
Thanks these two tools are great . Using the first tool I removing [ ] bracket set result and getting me the proper Jinja2 dictionary.
"{% set response = (
{
“forecast”:
{
“datetime”: “2023-09-18T13:00:00+00:00”,
“condition”: “rainy”,
“precipitation_probability”: 80,
“temperature”: 13
}
}) %}
{{ response.forecast.condition }}"
result: rainy
many thanks for your help Taras
question for you Petro if you allow me .
in template testing putting {{ states.weather.granby_forecast}}
I get the following which I split in two portion
first portion >
<template TemplateState(<state weather.granby_forecast=rainy; temperature=16.0,
temperature_unit=°C, humidity=91, pressure=1011.0, pressure_unit=hPa, wind_bearing=74.0, wind_speed=2.0, wind_speed_unit=km/h, visibility_unit=km, precipitation_unit=mm,
Remaining data>
forecast=[{‘datetime’: ‘2023-09-18T11:36:49.189328-04:00’, ‘condition’: ‘rainy’, ‘precipitation_probability’: 0, ‘temperature’: 16.0, ‘templow’: 12.0}, {‘datetime’: ‘2023-09-19T11:36:49.189373-04:00’, ‘condition’: ‘pouring’, ‘precipitation_probability’: "
note the first line >
<template TemplateState(<state weather.granby_forecast=rainy; temperature=16.0…
which if I am correct is giving me current conditions. Compare to the second portion which add dates to data .
My question is will all that information be gone with the change or is the first portion still be existing ?
And if it does exist after change then this {{ states.weather.granby_forecast.state }} will always provide me with the information I am looking for.
Great!!! Thank you very very much Petro you just gave me the fishing rod I needed +++
Ok So in my automation I dont need to call the service and assign it a variable. I can still use the automation checking current condition if the following form in the trigger statement >
platform: state
entity_id:
- weather.granby_hourly_forecast
to: snowy
enabled: true
id: snowy
That makes my day … a lot learned from you guy . Gratefully thank you
That’s a string representation of a state object. The only deprecation is the forecast attribute. Meaning, only the forecast.
1 Like
It’s my understanding that only the forecast attribute will be eliminated. The rest of it will continue to exist and be periodically updated by your chosen weather integration.
Ninja’d by petro.
I have a Markdown Card, the first line reading:
{% set forcast = state_attr( 'weather.city_hourly_forecast', 'forecast' ) %}
From that point, I can get forcast[0]-[23] and everything is rainbows and unicorns.
How do I get/make that first line 5 months from now?
Thank you,
MrGrey.
Use the example in the documentation for Trigger-based Template Sensor.
Trigger-based handling of service response data
Assuming you name the new Trigger-based Template Sensor sensor.city_hourly_forecast then your Markdown card will use:
{% set forcast = state_attr( 'sensor.city_hourly_forecast', 'forecast' ) %}
1 Like
Thank you, it’s working perfectly.
For anyone following along, placing the example code in VSCode produced a warning.
I ignored the warning and everything works great. I suspect some validation stuff in VSCode needs updating.
Thank you again,
MrGrey.
If someone still uses a third party weather card that was not updated yet, you can find here template sensors that you can copy and adapt:
They provides the forecast as state attributes and also forward the normal state attributes.
1 Like
Hi,
As a worked example, here’s my update to my previous code query above.
Old
service: tts.google_say
data:
entity_id: media_player.1234
message: >-
Good morning.
It is {{ now().hour}} {{ now().minute }}
and the forecast is {{ states('weather.home') }}
New
action:
- service: weather.get_forecast
data:
type: daily
target:
entity_id: weather.home
response_variable: forecast_daily
- service: tts.google_say
data:
entity_id: media_player.1234
message: >-
Good morning. It is {{ now().hour}} {{ now().minute }}
The forecast is {{ forecast_daily.forecast[0].condition }}.
With a temperature of {{ forecast_daily.forecast[0].temperature|round(1) }}, wind speed of {{ forecast_daily.forecast[0].wind_speed|round(0) }}, and precip of {{ forecast_daily.forecast[0].precipitation|round(0) }}
At {{ as_timestamp(forecast_daily.forecast[0].datetime) | timestamp_custom('%H %M %A') }}
Notes
- The service call to
weather.get_forecastusing the default service seems to bring back six days of forecasts. - After some experimentation with loops, only the first is read out for brevity and
forecast_daily.forecast[0]is used to get the first entry. - A few
round()calls are used to make the numeric values easier to listen to. - The time and day of the forecast is read out at the end as a check that it is current (in case the service changes).
- The ability to call specific weather services and process different elements of the result is interesting, but less relevant in this “alarm clock” use-case.
Thanks to all who added to this discussion as many of your ideas and code snippets helped with this update!
1 Like
Hi,
After banging my head against more deeply nested JSON returned by the newly changed 2023.12 weather.get_forecasts (note the extra s on get_forecasts), here’s an updated, updated implementation:
# weather.get_forecasts example service call and TTS template functions
action:
- service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.home
response_variable: forecast_daily
- service: tts.google_say
data:
entity_id: media_player.nesthub1234
message: >-
Good morning.
It is {{ now().hour}} {{ now().minute }} on {{ states('sensor.date_in_text') }}.
The forecast is {{ forecast_daily['weather.home']['forecast'][0].condition }}.
With a temperature of {{ forecast_daily['weather.home']['forecast'][0].temperature|round(1) }}, wind speed of {{ forecast_daily['weather.home']['forecast'][0].wind_speed|round(0) }}, and precip of {{ forecast_daily['weather.home']['forecast'][0].precipitation|round(0) }}
At {{ as_timestamp(forecast_daily['weather.home']['forecast'][0].datetime) | timestamp_custom('%H %M %A') }}
Hopefully by the time you read this post, the HASS docs will have been updated with the 2023.12 changes to weather.get_forecasts. Last I checked, the PR was being reviewed in GitHub, and the docs are moving around so I can’t provide a link at the moment.
APIs get changed, designs don’t workout, but this one has become a bit of a pain.
Why the multiple nested brackets?
Old return format:
forecast:
- condition: rainy
New 2023.12 return format:
weather.home: <-- NEW: forecast location
forecast:
- condition: rainy
This suggests the service call can return forecasts for several different locations, hence the extra level of nesting.
If this helps, 
this post!
2 Likes
You should’ve just asked. We helped many people in beta transition to the new format. I suggest you check out the discord channel in the future.
I was also looking for this info and I’m unfortunately not a regular user of the Discord channels. It’s just too much info I can’t keep up with, given my day.
I truly think the release notes could’ve said just a little bit more than just “the schema changed”.
I think a number of people will trip over how to index the fields, because one can usually just use dot notation. It’s a done deal now (and not upset about it in any way), but if I caught this earlier I would’ve suggested to not use the entity ID, but just the slug part of it, e.g. forecast_daily.home.forecast.... Now that I’ve written this, I realise you need to use the indexing notation anyway on lists, so maybe this is moot. 
1 Like
TBH, I usually do this:
action:
- variables:
target: weather.home
- service: weather.get_forecasts
data:
type: daily
target:
entity_id: "{{ target }}"
response_variable: raw
- variables:
forecast_daily: "{{ raw[target] }}"
or some derivation of that. So it never crossed my mind that you couldn’t use dot notation.
I’m sure it probably didn’t cross the dev’s mind either. This type of syntax is unique to Jinja, it’s not standard in python.
2 Likes
Hi,
i currently have a sensor for get the forcast with the service weather.get_forecast. How do i switch my attributes to work with weather.get_forecasts?
template:
- trigger:
- platform: time_pattern
minutes: "/1"
action:
- service: weather.get_forecast
target:
entity_id: weather.worms_worms
data:
type: daily
response_variable: forecast
sensor:
- name: Weather Forcast
unique_id: 6ef16182-4089-4f16-bbee-d4fc79722079
availability: "true"
icon: mdi:weather-cloudy-clock
state: "OK"
attributes:
weather_rain_today: >
{{ forecast.forecast[0].precipitation | round(1) }}
weather_temperature_today: >
{{ forecast.forecast[0].temperature | round(1) }}
weather_templow_today: >
{{ forecast.forecast[0].templow | round(1) }}
2 Likes
Why are you triggering every minute for a daily value?
...
sensor:
- name: Weather Forcast
unique_id: 6ef16182-4089-4f16-bbee-d4fc79722079
availability: "true"
icon: mdi:weather-cloudy-clock
state: "OK"
attributes:
weather_rain_today: >
{{ forecast['weather.worms_worms'].forecast[0].precipitation | round(1) }}
weather_temperature_today: >
{{ forecast['weather.worms_worms'].forecast[0].temperature | round(1) }}
weather_templow_today: >
{{ forecast['weather.worms_worms'].forecast[0].templow | round(1) }}
4 Likes
Thank you! And you are right make no sense to update it every minute. Currently only a test setup 