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?
from what I understand it can vary by weather integration, but the weather integration holds the forecast data in an in-memory cache so it does not hit the API every time the service is called
1 Like
Hi , I am trying to understand how to use template in an automation that use weather forecast. It does not seem I get the response I am expecting from the automation service call.
The service call in the automation is :
service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.granby_forecast
response_variable: response
The choose function is as follow
conditions:
- condition: template
value_template: ‘{{ response == ‘‘cloudy’’}}’
which fails . Its not possible to debug and see the response from the automation
So testing in developer tool template I have the following:
{% set response = states(‘weather.granby_forecast’) %}
{{response}}
{{ response == ‘cloudy’}}
with result:
cloudy
True
(please note this works very well in the actual automation in the condition field not using the service call as follows: )
condition: state
entity_id: weather.granby_hourly_forecast
state: cloudy
Any clue to help ??
The value of the response variable produced by this example:
{% set response = states('weather.granby_forecast') %}
{{response}}
{{ response == 'cloudy'}}
Is nothing like the value of the response variable produced in this example:
service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.granby_forecast
response_variable: response
If you look at the bottom of the page in the Weather integration’s documentation, it shows you what the value looks like. It’s a list where each item in the list represents the forecast for a separate hour (type: hourly) or day (type: daily).
Your Template Condition must specify which item in the list it wants to use and then refer to that item’s condition key.
For example:
- condition: template
value_template: "{{ response.forecast[0].condition == 'cloudy' }}"
2 Likes
Thank you effectively that works .
Might be you can help me further to help myself next time. In the spirit of give me a fish I will be happy for the day , give me a fishing rod and you will make me happy for life.
In debuging in general I try to follow the trace of the error . In this case I wanted to know what is the intermediary value of “response” in the automation call for service . I did check the help page you refer too and tried to use the developper tool template.
With the following :
{% set response = states(‘weather.granby_forecast’) %}
{{ response.forecast[0].condition == ‘cloudy’ }}
Expecting a True value if the response has the same shape as help page suggest , I got UndefinedError: ‘str object’ has no attribute ‘forecast’ .
Any suggestion as to how to see the result of the response variable as provided in the automation as a suspect similar problem might occur for other service call request on other kind of calls .
Agrain gratefully thank you for your time and support .
Just use the developer tools services section, you can call the service and it will tell you what the response is
You got that error because the template you created is invalid.
You appear to have taken bits and pieces from what I explained and put them together into something that cannot work.
Thanks again for you time in replying to above discussion. I did not take bits and piece from your information believe me . I spend many hours before contacting you in testing all kind of alternative in the /developer-tools/template including the solution you provided. Which failed in the /developer-tools/template and I dont understand why??
Interesting I did find a few solution that did work properly in the developper template tool but the result did not in the automation because as you are saying its not the same format as the call service weather forcast.
One of being :
{% set response = state_attr(‘weather.granby_forecast’,‘forecast’) %}
{{ response.condition == ‘cloudy’ }}
My question is in regards to the template developper tool (/developer-tools/template) usage . Is there a way to get the very same response provided by the service: weather.get_forecast in the tool properly. What form should the request be in the tool?
Please, I understant that help page for service: weather.get_forecast at the bottom of the page is providing the format of the service call. To my understanding homeassistant template developper tool is the tool provided to developpers to get to test templates. So I need to be able to get, in the tool, the same result I would get in the automation service call request . Otherwise I cant use that tool. If that was overlook in the developpment of the weather service call , it should be corrected .
So my question is simple . How can I get the same response ( service: weather.get_forcast , entity_id : weather.granby_forecast ) in the template developper tool .
Knowing that the following request is not good then what is :
{% set response = states('weather.granby_forecast') %}
The Template Editor is for testing templates. You can’t use it to test service calls and this is a service call:
service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.granby_forecast
response_variable: response
Thanks Taras, Fare enough . Noted as this applies to all service calls .
The automation needs a template format to address the data in two steps, call the service, then apply template to its response. And the template cant be tested in the developer testing tool since service call cant be call from the template developer tool.
Acknowledge