[PETITION] Don't delete the forecast attribute

Feature Requests
47

Just remembered I use a bunch of apex chart generators on forecast attributes too:

  - entity: sensor.solcast_forecast_data
    type: line
    name: Forecast
    color: '#e45e65'
    extend_to: now
    stroke_width: 2
    unit: W
    show:
      in_header: false
      legend_value: false
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.period_end), entry.pv_estimate*1000];
      });
48

tbh, who cares about DB size anymore? isnt that a somewhat over articulated aspect nowadays? While phones and watches outgrow the specs from devices at the time this decision was made (not even mentioning the other devices people run HA on), it seems watching DB size decrease has low priority?

so its 1.4 GB. doesnt break the system? while breaking this functionality causes real trouble for the non savvy.

2 Likes
49

Well, according to that blurb, that’s not a weather entity, so it’s unaffected by this change.

51

The attribute is staying for 6 months from September. So there’s nothing to delay, we just have six months to merge a PR that solves the problem.

52

:man_facepalming:

2 Likes
53

You’re right, it’s not going away immediately. Nevertheless, that PR reduces the aforementioned “mess” by half, thereby making it easier to show users how to get a forecast attribute.

Just a guess but I think it would look something like this:

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 }}"
4 Likes
54

I think this one could blow up into a real *** storm in this forum, just like the MQTT nameing issue. It never rains but it pours!

(All puns intended!)

2 Likes
55

One possible pitfall - Time Pattern Triggers are great, and I use them all over, BUT, they don’t trigger on a restart so can leave entities undefined without some extra magic (included in my example above)

trigger:
  - event: start
    platform: homeassistant
  - platform: event
    event_type: event_template_reloaded
  - platform: time_pattern
    hours: /1
condition: []
action:
  <stuff and things>

I’ve got a separate templates.yaml file, so have updated my previous syntax for the more general case.

57

Which exactly why I’m here gently asking questions and hoping that both pitchforks are left in the barn, and possible improvements to the change from valid use cases are discussed within the 6 month depreciation period…

Communication is key - so let’s keep talking so we all understand what’s going on properly.

I for one have learnt a few things in this thread, which is noice!

1 Like
58

Yes, I agree it needs a startup trigger. Nevertheless the example was merely meant to demonstrate the basic principle of getting the weather forecast into a Template Sensor by way of an automation. The user is free to modify/enhance the triggers, and all other aspects of it, as they see fit.

Anyway, we’re likely to be discussing this thing a whole lot more in the near future as more users become aware/affected by the change.

NOTE

See the example here to get an idea of what might become possible in the near future.

1 Like
59

Regarding the DB, I don’t understand, forecast attributes are already excluded from the DB, see Exclude weather forecast attribute from recorder by frenck · Pull Request #69205 · home-assistant/core · GitHub

Also from the documentation: Events - Home Assistant

CALL_SERVICE
This event is fired when a service is called.

If the weather is now updated using a service call, why not include the service response in the event data which are sent when the service is called?

Then we don’t need the automation.

3 Likes
61

It’s not a theory, that’s the literal reason why attributes are being removed from entities. Weather is no different, it just had a special case to exclude the forecast from recorder. I purposely glossed over that because it’s not relevant to the actual reason and it just derails the conversation. You will see attribute reduction or complete exclusion in existing and future entities. This has been a goal for multiple years now.

Again, we should not be focusing on why, we should be focusing on “what to do next”.

1 Like
63

What about:

64

This is being brought into arch discussions by Alan Porter, so something will end up replacing this, not necessarily the linked PR.

2 Likes
65

Well, events aren’t the easiest to work with, that’s a whole other issue. I’m not saying “no”, but more or less saying we need something easier.

2 Likes
66

But where is the benefit then? Instead of having the data where they were useful and usable in the attribute (and not stored in the history) (e.g. without a template sensor directly in template and UI) we have to define new template entities which will periodically call services and store data into entities and db history …

I can see lots of disadvantages of this idea/decision and have to really puzzle to find any benefits at all.

But for every click on a weather card it will be live-pulled then via such services and cannot be taken out of the attributes anymore … Or perhaps with every display of such cards to be prepared for the click? Either … or … both seem to be not good approach.

2 Likes
67

Then calling the service in a template trigger seems a nice solution

68

Personally, I’d rather just have a function inside a template. But that’s just my opinion. I’ll adapt to whatever decision is made, although I don’t use these attributes at the moment but I will be using events from calendars in the future.

70

Speaking about “integrations” , I.E Weather-integrations can/could “temporary” store these Variable Attributes Forecasts/conditions in a file(2).( in i.e /local(or some user write-protected area, just in case :slight_smile: , i mean it’s not confidential info) and Update/remove “timestamp-sections” every hour/day, No DB, little or maybe less writes to disk, or entirely depend upon “store” in memory, thou with these “attributes/data” in a file = easy addressable

72

Yeah no. This is how you get the volunteer developers to just ignore you. And it’s what I’m trying to avoid. You’re more than welcome to “fight” but I’ll bow out as well as other people. It’s not an us vs them and this it’s this mentality that needs to stop.

No amount of understanding is going to make a difference, it will just be met with disdain. So, again, let’s focus on what matters: getting the functionality back by discussing our future options.

4 Likes