Thanks, Tom could you maybe help me understand the mistake I do, given that I cannot make this thing working. I have a dedicated template.yaml file to which I link to in the configuration yaml and use the follwoing code(s). Unfortunately, none of these sensors give any value back:
Does this mean the template weather sensor has code to return the forecast template as a result of the new forecast service? The documentation is not clear on that. If it just feeds the deprecated attribute, it will not be future proof.
Correct, it’s going to break when the “forecast” attribute of the integration’s sensor goes away due to changes in background weather polling. A “forecast” key will still be returned by the weather integration when the get_forecast service is called. You’ll need to build a trigger template that calls the weather.get_forecast service and copies the resultant data into this weather sensor template.
I really thank you for helping out here. It is by no means your fault, but I am a bit frustrated with the half thought out deprecation of the attribute. In it’s current form removing the attribute break things that cannot be fixed as it is now.
A major reason of a weather template sensor is to use it in weather cards. If the weather template cannot implement the service then it defeats the whole purpose. The weather card can only use the service once the attribute is gone. So eventually this will break (if it isn’t broken already).
At the same time, the service was meant to prevent the attribute, and every post about this that I read is all about putting the service call data in an attribute. So we’ll have a service that needs a cache, plus a self made attribute that holds the same data. The official attribute was at least excluded from the recorder by default. Self made attributes won’t be, so the current change will often lead to more recorded data unless people are smart enough to exclude them.
Template/MQTT weather entities need to implement the service one way or another. From an architectural perspective the move is perfectly sound and logical, but the practicallity suffers as a result here.
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.
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.
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.
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.