Failed to get forecast weather temperature in my Dashboard, worked before perfect

[Todzjoe (Benjamin)]

Hello,

i have setup my Dashboard with the forecast Weather from the met.no integration. I was able to get the temperature for the next day, but it stopped working.

If i open the Integration i can see the temperature for the next days but i am not able to use the sensor data in my dashboard.

i get the info: “None has no element 1”

In my Dashboard i use the MarkDown Card, it worked perfect for now but stopped.

{{ state_attr(‘weather.home’, ‘forecast’)[1].temperature }}
{{ state_attr(‘weather.home’, ‘temperature_unit’) }}

I rebooted HA multiple Times

• Core 2024.4.2
• Supervisor 2024.04.0
• Operating System 12.1
• Frontend 20240404.1

[armedad]

take a look at this:

2023.9: New climate entity dialogs, lots of tile features, and template...

[Todzjoe (Benjamin)]

wow what a step back just to have the forecast not as an attribute…

got it working afters hours…

put in template.yaml

Reload template

Check the stats under section development

watch this video:

Unlock the Hidden Weather Forecast in Home Assistant

### Wetter heute
- trigger:
  - platform: time_pattern
    hours: /4
  - platform: homeassistant
    event: start
  - platform: event
    event_type: event_template_reloaded
  action:
    - service: weather.get_forecasts
      data:
        type: daily
      target:
        entity_id: weather.home
      response_variable: daily
    - variables:
        today: "{{ daily['weather.home'].forecast[0] }}"
  sensor:
    - name: "Today's High"
      unique_id: forecasted_high_temp
      state: "{{ today.temperature }}"
      unit_of_measurement: °C
    - name: "Tonight's Low"
      unique_id: forecasted_low_temp
      state: "{{ today.templow }}"
      unit_of_measurement: °C
### Wetter morgen
- trigger:
  - platform: time_pattern
    hours: /4
  - platform: homeassistant
    event: start
  - platform: event
    event_type: event_template_reloaded
  action:
    - service: weather.get_forecasts
      data:
        type: daily
      target:
        entity_id: weather.home
      response_variable: daily
    - variables:
        tomorrow: "{{ daily['weather.home'].forecast[1] }}"
  sensor:
    - name: "Tomorrows High"
      unique_id: forecasted_high_temp_tomorrow
      state: "{{ tomorrow.temperature }}"
      unit_of_measurement: °C
    - name: "Tomorrows Low"
      unique_id: forecasted_low_temp_tomorrow
      state: "{{ tomorrow.templow }}"
      unit_of_measurement: °C

[TheFes]

you don’t need two seperate triggers here

- trigger:
    - platform: time_pattern
      hours: /4
    - platform: homeassistant
      event: start
    - platform: event
      event_type: event_template_reloaded
  action:
    - service: weather.get_forecasts
      data:
        type: daily
      target:
        entity_id: weather.home
      response_variable: daily
    - variables:
        today: "{{ daily['weather.home'].forecast[0] }}"
        tomorrow: "{{ daily['weather.home'].forecast[1] }}"
  sensor:
    ### Wetter heute
    - name: "Today's High"
      unique_id: forecasted_high_temp
      state: "{{ today.temperature }}"
      unit_of_measurement: °C
    - name: "Tonight's Low"
      unique_id: forecasted_low_temp
      state: "{{ today.templow }}"
      unit_of_measurement: °C
    ### Wetter morgen
    - name: "Tomorrows High"
      unique_id: forecasted_high_temp_tomorrow
      state: "{{ tomorrow.temperature }}"
      unit_of_measurement: °C
    - name: "Tomorrows Low"
      unique_id: forecasted_low_temp_tomorrow
      state: "{{ tomorrow.templow }}"
      unit_of_measurement: °C

[GSzabados (Gábor Szabados)]

@TheFes

you don’t need two seperate triggers here

I would refer to frenck’s blog post from years ago.

The enterprise smart home syndrome – Frenck.dev

The enterprise smart home syndrome is the art
of overcomplicating your Home Assistant setup.

Franck Nijhof

Now the weather forecast is a great example how developers can over complicate a simple thing.

@Todzjoe

{{state_attr(‘weather.home’, ‘forecast’)[1].temperature }}
{{ state_attr(‘weather.home’, ‘temperature_unit’) }}

Is really nobody at NabuCasa can see the problem with this change in light of the streamlining? That two line became 34 lines!!!

[TheFes]

The ship has sailed, the attribute has been removed, and this was already announced 7 months ago.

The forecast attributes are huge chuncks of data which had to be loaded, and therefor were causing issues. Using the service call you can get them out when you need them, and they don’t have to be loaded that much.
I don’t know the fine details, but it was not done to make things more difficult, it was done to improve the general performance of HA.

[GSzabados (Gábor Szabados)]

@TheFes

I don’t know the fine details, but it was not done to make things more difficult, it was done to improve the general performance of HA.

If not stored as an attribute then how is it stored? Why it cannot be accessed without using the service? Why is it make sense to generate new templates just to be able to use it.

@TheFes

The ship has sailed, the attribute has been removed, and this was already announced 7 months ago.

It is fine, but do you know why people did not update? (including myself!) Because people do not want to spend all their times to make a 34 lines of code from a 2 lines of code and spend hours researching how will it work again.

And sorry for ranting on this, but don’t you recognise a pattern? How many projects are using forecasts which has been wrecked by this change? How many topics have you replied to recently which are all about the same issue?

Why the documentation has not been updated to cover this subject adequately? And why the built in integration has not been updated to match the requirements?

Maybe someone should look at the issue and consider that this sort of changes are not user friendly at all. Maybe bring it up on the next meeting and see the number of comments and topics which cannot deal with it?
You know, review of the work which has been done, how effective, useful, user friendly, etc.

A home automation system should make life easier, but this sort of changes just wasting people’s time to solve a problem which was working perfectly before.

Maybe look at how is this effecting the WAF as well…

[TheFes]

May I suggest to continue in this topic (or maybe read it first)

[PETITION] Don't delete the forecast attribute

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. 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…

This was a request for help on resolving the the new situation, not a discussion thread on why this decision was made and the changes are handled in integrations and documentation

[petro]

@GSzabados

A home automation system should make life easier, but this sort of changes just wasting people’s time to solve a problem which was working perfectly before.

The weather integration should provide optional entities that contain the forecast information. If it does not, write up a feature request for those.

The shift is to make this easier on the user. Users shouldn’t need templates at all to access information like this. It should just be an entity. This is the direction that things are going.

Right now, we are in a transition period. So please write up feature requests that fill the gaps on integrations that do not supply forecast information as separate entities.

[GSzabados (Gábor Szabados)]

@TheFes

May I suggest to continue in this topic (or maybe read it first)

Thanks! I just found it. It is like a good crime book, someone killed Colonel Mustard with a wrench, but knowbody understands why!