Which mode did you chose? Did you stick to the default hourly?
Just for reference: I’m not satisfied with the default OWM implementation in HA. Especially as owm provides a daily report that directly gives out the min/max temperatures for a day. So no need for calculations.
I set up my own sensors using a rest_template as follows:
- name: owm_report
platform: rest
resource: 'https://api.openweathermap.org/data/2.5/onecall?units=metric&exclude=minutely,hourly&lat=<lat>&lon=<lon>&appid=<apikey>'
scan_interval: 600
value_template: '{{ value_json.current.temp }}'
unit_of_measurement: '°C'
json_attributes_path: "$.daily[0]"
json_attributes:
- temp
- clouds
- platform: template
sensors:
weather_today_max_temp:
friendly_name: 'Today Max Temp'
device_class: temperature
unit_of_measurement: '°C'
value_template: '{{ state_attr("sensor.owm_report", "temp")["max"] }}'
weather_today_min_temp:
friendly_name: 'Today Min Temp'
device_class: temperature
unit_of_measurement: '°C'
value_template: '{{ state_attr("sensor.owm_report", "temp")["min"] }}'
weather_today_clouds:
friendly_name: 'Today Cloudiness'
unit_of_measurement: '%'
value_template: '{{ state_attr("sensor.owm_report", "clouds") }}'
7 Likes
Much better! Thx a lot!
Maybe it would make sense to ask the maintainer of the OWM platform to include this within the official platform? 
PS: The OWM One Call API is being implemented (Convert OpenweatherMap Integration to use "one-call-api"). So just be patient… 
1 Like
I like your solution, but I am a bit confused since temp and temp_min/temp_max are always the same in my installation. Now I found this in the OWM API docs:
Please, do not confuse min/max parameters in our weather APIs.
In Current weather API , Hourly forecast API and 5 day / 3 hour forecast API - temp_min and temp_max are optional parameters mean min / max temperature in the city at the current moment just for your reference. For large cities and megalopolises geographically expanded it might be applicable. In most cases both temp_min and temp_max parameters have the same volume as ‘temp’. Please, use temp_min and temp_max parameters in current weather API optionally.
At least for the free subscription plan this might not be what you want?!
PS: Sorry, my mistake. You are using the new One Call API which indeed does provide day min/max temp (daily.temp.min).
Thanks for your feedback.
So we can hope to switch back to the owm plugin in some weeks?
Hi, many thanks for the code. It´s generally working. Now I have two requests.
- How can I round the decimal of the temp, i.e. 26.45 to 26.5
- I tried to modify the api code for using the !secrets=myapikey or !secrets:myapikey implementation without success. How is this possible, is there a solution available?
https://api.openweathermap.org/data/2.5/onecall?units=metric&exclude=minutely,hourly&lat=<lat>&lon=<lon>&appid=!secrets=myapikey
I did not move the apikey/appid to secrets. Because, if anybody would get knowledge of it, I don’t care. It’s a free service with no personal information.
If you want it in secrets, you have to move the full url to secrets, and then use resource: !secret openweatherurl
Like this solution. Basic question, the I assume need to be replaced by actual values or are these subsituted by HA? If so: where does the apikey come from?
This works great! Thanks.
Please forgive my question I am a HA beginner, but how do I integrate your template?
First part in the configuration.yaml and the second as manual automation? 
Hi
IMHO you don’t need the template anymore since the OWM integration uses OWM one call API to provide forecast information directly:
https://openweathermap.org/api/one-call-api
Therefore, you can just write something like this in your automations:
conditions:
- condition: numeric_state
entity_id: sensor.openweathermap_forecast_temperature
above: 20.0
The only thing that may be missing is a cloud coverage forecast. But there is a current cloud coverage sensor (sensor.openweathermap_cloud_coverage).
HTH
Thorsten
1 Like
If it helps, here’s how I did it:
First, I have a sensor collecting forecasted temperature 1 day from now:
# Buienradar weather data
# https://www.home-assistant.io/integrations/sensor.buienradar/
- platform: buienradar
monitored_conditions:
- temperature_1d
From what I saw, this sensor switches max forecasted temperature around 2am at night.
So I implemented a SQL sensor that queries the max forecasted temperature between current time yesterday and last midnight
(I record my data in a local MariaDB)
# Determine max forecasted temperature for 'today'
- platform: sql
db_url: !secret mariadb_url
queries:
- name: max_temp_fcst_today
query: >
SELECT date(date_add(last_updated, INTERVAL 1 DAY)) AS date, MAX(state) AS max_temp
FROM home_assistant.states
WHERE entity_id = 'sensor.br_temperature_1d'
AND last_updated BETWEEN DATE_ADD(NOW(), INTERVAL -1 DAY) AND CURDATE();
column: max_temp
unit_of_measurement: °C
In other words: I went back into my history to retrieve the forecasted temperature, rather than trying to collect a forecasted temperature for today when I need it.
Another approach if you’re not comfortable with writing SQL statements would be to use an automation that writes the state or attribute of a (sensor) entity into an input_number entity at a given point of time. You can then use this over a certain interval while the source changes.
I have a similar problem as others. I would like to use our local weather forecast from switzerland (HACS, Meteoswiss integration).
Using the template editor in development tools with the template {{ states.weather.basel_binningen }}, I get the following response:
<template TemplateState(<state weather.basel_binningen=lightning; temperature=27.3, humidity=51, pressure=973.0, wind_bearing=E, wind_speed=9.7, attribution=Weather forecast from MeteoSwiss (https://www.meteoswiss.admin.ch/), forecast=[{'datetime': '2021-06-21', 'templow': 17.0, 'temperature': 26.0, 'condition': 'lightning-rainy'}, {'datetime': '2021-06-22', 'templow': 16.0, 'temperature': 23.0, 'condition': 'lightning'}, {'datetime': '2021-06-23', 'templow': 15.0, 'temperature': 24.0, 'condition': 'lightning-rainy'}, {'datetime': '2021-06-24', 'templow': 15.0, 'temperature': 22.0, 'condition': 'cloudy'}, {'datetime': '2021-06-25', 'templow': 14.0, 'temperature': 22.0, 'condition': 'rainy'}], friendly_name=Basel / Binningen @ 2021-06-20T13:07:57.922758+02:00>)>
My question as a template newbie: How do I get the forecast temperature of the next day out of this with a template? I assume this must be the the temperature in forecast[0], but this is how far I get
Hi,
I’ve managed to use the weather.xxx_hourly entity to get the forecast for the current day.
Fist you need to head over to Integrations, select Home. There will be a disabled entity for an hourly forecast, enable it.
You can then use the same array notation, but it will give you the forecast for the hour you indicate rather than the day…
{{ state_attr('weather.xxx_hourly', 'forecast')[4].temperature }}
3 Likes
HEllo,
could somebody help me to extrct the data from my local weather?
http://daten.buergernetz.bz.it/services/weather/district/6/bulletin?format=json&lang=de
And this was the parameter to extract for the precipitation of the day: $.forecasts[0].rainTo
How can i implente the value from raintto in a condition for a automation?
Thanks a lot
Philipp
1 Like
This is a late reply, but might help somebody.
I’d suggest to use NodeRed which can manipulate data and create a node sensor that will provide you with the desired data.
A working example for those still struggling.
Step 1) Extract the desired attributes and create a separate entity for them.
Configuration.yaml:
template:
- sensor:
- name: Forecasted Precipitation
unit_of_measurement: "mm"
state: "{{ state_attr('weather.forecast_hourly', 'forecast')[0].precipitation }}"
- name: Forecasted Temperature Tomorrow
unit_of_measurement: "°C"
state: "{{ state_attr('weather.forecast', 'forecast')[1].temperature }}"
- name: Forecasted Temperature Day after Tomorrow
unit_of_measurement: "°C"
state: "{{ state_attr('weather.forecast', 'forecast')[2].temperature }}"
Step 2) Create an automation
alias: Sunscreen out to prevent heating the house on warm days
description: ""
trigger:
- platform: numeric_state
entity_id: sun.sun
attribute: azimuth
above: 119
alias: Before the sun hits the house on the South side.
condition:
- condition: or
conditions:
- condition: state
entity_id: sensor.season
state: spring
- condition: state
entity_id: sensor.season
state: summer
alias: During spring and summer;
- condition: and
conditions:
- condition: numeric_state
entity_id: sensor.forecasted_temperature_day_after_tomorrow
above: 21
- condition: numeric_state
entity_id: sensor.forecasted_temperature_tomorrow
above: 21
alias: When the next two days are forecasted to be warmer than inside;
- condition: numeric_state
entity_id: sensor.forecasted_precipitation
below: 0.1
alias: When no rain is to be expected in the next hour;
- condition: numeric_state
entity_id: weather.forecast_hourly
attribute: wind_speed
enabled: true
below: 5.1
alias: With not to much wind expected in the next hour (meters per second);
- condition: device
# Device_id is generated for you if you use build the automation using the UI.
device_id: 6afa398809a08778afda1b614e
domain: cover
entity_id: cover.sunscreen
type: is_position
enabled: true
below: 40
alias: When the sunscreen is not opened already;
- condition: numeric_state
entity_id: zone.home
enabled: true
above: 0
alias: When somebody is home.
action:
- device_id: 6afa398809a08778afda1b614e
domain: cover
entity_id: cover.sunscreen
type: set_position
position: 41
alias: Open sunscreen a bit to prevent warming the house!
mode: single
HINT: Use something you use to perform easy tests as an additional trigger such as a button/switch during testing.
3 Likes
I created a automation and lovelace card for controling my awning/sunscreen,
Hope to help and inspire others: GitHub - remb0/Sunscreen: Sunscreen-Awning project
It’s work in progress and I have a wishlist with things like: actionable notifications, blueprint, shutter integration and other improvements.
1 Like