Yes you can do it within that automation. The key part is to move the condition into the action part after you have called the get_forecast service. I choose personally to wrap it in a if/then action.
The response variable is only accessible if the full automation is triggered. If you manually trigger the automation each action is triggered separately, so each actions is unaware of previous actions.
In your case it means you have to wait to 23:55:00 or change the time for testing purposes.
I initially tested it with the weather.get_forecast service but that one is already depreciated.
I did change it to weather.get_forecasts when posting the snippet, without realizing that that service packs everything inside an additional dict with the entity_id(s) as key(s).
The main goal as from OP’s first post was to handle it within a single automation. Which can work with response variables.
Second the last error is not caused because the template cannot read the forecast temperature, but because the entity input_number.setpunt_verwarmen seems not to have a correct value. @SBeukers you can do two things. Check whether the input_number entity_id is correct and it has a proper number as state value. Change | float to float(0) or any number other than zero (within the brackets) that should be the default state of the input_number.
well, it could, but it is a bit convoluted. And, it would be a pity to only use that response inside that single automation.
if using that service and creating the response variable, why not keep it for further reference, and set a template entity. It would also allow displaying it in the Dashboard.
but again, if its only for daily forecasts, this whole exercise probably isnt necessary as the weather integration provides the entity (temp for the next day) out of the box.
agreed, floats and ints should get the default value in the template, has been for years now, and has nothing to do with the rant about the deprecated forecast attributes
@Mariusthvdb also many thanks.
I am aware of the call only providing the value for this automation now.
It’s only called once a day. Otherwise I have to make a complete new entity for a value that could easily have been (and was till now) just an attibute.
I still am very curious to the integration you’re using. and, if it doesn’t provide the value you’re interested in as an entity now out of the box (it should)
I guess the problem is that some of the integrations disable those entities by default, like Buienradar does. That can be not straight-forward for those that are unaware of that.
I don’t think they gonna change it back as attributes are not considered as the place where datapoints and forecasts can be placed within the HA architecture. The same holds for pricing data and other types of forecasts/large dicts.
Sjoerd could however recreate the original forecast attribute by running the service like I posted above.
Next, his original template would probably still work. it would take a 1 time effort
Tbh, I have no real need for this myself, and only made it for the sake of experiment, and to be able to use that forecast attribute and do stuff like this:
series:
- entity: sensor.buienradar_voorspelling_per_dag
name: min.
yaxis_id: temp
unit: °C
type: line
color: green
data_generator: |
return entity.attributes.voorspelling.map((entry) =>
{
var date = new Date(entry.datetime);
return [date, entry.templow];
});
show:
datalabels: false
- entity: sensor.buienradar_voorspelling_per_dag
name: max.
yaxis_id: temp
unit: °C
type: line
color: '#FFBF00'
data_generator: |
return entity.attributes.voorspelling.map((entry) =>
{
var date = new Date(entry.datetime);
return [date, entry.temperature];
});
show:
datalabels: false
- entity: sensor.buienradar_voorspelling_per_dag
name: Precip
yaxis_id: mm
unit: mm
type: column
color: '#6495ED'
data_generator: |
return entity.attributes.voorspelling.map((entry) =>
{
var date = new Date(entry.datetime);
return [date, entry.precipitation];
});
in an Apexcharts card:
hmm, cant upload a picture anymore using the button
