The recent announcement in the September release suggests that the weather entities are being nerfed in favor of service calls. My challenge here is that service calls cannot be used in templates, and as a result, we can no longer access weather in templates. This feels like a huge oversight.
The general response is to create a template sensor through the UI, but the problem here is that blueprints do not have a means of doing this for you. As a result, blueprints are no longer able to interact with weather in any meaningful way without the user also taking a bunch of extra steps to get it deployed and then to get the entity names to line up etc.
What is the plan here? If we’re removing the ability to directly interact with weather via templates, and thus blueprints, is there some suggestion as to how to handle this instead?
That is exactly what I’d need! Let me dig into this, I’m pretty sure this would work. Thanks @tom_l and pre-emptively thanks @petro for the original answer
The response_variable bit is the new thing I was missing. This really unlocks a lot of functionality (including solving for my weather problem) and man now I have a lot of code to review to figure out how to use this cool tool. Thanks for pointing it out!
Reading further, I’m now starting to realize what a step backwards this is in terms of performance and it’s hard to understand why.
In the existing blueprints the weather entity is set as a trigger, so whenever new weather info is available, the blueprint runs and sends the new info to the display.
The new approach is worse in two key ways:
I now have to poll a service at some interval. Previously, my code only ran when it needed to, now it has to run every minute no matter what.
I now have to push the result to the display every interval. Blueprints do not allow me to persist any data, so I have no idea what happened with the last trigger, so now I have to push out the new value with every update cycle.
All of this adds up to making overall performance worse, because I’m stuck polling the service call to find updates instead of just being triggered when (and only when) an actual update happens.
Right, but that doesn’t address the device side. Because I cannot persist the previous state of the forecast in my blueprint, each run of the polling interval has no idea if the new result is the same as the last, so I have to shove the data to the device every interval regardless.
The issue here is that we lose the trigger condition when the forecast updates.
Your trigger will be the same, just don’t include the forecast attribute, it’ll use the state object change instead.
You really don’t. On a technical level it appears you do. However on a practical level, using a state trigger without specifying the state is almost identical to using a state trigger looking at the forecast attribute. Reason being, the forecast will roll into the current attributes each time the forecast changes, causing the state object to update. Functionally being the same.
trigger:
- platform: state
entity_id: weather.xyz #Triggers on ANY stateobject change.
forecast will roll into the current attributes each time the forecast changes
So currently a weather object will have attributes like current temperature etc. It will also have some forecast attribut for tonight or tomorrow or 3 days from now etc. That forecast is not tightly defined and can be different for each provider. Are you suggesting that a change in the “3 days from now” forecast attribute, which is not reflected by any of the other attributes (eg, it’s not the current temperature), will still trigger the state entity?
This makes the somewhat confusing situation where state triggers now will trigger on updates which don’t appear to have any changes (because none of the entities left changed, only the forecast which isn’t an entity any more), but it would for sure solve my issue.
typical weather entities have a main state and ~15 current attributes. The likelihood of forecast changing and one of the ~15 attributes not changing is almost impossible, especially when the weather integrations work off a polling frequency of 1 hour or 5 minutes (depending on the integration)
Allright, I hope this doesn’t sound like arguing here as I just want to make sure I’m clear on the new situation.
Based on your take above, my read is that forecast updates no longer update the main entity, and the best that I can get is to trigger on the entity and just hope that forecasts, when updated, also have some other update that will trigger my blueprint. Likewise, accept the fact that a bunch of updates will be sent to the device which might not have been necessary, because I can no longer trigger on a change of the forecast and have to rely on some other update as a proxy.
Does that align with your understanding? I can live with that and will just note it in the blueprint description.
edit: I should note that this is still LOADS better than polling the entity and just pushing out changes every cycle. Triggering on the entity plus getting the service call into a template solves for like 98% of my concerns here.
