Current and next hour conditions as separate sensor

[hillbicks]

Is your feature request related to a problem? Please describe. Last year during the summer I already tried to optimize my garden irrigation by checking the current rain and the rain probability for the next couple of hours. There are already sensors for that: Precipitation Duration, Precipitation Probability but you have to use templates in order to get the values for the next x hours, for each sensor.

Describe the solution you'd like The disabled sensors should (i.e. Precipitation Duration, Precipitation Probability) should have readable attributes for the values of the next hours, so they can be used in automations and dashboards. Ideally the state of each sensor holds the value that matches the current time with the right measurement unit. Additional attributes for the next x hours for each sensor, either as default, or configurable.

Describe alternatives you've considered Using templates to get these values value_template: "{{ state_attr('sensor.precipitation_probability_XXX', 'data')[0]['value'] }}"

Additional context No additional context, I hope it's clear, otherwise let me know and I'll provide more input.

Thanks

[FL550]

Hey, I can implement the sensor reading to be the actual value of that hour. The unit_of_measurement is already included in the sensor state. Maybe if I also include the device class the display on the dashboard is better. I'll add them as well.

I don't understand what you mean with this:

Additional attributes for the next x hours for each sensor, either as default, or configurable.

The forecast data already contains the values for the next hours. Can you please clarify this?

[hillbicks]

That sounds very good!

I thought maybe having the detailed sensor cards look more like this would be nice looking for one and having fixed attributes with clear names would be easier for most people to work with I guess. This way it would look like similar to the "main" weather entity card and the attributes would be better aligned as well. While it is nice to have to all the values available that DWD provides, I personally only care about the next couple of hours. How many attributes are available here, could either be a fixed value (easier for you) or configurable, meaning I want to show the next 12 hours, or the next 6 hours. (more effort for you to implement). I think the next 6 hours would be plenty for most use cases.

https://imgur.com/a/qUFkMh1

I hope that makes it a bit easier, although I'm not sure if it makes sense to have new cards or change the existing ones.

[FL550]

I am on this and I will provide an update within the next week.

[nikipore]

Hi,

Over at Buy Me a Coffee you asked whether it was me who opened this issue. No, I wasn't.

But I would like to take your question as an opportunity to share (possibly as an inspiration) how I solved this issue until you provide a better solution:

sensor:
  - platform: template
    sensors:
      weather_hourly_forecast_index:
        friendly_name: "Wettervorhersage: Index der aktuellen Stunde"
        value_template: "{{ (((utcnow() - state_attr('weather.dwd_weather_frankfurt_m_1h', 'forecast_time_utc')).total_seconds() // 3600) - 1) | max(0) | int }}"
      weather_latest_update:
        friendly_name: "Wetter: zuletzt aktualisiert"
        value_template: "{{ state_attr('weather.dwd_weather_frankfurt_m_1h', 'latest_update_utc') }}"
        device_class: timestamp
      weather_forecast_cloud_coverage:
        friendly_name: "Wolkenbedeckung"
        unit_of_measurement: "%"
        value_template: "{{ state_attr('sensor.cloud_coverage_frankfurt_m_1h', 'data')[states('sensor.weather_hourly_forecast_index') | int]['value'] | float }}"
        icon_template: mdi:cloud-outline

I am using weather_hourly_forecast_index to look up the current hour in the forecast arrays (example: weather_forecast_cloud_coverage).

The max(0) filter is important because at times (about ~15 minutes before 06:00, 12:00, … CEST) the index may become -1 – which in Python is the last index. Yesterday I had latest_update_utc=21:52:33, forecast_time_utc=21:00:00, forecast_vector.data[0][datetime]=22:00:00, so between 23:52:33 CEST and 23:59:59 CEST, the index became -1. The best approximation for the forecast obviously is to take index 0 and not -1.

The combination of weather_hourly_forecast_index and weather_latest_update triggers on forecast updates and on every new hour:

automation:
  - alias: Update Weather on Homematic
    trigger:
      - platform: state
        entity_id: sensor.weather_last_updated
      - platform: state
        entity_id: sensor.weather_hourly_forecast_index
    action:
      - service: homematic.set_variable_value
        target:
          entity_id: homematic.central
        data:
          name: "weather_forecast_cloud_coverage"
          value: "{{ states('sensor.weather_forecast_cloud_coverage') }}"

[FL550]

I just released an update, which should address both your requests. Please let me know if this is what you are expecting.

[nikipore]

I'll look into it and let you know.

[hillbicks]

From the first look, this seems to do the trick! I was a bite irritated at first about old data, but the timestamps are in UTC, which matches my current time zone.

So thanks again for implementing this feature request!

[nikipore]

From my first look, I see that the sensors are only updated when the integration polls the DWD service. But now that the sensors are truncated and the forecasts are made explicit as sensor values, they should be updated at every full hour.

[FL550]

It has updated itself every 15 minutes. I changed this now to be exactly on the hour.

[nikipore]

Works great. But I suggest you leave the 15-minute rhythm in place (only synced on the hour). I understood that DWD refreshes the current (not the forecast) weather data more frequently than on an hourly basis.

[nikipore]

Little how-to: This is how I extract the temperature high and low from your new truncated temperature forecast vector:

sensor:
  - platform: template
    sensors:
      weather_hourly_forecast_index_next_rising:
        friendly_name: "Wettervorhersage: Index des nächsten Sonnenaufgangs"
        value_template: "{{ ((as_timestamp(state_attr('sun.sun', 'next_rising')) - as_timestamp(state_attr('weather.dwd_weather_frankfurt_m_1h', 'forecast')[0]['datetime'])) // 3600) | max(0) }}"
      weather_hourly_forecast_index_next_setting:
        friendly_name: "Wettervorhersage: Index des nächsten Sonnenuntergangs"
        value_template: "{{ ((as_timestamp(state_attr('sun.sun', 'next_setting')) - as_timestamp(state_attr('weather.dwd_weather_frankfurt_m_1h', 'forecast')[0]['datetime'])) // 3600) | max(0) }}"
      weather_forecast_temperature_high:
        friendly_name: "Temperatur (max.)"
        unit_of_measurement: "°C"
        value_template: "{{ state_attr('sensor.temperature_frankfurt_m_1h', 'data')[:(states('sensor.weather_hourly_forecast_index_next_setting') | int) + 1] | map(attribute='value') | max | float }}"
        device_class: temperature
      weather_forecast_temperature_low:
        friendly_name: "Temperatur (min.)"
        unit_of_measurement: "°C"
        value_template: "{{ state_attr('sensor.temperature_frankfurt_m_1h', 'data')[:(states('sensor.weather_hourly_forecast_index_next_rising') | int) + 1] | map(attribute='value') | min | float }}"
        device_class: temperature

[FL550]

Why aren't you using the values directly from the weather entity?

[nikipore]

I do. So they still update more often? And you update the forecast sensors not only on the hour but also when a new forecast is available? Then that's just perfect.

[FL550]

They all share the same data. New forecasts are available every 6 hours.

[nikipore]

So even before the update the values of the weather entity were forecast values not actual values?

[FL550]

Unfortunately, yes. I don't know a source to get more frequent updates. DWD publishes an hourly forecast, but only within an 700MB package.