Well, petro is certainly not an idiot, even though I keep thinking that this change has caused hundreds of man-hours down the trial-and-error drain. In my particular case I had to play with it somewhat and didn’t find it unusually complicated. I guess I got lucky getting it to work. However, all the many users above struggling is the evidence that in fact this not as easy as it was before.
He’s a programmer. So of course he understands it. I made that clear,…
You shouldn’t even need to access the forecast information unless you’re doing something high level.
The weather integration you use should have added the infomration you’re looking for as separate sensors.
However everyone here is looking to replicate exactly what they had before. When they actually should be spending a few minutes looking at their integration and seeing if the information exists elsewhere.
Sorry that my comments hurt your feelings. But in the grand scheme of things, you shouldn’t need this information from the get_forecast service.
Here’s an example, AccuWeather broke out the forecast into individual entities, which Do not require templates at all.
TLDR: It’s actually easier, but you’re not looking in the right spots. No one here should ever need to use the new method to replicate your old template entities. You should be using new entities provided by your weather integration.
3 Likes
The pain is only just beginning… there’s a large and growing contingent of us less skilled (programatically) who have moved in to advanced things like OpenHASP. The vast majority of us are NOT programmers and we relied (foolishly) on the HA objects to be easy to retrieve. EVERY pixel has to be accounted for and each objects value derived from HA entities, ALL of my screens in my house went blank when the early April release came. And now we’re in the rabbit hole. Each of them needs to be updated after 100’s of hours of work to get them deployed. I’ve pulled the detailed _description, but that’s as far as I’ve gotten. I don’t have 3 days of free time to figure out how to extract everything else.
What previously only took one object extraction in 1 simple line of code
{{ state_attr('weather.keul_daynight','forecast')[1]['condition'] }}
will now take me more than 50+ lines of obscure coding, of which there are few examples of and a dozen or more weather integrations that are ALL affected. Sheesh.
What may seem trivial to advanced folks like yourself is anything but for folks like me and the HUNDREDS of other people screaming about this change. I’ve never seen more pissed off people. It more like outrage. Just take 2 minutes and peruse the Discord channels or the 79 forum posts above this one or the dozens of others that mostly go unanswered for days.
This will go down as one of the most ill-informed and poorly executed updates of all time in this community. Whoever was ultimately responsible for it should do some inner soul searching and take a step back from this project, Paulus @balloob keeps preeching that he wants the platform to be MORE accessible for a greater number of less-technical users. Well, you guys missed the mark on this BIG TIME.
4 Likes
The change was made 7 months ago and you had warnings in your logs and repairs when it was initially rolled out. This is the release that finalized the deprecation. It was announced in the original release 2023.9 that the attributes were being removed in 2024.3, it ended up making it into 2024.4.
During that time a repair was put with it to make a notification in your system, so you had a notification in HA with this information. Also, if you dismissed that repair, your log still contained warnings about this. It would be very hard to miss this announcement.
Many people on the forums and discord have been helping people fix these problems with their custom things like OpenHASP. Myself, TheFes, 123, Didgeridrew, mekaneck, Troon, rccoleman, and plenty of others. You can simply look up any example provided by one of these people, and if you can’t get it working… ask.
Lastly, as someone who mostly volunteers their time helping people with HA, I have very little remorse for your situation. Not only because of the information I just provided, but also because you think I am forcing the change on you. “Us guys” didn’t miss any mark, I simply volunteer my time helping others move forward.
5 Likes
No argument, You go over and above trying to help folks. I stand corrected. I should have said:
Well, the feature planners & developers missed the mark on this BIG TIME .
1 Like
FWIW, there was an extensive and thoughtful discussion of the proposed concept (service calls with return values) in the Architecture repo.
Both the Calendar and Weather integrations now employ it in order to get upcoming events/forecasts. One of the spinoffs is the addition of an action section to the Trigger-based Template Sensor which makes it more powerful (can execute service calls and define variables) and opens up new possibilities (beyond just for calling Calendar and Weather service calls).
I recall when the entity_id option was removed from Template Sensors. I wasn’t a fan of that decision (to say the least) because it eliminated fine-grained control of the template’s evaluation. However, it (eventually) led to new opportunities in the form of the Trigger-based Template Sensor which provides far better control than entity_id ever did (and created new ways of solving old problems).
All this to say that sometimes the benefits of a change aren’t immediately apparent but often lead to new opportunities. Yes, the transition from old ways to new ways can be challenging but change (and adapting to it) has always been part of the Home Assistant project.
A post was split to a new topic: Having trouble getting forecast from custom entity into a card on the UI
US user here, using the NWS (National Weather Service) integration. Fortunately, I never setup any detailed cards of custom cards with the forecast. What I did do with it, was read it aloud via Rhasspy for years. It was working on an HA Voice Assist just a few weeks ago. Now, if there were warnings present in my logs following multiple updates monthly, I will take 100% responsibility for missing them entirely. Or as the kids like to say, ‘my bad’. 
So, I reviewed the triggered template examples above (I am a software developer, fyi) and cannot determine if that’s a single block of YAML to drop into my configuration.yaml file, or it’s an automation (it seems like it) or if it should be split into pieces, an automation with a trigger, and a template sensor to be updated by that automation.
FYI, this is the output portion of my existing HA automation:
set_conversation_response: >-
{% set forecast = state_attr('weather.kclt_daynight','forecast') %}
{% set current = forecast[0].condition | replace('partlycloudy', 'partly cloudy') %}
{% set fc_detail = forecast[0].detailed_description | replace('mph', 'miles per hour') %}
{% set temperature = states.sensor.cotech_367959_121_temperature_f.state | round | int %}
{% set humidity = states.sensor.cotech_367959_121_humidity.state %}
The weather is currently {{ current }}. Temperature is {{ temperature }}
degrees and humidity is {{ humidity }} percent.
The forecast is {{ fc_detail }}
Any clarification or further explanation would be greatly appreciated.
Thank you in advance.
Thanks for the continued support @petro and highlighting the individual sensors exposed by each weather integration.
I have trid Openweather, Tomorrow.io and Met.no. However, none of these weather integrations provide indidivual sensors for the relevant data that was being accessing in the forecast arrtibutes. Is this expected and likely to change at a later date to match the AccuWeather integration you referenced?
1 Like
The configuration in Post #77 is for a Template sensor and should be placed wherever you have entities from the template integration configured. If you don’t have any Template integration entities, you can place it directly in configuration.yaml, just make sure to add the top-level key template above the sensor config.
If you don’t actually need the sensor for anything else, you can add the weather.get_forecasts service call to your existing automation.
...
action:
- service: weather.get_forecasts
data:
type: twice_daily
target:
entity_id: weather.kclt_daynight
response_variable: response
- variables:
set_conversation_response: >-
{% set forecast = response['weather.kclt_daynight'].forecast %}
{% set current = forecast[0].condition | replace('partlycloudy', 'partly cloudy') %}
{% set fc_detail = forecast[0].detailed_description | replace('mph', 'miles per hour') %}
{% set temperature = states.sensor.cotech_367959_121_temperature_f.state | round | int %}
{% set humidity = states.sensor.cotech_367959_121_humidity.state %}
The weather is currently {{ current }}. Temperature is {{ temperature }}
degrees and humidity is {{ humidity }} percent.
The forecast is {{ fc_detail }}
....
1 Like
I struggled a bit with the change also. But finally got it working. I share what I did.
First test with services, DevTools > Services:
service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.forecast_home
It works, so next step:
configuration.yaml
template: !include_dir_merge_list template/
new folder in /config:
template/weather.yaml
into the weather.yaml:
- trigger:
- platform: time_pattern
hours: "/1"
- platform: state
entity_id: weather.forecast_home
- platform: homeassistant
event: start
- platform: event
event_type: event_template_reloaded
action:
- service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.forecast_home
response_variable: daily
sensor:
- name: "Temperature Today"
icon: "mdi:thermometer"
state: "{{ daily['weather.forecast_home'].forecast[0].templow|float }} ... {{ daily['weather.forecast_home'].forecast[0].temperature|float }}"
- name: "Temperature Tomorrow"
icon: "mdi:thermometer"
state: "{{ daily['weather.forecast_home'].forecast[1].templow|float }} ... {{ daily['weather.forecast_home'].forecast[1].temperature|float }}"
- name: "Temperature Day After Tomorrow"
icon: "mdi:thermometer"
state: "{{ daily['weather.forecast_home'].forecast[2].templow|float }} ... {{ daily['weather.forecast_home'].forecast[2].temperature|float }}"
lovelace.yaml:
type: entities
entities:
- entity: sensor.temperature_today
- entity: sensor.temperature_tomorrow
- entity: sensor.temperature_day_after_tomorrow
Maybe it helps someone. 
3 Likes
Thank you VERY much, @Didgeridrew - I was blissfully unaware there was a new flavor of template sensor available. I maintain my sensors in a separate sensors.yaml file, and will probably setup the new forecast sensor there.
For the benefit of others, the final automation YAML is below. Note the required inputs:
a) weather service that provides forecasts
b) local temperature sensor
c) local humidity sensor
alias: Assist Tell Weather
description: Voice Assistant Tell Me the Weather
trigger:
- platform: conversation
command:
- What is the weather
- Tell me the weather
- Give me the weather
- Weather please
condition: []
action:
- service: weather.get_forecasts
data:
type: twice_daily
target:
entity_id: weather.kclt_daynight
response_variable: response
- set_conversation_response: >-
{% set forecast = response['weather.kclt_daynight'].forecast %}
{% set current = forecast[0].condition | replace('partlycloudy', 'partly cloudy') %}
{% set fc_detail = forecast[0].detailed_description | replace('mph', 'miles per hour') %}
{% set temperature = states.sensor.cotech_367959_121_temperature_f.state | round | int %}
{% set humidity = states.sensor.cotech_367959_121_humidity.state %}
The weather is currently {{ current }}. Temperature is {{ temperature }}
degrees and humidity is {{ humidity }} percent. The forecast is {{ fc_detail }}
mode: single
For those who are apparently doing “high level” functions with weather, this is a GREAT post. I use OpenHasp and this workaround is exactly what I needed. Very minimal changes required after creating the new entity.
Just got hit by this. Read a lot of threads and banged my head trying to implement the template sensor. I was trying to do it using helper mechanism like I have other templates done and it simply silently failed no matter what I tried. I finally did it through the yaml file way and it worked immediately.
1 Like
Currently, you can’t create a Trigger-based Template Sensor using the UI. It only supports Template Sensors and Template Binary Sensors.
1 Like
hi im having troubles getting my legacy weather converted over to the new weather… i had some help in another sub heading but its not creating the sensors… i did the dev …templates and it shows values… but it wont create the sensors… can someone help what is the right way to do it?
here is what i got
template:
- trigger:
- platform: time_pattern
hours: /1
- platform: homeassistant
event: start
action:
- service: weather.get_forecasts
data:
type: hourly
target:
entity_id: weather.peterborough_forecast
response_variable: hourly
- variables:
ptb_forecast: "{{ hourly['weather.peterborough_forecast'].forecast }}"
sensor:
- name: Temperature forecast next hour
unique_id: temperature_forecast_next_hour
state: "{{ ptb_forecast[0].temperature }}"
unit_of_measurement: °C
attributes:
forecast_0: "{{ ptb_forecast[0] }}"
- sensor:
- name: today_min
#friendly_name: Today's mimimal temperature
#unique_id: today_min
value_template: "{{ states('sensor.peterborough_low_temperature' ) }}"
availability: "{{ has_value('sensor.peterborough_low_temperature') }}"
- name: today_max
#friendly_name: Today's maximal temperature
#unique_id: today_max
value_template: "{{ states('sensor.peterborough_high_temperature' ) }}"
availability: "{{ has_value('sensor.peterborough_high_temperature') }}"
- name: today_rain
#friendly_name: Today's rain forecast
#unique_id: today_rain
value_template: "{{ states('sensor.peterborough_chance_of_precipitation') }}"
availability: "{{ has_value('sensor.peterborough_chance_of_precipitation') }}"
- name: today_icon
#friendly_name: Today weather forecast
#unique_id: today_icon
value_template: >-
{% set condition = states("sensor.peterborough_current_condition") %}
{% set mapper = {'clear-night': 3,
'cloudy': 5, 'fog': 16, 'hail': 6,
'lightning': 13, 'lightning-rainy': 17, 'partlycloudy': 8,
'pouring': 18, 'rainy': 9, 'snowy': 11,
'snowy-rainy': 7, 'windy': 14, 'windy-variant': 14 } %}
{{ mapper[condition] if condition in mapper.keys() else 12 }}
availability: "{{ has_value('weather.peterborough_forecast') }}"
the 4 sensors will not create.
@123 Thank you for clarifying this! It would be great if it was explicitly stated in the Template helper starting dialog that Trigger based Template Sensors are not yet supported. The only error was in the logs that said that the response variable was not defined.
I do have some template sensors which use state_attr method and thus have the “This template listens for the following state changed events” trigger-like behaviour. But it is of course not the same as this real trigger based template sensor.
There’s no way it will know you’re trying to make a trigger based template entity. All it knows is that a variable is missing, and there are almost an infinite number of reasons why a variable is missing. It’s not related to trigger based template entities at all. Unfortunately, you have to understand templates in order to use them. They are not going to be “easy” compared to the rest of HA. They are the hardest thing to implement because you need to understand code.
A menu shows what it can do, not what it cannot do.
In addition, the UI that is presented for a Template Sensor helper only offers a field where you can enter the Template Sensor’s State template and not the Trigger and optional Action of a Trigger-based Template Sensor. That’s a clue that it’s exclusively for a Template Sensor (like it says in the menu).
The UI for a Trigger-based Template Sensor helper would need to provide fields for entering the Trigger(s) of a Trigger-based Template Sensor and a field where you could enter its optional Action. In other words, it would need a UI that’s similar to the one used for creating automations. Those two fields clearly don’t exist in the UI for a Template Sensor helper.