[PETITION] Don't delete the forecast attribute

tw18jsy · December 12, 2023, 9:58am

Right I’m still confused and don’t see an example of how to reproduce my logic / workings. As I understand my configurations I have some logic that I use both in a template sensor and an automation, that evaluates the next 12 hours forecasts. The sensor records the lowest temperature for graphing / historical purposes. The automation does a point in time evaluation everynight as a prompt if I need to do things because of the temperature.

The sensor which records the lowest temp (don’t forget I’ve got 4 of these for each weather service).

- sensor:
    - name: "12 hours ahead temp low onecall_hourly"
      unit_of_measurement: "°C"
      state: 
        "{% set next12hours = (as_timestamp(now() + timedelta(hours=12)) |
      timestamp_utc) .replace(' ', 'T') ~ '+00:00' %} {% set today =
      state_attr('weather.openweathermap_onecall_hourly', 'forecast') |
      selectattr('datetime', 'lt', next12hours) | map(attribute='temperature') |
      list %}
      {{ today | min }}"

Then an automation on a daily schedule of 20:30 that sends a prompt to my phone giving me mins and max’s overnight.

service: notify.mobile_app_iphone_13_pro
data:
  title: Tonights temperature
  message: >-
    {% set tomorrow = (as_timestamp(now() + timedelta(hours=12)) |
    timestamp_utc) .replace(' ', 'T') ~ '+00:00' %} {% set today =
    state_attr('weather.openweathermap_onecall_hourly', 'forecast') |
    selectattr('datetime', 'lt', tomorrow) | map(attribute='temperature') | list
    %} Openweather says it is now
    {{state_attr('weather.openweathermap_onecall_hourly', 'temperature')}} °C
    outsid and they say the forecast for the next 12 hours today says it will be
    max {{ today | max }} °C with a low of {{ today | min }} °C
  data:
    push:
      interruption-level: time-sensitive
      tag: daily-weather-update
      sticky: "true"

I can’t see how I can reproduce this with the service calls etc?

This was my initial use case and reason for setting up and getting into HA in the first place some 2 years ago, and now I am looking to try and use some new weather integrations only to stumble across this and that my existing setup will stop working in 4 months.

tw18jsy · December 12, 2023, 1:51pm

Right another night and I’ve made progress, I even managed to use the new get_forcecasts, but I’m sure someone will tell me a better way of doing this.

New sensor

- trigger:
    - platform: state
      entity_id: weather.forecast_home
  action:
    - service: weather.get_forecasts
      data:
        type: hourly
      target:
        entity_id: weather.forecast_home
      response_variable: hourly
  sensor:
    - name: Weather Forecasts Hourly New
      unique_id: weather_forecasts_hourly_new
      state: "{{ now().isoformat() }}"
      attributes:
        forecast: "{{ hourly['weather.forecast_home'].forecast }}"

And I can query it with

state: 
"{% set next12hours = (as_timestamp(now() + timedelta(hours=12)) |
timestamp_utc) .replace(' ', 'T') ~ '+00:00' %} {% set today =
state_attr('sensor.weather_forecasts_hourly_new', 'forecast') |
selectattr('datetime', 'lt', next12hours) | map(attribute='temperature') |
list %}
{{ today | min }}"

The forecast seems to include a lot more data that before, so might look to limit its scope to the temperature for the next 12 hours.

disruptivepatternmat · December 23, 2023, 3:39pm

THIS IS THE ANWER!!! Thanks! Undid all the “progress” in the latest releases making my things all work again…thanks!

123 · December 23, 2023, 4:25pm

When I test that template, it produces a result containing two instances of 00:00

If you want to add 12 hours to the current time and report the result as a UTC datetime string, you can simply do this:

{% set next12hours = (utcnow() + timedelta(hours=12)).isoformat() %}

tw18jsy · December 29, 2023, 10:25am

Thanks, it wasn’t broken, but its less broken now!

Also I figured out how to limit the returned forecast items to a days worth, couldn’t just limit to the temperature, but its good enough for my use case.

forecast: "{{ (hourly['weather.forecast_home'].forecast)[:24] }}"

the :24 on the end was all I needed.

erkr · January 16, 2024, 3:48pm

