When I test that template, it produces a result containing two instances of 00:00
If you want to add 12 hours to the current time and report the result as a UTC datetime string, you can simply do this:
{% set next12hours = (utcnow() + timedelta(hours=12)).isoformat() %}
Thanks, it wasn’t broken, but its less broken now!
Also I figured out how to limit the returned forecast items to a days worth, couldn’t just limit to the temperature, but its good enough for my use case.
forecast: "{{ (hourly['weather.forecast_home'].forecast)[:24] }}"
the :24 on the end was all I needed.
A small variation on creating one single forecast sensor, one can also create dedicated template sensors for each forecast element of interest. In the example below temperature, wind_speed and precipitation. The data size of these sensors is kept minimal, as the forecast lists only contain the values for that sensor
- trigger:
- platform: state
entity_id:
- weather.Home57
action:
- service: weather.get_forecasts
data:
type: hourly
target:
entity_id: weather.home
response_variable: hourly
- variables:
hourly_forecast: "{{ hourly['weather.home'].forecast }}"
sensor:
- unique_id: weather_forecast_temp
name: Forecast temperature
unit_of_measurement: '°C'
state: "{{ hourly_forecast[0].temperature }}"
device_class: temperature
attributes:
time: "{{ hourly_forecast[0].datetime }}"
forecast: "{{ hourly_forecast | map(attribute='temperature') | list }}"
- unique_id: weather_forecast_wind_speed
name: weather Forecast wind speed
unit_of_measurement: 'km/h'
state: "{{ hourly_forecast[0].wind_speed }}"
device_class: wind_speed
attributes:
time: "{{ hourly_forecast[0].datetime }}"
forecast: "{{ hourly_forecast | map(attribute='wind_speed') | list }}"
- unique_id: weather_forecast_precipitation
name: weather Forecast precipitation
unit_of_measurement: 'mm'
state: "{{ hourly_forecast[0].precipitation }}"
device_class: precipitation
attributes:
time: "{{ hourly_forecast[0].datetime }}"
forecast: "{{ hourly_forecast | map(attribute='precipitation') | list }}"
`
these sensors have two attributes:
time which is the forecast time of the first entryforecast with the forecast values per hourIn the dev tools it then looks like this:
Best Eric
Note: removing the attributes from the weather sensor I can understand, but deprecating weather.get_forecast caused me a lot of extra work, and seems just a variation of weather.get_forecasts with a single entity.
Keeping those variations available causes a lot of confusion and frustration for new and less knowledgeable users… better to just rip the bandage off quickly.
In my opinion the new version get_forcasts is harder to understand how to parse the response for less experienced users. Users who typically have just one weather entity as well.
That’s exactly right (for both the get_forcasts change as well as the hourly change). Users that have a few automations with value template elements that were set up entirely through the UI, like this one:
{{ (states.weather.home_hourly.attributes.forecast[3].temperature) | float < 16 }}
… are now not having their heating come on in the morning 
And they are rather irritated because the removal of other features (like the counter.configure service) have alerted me with notifications for months, so I was prepared for the breaking change.
I have spent two hours yesterday and another three this morning, trying to find out what the best way forward for me is, and unless I learn multiple complex skills at the same time, I cannot solve this.
Yesterday, I performed the update. My dashboard complained about weather.home_hourly not being available, which I found odd, but when I edited it to weather.home for the time being, there was a new toggle between “daily” and “hourly”, which restored the exact functionality (a fairly smooth experience overall for something considered a breaking change).
This morning, my heating did not come on. In case it is interesting to those that have not been novice users for a long time, here’s my thought process:
weather.home_hourly entity is still gone. I have previously enabled it manually, the update must have undone that. Huh. No, it is really gone, including the previously-disabled one.weather.get_forecast.Overall, I do agree with @FloatingBoater:
Could I ask that someone skilled could point me to the bare minimum of skills I need to learn, please? I am happy to put the work in, but filtering out what concepts I need to build an understanding of (with all the changes that play into this situation) is an insurmountable task for a relative beginner.
I’ve posted two worked examples not 20 posts above…
You might want to change type: hourly to type: daily.
Thank you, and I did see and read this post, but it did not help me much, I am afraid.
That is entirely on me. As I said, I am clearly lacking the overall structural understanding of how to adapt all the examples, which is why I asked for help to gain further understanding in the areas needed.
What I need is a condition to use inside an automation to verify that the temperature in four hours is forecast to be less than 16 degrees.
I currently use a value template for it (as quoted above), and your working example is no direct substitute for that, if I understand correctly.
This trigger based template sensor may help you.
You can paste that into your configuration.yaml, with template: before the first line, like:
template:
- trigger:
- platform: time_pattern
minutes: "*"
...
Then just change weather.stuttgart_echterdingen to your weather entity, and the other references to Stuttgart-Echterdingen or stuttgart_echterdingen to suit you.
Run a config check and then reload your templates (or restart HA).
Hi all!
I’m trying to understand templating by copying and editing what I find around the community 
I’m trying to get the temperature and humidity each hour so that I can use it with some messages, I’m using Met.no weather forecast.
This is my template code that is not working:
- unique_id: test_meteo
trigger:
- platform: time_pattern
hours: /1
action:
- variables:
weather: weather.forecast_casa
- service: weather.get_forecasts
target:
entity_id: "{{ weather }}"
data:
type: hourly
response_variable: response
- variables:
forecast: "{{ response[weather].forecast }}"
start: "{{ now().year ~ '-0' ~ now().month ~ '-0' ~ now().day ~ 'T' ~ now().hour ~ ':00:00+00:00'}}"
sensor:
- name: my_meteo
unique_id: my_meteo
state: >
{{ forecast | selectattr('datetime', '==', start) | map(attribute='datetime') }}
attributes:
temperature: "{{ forecast | selectattr('datetime', '==', start) | selectattr('temperature') }}"
humidity: "{{ forecast | selectattr('datetime', '==', start) | selectattr('humidity') }}"
The result is that sensor.my_meteo has state = unknown and there aren’t the attributes temperature and humidity
Could someone help me please?
thanks!
Thank you, @Tinkerer, that was an excellent flight level and very helpful in this specific instance.
For the next person running into this, here is a more detailed rundown of what I did to fix my automations:
configuration.yaml:template:
- trigger:
- platform: time_pattern
minutes: "*"
- platform: homeassistant
event: start
- platform: event
event_type: event_template_reloaded
action:
- service: weather.get_forecast
target:
entity_id: weather.home
data:
type: hourly
response_variable: hourly_forecast
- service: weather.get_forecast
target:
entity_id: weather.home
data:
type: daily
response_variable: daily_forecast
sensor:
- name: "Weather Hourly"
unique_id: home_hourly
state: "{{ states('weather.home') }}"
attributes:
temperature: "{{ state_attr('weather.home', 'temperature') }}"
dew_point: "{{ state_attr('weather.home', 'dew_point') }}"
temperature_unit: "{{ state_attr('weather.home', 'temperature_unit') }}"
humidity: "{{ state_attr('weather.home', 'humidity') }}"
cloud_coverage: "{{ state_attr('weather.home', 'cloud_coverage') }}"
pressure: "{{ state_attr('weather.home', 'pressure') }}"
pressure_unit: "{{ state_attr('weather.home', 'pressure_unit') }}"
wind_bearing: "{{ state_attr('weather.home', 'wind_bearing') }}"
wind_gust_speed: "{{ state_attr('weather.home', 'wind_gust_speed') }}"
wind_speed: "{{ state_attr('weather.home', 'wind_speed') }}"
wind_speed_unit: "{{ state_attr('weather.home', 'wind_speed_unit') }}"
visibility: "{{ state_attr('weather.home', 'visibility') }}"
visibility_unit: "{{ state_attr('weather.home', 'visibility_unit') }}"
precipitation: "{{ state_attr('weather.home', 'precipitation') }}"
precipitation_unit: "{{ state_attr('weather.home', 'precipitation_unit') }}"
forecast: "{{ hourly_forecast.forecast[:5] }}"
- name: "Weather Daily"
unique_id: home_daily
state: "{{ states('weather.home') }}"
attributes:
temperature: "{{ state_attr('weather.home', 'temperature') }}"
dew_point: "{{ state_attr('weather.home', 'dew_point') }}"
temperature_unit: "{{ state_attr('weather.home', 'temperature_unit') }}"
humidity: "{{ state_attr('weather.home', 'humidity') }}"
cloud_coverage: "{{ state_attr('weather.home', 'cloud_coverage') }}"
pressure: "{{ state_attr('weather.home', 'pressure') }}"
pressure_unit: "{{ state_attr('weather.home', 'pressure_unit') }}"
wind_bearing: "{{ state_attr('weather.home', 'wind_bearing') }}"
wind_gust_speed: "{{ state_attr('weather.home', 'wind_gust_speed') }}"
wind_speed: "{{ state_attr('weather.home', 'wind_speed') }}"
wind_speed_unit: "{{ state_attr('weather.home', 'wind_speed_unit') }}"
visibility: "{{ state_attr('weather.home', 'visibility') }}"
visibility_unit: "{{ state_attr('weather.home', 'visibility_unit') }}"
precipitation: "{{ state_attr('weather.home', 'precipitation') }}"
precipitation_unit: "{{ state_attr('weather.home', 'precipitation_unit') }}"
forecast: "{{ daily_forecast.forecast[:5] }}"
(This code is based on the mentioned GitHub post and will work without any changes needed as long as you are using the )weather.home entity.
Above code example does no longer work since it still uses the weather.get_forecast service call, which has been deprecated. See my post below for the updated, working version of this code.
This should create an entity sensor.weather_hourly (and also an entity sensor.weather_daily), which should contain the following:
temperature: 5.7
dew_point: -0.7
temperature_unit: °C
humidity: 63
cloud_coverage: 0
pressure: 1016.4
pressure_unit: hPa
wind_bearing: 97
wind_gust_speed: null
wind_speed: 18
wind_speed_unit: km/h
visibility: null
visibility_unit: km
precipitation: null
precipitation_unit: mm
forecast:
- condition: sunny
datetime: '2024-03-08T11:00:00+00:00'
wind_bearing: 98.8
cloud_coverage: 0
temperature: 7.4
wind_speed: 19.4
precipitation: 0
humidity: 59
- condition: sunny
datetime: '2024-03-08T12:00:00+00:00'
wind_bearing: 96.2
cloud_coverage: 0
temperature: 8.6
wind_speed: 22
precipitation: 0
humidity: 54
- condition: sunny
datetime: '2024-03-08T13:00:00+00:00'
wind_bearing: 97.5
cloud_coverage: 0
temperature: 9.4
wind_speed: 23
precipitation: 0
humidity: 52
- condition: partlycloudy
datetime: '2024-03-08T14:00:00+00:00'
wind_bearing: 108.1
cloud_coverage: 17.2
temperature: 9.9
wind_speed: 25.2
precipitation: 0
humidity: 50
- condition: sunny
datetime: '2024-03-08T15:00:00+00:00'
wind_bearing: 103.3
cloud_coverage: 0
temperature: 9.6
wind_speed: 22.3
precipitation: 0
humidity: 51
friendly_name: Weather Hourly
{{ (states.weather.home_hourly.attributes.forecast[3].temperature) | float < 16 }}
I changed into this:
{{ (states.sensor.weather_hourly.attributes.forecast[3].temperature) | float < 16 }}
Note: I had to both change weather to sensor (because the above code does provide an entity of the type sensor while the previous entity was of the type weather) and home_hourly to weather_hourly (because the above code specifies the unique_id as weather_hourly).
Another way would be to use state_attr() as strongly suggested in the documentation:
{{ state_attr('sensor.weather_hourly','forecast')[3]['temperature'] | float < 16 }}
If you test the condition inside automations, please note that if you are running “Test” on a condition while it is disabled, the test will always fail. This did cost me the better part of an hour to figure out.
If you do not mind me asking, what is the best way to understand where yaml code may be inserted?
Here is why:
I used to always insert them into the configuration.yaml file.
More recently, there have been a number of breaking changes where configuration in configuration.yaml is being deprecated and subsequently even being ignored (in favour of configuration through the UI). I also noticed more helper types are being made available in the UI.
That led me to believe that the code you told me to insert into configuration.yaml could also be inserted through the use of a template type helper.
However, that does not appear to be the case. How do I tell apart what should work?
Try the solution I outlined above, it will provide you with temperature and humidity as well. Do make sure you change weather.home in the code if needed. I believe you might be using weather.forecast_casa.
Should you need more than five hours, increase the number 5 for the home_hourly sensor
forecast: "{{ hourly_forecast.forecast[:5] }}"
as explained on GitHub.
- unique_id: test_meteo
trigger:
- platform: time_pattern
hours: /1
action:
- variables:
weather: weather.forecast_casa
- service: weather.get_forecasts
target:
entity_id: "{{ weather }}"
data:
type: hourly
response_variable: response
- variables:
forecast: "{{ response[weather].forecast }}"
start: "{{ today_at('00:00') }}"
sensor:
- name: my_meteo
unique_id: my_meteo
state: >
{{ forecast | selectattr('datetime', '==', start) | map(attribute='datetime') | first }}
attributes:
temperature: "{{ forecast | selectattr('datetime', '==', start) | selectattr('temperature') | list }}"
humidity: "{{ forecast | selectattr('datetime', '==', start) | selectattr('humidity') | list }}"
The documentation tells you where to put the yaml. Every single yaml integration has this information in the integration pages on the integration page.
The UI template integration only supports very basic template sensors and template binary_sensors. You can’t put in full configurations like you’re doing.
FYI, you should take a look at this page to understand the difference between yaml and jinja, which is probably what tripped you up in the first place.
Thank you, @petro! I understand why it did not work, but do let me elaborate on where my confusion stems from, and why I think there is room for improvement.
Could it be that this information is not on every single page? Here is where I looked:
I opened the Weather integration page, then scrolled to the Examples section. There is an example named “Example template sensor using get_forecasts”.
It contains the following code:
template:
- trigger:
- platform: time_pattern
hours: /1
action:
- service: weather.get_forecasts
data:
type: hourly
target:
entity_id: weather.home
response_variable: hourly
sensor:
- name: Temperature forecast next hour
unique_id: temperature_forecast_next_hour
state: "{{ hourly['weather.home'].forecast[0].temperature }}"
unit_of_measurement: °C
(I could have probably easily adopted that code to return forecast[3] and that would have helped me to solve my challenge on my own.)
But the documentation does not state whether this code can be used through the UI template integration and without the additional knowledge that the UI
there is no way for a novice user to recognise that this qualifies as “full configurations” and/or that this code needs to be placed in configurations.yaml to work.
That being said, I actually asked because people post a lot of code snippets in the forum, and usually do not mention whether there is a constraint of where they will work. Take the example mentioned earlier: I tried it in the UI, because that looked like it should work. It does not, and there is no guidance to the user that the UI is severely limited.
Thanks now it works 
Thanks! I will try it and change something about the values
Yes, it’s implied that it goes into configuration.yaml as-is. All examples are under the assumption that you place them into configuration.yaml unless otherwise specified. And in many cases, it will just say “it goes in configuration.yaml”.
Because you can’t put any yaml into the UI (outside automation/script yaml mode in UI). The UI is for UI adjustments, not yaml adjustments. This is why I linked the difference between jinja and yaml above. You can’t put yaml into the UI but you can put Jinja into the template fields in the UI.
And that’s why you should use the documentation as full examples and treat all posts on the forums as “potentially old or incomplete information”. His post is showing an automation or script action section.
Once more, thank you @petro, for tying together the lose ends of my understanding!
I now understand why you posted the links before, thank you for clarifying your intention.
Here is what tripped me up: I did already understand the difference between yaml and Jinja. Missing from my understanding was that a template helper will only accept a much smaller subset of what is stored inside a “full” configuration.yaml template entry.
That used to be the assumption under which I worked, but I stopped being so sure about the implied meaning when I sensed a shift to the UI. I have thought about where this feeling came from and I think this makes little sense from a more advanced perspective. It came from the following two, independent factors:
configuration.yaml-only is increasingly incorporated into the UI, occasionally with a push to prefer UI, andconfiguration.yaml-only are being moved to the UI, with removing configuration.yaml support entirely.In conjunction, they gave me the impression that there was an overall shift from configuration.yaml to the UI, so I expected new UI items to have the intent of replacing the existing configuration.yaml way of doing things.
With the additional knowledge from this conversation, I understand now that there is no such overall shift and that general rule is standing as strong as always.
Agreed. I always prefer the documentation over a forum post from any user with an unknown proficiency level for that exact reason.
In this instance however, it was difficult to find the right starting spot in the documentation, as the documentation does not aim to provide a solution to my question. The documentation is trying to convey the fact that forecasts are no longer available as attributes, but can be retrieved through a service call.
The mismatch between what the documentation conveys (there will be no more attributes) and my question (how do I get attributes back) is so vast that the documentation was simply not helpful for me to determine the best next step.
All that being said, I am well aware of the tremendous amount of work that goes into maintaining the documentation on the level that you do provide it, and I truly appreciate all of it. All I wanted was to point out that the documentation is – by design – not going to be a guide through the complicated change processes ahead of everyone.
If there was one thing that I could suggest going forward, it would be to extend the alerts inside HA going out for deprecated functionality. This would greatly increase the time that users have to adopt before the breaking change occurs.