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.
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
I just wasted a couple of hours also trying to figure out why many examples around don’t work. I realise though this is the problem with breaking changes, that the plethora of ‘helpful’ examples on the internet no longer work and you’re left wondering why as a beginner.
Got it working now though with template.yaml using OpenWeatherMap!