A small variation on creating one single forecast sensor, one can also create dedicated template sensors for each forecast element of interest. In the example below temperature, wind_speed and precipitation. The data size of these sensors is kept minimal, as the forecast lists only contain the values for that sensor

- trigger:
  - platform: state
    entity_id: 
     - weather.Home57
  action:
    - service: weather.get_forecasts
      data:
        type: hourly
      target:
        entity_id: weather.home
      response_variable: hourly
    - variables:
        hourly_forecast: "{{ hourly['weather.home'].forecast }}"
  sensor:
  - unique_id: weather_forecast_temp
    name: Forecast temperature
    unit_of_measurement: '°C'
    state: "{{ hourly_forecast[0].temperature }}"
    device_class: temperature
    attributes:
      time: "{{ hourly_forecast[0].datetime }}"
      forecast: "{{ hourly_forecast | map(attribute='temperature') | list }}"
  - unique_id: weather_forecast_wind_speed
    name: weather Forecast wind speed
    unit_of_measurement: 'km/h'
    state: "{{ hourly_forecast[0].wind_speed }}"
    device_class: wind_speed
    attributes:
      time: "{{ hourly_forecast[0].datetime }}"
      forecast: "{{ hourly_forecast | map(attribute='wind_speed') | list }}"
  - unique_id: weather_forecast_precipitation
    name: weather Forecast precipitation
    unit_of_measurement: 'mm'
    state: "{{ hourly_forecast[0].precipitation }}"
    device_class: precipitation
    attributes:
      time: "{{ hourly_forecast[0].datetime }}"
      forecast: "{{ hourly_forecast | map(attribute='precipitation') | list }}"

