[PETITION] Don't delete the forecast attribute

Feature Requests
1

In Home Assistant RC 2023.9, the HA team has changed forecasts from attributes to a service reply. This does have some upsides (no forecast spam in devtools, no duplicate weather entities for different forecasts, etc), but overall it’s a bad decision. Here are 3 reasons why it doesn’t make sense.

  1. Service replies are used for responses from actions, such as generating an image based on a prompt. However forecasts are static, and fetching them doesn’t have any effects. See point #3 for the speed implications of this.
  2. This breaks templating. You can’t get the forecast from a template because you can’t call a service from a template, as it doesn’t make sense for a template to perform an action. Now, you can technically get around this by creating an automation to fetch forecast data into an entity, but come on. This is just simulating the previous behavior to work around a bad decision.
  3. I don’t have any data on this, but this seems intuitively bad for performance. Every time you have a weather card, it has to call the service to get the forecast (instead of just using the entity that’s already cached). Every time the service is called, either it has to re-fetch the data or use some sort of complicated cache. It would make more sense to just group updating the forecast in with updating the weather (how it is done now!)

This has a deadline. If nothing happens, on Sep 6, HA 2023.9 will be released with the change included. Actually it’ll just deprecate the attribute - however, after Mar 6 2024, the worse method will be your only option.

If you disagree with me, of course you can explain your opinion in a comment, but if not I’ll thank you for “signing” this petition by voting on it - hopefully we can stop this change.

2

Would have been “appropriate” if you had linked to this, just saying ( im to lazy to try an find it ) , on the other hand i think there should be some kind of explanation/reasoning involved in this decision, which could “come in handy” for people wondering i.e where you got the “delete attribute” from.
To be honest i thought, forecast was “updated” “periodically” from “provider/integration” , and the Card cached in browser, updating when forecast provider/integration change state (ones an hour or so)

I do however have a template for “fetching” this also ( as i use it in graph-card )


              return entity.attributes.forecast.map((entry) => 
              {
                var date = new Date(entry.datetime);
                
                return [date, entry.temperature];
              });

im not sure how often this template/graph-card “calls” the integration/entity (maybe updating every 10 min or so, even thou it’s hourly/daily forecast ?), then maybe a “Service” (set to update cording to datetime, once an hour/once a day) would not be that bad for performance ? … or how do you think ?

3

Here’s a link for you: https://rc.home-assistant.io/blog/2023/08/30/release-20239/#weather-forecast-service

Well with the current architecture, the weather forecast is updated with the weather, and can be accessed at any time as an attribute. This makes sense as the forecast doesn’t change often, and the data can be cached on the client (as in: the method you’re already using takes almost 0 time to run) instead of having to make a service call to get the info.

4

isn’t it an api-call every 10min or more wih this template/graph-card ?

point is i only need it once an hour/day

1 Like
5

Well right now it’s up to the backend to update the forecast, and the states system does the work of propagating the forecast change to the frontend. I’m not entirely sure how you set up your template, but it shouldn’t need to do anything at 10 minute intervals (unless that’s the interval it runs your template at, in which case it’s basically instant).

8

Same here, I’m using it in templates as well, and while the idea above with an automation and a trigger based template is nice, it’s still a workaround.

+1 for not removing

1 Like
9

Point 2 is my main concern.

10

consider the scenario where an item in the forecast attributes is taken in to account in ones cover templates.

We’d now have to trigger that automation with the new forecast service to make this up to date (if I even grasp what that service returns, and where it returns it…)

tbh, this is a change without true real life effect for the HA system, (especially if one doesn’t record the attributes in the first place), but a mere theoretical one (keep large attributes out of the DB…)

knowing very well every one using those will now create their own attributes storage.so the result may possibly be worse than status quo.
And a heck of a lot more complex and involved for the user. So much for streamlining the HA experience.

tbh, this feels a bit like checking a weather app, only being served the current rain. and having to click an extra click for seeing what one actually needs: the forecast.

What else is a weather service for than showing the forecast. It’s the main thing of interest?
And future HA hides it behind a wall of internal complexity.
Please dont.

6 Likes
11

As im ( as alot others ) is “picky” upon how my data is exposed, i had to make a combination of 2 different Cards in vertical stack( + above template in 5 places) and card_modded … + 250 rows ( I know, if i could make my own Card, i could “bury” this in a .js file )
I do to wonder what/where and how a service-response will expose these data, in a way that i find appealing and useful. And how many extra rows of codes i have to write to make some kind “personalization” by splitting up a Service-Response.

( And no, i still don’t have any Scripts/Templates/Automations controlling my i.e Heating.System or Daily Tasks, through these “Attributes”, lucky me :slight_smile: )

01.09.2023_10.34.47_REC

