Thanks. Then I get it, what you and Tom wanted to point out.
It sounds like there’s only one polling interval per integration. Correct? That is, given a 5-minute interval, it’s doesn’t seem of practical value to do both because it would use up more of a fixed allocation of requests.
This is also something that could be taken into consideration, i.e Requirements upon Weather-integrations/Weather-cards, optional updates intervals, whether it’s template/entity or remote-API-call, … options to set update value, as it’s most often an “individual requirement/need”, which some are using for other entities/devices//automations/templates/purposes. the more one stuff into i.e the DB( State-engine ) , and the more people want in their views, and the more their Recorder “stores” etc, all individual factors, out of control from the Devs.
People have to remind them self, that it all comes with a cost
Ohh well i guess this is just what this Topis is 
Trying to get my head around these changes.
I like to count how many hours in the next 24 forecasts are going to be over a set point, so I know how many hours to run my air conditioner, which I do in one line of YAML:
To do the same thing now, do I need a trigger: action: and sensor: ?
2 Likes
yes. Or an automation with action and condition. Depending on the use case.
Just make a sensor
template:
- trigger:
- platform: time_pattern
minutes: 1 # 1 minute past the hour, every hour
action:
- service: weather.get_forecast
target:
entity_id: weather.noosa_heads_hourly
data:
type: hourly
response_variable: hourly
sensor:
- name: Hours Above Set Point
unique_id: hours_above_set_point
state_class: measurement
unit_of_measurement: count
state: "{{ hourly.forecast[:24] | selectattr('temperature', '>=', states('input_number.emhass_deferrable3_set_point') | int) | list | count }}"
1 Like
Thanks for your help and the clarification, does seem a bit regressive.
This sucks. (Does this count as signing the petition?)
(I’d type more but I need to allocate that time to re-writing a ton of shit.)
1 Like
That’d be more:
- Vote at the top
- Be more constructive
5 Likes
So this is done in order to reduce the number of attributes for a sensor.
Then I guess the media_player will be next as in my system, with limited Favorite stations, that one is ~1200bytes each for my current 6 players. The weather is only ~1400bytes once.
No it is being implemented to improve performance.
Your media player is not the default situation for everyone using that integration. The weather forecast was the default situation for everyone.
And as home assistant is supposed to run on low end hardware like a raspberry pi, this is important.
Though now that you have brought this to light, sure we can do this for the media player too, I’ll get right on making a pull request…
That was a joke, I’m not a developer and you can sort your media attributes out yourself if you have issues with performance.
3 Likes
And to add to the above, the media_player is handled totally different in the code, than other things like the weather. The media_player isn’t handled in the state machine, it is handled outside of it. At least as far as I know! 
Whereas the weather was handled in the state machine and therfor the attributes are taking up too much room. That’s it! As explained by Paulus in the release video, one weather entity with its attributes used more space than 30 different sensors (I think it was 30, not sure, could be more). If it really interests you, and it’s not just “I want to be p***, because!”, than here is the link to the YT video of the release party, forwarded to Paulus statement about it. Listen to it, it really is interesting.
3 Likes
Will do later tonight, thanks for the link.
Off course my comment was made without knowing the inner architecture of HA. It just strikes me as odd the situation with the mediaplayer and the weather. Why not do the same thing for the weather as for the mediaplayer then and leave the attributes? Not trolling, really interested in that.
I told you why.
1 Like
I didn’t either. That’s why I made some dumb posts above, that I meanwhile deleted, and am still thinking about, if an explicit excuse is necessary to some people…
Moving on, I’m sorry, but in the last months I get more often the feeling, people are just here to troll, so I ask directly, to know where I stand. Sorry, if this came of rude or offensive. Wasn’t meant to! No hard feelings!
And without further explanation I wouldn’t have thought about it either. The state machine needs to save every information of every entity. Until now, everytime the weather provider is called, the state machine needs to set a lot of entites with values that are the exact same as before, as a forecast doesn’t change that often.
As if that wouldn’t be enough motivation to change something, the weather entity has another pitfall. In theory, the forecast is nothing else than another weather entity, just XX days in the future. So technically what is done here, is to safe complete entity values in an attribute of another entity. Just like you would safe all information about all lights in your house as an attribute in one of your lights.
That not only takes a lot of space in the state machine, it simply is unnecessary, because you don’t need to have a state associated with it (a state for the attribute forecast). If you need a state, it should be its own entity.
I can’t say why the media player is handled differently, but I speculate, that it has something to do with the media file itself. The bit value of an mp3 file in a state machine isn’t even possible, I believe. 
But that doesn’t apply for the weather entity. If you will, you could say the weather entity wasn’t handled right up until now, as there is no need for an exception just for the weather. It should be handled the same way, all other entities in HA are handled. And that is, what this change does. It “normalizes” the process.
Does this clear it up a little? 
Or does it make it even more complicated? 
2 Likes
Thanks Patrick, that clears up a lot to me. I like your analogy with with the lights.
Appreciate you are taking the time and explain in more detail the workings/background.
As Tom mentions this impacts almost all users as just Met.no is already used by 74% of the users, my HEOS integration has only 4% (sonos 14% seems similar style though).
Anyway the change has happened, let’s move on.
2 Likes
AUTOMATION SUGGESTION:
The change automation user interface (UI) does not seem to support the new change else then through yaml entry.
My case is a actual automation trigger of forecast cloudy that now to be change to a service call request. Before the change the forecast cloudy was in the condition of the automation. Now as I understand it need to be added in action portion of the automation as a service call request. The request itself is well supported by the automation user interface (UI). Its easy to define a “response” . But when it comes to using that “response” variable in the condition of subsequent action the only UI function available is template. Which is calling for deeper knowledge of the response format in YAML.
Would it be possible for users without yaml knowledge to do as with the new trigger ID condition and offer a choice of available response.parameter to use next in the condition. So the template format is transparent to users wihtout the need to address it via yaml.
Thanks for reading suggestion.
Forgive my lack of understanding, but is there any reason HA couldn’t just add a UI drop down menu in the weather integration configuration to select what forecast data is desired (ie high temperatures x5 days) and how often you’d like the forecast data to be refreshed, and keep the truncated forecast data as an attribute instead of using a service call? I’d be fine with twice a day, three times a day, or four times a day refreshes, but I’ll still need to store the relevant forecast data somewhere.
I use the forecast high temperature data in three binary sensor template entities to identify when to open the windows to regulate the indoor temperature with passive air flow. I just moved them from the YAML configuration to the new UI template helper, but it seems I would have to move it back to the YAML to utilize this trigger action template get_weather service call.
I would have to poll the API three times every so often for the same forecast high temperature data instead of pulling it from cache. Although perhaps I could make a new template sensor to get the weather data and store it as attributes for my other binary sensors to reference, similar to the original weather forecast attributes… seems redundant until HA sunsets the original attributes.
I also use the forecast conditions to look for snowfall in the next 48h to warn me in my daily briefing TTS script. It is helpful to know when I come home if it will snow tomorrow so I can wake up early and scrape the frost/ice/snow off the vehicle before I commute to work. I suppose I’d have to use the get_weather service in the automation before this briefing is announced.
that’s not how that works, the weather integrations have their own internal caches, it is not calling the api every time.
Wait, are you saying the weather data is already cached but the only way to access the cache is through the get_weather service call and not the former attribute?