New weather forecast template

petro · April 30, 2024, 12:11pm

Make sure that 1.5.0 has the ability to read the forecast data. Last I checked, it was only in the beta.

jkseamons · April 30, 2024, 10:31pm

Thank you for the nudge in the right direction. I had to make a couple of minor changes, but this now works. Here is the updated template

It's {{state_attr('weather.galveston','temperature')}}° outside. {% set list = state_attr('sensor.galveston_forecast','forecast')
| selectattr('datetime', 'match', (now()|string)[0:11]|trim)
| sort(attribute='datetime')|map(attribute='detailed_description')|list %}
{{- list[0] if now().hour < 17 else list[1] }}

Thanks for your assistance!

roofuskit · May 2, 2024, 1:29pm

Well another fun stop on this continuing saga of ridiculousness.

No matter how I do it none of these templates pull the number in as a number. So I can’t have anything use it as a number. The float and is_number tests always fail.

I really hope the devs responsible for removing such a vital function with no similarly easy replacement read this large thread of frustrations. It should not be this hard to pull a daily temperature and test it against something. I’ve been able to do this for years with home assistant and now automations are broken. I can’t remember anything being this frustratingly difficult with home assistant before and I have been templating and using yaml since the early days.

petro · May 2, 2024, 1:34pm

You don’t need to use is_number for any of this…

roofuskit · May 2, 2024, 1:37pm

I didn’t say I was. I said I was running it as a test against the sensor value.

Alderete · May 9, 2024, 7:20pm

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!)

123 · May 9, 2024, 7:48pm

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

jryanmack · May 13, 2024, 2:16pm

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 }}

Didgeridrew · May 13, 2024, 2:44pm

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.

petro · May 13, 2024, 2:49pm

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 }}

jryanmack · May 13, 2024, 4:16pm

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!!

xstrex · May 15, 2024, 6:36pm

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!

Amsterdam · May 18, 2024, 3:55pm

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

Didgeridrew · May 18, 2024, 4:06pm

The Template Helper only supports basic state-based Template Sensors or Binary sensors. The “State template” field should only contain Jinja templating, YAML configuration is not supported in the field.

Attributes are not supported and, as stated above, neither are trigger-based sensors… they must be set up in your YAML configuration.

Amsterdam · May 18, 2024, 11:11pm

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

Didgeridrew · May 18, 2024, 11:36pm

I don’t disagree with you that the editor could use some attention… 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.

petro · May 20, 2024, 12:57pm

FYI the reason you’re confused is because you think the whole yaml chunk is the template, when templates are actually just the code between {% %}, {{ }}, and {# #} tags.

poldim · May 31, 2024, 8:23pm

Can anyone spot what I’m missing? This is using the format @petro suggested in New weather forecast template - #21 by petro

template:
- trigger:
  - platform: time_pattern
    minutes: "/2"
  action:
    - service: weather.get_forecasts
      data:
        type: daily
      target:
        entity_id: weather.tomorrow_io_home_daily
      response_variable: daily
    - variables:
        today: "{{ daily['weather.tomorrow_io_home_daily'].forecast[0] }}"
  sensor:
    - name: "Today's High Temperature"
      unique_id: tomorrow_io_d0_high_temp
      state: "{{ today.temperature }}"
      unit_of_measurement: °F
    - name: "Today's Low Temperature"
      unique_id: tomorrow_io_d0_low_temp
      state: "{{ today.templow }}"
      unit_of_measurement: °F
    - name: "Today's Precipitation"
      unique_id: tomorrow_io_d0_precipitation
      state: "{{ today.precipitation }}"
      unit_of_measurement: "in"
    - name: "Today's Rain Chance"
      unique_id: tomorrow_io_d0_precipitation_probability
      state: "{{ today.precipitation_probability }}"
      unit_of_measurement: "%"

This is all I get:

Edwin_D · May 31, 2024, 8:27pm

The opening {{ were missing from the templates. But you edited the code in the post, so it may be different now.

Roelv · July 10, 2024, 4:26pm

I recently got a similar issue with the weather forecast, but am not sure how to get this part working again. Could somebody help me what kind of template (and where) I should be building? It was working with the ‘met.no’ integration

 #Weather forecast temperature next day
   - platform: template
     sensors:
       temp_forecast_tomorrow:
         friendly_name: "Temperature forecast tomorrow"
         unit_of_measurement: '°C'
         value_template: "{{ state_attr('weather.de_woud', 'forecast') | map(attribute='temperature') | first }}"