I had a simple automation to turn the heating on if the forecast for the next day is < x deg.
{{ state_attr(‘weather.home’, ‘forecast’)[1][‘temperature’] <= states.input_number.setpunt_verwarmen_aan.state|float}}
Now we have to use the (awful) get_forecast service.
Is there any way to do this within one automation now?
(without creating extra templates etc)
Do what exactly…? Is that template being used as a trigger, a condition, or part of an action?
Check the sensor entities being supplied by your weather integration. A number of the integrations have already been updated with forecast sensors.
If you need the value for a trigger and your weather integration has not updated yet, create your own sensor using a trigger-based template sensor.
It really doesn’t matter what it does.
In this case it it a simple automation that uses the forecast to determine if heating (or cooling) is needed. But ‘weather.location’, ‘forecast’ is depricated and have to be called with a service call weather.get_forecasts.
So to achieve the same simple functionality I have to make a template to read out the forecast then use that new entity. Or am I missing something?
Can the answer of a service call be directly used as a condition in a automation?
description: ""
mode: single
trigger:
- platform: time
at: "23:55:00"
condition:
- condition: template
value_template: >-
{{ state_attr('weather.home', 'forecast')[1]['temperature'] <=
states.input_number.setpunt_verwarmen_aan.state|float}}
action:
- service: input_boolean.turn_on
data: {}
target:
entity_id: input_boolean.verwarmen_vandaag
This it the full automation now.
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.
alias: Nieuwe automatisering
description: ""
trigger:
- platform: time
at: "23:55:00"
condition: []
action:
- service: weather.get_forecasts
metadata: {}
data:
type: daily
response_variable: weather_forecast
target:
entity_id: weather.home
- if:
- condition: template
value_template: >-
{{weather_forecast['forecast'][1]['temperature'] <=
states('input_number.setpunt_verwarmen')|float}}
then:
- service: input_boolean.turn_on
data: {}
target:
entity_id: input_boolean.verwarmen_vandaag
mode: single
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.
Ah I see, the template should be this:
value_template: >-
{{weather_forecast['weather.home']['forecast'][1]['temperature'] <=
states('input_number.setpunt_verwarmen')|float(0)}}
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).
seems you are using the incorrect target entity-id in the forecast template.
considering you have entity_id weather.home you should have
{{weather_forecast('weather.home').forecast}} or, its attributes
{{weather_forecast('weather.home').forecast[1].temperature}}
see this:
- trigger:
- platform: state
entity_id: sensor.date
action:
- service: weather.get_forecasts
target:
entity_id:
- weather.knmi
- weather.buienradar
data:
type: daily
response_variable: voorspelling_per_dag
sensor:
- unique_id: knmi_voorspelling_per_dag
state: >
{{now()}}
attributes:
voorspelling: >
{{voorspelling_per_dag['weather.knmi'].forecast}}
- unique_id: buienradar_voorspelling_per_dag
state: >
{{now()}}
attributes:
voorspelling: >
{{voorspelling_per_dag['weather.buienradar'].forecast}}
- unique_id: buienradar_voorspelling_condition
state: >
{{voorspelling_per_dag['weather.buienradar'].forecast[0].condition}}
binary_sensor:
- unique_id: buienradar_voorspelling_neerslag_binary
state: >
{{voorspelling_per_dag['weather.buienradar'].forecast[0].precipitation > 0}}
device_class: problem
and @Mariusthvdb
Such a hassle to get such a simple task done.
Unbelievable that they cut the forecast attribute away
you are doing it wrong so it seems
the template I suggested is inside the trigger based template for the service weather.get_forecasts.
it can not be used like that in an automation. Why don’t you use the resulting template entity inside the automation?
can you at least confirm the trigger based template entity is created correctly?
besides all of this, dont you have a forecast entity created by the weather integration itself?
these are all made by Buienradar, without using any get_forecast service at all:
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 
Yep that has done it.
I’ll make the default something that doesn’t trigger heating nor cooling.
@basbrus
Thanks for helping
@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.
Thank you both!
cool, np, and yw…
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)
Just the met.no weather integration.
but the forecast attribute was deprecated and is now a service call.
Check (and please vote while you are there )
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.
right! well, serves you right using a Norwegian service to get Dutch forecasts Use Buienradar and you’re set…
yes, I am aware, for some time. I did even see your copy of the original.
Imho, there’s no use. and I fear for you its a closed discussion, it wont come back
Met seems to not provide them at all.
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
I think it is because it is solved. I removed the marker for now so we can still discuss.
I’m aware of how to create a separate entity with forecasts but I think it is nicer to keep all code in one place. It was so simple and nice haha.
You see how a simple change can have lots of impact.
