It might be a bit tedious, but you can test your templates in devtools
Run the service call in devtools > services and copy the output
Put that in a yaml to json convertor like: Transform YAML into JSON - Online YAML Tools
Then start the devtools > templates section with: {% set buienradar_forecast = json output from website %}
After that you can do all the testing you want.
And trigger based template sensors are only processed on the trigger, if you want them to be processed when you want, you can:
add a HA start trigger and restart HA
add a template reload trigger, and reload template entities
add an event trigger with something like event_type: reload_weather_forecast and send that event from devtools > events
add a state trigger on a state change from a test input_boolean
Thank you!
that is what I was looking for… argh, I hadnt thought of that, sorry, indeed silly, all clear now, full data set is presented just nicely.
yes, I am aware of all the triggering options, and as described used that in the starting up config. Now only use the date to update, and as usual these trigger based templates are restored (on startup), so took out that trigger again.
What I just hadnt realized is that using the homeassistant.update_entity service does Not update trigger based entities.
using the homeassistant.update_entity service would have the same problems as using Run automation from the GUI. It won’t have a trigger, so everything which is based on trigger variables won’t work.
And I personally have a lot of trigger based template sensors which rely on trigger variables.
Regarding the Weather Forecast Service how do get forecast in the template weather now? If the forecast attribute will not be present, then it turns out that I will not be able to use it in the template weather, and the service cannot be called there. Or will I have to make crutches, get forecast in other entities and then substitute it into the template?
in the release thread brought up again this use case in my mind as well.
How to trigger security things on e.g. upcoming temperature or wind speed things when they show up in the forecast from now without periodically call the call-service and react on the response?
Because with this periodically calls and/or one to many templates entities to replace the attribute from before with entities now, I have still the same (or more) data in the state machine as before and most probably more calls/update as delivered before from the weather integration, haven’t I?
Or is the background/guiding principle/assumption, that only few users are doing it and then having the same state machine situation as before and the majority of the users are not using such scenarios and not needing them and so most of them have benefits from the change?
That would just be a binary_sensor using a trigger, action, and your calc.
Marius above has a good example doing just that. You can add as many binary sensors as you want.
You’ll have less data in the state machine, unless you put all the forecast into an attribute on an entity. And at that point, it will be the same amount of data as before.
Depending on what weather integration you use, that will be less calls/updates. ATM none of the weather providers have the service perform a call, they cache the data and return the cashed data on service call. So, it’s the exact same number of calls as before to the endpoint.
Great solution…
How will forecast work in the Template weather if there is no forecast attribute? And why produce extra entities?
If we remove the attribute, then in the Template weather sensor for forecast we need to specify the entity_id of the parent weather, and then the template sensor, when accessing it for forecast via service call, will receive it from the specified weather, and then all new cards will work correctly.
I (we?) want forecast as state. Why? To react on state changes. So sure forecast can be deleted from attributes but then we need a separate state entity for forecast. Why? Because state machine has a lot of side capabilities apart from keeping state like polling data and notifying of state changes. Why push it to template automations if this is already happening as part of the state machine? I don’t care about forecast and don’t want to call services to get forecast data as long as sun is shining. But as soon as forecast changes from “sunny” to “shitstorm”, I want my home to act accordingly. How to achieve that without forecast as state? Time triggers? But state machine is already doing just that by polling data through integrations regularly, right?
It would work the same way as all other weather integrations. You’d use the service to get the data, but using the entity in the weather card would display the forecast like it does for any other weather entity.
Because you want to use it in that template, which does not have the ability to call a service. That integration probably needs an update to support the action or it needs to be rethought for extracting forecast data. I.e. a new field that doesn’t use a template, instead gets the forecast from a different weather entity.
yes, I understand that. But think of a forecast as state. Simple as that. Would you still need forecast as weather attribute if you could just have weather.forecast? Or actually better yet forecast.weather (forecast.solar_wind, forecast.sun etc)?
So here we are, a topic with more than 170 posts, a lot of nerves lost and some insults later…
And for what? That we still come back to the one thing that would have solved all of this upfront: communication! As easy as it could be to just say a few explaining words, no that needs a topic for the eternity…
@luka6000
You need to see the broader picture. There is no need for data to be in the state machine, when it is only updated every few hours. That is a problem, and if explained seems more than reasonable. So to get unnecessary data out of the state machine, there is now a specific possibility to configure your forecast as you want it. Daily, hourly, weekly. And it is only polled, if necessary.
So for what you want it to work, you need to do nothing. The update weather cards will take care for you of that.
You’d only need to change something, if you are already working with some template thingies for the forecast. If not, this change doesn’t concern you.
As I said above, it is all about the communication, and explaining things for users. I’m still convinced, that this discussion would have been avoidable, if only someone from the team would have asked the dev team for a few explaining words…
Would you still need forecast as weather attribute if you could just have weather.forecast?
Well states have a 256-char limit, so it couldn’t go in the state anyway.
Or actually better yet forecast.weather (forecast.solar_wind, forecast.sun etc)?
The idea of a forecast domain has been brought up before, and I made a proposal for how it might work - it would be a little unintuitive if you don’t want it to be polling all the time though.
I don’t agree with you on state machine. My cellar light changes state every few days or a few times a month and yet it’s state is in state machine where it belongs.
You describe weather forecast completely from frontend perspective. And the purpose of state machine is not only to hold state but also to trigger state changed events for automations to react on.
Now, how can we do this automation without forecast state attribute?
As I’ve already said, I don’t care what the forecast is (apart from morning routine). I want my automation to react on changes. And for that I’m using state machine.
