[PETITION] Don't delete the forecast attribute

Feature Requests
232

My example shows all attributes which I can see in dev tools. Because of that my question. There are no more tons of other attributes (and even this would then not a technical reason but only the assumption/hope that anything else would change). Therefor my question which attribute of e.g. met.no would change and trigger 100%?

I don’t care about the usecase, Nor pushing it back. Don’t have a clue why a technical question to understand background is pushed in this direction now.

I only want to understand it, why it is technically the case that it is 100% triggering without the forecast-attribute-upate (if state and the other attributes in my example stay as before). If you are sure, why it is not possible to explain it?

If the answer is: No not 100%, but only in assumption that everything else will >95% change at least in between and therefor trigger, completely fine, but then the ultimateness in the answers above that it will trigger by design and not only by hope is perhaps not right from a programming point of view.

233

Im not sure what you mean, but in your example the condition: changed from “sunny” to " clouded" , maybe a “hickup” or not relevant to your context, but every hour the next coming “forecast-condition”, will become “current-condition” etc , but that will always occur, regardless if the forecast is an Attribute to “Current-Entity”, but if it’s currently build so the this/these changes “wipe the table” so to speak, and write the whole thing again, Current + All Attributes, not ( -1"old/staled" + 1 “new” ) all states(attribute.state) changes every hour , no matter what .
Im not a programmer, and i know ofcause not much about the functionality within HA and its components, And the DB type ( time-serie ) but the State here is the conditions, not the “datetime”, which in this case i would find most logic in a forecast

234

Yep.

Basically, if you if you have hourly forecast, the [0] item moves into the weather attributes when the hourly will change. I.e it will change. Most of these integrations only update on a polling frequency and the likelihood of the above case is extremely low based on how the data will move through the forecast to the other attributes. I’m sure there are some weather integrations that might be an exception, but most work this way.

2 Likes
235

Thanks. Then I get it, what you and Tom wanted to point out.

236

It sounds like there’s only one polling interval per integration. Correct? That is, given a 5-minute interval, it’s doesn’t seem of practical value to do both because it would use up more of a fixed allocation of requests.

237

This is also something that could be taken into consideration, i.e Requirements upon Weather-integrations/Weather-cards, optional updates intervals, whether it’s template/entity or remote-API-call, … options to set update value, as it’s most often an “individual requirement/need”, which some are using for other entities/devices//automations/templates/purposes. the more one stuff into i.e the DB( State-engine ) , and the more people want in their views, and the more their Recorder “stores” etc, all individual factors, out of control from the Devs.
People have to remind them self, that it all comes with a cost

Ohh well i guess this is just what this Topis is :laughing:

238

Trying to get my head around these changes.

I like to count how many hours in the next 24 forecasts are going to be over a set point, so I know how many hours to run my air conditioner, which I do in one line of YAML:

image
image945×258 28.6 KB

To do the same thing now, do I need a trigger: action: and sensor: ?

2 Likes
239

yes. Or an automation with action and condition. Depending on the use case.

240

Just make a sensor

template:
- trigger:
  - platform: time_pattern
    minutes: 1 # 1 minute past the hour, every hour
  action:
    - service: weather.get_forecast
      target:
        entity_id: weather.noosa_heads_hourly
      data:
        type: hourly
      response_variable: hourly
  sensor:
  - name: Hours Above Set Point
    unique_id: hours_above_set_point
    state_class: measurement
    unit_of_measurement: count
    state: "{{ hourly.forecast[:24] | selectattr('temperature', '>=', states('input_number.emhass_deferrable3_set_point') | int) | list | count }}"
1 Like
241

Thanks for your help and the clarification, does seem a bit regressive.

242

This sucks. (Does this count as signing the petition?)

(I’d type more but I need to allocate that time to re-writing a ton of shit.)

1 Like
243

That’d be more:

  1. Vote at the top
  2. Be more constructive :stuck_out_tongue:
5 Likes
244

So this is done in order to reduce the number of attributes for a sensor.
Then I guess the media_player will be next as in my system, with limited Favorite stations, that one is ~1200bytes each for my current 6 players. The weather is only ~1400bytes once.

