New weather forecast template

I completely understand that there are valid, important technical reasons for this change. I’m in favor of seeing Home Assistant make progress! This change makes a significant improvement “under the hood”, and we all benefit from it. No argument there.

I also want to acknowledge — and say thank you! — to the volunteers in this thread and elsewhere in these discussions who are helping folks who are having difficulties with the change. You guys are awesome! We are grateful that you’re here and helping. I hope you’ll understand and forgive when frustrations boil over a bit and someone (me!) gets snippy in our comments here. It’s the problem with our config, not the discussion. Again, thank you!

That said, I want to offer some (hopefully) constructive feedback. I hope this will be seen as friendly and useful, rather than a complaint.

First, in the commercial software world where I work, when we roll out a feature change and it generates a slew of unexpected customer complaints and cases, we look at that as signal. Our customers are telling us something; what is it?

  • Sometimes the feature is a bad idea. (Not the case here!)
  • Sometimes the feature is buggy.
  • Sometimes the feature is poorly documented (my job), and customers can’t fix the problem themselves by reading it.
  • Sometimes the feature is great, but the transition was problematic. We didn’t understand the impact or effort customers would have to go through to adopt the change.
  • Sometimes the feature misses one or more important customer use cases.
  • And so on.

I hope that the folks who manage this feature area will take the time to read through this whole thread, and think about what signal is being sent. What does it mean? What improvements can we make, either to this feature, or to our rollout process, or whatever?

Second, a couple thoughts about specific comments here:

My use case is that I want to use my local backyard temperature instead of the “local” current temperature provided by the integration. That’s it. One value, from one sensor, “pushed” into the weather data used by all the rest of my Home Assistant install. Scripts, dashboards, etc.

The Template Weather Provider seems (seemed) like the perfect way to handle this. It worked great for months. It was easy to understand, and straightforward to implement.

It was not, in my opinion, a “high level” use case or advanced configuration. Certainly, I think that taking your local weather forecast but using your backyard temperature in displays doesn’t seem like an uncommon thing for people to want to do. Temperature sensors are among the easiest and most common devices added to any smart home, and “what temperature is it outside right now?” is probably the second most important weather-related question that people regularly ask. (After, “will it rain today?”, and setting aside hazardous conditions like tornados and lightning.)

So, the signal I’m sending is that the new feature design makes an important use case harder to understand and harder to implement. (The weather template docs are also…not helping.)

I very much hope that there’s zero expectation that “normal users” will hang out in the developer forums and repos, trying to parse out useful information from technical conversations that make zero sense to them.

Maybe this discussion was great, and would address end user concerns with understanding the change and its impact. But, uh, yeah, we don’t hang out there. How would any non-HA dev ever have even come across this discussion? If a tree falls in a forest…

Final thoughts:

  • Regardless of the completeness, thoroughness, and best intentions of the folks who designed and implemented this feature change, this and other discussions suggest that the full impact of the change on end users was not fully understood. I think it would be worth ask, why not? How could we do better?

  • Regardless of the quality of the implementation, and the number of deprecation and repair notices, many end users didn’t understand the implications of this change. We upgraded, things that worked before broke, and fixing it was hard. That wasn’t a good experience. How can repair notifications be made more understandable?

  • There’s no doubt in my mind that the documentation wasn’t fully updated for this change. Some doc was updated, but not all of it, or without clear and complete explanations of the new feature design and how to use it. Why not? What process changes could be made to ensure all doc for an affected feature is updated and complete in the future?

If you made it this far, what signal do you think this discussion thread is sending? What signal do you want to send? (Be constructive, please!)

7 Likes

I’m a “non-HA dev” (a user, not a developer) but I know just enough about Github to know where to find Home Assistant’s Issues, PRs, Discussions, etc (because they don’t have those technical discussions here).

BTW, I posted that link to dispel the notion that the change was the product of short-sightedness (because that accusation has been made more than once).

Any way to call forecast with in a TTS? I am just trying to read out the next day’s data:

service: tts.google_translate_say
data:
  entity_id: media_player.master_bedroom_speaker
  message: >-
    Ok Goodnight mode triggered. The alarm system activated and the home is
    secure. The weather for tomorrow is forecasted as 
    {{state_attr('weather.downstairs','forecast')[0].condition}}
    with a low of {{ state_attr('weather.downstairs','forecast')[0].templow }}  
    and a high of {{ state_attr('weather.downstairs','forecast')[0].temperature }}

