[PETITION] Don't delete the forecast attribute

[parautenbach (Pieter Rautenbach)]

@HeyImAlex

Wouldn’t that imply that the various forecasts under that domain would again end up in attributes ?

I think one needs to consider the options. Even if it does, at least it’s isolated and can get special treatment, rather than being a side-effect of sorts. That’s why I want to find the discussion I read before. I’ll check again later.

[boheme61]

@parautenbach

I think one needs to consider the options.

Yes, One don’t need to use the term/concept “attribute”, it’s relevant data(often used in atuomations/templates/graphs for controlling various “interests/functions” , it’s most often a “nice” time-serie structured array( few kb in size, updated regularly( peace of cake even for a time-serie DB ), which fits in a BLOB.
Not entirely in a cache, with only option to make the integration perform another API-call( to in some cases payed services), as “fallback”

[KTibow (Kendell R)]

That might actually work. It solves most of the problems with the current method and with service calls.

The only con is that it doesn’t solve the problem with the forecast being fetched when it’s not needed, and I’m not sure how to move forward on that - here are some possible ways though:

• Just continuously fetch it (as we do right now)
• Make the user create an automation to fetch it (as is done with some other integrations, and as is being proposed with the service calls)
• (Possibly adding on to one of the above) Create a more complicated system of knowing when it needs to be updated, eg continuously fetch it if the weather card is open on any systems or if any templates rely on it? 🤷

[parautenbach (Pieter Rautenbach)]

@KTibow

Make the user create an automation to fetch it (as is done with some other integrations, and as is being proposed with the service calls)

This would fit in with the removal of scan_interval that’s been ongoing.

[parautenbach (Pieter Rautenbach)]

@parautenbach

I’ll check again later.

Here is the idea of a specific forecast entity:
Sensor entity value forcasting / prediction · home-assistant/architecture · Discussion #667 (github.com)

The other one that was interesting, was this comment by Balloob:

I think that we should create a generic way to handle forecasts, for anything. I’ve played with the idea of data sources in the past, but that got kinda stuck for being too similar to services.

Air quality only Weather entities · home-assistant/architecture · Discussion...

Last one, closed to say “we’re not adding more attributes”:
Ability to add “optional” fields to weather forecasts · home-assistant/architecture · Discussion #925 (github.com)

[arganto]

@HeyImAlex

For the met.no integration, for example, the forecast data is requested from the cloud at some rate (completely independent of the service call rate) and stored in an array in memory (the cache). That data will then be returned when you call the service call, directly from memory. Means it is reused everytime you call the service, regardless from where and how often. It is stored only once for that entity.

Hm. But again, where is the benefit to remove the attribute? Or at least leave them for those who want to use ist. If I understood correctly in your example

• the data is this case is pulled from Cloud as often as before
• the data is still cached/stored
• already before it wasn’t stored in history db

But now it would introduce that we have visible sources like states and Attributes, where I can always check via Dev tools and use via templates what is there. Directly and holistic complete. And now in addition a hidden set of data which I cannot directly see and check and use for debugging or checking but only see or unhide with one or many service calls and on top never know if they are reliable old or new. Some kind of Schroedinger hidden data in HA

For me the opposite of easynes and/or transparency.

[DudeShemesh]

@parautenbach

Why not a new forecast domain? Besides weather forecasts, we already have solar forecasts built in too. It will fit nicely and define a way forward for other kinds of forecasts too.

Why do we need a new domain? What if a weather integration had several weather entities - one for current, one for tomorrow, etc…? (It’s a very long discussion so sorry if this was already brought up and I missed it)

[parautenbach (Pieter Rautenbach)]

Because there’s more than weather that can benefit from it. Read that whole piece you quoted again.

[DudeShemesh]

I read that before posting, but I don’t think this is the right approach. A weather forecast is different than a solar forecast, and in the same way that the original entities for the current state are different domains, I think the future state should be represented by those different domains.

[parautenbach (Pieter Rautenbach)]

Well, I posted some other ideas too. I don’t have strong convictions about this particular one, but without a full development of this idea or any other, it remains opinions and ideas. I’m just trying to get a conversation going that can lead to an actual solution instead of complaining.

[pocket (Rob)]

I think I have a good reason why it’s a bad idea to eliminate the forecast attribute. It’s the limit on the number of characters in a string, which is 255. While it’s good for most forecasts, it’s insufficient for the more important ones.

My favorite weather integration will often add additional detail the more near-term the forecast is. As stormy weather approaches, the amount of detail increases and many times the forecast for the current day or night is over the entity limit. The attribute has no limit I’m aware of.

[makai]

PR merged

Example in that PR:

template:
  - trigger:
      - platform: time_pattern
        hours: /1
    action:
      - service: weather.get_forecast
        data:
          type: hourly
        target:
          entity_id: weather.home
        response_variable: hourly
    sensor:
      - name: Weather Forecast Hourly
        unique_id: weather_forecast_hourly
        state: "{{ now().isoformat() }}"
        attributes:
          forecast: "{{ hourly.forecast }}"

[DudeShemesh]

Yeah, I’m all in favor of a discussion, and if I came off as dismissive of your idea, that was definitely not my intention. Quite the contrary - my suggestion builds on top of yours.

[Edwin_D]

I’m all for finding solutions for the changes to come, but in this case it is hard to see the added value.

Weather api’s should not be called too often, so forecasts need caching as they will likely end op on a dashboard. Cynical me would say, the attribute we already have is that cache. As long as it is not stored in the db, all is fine. Users and components already should know how to get to attributes. If you replace it service calls, both users and UI components need to learn new tricks.

Requiring the integrations to add caching in favor of a cleaner weather platform design adds complexity. There are multiple weather integrations but there is just one weather platform. They will all implement a form of caching.

Services hide what information is available in the documentation. Entities and attributes data is there for any one to see. Chances are people won’t know the forecast data is there to use if you need to call a service to get it.

And guess what: some users will create a template to store the (cached) service call data in… an attribute, so they can get to it more easily. Those who don’t understand how to use services will copy such a solution form this forum, because it will get the info in a place they understand. And then we cache it twice. And if they don’t configure the recorder it it also lands in the database.

I agree we should avoid attributes when we can, but the rule should not be dogmatic and architecture choices should be made in service of user experience. In this case, we seem to have endless discussions how users should work around the new design. Users do not benefit from ever growing ways to retrieve data. That just adds confusion.

[123 (Taras)]

@makai

Example in that PR:

Yup, I had copied that example from the PR when it was still a ‘request for comment’ (up until about 2 days ago when its development was rekindled and expedited).

Now it will be included in 2023.9.0’s documentation for the Template integration:

A big thanks to allenporter and emontnemery for implementing this feature in time for the September release; it will simplify the task of getting calendar events and weather forecasts (and other things).

---

BTW, this comment intrigues me:

Perhaps, as a side-effect, this PR also fulfills a long-standing Feature Request:

Support Variables in Template Sensors

Release 0.115 introduced Variables for automations and scripts. Variables would also be useful for creating Template Sensors, Template Binary Sensors, Template Switches, etc. For example, here’s a Template Sensor I use to report the quantity of open doors. It also has an attribute reporting the names of all open doors. The two templates it uses are nearly identical. open_doors: friendly_name: 'Open Doors' value_template: > {{ expand('group.doors_all') | selec…

[KTibow (Kendell R)]

Based on that, here’s a proposal:

• 1 entity for the current weather
• Each type of forecast gets an entity
• If a forecast is viewed from the UI and its data is stale, a service is called to update it
• If you want to use the forecast in a template/automation, you need to call the service to update it

The con is that the user has to create an automation to call the service, and if they don’t they might be like “why is my forecast only updating when I have HA open?”

[KTibow (Kendell R)]

I don’t think this is the proper solution (it’s something extra to set up, it pollutes the recorder, it’s just reproducing the previous intuitive behavior), and I’m scared that this will cause the HA team to reject any other solutions.

[petro]

I believe it does. As a sidebar, adding a template that calls a service is not off the table, it just requires a complete rewrite of the templating engine to use async. It’s a bit harder to do at the moment because of that.

[tom_l]

This is not a good solution. At least when the forecast was polled users could not set the polling interval to 1 second. And now that they can someone will do this.

[crzynik (Nicolas Mowen)]

@pocket

It’s the limit on the number of characters in a string, which is 255.

I don’t know where you’re getting that number, but that is definitely not the limit on the length of a string that is held in memory