The forecast attribute of weather entities was deprecated in 2023.9. I’m not entirely sure I understand how to get the latest weather forecast using the new service.
For example, let’s say I want to know if it’s forecast to rain in the next hour and send a notification to take in the laundry. We’ll assume my weather integration of choice is well behaved and only polls the API at set intervals so it doesn’t hit its limits. Right now I simply have an automation triggered by a state update on the weather entity. Or I can template the forecast attribute to its own entity and trigger off that. This means my automation is run (or my template entity is updated) the moment new data is available.
Under the new system I need to call the service to get a forecast. I assume that under the hood my weather integration will not actually call the API each time, but instead will call it at set intervals and cache the response then serve that up to me when I call the service. My issue though is that I don’t know when the API is being called so I have know way to know when there is fresh data available.
For example I have seen that the intended solution is to call the service every hour. But the trouble with that is that I can’t align with the polling interval of the API. i.e. if I am unlucky I might call the service 1 second before it was due to poll for new data. So my data will always be an hour out of date. This problem is somewhat exacerbated if the API is not polled often and/or I live in an area with highly changeable weather.
All of which is to say - is there any way to listen to the integration to know when it is grabbing a new forecast?
Alternatively I could set the trigger action to every minute (instead of every hour), but I’m not sure if that’s ok. Would it cause issues with performance/logging to run it so frequently?
To be honest, the whole attraction of Home Assistant is being able to trigger actions off events like state changes (like Google Home/Alexa routines but more powerful and with wider compatibility) so it feels like a bit of a backwards step to need to schedule things like this. Especially as there has been so much great work lately in making things more user friendly and trying to hide away some of the more technical workings. But this honestly isn’t meant to be a rant - I just want to know what the intended flow is meant to be for this scenario and to understand how new users are meant to discover it.
Automations are pretty lightweight. Many template triggers already implicitly trigger every minute. Heavy actions and templates would be a greater concern. But 5 min would maybe be a good interval too, depending…
No different from the way it has always worked. The hourly forecast you get from the weather entity’s forecast attribute is retrieved by your weather integration according to whatever polling rate it uses. When you reference that forecast data, you don’t know how ‘fresh’ it is other than it might be a few seconds or many minutes old.
That’s not quite what I meant - I was talking about the freshness of the data relative to the last API fetch. You’re right of course that the API is polled at some interval but my point was that needing to call the service to get the forecast means adding a second polling interval on top of that, i.e. an additional layer of delay. Currently the forecast attribute provides whichever data was fetched last time the API was polled, without me needing to know when that was.
That’s a good idea! Technically it relies on some attribute of the weather entity having updated which isn’t necessarily guaranteed (state and attributes only update in the state machine if they are changed) but in practice it seems likely that there will have been some change in conditions 99% of the time. I think I will go that route. 5-minute check would also work well but still slightly worried it would increase DB writes (I’m using an SD card) so I think I will go with the former.
It’s my understanding that it’s not a second polling, it’s merely a different way to get the data that was already retrieved the last time the integration performed its polling. The main difference is that the polled data is not stored in the state machine. So to get it, you can’t use state_attr(), which retrieves attribute data from the state machine, you use the new service call.
Well, since the forecast is not in the attributes any more it’s possible for the polling to happen (and a new, changed forecast to be available) without any of the weather entity’s attributes changing. In practice that’s highly unlikely though because it would require all of the current conditions to remain the same.