You will need to either set up a template sensor to hold the required data or call the weather.get_forecasts service in your script before the TTS service call (see Post #92 ) and modify your TTS templates as required.

first service:

service: weather.get_forecasts
target:
  entity_id: weather.downstairs
data:
  type: daily
response_variable: response

then

service: tts.google_translate_say
data:
  entity_id: media_player.master_bedroom_speaker
  message: >-
    Ok Goodnight mode triggered. The alarm system activated and the home is
    secure. The weather for tomorrow is forecasted as 
    {{ response['weather.downstairs'].forecast[0].condition}}
    with a low of {{ response['weather.downstairs'].forecast[0].templow }}  
    and a high of {{ response['weather.downstairs'].forecast[0].temperature }}
2 Likes

This worked perfect once I figured out that you can’t run services individually in an automation to test but had to run the entire automation for the response variable to be valid from one service to the other.

Thanks for the help!!

This is the way.

Thank you for this, I’ve been fighting with this for weeks, and this finally worked. And yea, it’s impossibly difficult to troubleshoot!

I’ve spent 6hrs trying to get a plot of the temperature from an hourly weather forecast to work. I’ve tried every damn template and example in every damn post. Feel like I’m being gaslit… Anyone know what is going wrong here?

I have the default weather.forecast_home from the Meteorologisk institutt (Met.no) integration ( http://homeassistant.local:8123/config/integrations/integration/met )

In dev tools services ( http://homeassistant.local:8123/developer-tools/service ) i can do:

service: weather.get_forecasts
data:
  type: hourly
target:
  entity_id:
    - weather.forecast_home

and i get back:

weather.forecast_home:
  forecast:
    - condition: rainy
      datetime: "2024-05-18T15:00:00+00:00"
      wind_bearing: 337.9
      cloud_coverage: 52.3
      temperature: 19.7
      wind_speed: 13.7
      precipitation: 0.2
      humidity: 64
    - condition: partlycloudy
      datetime: "2024-05-18T16:00:00+00:00"
      wind_bearing: 60.5
      cloud_coverage: 69.5
      temperature: 18.4
      wind_speed: 13.7
      precipitation: 0
      humidity: 71
    - condition: sunny
      datetime: "2024-05-18T17:00:00+00:00"
      wind_bearing: 98.3
      cloud_coverage: 4.7
      temperature: 18.4
      wind_speed: 4.3
      precipitation: 0
      humidity: 70
etc

But as we see in this huge thread, those attributes are not supposed to be used anymore, so we need to make a custom sensor to replace it.

In the config helpers ( http://homeassistant.local:8123/config/helpers ) I have created a template sensor:

This is using a template that worked for numerous users on march 8th ( Unsure How To Use Hourly Forecast Information (Since 2024.3.0) · Issue #112628 · home-assistant/core · GitHub ), although I did see that the weather.home has changed to weather.forecast_home between then and now, so I made that adjustment

template:
  - trigger:
      - platform: time_pattern
        hours: /1
      - platform: homeassistant
        event: start
    action:
      - service: weather.get_forecasts
        data:
          type: hourly
        target:
          entity_id: weather.forecast_home
        response_variable: hourly
    sensor:
      - name: Weather Hourly
        state: "{{ states('weather.forecast_home') }}"
        attributes:
          temperature: "{{ state_attr('weather.forecast_home', 'temperature') }}"
          dew_point: "{{ state_attr('weather.forecast_home', 'dew_point') }}"
          temperature_unit: "{{ state_attr('weather.forecast_home', 'temperature_unit') }}"
          humidity: "{{ state_attr('weather.forecast_home', 'humidity') }}"
          cloud_coverage: "{{ state_attr('weather.forecast_home', 'cloud_coverage') }}"
          pressure: "{{ state_attr('weather.forecast_home', 'pressure') }}"
          pressure_unit: "{{ state_attr('weather.forecast_home', 'pressure_unit') }}"
          wind_bearing: "{{ state_attr('weather.forecast_home', 'wind_bearing') }}"
          wind_speed: "{{ state_attr('weather.forecast_home', 'wind_speed') }}"
          wind_speed_unit: "{{ state_attr('weather.forecast_home', 'wind_speed_unit') }}"
          visibility_unit: "{{ state_attr('weather.forecast_home', 'visibility_unit') }}"
          precipitation_unit: "{{ state_attr('weather.forecast_home', 'precipitation_unit') }}"
          forecast: "{{ hourly['weather.forecast_home'].forecast }}"

However it is shown as unavailable and doesn’t get any data:

Which means then it fails to plot data in a plotly graph card:

type: custom:plotly-graph
hours_to_show: 16
time_offset: 3h
entities:
  - entity: sensor.smile_anna_outdoor_temperature
    line:
      width: 3
      color: orange
  - entity: sensor.smile_anna_outdoor_temperature
    name: Temperature yesterday
    time_offset: 1d
    line:
      width: 1
      dash: dot
      color: orange
  - entity: sensor.weather_hourly
    attribute: temperature
    unit_of_measurement: °C
    time_offset: 0d
    name: Forecast temperature
    line:
      width: 1
      dash: dot
      color: grey

Any help would be appreciated

The Template Helper only supports basic state-based Template Sensors or Binary sensors.
Attributes are not supported and, as stated above, neither are trigger-based sensors… they must be set up in your YAML configuration.

Thanks for the reply. Can you point me to the yaml configuration file you’re referring to?

The gui menu should mention this incompatibility. It has a choice for “template sensor” but then only actually works some some types and silently fails for the rest

And mate, yeah sure that was “As stated earlier” but it was …in comment number 96/129 of a forum thread. Let’s not pretend that’s a valid replacement to having clear signposting in the software itself

I don’t disagree with you, this seems to be a relatively common point of confusion since the introduction of Template Helpers and their UI editor earlier this year.

Maybe start a discussion on the frontend git explaining what you think would make the Helper editor more self-explanatory or easy to use.

1 Like