Hi, Thanks for the reply. the weather card is up to date (1.5.0).
Make sure that 1.5.0 has the ability to read the forecast data. Last I checked, it was only in the beta.
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!
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.
4 Likes
You don’t need to use is_number for any of this…
I didn’t say I was. I said I was running it as a test against the sensor value.
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!)
8 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. 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.
1 Like
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
1 Like
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.
1 Like
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.
1 Like
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:
The opening {{ were missing from the templates. But you edited the code in the post, so it may be different now.