`
these sensors have two attributes:

time which is the forecast time of the first entry
forecast with the forecast values per hour

In the dev tools it then looks like this:

Best Eric

Note: removing the attributes from the weather sensor I can understand, but deprecating weather.get_forecast caused me a lot of extra work, and seems just a variation of weather.get_forecasts with a single entity.

Didgeridrew · January 16, 2024, 5:08pm

Keeping those variations available causes a lot of confusion and frustration for new and less knowledgeable users… better to just rip the bandage off quickly.

erkr · January 16, 2024, 8:42pm

In my opinion the new version get_forcasts is harder to understand how to parse the response for less experienced users. Users who typically have just one weather entity as well.

FearlessReach · March 8, 2024, 7:53am

That’s exactly right (for both the get_forcasts change as well as the hourly change). Users that have a few automations with value template elements that were set up entirely through the UI, like this one:

{{ (states.weather.home_hourly.attributes.forecast[3].temperature) | float < 16 }}

… are now not having their heating come on in the morning

And they are rather irritated because the removal of other features (like the counter.configure service) have alerted me with notifications for months, so I was prepared for the breaking change.

I have spent two hours yesterday and another three this morning, trying to find out what the best way forward for me is, and unless I learn multiple complex skills at the same time, I cannot solve this.

Yesterday, I performed the update. My dashboard complained about weather.home_hourly not being available, which I found odd, but when I edited it to weather.home for the time being, there was a new toggle between “daily” and “hourly”, which restored the exact functionality (a fairly smooth experience overall for something considered a breaking change).

This morning, my heating did not come on. In case it is interesting to those that have not been novice users for a long time, here’s my thought process:

Oh. My heating has not come on this morning. Weird.
The automation has not run today. The conditions do not seem to be met. That is odd since it is freezing outside. The value template (as quoted above) is not matching.
The weather.home_hourly entity is still gone. I have previously enabled it manually, the update must have undone that. Huh. No, it is really gone, including the previously-disabled one.
Hm. Others have the same issue.
There are examples in the help, but I am not sure where to put them. Using “Example template sensor using get_forecasts” from the help in a template helper does not appear to be working. It displays as “Unavailable” and states “This template does not listen for any events and will not update automatically.”, which does not seem right.
There are other code snippets offered as ideas but I also do not know where to insert them (can they be put in one or multiple places inside the UI or do I need to edit the configuration files?), or they do not work, even if I account for the renaming of weather.get_forecast.

Overall, I do agree with @FloatingBoater:

Could I ask that someone skilled could point me to the bare minimum of skills I need to learn, please? I am happy to put the work in, but filtering out what concepts I need to build an understanding of (with all the changes that play into this situation) is an insurmountable task for a relative beginner.

FloatingBoater · March 8, 2024, 8:30am

I’ve posted two worked examples not 20 posts above…

You might want to change type: hourly to type: daily.

FearlessReach · March 8, 2024, 8:45am

Thank you, and I did see and read this post, but it did not help me much, I am afraid.

That is entirely on me. As I said, I am clearly lacking the overall structural understanding of how to adapt all the examples, which is why I asked for help to gain further understanding in the areas needed.

What I need is a condition to use inside an automation to verify that the temperature in four hours is forecast to be less than 16 degrees.

I currently use a value template for it (as quoted above), and your working example is no direct substitute for that, if I understand correctly.

Tinkerer · March 8, 2024, 8:50am

This trigger based template sensor may help you.

You can paste that into your configuration.yaml, with template: before the first line, like:

template:
- trigger:
    - platform: time_pattern
      minutes: "*"
...

Then just change weather.stuttgart_echterdingen to your weather entity, and the other references to Stuttgart-Echterdingen or stuttgart_echterdingen to suit you.

Run a config check and then reload your templates (or restart HA).

SaintTDI · March 8, 2024, 10:54am

Hi all!

I’m trying to understand templating by copying and editing what I find around the community

I’m trying to get the temperature and humidity each hour so that I can use it with some messages, I’m using Met.no weather forecast.

This is my template code that is not working:

- unique_id: test_meteo
  trigger:
    - platform: time_pattern
      hours: /1
  action:
    - variables:
        weather: weather.forecast_casa
    - service: weather.get_forecasts
      target:
        entity_id: "{{ weather }}"
      data:
        type: hourly
      response_variable: response
    - variables:
        forecast: "{{ response[weather].forecast }}"
        start: "{{ now().year ~ '-0' ~ now().month ~ '-0' ~ now().day ~ 'T' ~ now().hour ~ ':00:00+00:00'}}"
  sensor:
    - name: my_meteo
      unique_id: my_meteo
      state: >
        {{ forecast | selectattr('datetime', '==', start) | map(attribute='datetime') }}
      attributes:
        temperature: "{{ forecast | selectattr('datetime', '==', start) | selectattr('temperature') }}"
        humidity: "{{ forecast | selectattr('datetime', '==', start) | selectattr('humidity') }}"

The result is that sensor.my_meteo has state = unknown and there aren’t the attributes temperature and humidity

Could someone help me please?

thanks!

FearlessReach · March 8, 2024, 11:08am

Thank you, @Tinkerer, that was an excellent flight level and very helpful in this specific instance.

For the next person running into this, here is a more detailed rundown of what I did to fix my automations:

Here is the precise code I inserted into configuration.yaml:

Code Example (no longer functional)

template:
  - trigger:
    - platform: time_pattern
      minutes: "*"
    - platform: homeassistant
      event: start
    - platform: event
      event_type: event_template_reloaded
    action:
      - service: weather.get_forecast
        target:
          entity_id: weather.home
        data:
          type: hourly
        response_variable: hourly_forecast
      - service: weather.get_forecast
        target:
          entity_id: weather.home
        data:
          type: daily
        response_variable: daily_forecast
    sensor:
      - name: "Weather Hourly"
        unique_id: home_hourly
        state: "{{ states('weather.home') }}"
        attributes:
          temperature: "{{ state_attr('weather.home', 'temperature') }}"
          dew_point: "{{ state_attr('weather.home', 'dew_point') }}"
          temperature_unit: "{{ state_attr('weather.home', 'temperature_unit') }}"
          humidity: "{{ state_attr('weather.home', 'humidity') }}"
          cloud_coverage: "{{ state_attr('weather.home', 'cloud_coverage') }}"
          pressure: "{{ state_attr('weather.home', 'pressure') }}"
          pressure_unit: "{{ state_attr('weather.home', 'pressure_unit') }}"
          wind_bearing: "{{ state_attr('weather.home', 'wind_bearing') }}"
          wind_gust_speed: "{{ state_attr('weather.home', 'wind_gust_speed') }}"
          wind_speed: "{{ state_attr('weather.home', 'wind_speed') }}"
          wind_speed_unit: "{{ state_attr('weather.home', 'wind_speed_unit') }}"
          visibility: "{{ state_attr('weather.home', 'visibility') }}"
          visibility_unit: "{{ state_attr('weather.home', 'visibility_unit') }}"
          precipitation: "{{ state_attr('weather.home', 'precipitation') }}"
          precipitation_unit: "{{ state_attr('weather.home', 'precipitation_unit') }}"
          forecast: "{{ hourly_forecast.forecast[:5] }}"
      - name: "Weather Daily"
        unique_id: home_daily
        state: "{{ states('weather.home') }}"
        attributes:
          temperature: "{{ state_attr('weather.home', 'temperature') }}"
          dew_point: "{{ state_attr('weather.home', 'dew_point') }}"
          temperature_unit: "{{ state_attr('weather.home', 'temperature_unit') }}"
          humidity: "{{ state_attr('weather.home', 'humidity') }}"
          cloud_coverage: "{{ state_attr('weather.home', 'cloud_coverage') }}"
          pressure: "{{ state_attr('weather.home', 'pressure') }}"
          pressure_unit: "{{ state_attr('weather.home', 'pressure_unit') }}"
          wind_bearing: "{{ state_attr('weather.home', 'wind_bearing') }}"
          wind_gust_speed: "{{ state_attr('weather.home', 'wind_gust_speed') }}"
          wind_speed: "{{ state_attr('weather.home', 'wind_speed') }}"
          wind_speed_unit: "{{ state_attr('weather.home', 'wind_speed_unit') }}"
          visibility: "{{ state_attr('weather.home', 'visibility') }}"
          visibility_unit: "{{ state_attr('weather.home', 'visibility_unit') }}"
          precipitation: "{{ state_attr('weather.home', 'precipitation') }}"
          precipitation_unit: "{{ state_attr('weather.home', 'precipitation_unit') }}"
          forecast: "{{ daily_forecast.forecast[:5] }}"

(This code is based on the mentioned GitHub post ~~and will work without any changes needed as long as you are using the weather.home entity.~~)

Above code example does no longer work since it still uses the weather.get_forecast service call, which has been deprecated. See my post below for the updated, working version of this code.

This should create an entity sensor.weather_hourly (and also an entity sensor.weather_daily), which should contain the following:

temperature: 5.7
dew_point: -0.7
temperature_unit: °C
humidity: 63
cloud_coverage: 0
pressure: 1016.4
pressure_unit: hPa
wind_bearing: 97
wind_gust_speed: null
wind_speed: 18
wind_speed_unit: km/h
visibility: null
visibility_unit: km
precipitation: null
precipitation_unit: mm
forecast: 
- condition: sunny
  datetime: '2024-03-08T11:00:00+00:00'
  wind_bearing: 98.8
  cloud_coverage: 0
  temperature: 7.4
  wind_speed: 19.4
  precipitation: 0
  humidity: 59
- condition: sunny
  datetime: '2024-03-08T12:00:00+00:00'
  wind_bearing: 96.2
  cloud_coverage: 0
  temperature: 8.6
  wind_speed: 22
  precipitation: 0
  humidity: 54
- condition: sunny
  datetime: '2024-03-08T13:00:00+00:00'
  wind_bearing: 97.5
  cloud_coverage: 0
  temperature: 9.4
  wind_speed: 23
  precipitation: 0
  humidity: 52
- condition: partlycloudy
  datetime: '2024-03-08T14:00:00+00:00'
  wind_bearing: 108.1
  cloud_coverage: 17.2
  temperature: 9.9
  wind_speed: 25.2
  precipitation: 0
  humidity: 50
- condition: sunny
  datetime: '2024-03-08T15:00:00+00:00'
  wind_bearing: 103.3
  cloud_coverage: 0
  temperature: 9.6
  wind_speed: 22.3
  precipitation: 0
  humidity: 51

friendly_name: Weather Hourly

In automations, change the value template. Where I previously had this:

{{ (states.weather.home_hourly.attributes.forecast[3].temperature) | float < 16 }}

I changed into this:

{{ (states.sensor.weather_hourly.attributes.forecast[3].temperature) | float < 16 }}

Note: I had to both change weather to sensor (because the above code does provide an entity of the type sensor while the previous entity was of the type weather) and home_hourly to weather_hourly (because the above code specifies the unique_id as weather_hourly).

Another way would be to use state_attr() as strongly suggested in the documentation:

{{ state_attr('sensor.weather_hourly','forecast')[3]['temperature'] | float < 16 }}

If you test the condition inside automations, please note that if you are running “Test” on a condition while it is disabled, the test will always fail. This did cost me the better part of an hour to figure out.

Save the file, check the syntax, restart Home Assistant.

FearlessReach · March 8, 2024, 11:09am

If you do not mind me asking, what is the best way to understand where yaml code may be inserted?

Here is why:

I used to always insert them into the configuration.yaml file.

More recently, there have been a number of breaking changes where configuration in configuration.yaml is being deprecated and subsequently even being ignored (in favour of configuration through the UI). I also noticed more helper types are being made available in the UI.

That led me to believe that the code you told me to insert into configuration.yaml could also be inserted through the use of a template type helper.

However, that does not appear to be the case. How do I tell apart what should work?

FearlessReach · March 8, 2024, 11:23am

Try the solution I outlined above, it will provide you with temperature and humidity as well. Do make sure you change weather.home in the code if needed. I believe you might be using weather.forecast_casa.

Should you need more than five hours, increase the number 5 for the home_hourly sensor

forecast: "{{ hourly_forecast.forecast[:5] }}"

as explained on GitHub.

petro · March 8, 2024, 11:24am

- unique_id: test_meteo
  trigger:
    - platform: time_pattern
      hours: /1
  action:
    - variables:
        weather: weather.forecast_casa
    - service: weather.get_forecasts
      target:
        entity_id: "{{ weather }}"
      data:
        type: hourly
      response_variable: response
    - variables:
        forecast: "{{ response[weather].forecast }}"
        start: "{{ today_at('00:00') }}"
  sensor:
    - name: my_meteo
      unique_id: my_meteo
      state: >
        {{ forecast | selectattr('datetime', '==', start) | map(attribute='datetime') | first }}
      attributes:
        temperature: "{{ forecast | selectattr('datetime', '==', start) | selectattr('temperature') | list }}"
        humidity: "{{ forecast | selectattr('datetime', '==', start) | selectattr('humidity') | list }}"

petro · March 8, 2024, 11:28am

The documentation tells you where to put the yaml. Every single yaml integration has this information in the integration pages on the integration page.

The UI template integration only supports very basic template sensors and template binary_sensors. You can’t put in full configurations like you’re doing.

FYI, you should take a look at this page to understand the difference between yaml and jinja, which is probably what tripped you up in the first place.

FearlessReach · March 8, 2024, 11:43am

Thank you, @petro! I understand why it did not work, but do let me elaborate on where my confusion stems from, and why I think there is room for improvement.

Could it be that this information is not on every single page? Here is where I looked:

I opened the Weather integration page, then scrolled to the Examples section. There is an example named “Example template sensor using get_forecasts”.

It contains the following code:

template:
  - trigger:
      - platform: time_pattern
        hours: /1
    action:
      - service: weather.get_forecasts
        data:
          type: hourly
        target:
          entity_id: weather.home
        response_variable: hourly
    sensor:
      - name: Temperature forecast next hour
        unique_id: temperature_forecast_next_hour
        state: "{{ hourly['weather.home'].forecast[0].temperature }}"
        unit_of_measurement: °C

(I could have probably easily adopted that code to return forecast[3] and that would have helped me to solve my challenge on my own.)

But the documentation does not state whether this code can be used through the UI template integration and without the additional knowledge that the UI

there is no way for a novice user to recognise that this qualifies as “full configurations” and/or that this code needs to be placed in configurations.yaml to work.

That being said, I actually asked because people post a lot of code snippets in the forum, and usually do not mention whether there is a constraint of where they will work. Take the example mentioned earlier: I tried it in the UI, because that looked like it should work. It does not, and there is no guidance to the user that the UI is severely limited.

SaintTDI · March 8, 2024, 11:50am

Thanks now it works