[PETITION] Don't delete the forecast attribute

Feature Requests
192 
template:
- trigger:
    - platform: state
      entity_id: weather.home
  action:
    - service: weather.get_forecast
      target:
        entity_id: "{{ trigger.entity_id }}"
      data:
        type: daily
      response_variable: home
  binary_sensor:             
    - name: It's gonna rain
      state: "{{ home.forecast[0].condition in ['hail', 'lightning', 'lightning-rainy'] }}"

Or if you don’t want the binary sensor…

alias: _aaaaaaaaa_dev_weather forecast
description: ""
trigger:
  - platform: state
    entity_id: weather.home
condition: []
action: 
  - service: weather.get_forecast
    target:
      entity_id: "{{ trigger.entity_id }}"
    data:
      type: daily
    response_variable: home

  - condition: template
    value_template: >-
      {{ home.forecast[0].condition in ['hail', 'lightning', 'lightning-rainy'] }}
mode: single

There’s a number of ways to do this

3 Likes
193

Yeah but your light state value is tiny compared to a forecast. That amount of data does not belong in the state machine.

194

Is 30 kb of forecast that much when it’s only ever stored in memory?

1 Like
195

Apparently, or the change would not have been made.

1 Like
196

Why do you assume weather state can be a trigger for forecast changes?
There is a number of ways to replicate this behavior and none that actually replicates the behavior of tracking forecast changes. Like time triggers, right? Only proper way without forecast attribute. But state machine integration polling is already doing that.

197

Because the code under the hood assumes that for attribute state changes :wink: Attribute state changes don’t work the way you think they do.

198

Since there are changes to the domain, all entities in the domain should work the same way. Since Template weather is part of the Weather domain, the weather.get_forecast service should work with it. In the same way, the weather map will get forecast using this service inside itself and not from attributes, which is logical and uniform.
And since everything will work with the service get_forecast, it is necessary to change the template weather, for example, like this:

# Example configuration.yaml entry
weather:
  - platform: template
    name: "My Weather Station"
    condition_template: "{{ states('weather.my_region') }}"
    temperature_template: "{{ states('sensor.temperature') | float }}"
    temperature_unit: "°C"
    humidity_template: "{{ states('sensor.humidity') | float }}"
    forecast_entity_template: "weather.my_region"

And then when we use the weather.get_forecast sercice we get the chain, template_weather → target weather from attribute forecast_entity_template → forecast.

199

Yes, that’s what I was saying when I said:

200

1 light yeah, but a few colored light-strips with all it’s Attributes and your there :wink: , i still believe there is somehow a wrong Focus upon how this should be addressed in a Homeautomation-Sustem ( functionality/stability in it’s core, for “Important” factors of a Homeautomation system ( Which BTW SHOULD keep on running regardless if cloud-connection is lost, bc of i.e a storm

201

What attribute are you talking about? You no longer have forecast attribute. You mean any weather attribute change will trigger the automation but I don’t think you know what I think and the attribute state changes just work as they are. Forecast is a future state of weather but still a state.

202

If there is no forecast attribute, there will be no change trigger on that attribute.

203

well sorry. That’s just how it is with weather. If current weather is not to big for stare machine then future weather aka forecast also should fit in there, right?

204

State change triggers trigger off the whole state object, not just the state itself. When you narrow it down to an attribute, it attempts to compare the before and after states of the attributes (within reason). The forecast would cause it to trigger on every state object update, same with all other attributes. What I posted above will be equivalent to your previous trigger.

205

Right, which is why I removed it from the trigger…

206

Do I understand correctly that there will be changes to Template Weather to accommodate these changes?

207

No, I’m saying “this should be done”.

208

Wrong. Current weather is only one hour/day. Forecasts are for multiple hours or days.

1 Like
209

So the developers haven’t thought about it yet?
Or thought about it and it will be done later, or forgot and then there will be a surprise?
Or you don’t have that information?

210

your example will not trigger if there was only forecast change (current weather state with all limited attributes not changed) while in my example and 2023.8 would trigger on forecast attribute change. Of course you can trigger get_forecast action on any state changes but what’s the point of doing that? Will it work? Sure. It it better than what we have? No.

211

Actually im sure they have, changes have already been made in that repository( haven’t checked the details thou), most likely do to this release, so might come in next … However i STILL would love this data in my HA DB, , not wiped from cache/sensors bc of a “reboot”, The Datas of Tommorows, day After Tommorows etc. is still highly reliable to keep i.e Automations/Templates/Triggers running without cloud-connection to retrieve NEW ( I Gues it’s very few here which think/believe/want that their HomeAutomation system to function during/after an i.e heavy storm, which in some case causes NO internet for days up to weeks … But considered the “changing” climate we all might have notice, im sure a few more eventually will find that, wth, My Phone wont load properly from HA RPI ( ps, just a silly example) … Ban Me

1 Like