245

No it is being implemented to improve performance.

Your media player is not the default situation for everyone using that integration. The weather forecast was the default situation for everyone.

And as home assistant is supposed to run on low end hardware like a raspberry pi, this is important.

Though now that you have brought this to light, sure we can do this for the media player too, I’ll get right on making a pull request…

That was a joke, I’m not a developer and you can sort your media attributes out yourself if you have issues with performance.

3 Likes
246

And to add to the above, the media_player is handled totally different in the code, than other things like the weather. The media_player isn’t handled in the state machine, it is handled outside of it. At least as far as I know! :slight_smile:

Whereas the weather was handled in the state machine and therfor the attributes are taking up too much room. That’s it! As explained by Paulus in the release video, one weather entity with its attributes used more space than 30 different sensors (I think it was 30, not sure, could be more). If it really interests you, and it’s not just “I want to be p***, because!”, than here is the link to the YT video of the release party, forwarded to Paulus statement about it. Listen to it, it really is interesting.

3 Likes
247

Will do later tonight, thanks for the link.
Off course my comment was made without knowing the inner architecture of HA. It just strikes me as odd the situation with the mediaplayer and the weather. Why not do the same thing for the weather as for the mediaplayer then and leave the attributes? Not trolling, really interested in that.

248

I told you why.

1 Like
249

I didn’t either. That’s why I made some dumb posts above, that I meanwhile deleted, and am still thinking about, if an explicit excuse is necessary to some people…

Moving on, I’m sorry, but in the last months I get more often the feeling, people are just here to troll, so I ask directly, to know where I stand. Sorry, if this came of rude or offensive. :slight_smile: Wasn’t meant to! No hard feelings! :slight_smile:

And without further explanation I wouldn’t have thought about it either. The state machine needs to save every information of every entity. Until now, everytime the weather provider is called, the state machine needs to set a lot of entites with values that are the exact same as before, as a forecast doesn’t change that often.

As if that wouldn’t be enough motivation to change something, the weather entity has another pitfall. In theory, the forecast is nothing else than another weather entity, just XX days in the future. So technically what is done here, is to safe complete entity values in an attribute of another entity. Just like you would safe all information about all lights in your house as an attribute in one of your lights.
That not only takes a lot of space in the state machine, it simply is unnecessary, because you don’t need to have a state associated with it (a state for the attribute forecast). If you need a state, it should be its own entity.

I can’t say why the media player is handled differently, but I speculate, that it has something to do with the media file itself. The bit value of an mp3 file in a state machine isn’t even possible, I believe. :thinking:

But that doesn’t apply for the weather entity. If you will, you could say the weather entity wasn’t handled right up until now, as there is no need for an exception just for the weather. It should be handled the same way, all other entities in HA are handled. And that is, what this change does. It “normalizes” the process.

Does this clear it up a little? :blush: Or does it make it even more complicated? :laughing:

2 Likes
250

Thanks Patrick, that clears up a lot to me. I like your analogy with with the lights.
Appreciate you are taking the time and explain in more detail the workings/background.

As Tom mentions this impacts almost all users as just Met.no is already used by 74% of the users, my HEOS integration has only 4% (sonos 14% seems similar style though).
Anyway the change has happened, let’s move on.

2 Likes
251

AUTOMATION SUGGESTION:

The change automation user interface (UI) does not seem to support the new change else then through yaml entry.

My case is a actual automation trigger of forecast cloudy that now to be change to a service call request. Before the change the forecast cloudy was in the condition of the automation. Now as I understand it need to be added in action portion of the automation as a service call request. The request itself is well supported by the automation user interface (UI). Its easy to define a “response” . But when it comes to using that “response” variable in the condition of subsequent action the only UI function available is template. Which is calling for deeper knowledge of the response format in YAML.

Would it be possible for users without yaml knowledge to do as with the new trigger ID condition and offer a choice of available response.parameter to use next in the condition. So the template format is transparent to users wihtout the need to address it via yaml.

Thanks for reading suggestion.