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.
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.
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:
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.
The forecast attribute was deliberately removed as part of a general initiative to minimize the use of attributes. Its removal was announced last September (2023).
The examples in this topic are several months old and predate the change of service call (last December) from weather.get_forecast (singular) to weather.get_forecasts (plural). That’s why the older examples use the response_variable without an explicit reference to the weather entity (because it could only contain data for a single weather entity whereas now it can be more than one).
“Several months old” (not even a year, this topic is barely 6 months old at time of posting) and it’s gone through several breaking changes to the point where most of the information is incorrect? And who knows if my reply will even be correct in 2-3 months. The speed of breaking changes is ridiculous.
I’ve been using HASS since 2016, and I even contributed integrations myself (I am the original author of the Todoist integration, way back when). The fact that it’s been 8 years and the speed of breaking changes means I’m still looking up basic things like “how to write a template sensor” (since all my old template sensors broke) is silly. I’m a programmer as well, and I prefer being able to open an IDE and look at everything in one spot rather than having to pick through a bunch of GUI windows.
Removing attributes is something I can get behind… if they are given an easy, built-in, get-it-for-free alternative (e.g. another sensor). Having to make someone write a cryptic template to replace formerly built-in functionality for something as basic as “is it going to rain soon?” is really silly, IMO.
Regardless, this isn’t really the topic for that - I just wanted to provide a working (as of March 2024) template for others, as this page appears near the top of the Google results when someone is looking for how to get Home Assistant to tell you the hourly forecast for use in things like automations.
Two changes; remove attribute, improve service call.
In this particular case, the elimination of the attribute had a grace period of 6 months (ended this month). The service call evolved from handling single to multiple weather entities within the grace period.
Basically, a fairly pedestrian pace for changes and now the older examples in this topic are outdated (the eventual fate of many examples in this forum).
There should be. Check the device in integrations page and enable entities that you want.
An example for this is the accuweather integration. All the forcast information is separated into separate entities.
If that’s not the case for whatever weather integration you’re using, make a feature request for that integration.
The 6 month grace period is both for users and integrations to catch up with whatever the change is. This doesn’t always happen, and in those cases feature requests or issues should be raised.
All the solutions in this thread are band-aides for users to get back the exact same entity they previously had instead of rolling with the changes.
Alright jumping in on this thread now that 2024.4 is out and the forecast attribute has been removed. I updated a templated weather provider for my use case:
Start with a weather entity from the OpenWeather integration
Create a template weather entity combining a local sensor with the forecast from OpenWeather
Display this new entity in the weather-forecast card
I was unable to call the service weather.get_forecasts for either Accuweather or OpenWeathermap integrations. OpenWeatherMap did support an “hourly” data type. I am now forced to go to a HACS integration Pirate Weather based on code shown above which is working. If the roadmap is to remove attributes that is ok, but the solution to have to create a template sensor in configuration.yaml for Weather forecast is a step backwards and the next release needs to address this.