Getting Back To The Legacy 'forecasts' System for Weather

Community Guides
,
1

This topic has come up several times and I’ve had to copy and paste my code every time I answer, so I thought it would be easier to just put it on a topic instead.

As you know if you are reading this, the forecast attribute on weather entities was phased out quite some time ago, and finally removed from HA officially a few releases ago.

:warning: NOTE

The reason the forecast attribute got removed was to reduce unnecessary database bloat, due to the way attributes are stored in the database, and carrying all of that data in Home Assistant’s state machine. Keep that in mind when using this solution.

Getting at that weather now is a bit more difficult, particularly if you are just trying to get access to it easily rather than having to make a service call to get it, store it into a variable and then finally access the data in an entirely different way. Plus, the new method is useless in template editor testing.

What this does is create a sensor template that mimics the original way things were, it takes a few minutes to set up and then you have a sensor entity (not a weather entity) where forecast is again an attribute. You can make this fancier by adding the rest of your weather data too if you want, such as current condition, wind speed, etc.

The sensor is a triggered template, it updates when you start HA or every 5 minutes - change this to suit your needs. At that time it calls the get_forecasts (which is the second iteration of the new method to get forecasts), stores it into a variable and then you use that variable to populate the sensor attributes:

trigger:
  - platform: time_pattern
    minutes: /5
  - platform: homeassistant
    event: start

action:
  - service: weather.get_forecasts
    data:
      type: daily
    target:
      entity_id: weather.openweathermap
    response_variable: owm_daily

sensor:
  - name: Legacy Forecasts
    state: "{{ states('weather.openweathermap') }}"

    attributes:
      forecast: "{{ owm_daily['weather.openweathermap'].forecast }}"

Change the above weather entities and variable names to suit your needs, obviously. You can also set it to pull Hourly forecasts if your weather integration supports it, as well as Day/Night. Personally I pull all three into attributes called “daily”, “hourly” and “daynight” then I’m covered on all bases.

The only real change you have to make is to the domain of your old stuff that was using the forecast attribute from weather to sensor:

{{ state_attr('weather.openweathermap', 'forecast') }}

Now becomes:

{{ state_attr('sensor.whatever_you_named_it', 'forecast') }}

Purists might argue that this isn’t embracing the change, and I understand that, but for me I actually use the weather for a lot of automations and scripts and like to noodle it out sometimes in template editor, which can’t really be done any longer. It’s also nice to just have a single line to access the data rather than having to go through the hoops. I use both methods, but this gives me the ability for easy and immediate access when I need it.

5 Likes
2

What a great idea! :slight_smile: :+1:

And it’s a great way for people, who still want to rely on the “old technique”. It doesn’t make much sense, but it’s a free choice! :slight_smile:

But, I have a two part question. :laughing: Isn’t triggering every minute quite a lot? And as additional question, can’t there be a trigger for the last_changed or last_updated attribute of the weather entity?

3

I suppose you can make it however you want. I’ve been running this template for a while and don’t notice any degradation from running every 5, it’s only grabbing the forecast from a device that has it, not polling the weather provider itself.

As for triggers, the world is your oyster!

4

The issue is that you are now storing huge needless amounts of data in the recorder database. Precisely negating the reason the new method was introduced to solve.

5

I understand that and know that was the reason for the change. So far it hasn’t caused me undue problems and the solution for this might change over time, but it’s useful for now - even if counter to the reason it was removed.

6

Nice write-up, but I had the same thought as Tom, so I added it as a note.

1 Like
7

I can’t really see a reason one would ever need record the data for a “forecast” template sensor. Anyone using this method (I do something similar) should probably just exclude it from the recorder by default and avoid the issue all together.