[PETITION] Don't delete the forecast attribute

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