I did look at the “Beta release note” above and even tried to find some kind of “reasoning” in dev-.home-ass-.io. and GitHub, but neither :frowning: , then again i got this “uncomfortable” feeling that HA is going towards a full-blown “Mushroom” experience :zipper_mouth_face: ( i bet we’ll soon see a weather-card in the “mushroom.collection”)

1 Like
12

Tile cards are being developed as it will make “drag and drop” organisation easier to implement. However this does not mean support for custom cards is being abolished. So not sure why you are feeling uncomfortable.

2 Likes
13

What I think we need - and this has been hinted at elsewhere - is the ability to call services within template sensors: either by allowing scripting (actions) in these sensors or by having jinja functions that can get data from services. This would make it unnecessary to have automations that poll services and then pass data to entities via events. I think this would help here and for the calendar service too.

However, even with this I think the removal of attributes from weather will make it much harder for newbies to access forecast information.

14

Tile Cards is another thing yes( and i also find them appealing in certain Views/Cards ) , but i think it’s inspired by “mushroom” (in it’s style!), And yes i know Mushroom is (still) a custom-card, and also has become more and more “flexible” , which i like , but still looking at the topics it’s obvious that people(and me) find a extensive need to Card-mod them, and using template with/in them(or service-calls)

Anyway as Paul (it’s no offense !) , is involved in more than just Mushroom, i believe he has a huge impact in the ideas which are evolving HA( in a positive way) ( i don’t say it’s his idea, to “simplify/optimize” the “Weather-service” … Removing these Attributes, is maybe not well thought, unless there is an explanation/upcoming solution, howto solve the scripts/templates/automations which rely on these forecast-attributes , as mentioned, heating/cooling-system, irrigation-system, solar-power-system etc. etc.

All weather integrations are updated to support this new service.

What does this actually means ? , does it means that these attributes is still a part of the weather-integration which above system is highly depended upon

15

it just means the service will work with all weather entities. Nothing more to read into.

16

i know, but that was not the point

17

There’s a more concerning issue with the removal of this attribute that needs to be thought out. I’ll most likely create a discussion about this and potentially spearhead the change itself (if approved). But with the current service, it’s not possible to get multiple forecasts (or calendar events) into a single template without an incredible amount of work. The only way it’s possible ways to do this at the moment is with custom events & template entities or publishing to MQTT topics and retrieving the data once it’s all collected via an MQTT trigger to a template entity.

2 Likes
18

Then why’d you ask what it even means…

1 Like
19

I don’t think this petition will stop the change. The overall goal with attributes in home assistant is to get large footprint attributes out of the database. This is partly why events were never an attribute on calendar entities.

I do believe we can come up with another solution (potentially 1 line template solution), that replicates the behavior.

1 Like
20

Call it a “rhetoric” Question

Because:

21

Currently, it’s up to the integration. If the integration caches the data, then it’s cached (and then retrieved from the service call). If the integration decides to make the service call retrieve the data live, then it’s live.

I’m not sure why you even have this question, that much has already been answered. You call the current service and it responds with data in the response variable. This system has been in HA since 2023.7.

By calling the service and using the response data. The only ‘hole’ at the moment is getting this information into template entities. Automations and scripts have a solution that works without issue.

1 Like
22

Hi,
Cleaning up data models in older code is fun - I used to spend happy hours re-formatting code and finding stuff to fix. The repeated issue is change management - i.e. communicating and supporting the impact of the change on others. Like the 2023.8 changes to the Entity Naming Standards and dev blog post on MQTT naming, the code change is simple, but communicating is, well, harder…

The ideal would be to use the beta to get ahead of the change, and constructively offer updated usage docs to the community. If the change really breaks stuff without reasonable workarounds, the feedback needs to be to devs and PRs.

Custom cards have been mentioned as one use case, but can we collect the other likely impact areas and think about them now?

I suspect a lot of folk use templating with text to speech or notifications for messages.

Use case - Weather in a message string for text to speech or notifications

Uses templating to build up a text string to be read out, (or could be sent as a notification message) such as in an alarm clock:

service: tts.google_say
data:
  entity_id: media_player.1234
  message: >-
    Good morning. It is {{ now().hour}} {{ now().minute }} and the forecast is {{
    states('weather.home') }}

So what’s the way to do this after 2024.03 when the change is depreciated?

Adding a service call into the automation to refresh the forecast data isn’t terrible, but getting the data into the string? Just a different {{ template entity }} to extract the state from?

The regular refresh could be added back with a manual template trigger entity:

- trigger:
    - event: start
      platform: homeassistant
    - platform: event
      event_type: event_template_reloaded
    - platform: time_pattern
      # change time pattern as needed - weather likely more than once a day
      hours:   05
      minutes: 05
  unique_id: 1234567890
  sensor:
    - name: Refresh Weather
    <add service call to Weather>

My guess is the real issue here is the impact on the weather provider’s API of several hundred thousand HASS installs calling their server regularly by default, rather than by a configured decision.

2 Likes