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.
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.
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.
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.
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.
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?
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 }}
....
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.
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
@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.
Just FYI, yes this would be great. The keyword is “Should”, that is all good in theory, but not in practice.
My weather integration does not give simple things like “chance of rain today” as an entity - It would be great if it did! Sure.
But I have to dig down into the Attributes (array of forecasts) to get that data, as do many others. So your statement of “Should be simple” doesn’t track to our real world experiences.
And to be honest, simply accessing the attributes was super easy - this is one of the few HA changes that makes things much much harder and more complicated than they were before. (I just had a single line in my TTS yaml that read out todays chance of rain, for example)
FYI I use Tomorrow.io and not Accuweather because…Accuweather is funnily enough not very accurate where I live - Tomorow.io gives much more sane and accurate weather reports - but there are essentially no entities with such data - its all in the Forecast attribute.
Appreciate your volunteer help to the community. I understand this is super easy for you. It’s just worth noting that many don’t have you level of experience and knowledge in this field. There are no doubt things in life that I find super easy, that you would struggle with, and I might struggle to comprehend why those things are a struggle for you, when they are so easy for me… It is worth remembering the opposite is also true.
I will state this upgrade has one of the few HA upgrades that makes things far more complex and time consuming, than it used to be.
That is a complement - it means most of the upgrades improve things
There were system-stability reasons behind this decision. Mainly the state machine that HA uses is already large and has to be sent to client(s) quite often. To get the state machine into a maintainable state, some things have had to be removed. Given the huge amount of entities that have to be stored in the state machine, the developers are looking for as many things as they can to remove to keep the system stable.
