Hi,
I need a bit of help with the Meteorologisk institutt (Met.no) integration.
How can I access the hourly forecast for my templates ??
In the developer section I only see the values for the 5-day forecast but in the integration and in lovelace cards I get the hourly values, I am just not able to figure out how to access the values in my yaml script.
Hi, I only see one entity and I am on the latest version.
This is what I see when I click on the entity:
and also the display in lovelace works:
But this is what I see in the developer>YAML section:
So there must be a way to get this. All examples I found were refering to a separate entity for _hourly, which I do not have.
With the latest HA there is a new Service-Call introduced for the Weather-Forecast Integration
And im not sure if there is an “Official” solution “printed” down somewhere, but there is a few suggestions here in the forum, in regards to using these data (forecasts) in i.e templates … depending upon in what way one will need these data, … you are in for a journey in automations/templates/template-sensors/binary sensors etc 
EDIT: 2023.12
Note that the Service have changed to " Service weather.get_forecasts " an extra (s), Docs are updated !
Is there an easy way to ask in an automation for the highest temperature today to decide if the covers should stay closed to keep heat outside?
Weather.forecast_home temperature is available but I’m not sure what it really means. It seems to report the current temperature.
Edit: The reason why I didn’t create a new topic is that it is the same question and the answer wasn’t complete. It just said “the docs are current” but not how to access the values. I’m fine using some template trigger sensor to get some value at a given time once a day instead of a template helper which may get updates to often or whatever. But it seems obvious to me that the value “highest predicted temperature today” that should be made available first in a weather forecast. It’s what one usually wants to know.
Using a sensor that has hourly forecast values (in attribute ‘forecast’), it will however progress with time and as the forecast sensor gets updated. So you can e.g. run this early in the morning and compare to whatever value you need, then I would store the result in a helper (boolean).
A second automation would then trigger on the boolean at the time you need…
or…whatever you feel is better 
{{ (state_attr('sensor.your_forecast_sensor', 'forecast')|selectattr('datetime', 'lt', (now().replace(hour=23,minute=59)).isoformat()))| map(attribute='temperature') | list | max }}
You mean, I need to create some kind of template sensor to change the format of the data from weather.forecast_home to have the hourly array accessible to evaluate the remaining hours of the day in order to get the predicted max temperature for today?
Seriously? Or did I misunderstand something?
If you want to have a datetime to trigger the covers then you first need to find the upcoming max-temp-moment…hence. I cannot guess your required logic as you did not provide the details of your condition/trigger
If my children ask “what will the weather today be like?”, they usually want to know two details. What is the max temperature and will it rain?
The weather card shows these details. Everyone wants to know exactly these values. It’s what is being shown in every weather forecast in TV.
I don’t have a special requirements, I just want to have some condition for letting the covers down to not let the heat in. Above 28 degree predicted maximum temperature for today or similar will be fine.
But the snippet didn’t run at first try, probably because the values for hourly temperature need an additional template sensor to be available to look for the maximum.
I’ll get it to run soon, I’m quite sure. But it is not intended for some average user who just wants to evaluate some standard value. For me it sounds like a “What the heck?”-phenomenon.
Thank you very much for your help, btw.
You have imo two completely different goals
OK, you’d like to have details. I implemented a kind of state machine. Rolladen.Zustand can be one of several values:
In my template.yaml there are definitions for the right time:
- trigger:
- platform: time
at: '00:00:01'
- platform: state
entity_id:
- input_datetime.rolladen_auf_werktag
- input_datetime.rolladen_auf_feiertag
sensor:
- name: 'rolladen_heute_auf'
unique_id: "sensor.rolladen_heute_auf"
state: >-
{{ today_at(max(states('input_datetime.rolladen_auf_werktag')
if is_state('binary_sensor.workday_sensor','on')
else states('input_datetime.rolladen_auf_feiertag')
, as_timestamp(as_datetime(state_attr("sun.sun", "next_rising"))-timedelta(minutes=5)
) | timestamp_custom('%H:%M:%S')
))
}}
device_class: timestamp
- trigger:
- platform: time
at: '00:00:01'
- platform: state
entity_id:
- input_datetime.Rolladen_zu_max
sensor:
- name: 'rolladen_heute_zu'
unique_id: "sensor.rolladen_heute_zu"
state: >-
{{ today_at(min(states('input_datetime.rolladen_zu_max')
, (as_timestamp(as_datetime(state_attr("sun.sun", "next_setting"))+timedelta(minutes=5)
) ) | timestamp_custom('%H:%M:%S')
))
}}
device_class: timestamp
These times are shown in a dashboard where the input fields can be changed, also of course the rolladen state. There is also a short explanation of the basic rules for the times.
An automation triggered at rolladen_heute_zu runs skript rolladen_alle_zu (which calls skript rolladen_EG_zu and rolladen_OG_zu which activate several scenes, one for each room) - and activates State Auto.Nacht.
An automation triggered at rolladen_bedingt_auf very similar to previous if the forecast says cloud percentage is above 20 or temperature not above 25. It decides if next state is Rolladen.Tag (end state before night, call rolladen_alle_auf) or if several covers at the front shall be kept at Schlitz (open about 20 percent, depending on the cover) and activate state Auto.Morgensonne.
An automation triggered at 11:30 executed in state Auto.Morgensonne opens the cover of the kitchen, sets bathroom cover to Schlitz and actives state Auto.Mittagssonne.
An automation triggered at 13:30 exectuted in state Auto.Mittagssonne opens living room covers.
There is also an automation closing the living room cover if the time is before 4pm and the cover is above 50percent, but that doesn’t really matter here.
So all this does protection for direct sun, but if the temperature for today is maybe above 27 degree I’d like to let’s say at 11:00 just directly go to state Auto.Tag without opening any cover and set bathroom cover to Schlitz.
All this already exists, only the condition for heat today is missing. It would be fine to evaluate it once a day at 11:00 (sun on the bathroom starts in the afternoon). The weather.forecast_home has cloud percentage, current temperature - but you can’t directly get the value for today’s forecast as shown on the card.
But I’d like to have my cover automations transparent for the family. And for me. I don’t want to have a wonder-value boolean which says if today is heat or not. I’d want to look at the weather dashboard card with daily prediction values, see that the predicted temperature for today is above 27 and directly know why my automation should do one action or the other if activated in that moment.
I did ask for it
I hope I understood it correctly …
Then add a condition in the automation based on the script I set? I donot think the time plays a big role here as it is either 27 before 11 or after 11 and then it should be auto (just guessing)…else there could be a combine time and script condition
So each automation can have a condition if not (script) where only auto is True and others are False.
EDIT: but with multiple automations practically doing the same condition, it is easier imo to have one template sensor with the logic and use a True/False…if your condition chnages say to 10:00 you would only have to update the one sensor and not all automations
Currently I want to achieve nearly the same thing and i am sitting for hours on this problem to get the temperature (and precipitation) for the next hours from this new forecast service. I think this change is absolutely ridiculous. Before it was really easy and now I spent so much time to fix something that worked before. Hopefully you fixed your problem and I can understand what you did to fix my automations as well.
I assume you refer to the removal of forecast from the weather sensor … till now I have not seen any normal-human-readable justification that would allow to accept this for me as a user. Let’s assume there is one and just accept it (?)…or not, it won’t change…so do continue with setting up the separate (yes, sigh) forecast sensor and rebuild all the stuff on that.
However, the problem above seems to be a bit different
@jasonthefirst, OK ok. You have a template.yaml? If not, you need the template: around it and indent a level.
I have a helper datetime.test_sensor which I use to do tests. Changing it recalculates values. You need to adjust the trigger when the max-value shall get calculated as you like.
It seems to work fine. Still headshaking that all this is necessary to just get the temperature prediction for today. While the forecast_home from met.no entity already gives information about the weather condition. Guess it is current state despite the entity named forecast. But that’s fine I guess to decide for the day what to do. Only the current temperature is not sufficient to decide for the day.
- trigger:
- platform: state
entity_id: weather.forecast_home # this is my weather provider
- platform: state
entity_id:
- input_datetime.test_sensor
action:
- service: weather.get_forecasts
data:
type: hourly # change to hourly if you want hourly forecasts
target:
entity_id: weather.forecast_home
response_variable: hourly
sensor:
- name: Local Weather Forecast Hourly
unique_id: local_weather_forecast_hourly
state: "{{ now() }}"
attributes:
forecast: "{{ hourly['weather.forecast_home'].forecast }}" # note the array index with the weather provider name. This is what is different with get_forecasts (plural)
- trigger:
- platform: time
at: '10:01:00'
- platform: state
entity_id:
- input_datetime.test_sensor
sensor:
- name: 'max_temperature_today'
unique_id: 'sensor.max_temperature_today'
state: "{{ (state_attr('sensor.local_weather_forecast_hourly', 'forecast')|selectattr('datetime', 'lt', (now().replace(hour=23,minute=59)).isoformat()))| map(attribute='temperature') | list | max }}"
@vingerha What do you mean by “multiple automations doing the same condition”?
For instance the automation “Rolladen Tag Ende” (end of day)
Trigger: Time equals rolladen_heute_zu
Condition: Rolladen.Zustand is not Manuell
Actions: 1. call skript “Rolläden alle zu” 2. call service choose “Auto.Nacht” for Rolladen.Zustand
That is all. No condition is checked twice. It is in the category “Rolladen”, so I can hide it when I care about none-cover-things. Why should I touch another automation if the time for end of day changes?
I would have wanted that scenes could include other scenes. I would like not to use a skript for this, but if I define a scene for shut all covers, how can I include the scene shut all 1st floor blinds and all 2nd floor blinds? And how can the scene for 1st floor covers include the scene for living room shut, bathroom shut etc.? That’s the only reason why I use skripts instead of scenes. I don’t want to double the definition of “Schlitz” which is separately for every blind and may need corrections. Having it defined the same way in several scenes makes no sense.
Edit: Saw I used the wrong vocabulary for Rollladen. It is blinds what I mean, not cover.
First of all, donot expect me to understand what you want or what you have setup and why (frankly: donot care as this is your situation). You asked for a way on how to detect max temp, which I provided and I suggested to use as a condition and also suggested to use a sensor if you have multtiple automations based on the same … so you only need to have it in one place. Do with it what you like
edit
It is not ‘all this’ … your demand is particular to your request and depending on the underlying data you have to add templating. There is no ‘one size fits all’
Edit 2: you created a sensor but you could have done with a condition too.
First of all, I’m quite confident now with the situation and thank you for your help. I hope jasonthefirst now can/could adopt the solution for his installation. I don’t need an answer, just want to add this idea about weather forecast to “WTH section”, but I think many people complained about the forecast changes already. I hope my thoughts may help getting this sorted and improved, that is all.
Weather forecast:
I still must contradict. There is a dashboard card “weather” that displays the forecast for today. I need my automations to be transparent for the family, otherwise they won’t be accepted in the long term. The answer to the question “what will the weather today be like?” is not a requirement that only I have. Everyone needs that. If every person does a different implementation, that is a bad idea. Of course there are additional conditions like “the sun only shines at special hours/azimuth/whatever onto the window” or “I have a light/temperature whatever sensor which gives me the data if I should close or open”, these are individual. But the requirement to get a standard weather forecast is something anyone who deals with this kind of problems has.
You go on any website with weather forecast. weather.com, accuweather, whatever. It tries to get your location and then shows in big letters the predicted weather condition and the max/min temperature for today, tomorrow, next days. This is the information everyone immediately will understand and wants to use it because it is well-known. I wanted to use this information because the automations shall behave in a way which 1. is similar to what a human would do 2. can be understood without knowing anything about home assistant.
I show the dashboard using the met.no forecast, and it would have been my wish to have the automation for blinds using the numbers/conditions shown there. If my family looks at that dashboard, they can see why the blinds behave which way. Please note that I do not want to do the same calculation like the dashboard does. I’d like to have the same numbers. Preferably without the need to add a template sensor. It is ok the way it is now until the forecasts gets sorted in another (better!) way in home assistant. I do not say that the thoughts are wrong which made the last modification the way it was made, or that it is made without good ideas or that these ideas are implemented in a bad way. I say: The current implementation of weather forecasts in home assistant is not helpful for non-programmers to implement anything which needs weather forecast information to decide any condition.
It is a bad idea that everyone who wants to use weather information has to put a template in the configuration.yaml. This makes it difficult for people not in IT to ever use home assistant for that purpose.
Sensor/condition:
Regarding your Edit2: Using a condition I thought I would have difficulties answering the question “Why was this condition fulfilled at that time? Or wasn’t it?” Having a history available helps in case of unwanted behaviour to see the cause.
I ended up on this thread because OpenWeather changed their API and I’m not getting a forecast from them anymore. So I’m trying to rebuild what I had through them.
I’ve followed what everyone has tried to tell me. And I didn’t consider myself a novice. My Masters was computer modeling of sediment load in rivers. I’ve written hundreds of thousands of lines of code in my life.
But for the life of me I cannot get anything out of the forecast. I added Open-Meteo as an Integration and I’ve tried adding the template automation call as described but it keeps telling me I can’t add a sensor directly in the template.
So I have the automation up and running and it runs but it doesn’t have the forecast as a visible attribute. It shows the forecast in the info. But if never exposes the forecast. I tried referencing the forecast through the state_attr and it equals None.
I’m not sure what else to try.
