Help I had a simple automation to turn the heating on if the forecast for the next day is < x deg

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
2 Likes


Doesn’t work (yet)

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.


Ok I changed the time to let the whole automation fire but the same result.

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).

1 Like

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 :wink:

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!

1 Like

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 :wink: )

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. :wink:

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 :wink: 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.

I think this should solve the problem in general.

which would that be?

didnt you test Help I had a simple automation to turn the heating on if the forecast for the next day is < x deg - #4 by basbrus

which does exactly what you ask for?

That’s a workaround(which I am very graceful for) but not a solution.