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.
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
Thankyou for your work and support.
1 Like
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.
Thanks. That makes sense.
The reasons sound solid, and you described them well.
I think just I and many are wondering, if there couldn’t have also been an easier/smoother “upgrade” process.
I probably have better templating skills than the average HA user, and this was non-trivial to change for me.
1 Like
There might have been easier/better ways to do it and we might see those in future versions. I know that this was decided a long time ago (and had a deprecation notice associated with it for at least 6 months). So, I mean, there was time to get it done. But I get where you are coming from.
hi, I used this code before, now I can’t understand how to create a sensor that tells me tomorrow’s minimum temperature.
I created this by looking at your examples but I don’t see the sensor.
what am I doing wrong?
Thank you
old condition in automation:
condition:
- condition: template
value_template: '{{ (state_attr(''weather.casa'',''forecast'').0.templow)|float <= 2|float}}'
new:
template:
- trigger:
- platform: time_pattern
hours: "/1"
- platform: state
entity_id: weather.casa
- platform: homeassistant
event: start
- platform: event
event_type: event_template_reloaded
action:
- service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.casa
sensor:
- name: "Temperatura minima domani"
icon: "mdi:thermometer"
state: "{{ daily['weather.casa'].forecast[0].templow|float }}"