You’re miss informed. You can get old attribute functionality back with a template sensor and the data will persist.
This posts shows what you do
It’s not a half thought out deprecation. This is a 3-4 year coming deprecation. Entities and attributes are shifting towards devices and entities. You’ll see these types of changes over the coming years.
Mea Culpa. I must apologise as I misunderstood what the weather template entity is doing. My above question was: will the templates for the forecasts generate data for the service calls. I asked that question before, only to be met an answer that I took to be that I should keep using attributes. From that I wrongly assumed the weather templates would still create deprecated attributes too - I misread the above answer and the documentation (which does not describe what the forecast should look like by the way).
I just tested it, and they don’t create attributes. So to answer my own question (in case any one else wonders the same): the forecast templates are used to implement the new forecast services. If you provide them, the template weather entity will work with the new services. I thought they didn’t. So I must agree that is is not half baked - I just misunderstood. Apologies.
For those following along at home, it took me awhile to figure out the new weather.get_forecasts (plural) service format, but now that I have it working, I thought I would share my updated templates:
Automation Trigger Template to get the forecast:
template:
- trigger:
- platform: state
entity_id: weather.forecast_local # this is my weather provider
action:
- service: weather.get_forecasts
data:
type: daily # change to hourly if you want hourly forecasts
target:
entity_id: weather.forecast_local
response_variable: daily
sensor:
- name: Local Weather Forecast Daily
unique_id: local_weather_forecast_daily
state: "{{ now() }}"
attributes:
forecast: "{{ daily['weather.forecast_local'].forecast }}" # note the array index with the weather provider name. This is what is different with get_forecasts (plural)
Now you can pull values from the forecast array like normal:
template:
- sensor:
- name: Local Forecast High Temperature Today
unique_id: local_forecast_high_temperature_today
state: "{{ state_attr('sensor.local_weather_forecast_daily', 'forecast')[0].temperature }}"
unit_of_measurement: °F
I find triger templates difficult to debug, so hopefully others find this useful! Probably should put some checks in for the case where get_forecasts fails, but that is a problem for future me.
my previous reply unfortunately didn’t work properly and needs some more testing
I had to change quite a bit, but has been steady and reliable since.
Old way with template sensor to update forecast data and 3 other sensors populated from that data.
- trigger:
- platform: state
entity_id: weather.forecast_stratford
- platform: time_pattern
minutes: /10
action:
- service: weather.get_forecast
data:
type: daily
target:
entity_id: weather.forecast_stratford
response_variable: daily
sensor:
- name: Weather Forecast Daily
unique_id: weather_forecast_daily
state: "{{ now().isoformat() }}"
attributes:
forecast: "{{ daily.forecast }}"
#Smartweather
- sensor:
- unique_id: forecasted_high_temp
attributes:
friendly_name: "Today's High"
state: >
{{state_attr('sensor.weather_forecast_daily', 'forecast')[0].temperature}}
unit_of_measurement: "°F"
- unique_id: forecasted_low_temp
attributes:
friendly_name: "Tonight's Low"
state: >
{{state_attr('sensor.weather_forecast_daily', 'forecast')[0].templow}}
unit_of_measurement: "°F"
- unique_id: forecasted_rain_today
attributes:
friendly_name: "Rain Chance Today"
state: >
{{state_attr('sensor.weather_forecast_daily', 'forecast')[0].precipitation_probability}}
unit_of_measurement: "%"
New way with “integrated” sensors.
#Weatherflow
- trigger:
- platform: time_pattern
hours: "/4"
action:
- service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.forecast_stratford
response_variable: daily
sensor:
- name: "Today's High"
unique_id: forecasted_high_temp
state: "{{ daily['weather.forecast_stratford'].forecast[0].temperature }}"
unit_of_measurement: °F
- name: "Tonight's Low"
unique_id: forecasted_low_temp
state: "{{ daily['weather.forecast_stratford'].forecast[0].templow }}"
unit_of_measurement: °F
- name: "Rain Chance Today"
unique_id: forecasted_ran_chance
state: "{{ daily['weather.forecast_stratford'].forecast[0].precipitation_probability }}"
unit_of_measurement: "%"
you can make your templates easier to manage by doing the following.
- trigger:
- platform: time_pattern
hours: "/4"
action:
- service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.forecast_stratford
response_variable: daily
- variables:
today: "{{ daily['weather.forecast_stratford'].forecast[0] }}"
sensor:
- name: "Today's High"
unique_id: forecasted_high_temp
state: "{{ today.temperature }}"
unit_of_measurement: °F
- name: "Tonight's Low"
unique_id: forecasted_low_temp
state: "{{ today.templow }}"
unit_of_measurement: °F
- name: "Rain Chance Today"
unique_id: forecasted_ran_chance
state: "{{ today.precipitation_probability }}"
unit_of_measurement: "%"
Thanks @petro for the hint with variables
As I couldn’t find this in the documentation I created a helper service to extract the data from the response_variable, this is now no longer required
This snippet will create the the response I had from weather.get_forecast
- trigger:
- platform: time_pattern
minutes: "0"
action:
- service: weather.get_forecasts
target:
entity_id:
- weather.forecast_66_whitney
data:
type: hourly
response_variable: hourly
- variables:
forecast: "{{ hourly['weather.forecast_66_whitney'] }}"
I further changed the forecast variable to
- variables:
forecast: "{{ hourly['weather.forecast_66_whitney'].forecast }}"
to get direct access to the forecast array which allowed to drop the first forecast from the forecast.forecast[] sensor templates.
This doesn’t work. Sensors all come up blank. And I did change the entity to the service I’m using.
post what you tried because it does work.
- trigger:
- platform: time_pattern
hours: "/4"
action:
- service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.pirateweather
response_variable: daily
- variables:
today: "{{ daily['weather.pirateweather'].forecast[0] }}"
sensor:
- name: "Today's High"
unique_id: forecasted_high_temp
state: "{{ today.temperature }}"
unit_of_measurement: °F
- name: "Tonight's Low"
unique_id: forecasted_low_temp
state: "{{ today.templow }}"
unit_of_measurement: °F
- name: "Rain Chance Today"
unique_id: forecasted_ran_chance
state: "{{ today.precipitation_probability }}"
unit_of_measurement: "%"
Tried seeing if it was the service but I could not find another service available that even supports daily forecasts. Accuweather, Openweathermap, and NWS all available from home assistant do not support the getforecasts service in a daily format.
That looks correct, but the entities will be unknown on template reload.
Just an FYI, you are right that NWS does not support daily in the service call, because it doesn’t support daily in general, but NWS does support twice_daily.
Maybe i am confused on how this is to be used. If the entities end up unknown, how do I get the forecast data from them?
It triggers every 4 hours. If you want data on startup, add a startup trigger
It’s been well over 4 hours. The entities show no data.
Not sure what to tell you, the code is correct unless you put it in the wrong spot of your configuration. Check for errors in your logs.
I guess that’s what I get for updating.
Just look in the logs for errors, you have to be doing something wrong. There’s no way around that. This is working for me and many other people. Your logs or the entities themselves will show you what’s going on. If you’re unsure, post your text logs and screenshots of the entity.
The other thing to try is goto UI->DeveloperTools->Services(tab)
and in the text box fill in something like the following (YAML mode)
service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.pirateweather
Hit the “Call Service” button and see what the response is.
Because this is way too complicated (seriously - why not just have forecasts as an attribute in the weather sensor??? Forcing a template for basic functionality is ridiculous), and because several of the answers are flat-out broken, here is a working template sensor for daily and hourly forecasts, using Pirateweather:
template:
- trigger:
- platform: time_pattern
hours: "/4"
- platform: homeassistant
event: start
action:
- service: weather.get_forecasts
data:
type: daily
target:
entity_id: weather.pirateweather
response_variable: daily
- variables:
today: "{{ daily['weather.pirateweather'].forecast[0] }}"
sensor:
- name: Pirateweather Daily Weather Forecast
unique_id: pirateweather_forecast_daily
state: "{{ now().isoformat() }}"
attributes:
forecast: "{{ daily['weather.pirateweather'].forecast }}"
- name: "Pirateweather High"
unique_id: pirateweather_forecasted_high_temp
state: "{{ today.temperature }}"
unit_of_measurement: °F
- name: "Pirateweather Low"
unique_id: pirateweather_forecasted_low_temp
state: "{{ today.templow }}"
unit_of_measurement: °F
- name: "Pirateweather Rain Chance Today"
unique_id: pirateweather_forecasted_ran_chance
state: "{{ today.precipitation_probability }}"
unit_of_measurement: "%"
- trigger:
- platform: time_pattern
hours: "/1"
- platform: homeassistant
event: start
action:
- service: weather.get_forecasts
data:
type: hourly
target:
entity_id: weather.pirateweather
response_variable: hourly
sensor:
- name: Pirateweather Hourly Weather Forecast
unique_id: pirateweather_forecast_hourly
state: "{{ now().isoformat() }}"
attributes:
forecast: "{{ hourly['weather.pirateweather'].forecast }}"
Most of the other things posted in this thread are missing ['weather.pirateweather'] (or whatever your weather sensor is) as a lookup in the map on the forecast variable, and of course trigger-based templates are effectively impossible to debug outside of trial and error.
I would love to see this as an attribute in the weather domain. Home Assistant updates are supposed to make accessing information easier, not harder. I understand that the Home Assistant project prefers breaking changes to having legacy code stick around, but the fact that something as basic as “is it going to rain in the next 2 hours?” requires multiple nested templates when it used to be relatively straightforward is IMO ridiculous.