The knmi integration is using deprecated forecast (2023.9 beta) about ha-knmi HOT 33 CLOSED

Should be fixed by implementing async_forecast_daily instead of forecast property,
I'll be able to do this before the new release.

from ha-knmi.

#88 is ready but should be merged after HA 2023.8 release

from ha-knmi.

Works!

Thanks. I'll release it in a couple of days. So most of the early updaters are on 2023.9

from ha-knmi.

In your configuration.yaml

from ha-knmi.

To stress: just wait for 2023.8 final release, it's fixed in core (will be deprecated later).

home-assistant/core#97290

from ha-knmi.

I think the latest HA dev build has resolved this issue in home-assistant/core#97292, can you confirm?

from ha-knmi.

Yes.

Edit: well, it's postponed to the next release (2023.9). Probably good to keep an eye.

from ha-knmi.

async_forecast_daily Doesn't seem to do anything at this moment, I had my PR merged and realized there was no longer a forecast, 20ee1dc fixes this, and now both methods are supported, once HA decides to make the switch the old one can be removed

from ha-knmi.

https://developers.home-assistant.io/blog/2023/08/07/weather_entity_forecast_types/

from ha-knmi.

Jep, and the newest beta is now (again) complaining about it, including a repairs issue:

from ha-knmi.

I'll fix this somewhere next week after the next release, theoretically reverting 20ee1dc should be enough

from ha-knmi.

Yeah, and as far as I understand nothing will actually break now, it's just a warning

from ha-knmi.

I've quickly drafted a PR #91 if anyone has time, feel free to test it locally and provide feedback.
I'll wait till the HA 2023.9 update to test (we should merge after the update anyway).

from ha-knmi.

Eerst ff Formule 1, kan straks wel even testen

from ha-knmi.

Error is gone, but I guess some more work is needed

By the way, the weather entity does not appear in the entity-chooser (I added it manually), and when calling the service, it errors out.

from ha-knmi.

I missed a little thing, I've tested against 2023.9.0b3 and I think it should no work as expected, please let me know

from ha-knmi.

Works!

from ha-knmi.

You should be good as your hacs.json indicates 2023.9 as minimum version, so people running older versions won't see the update

from ha-knmi.

Fair enough; https://github.com/golles/ha-knmi/releases/tag/1.6.0

from ha-knmi.

In case anyone uses forecast in templates/automations like state_attr("weather.knmi_purmerend", "forecast")[0]["temperature"], you now need to use a template sensor to get the forecast data.
(Some of the built-in weather providers are still setting the old/deprecated forecast attribute...)

eg:

template:
  - trigger:
      - platform: time_pattern
        minutes: /10
    action:
      - service: weather.get_forecast
        data:
          type: daily
        target:
          entity_id: weather.knmi_purmerend
        response_variable: forecast
    binary_sensor:
      - name: KNMI regen vandaag
        state: "{{ forecast.forecast[0].precipitation_probability > 0 }}"
    sensor:
      - name: KNMI max temp vandaag
        state: "{{ forecast.forecast[0].temperature }}"

from ha-knmi.

I've extended the example a bit in my config, so it get's a value directly on restart & reload and with an unique_id, so you can more easily set icons from the frontend if you'd like:

  template:
    - trigger:
        - platform: time_pattern
          hours: /1
        - platform: homeassistant
          event: start
        - platform: event
          event_type: event_template_reloaded
      action:
        - service: weather.get_forecast
          data:
            type: daily
          target:
            entity_id: weather.knmi_home
          response_variable: forecast
      binary_sensor:
        - name: KNMI regen vandaag
          state: "{{ forecast.forecast[0].precipitation_probability > 0 }}"
          unique_id: knmi_regen_vandaag
      sensor:
        - name: KNMI max temp vandaag
          unique_id: knmi_max_temp_vandaag
          state: "{{ forecast.forecast[0].temperature }}"
          availability: "{{ is_number(forecast.forecast[0].temperature) }}"

@golles Maybe it's even worth thinking of to provide these two sensors directly from the integration - I think they'll be the most templated sensors anyways.

from ha-knmi.

I'm very against duplicating unnecessary data, but I was actually considering this as well.

I think this new way of dealing with the forecast isn't great at all. Maybe it's faster for the ui, but I don't think I've ever noticed it to be slow in the first place and not having to add extra (template) sensors is defeating the whole purpose in my opinion.

I've also noticed that, at least one (Met.no), built in weather integration is still using the old forecast attribute (combined with the new service). I shouldn't do that as the code mentions not to overwrite that function anymore. Which makes this weather integration look worse than built in ones...

from ha-knmi.

Geen speld tussen te krijgen.

from ha-knmi.

I think you've seen it, but there is a nice discussion about this subject:
https://community.home-assistant.io/t/petition-dont-delete-the-forecast-attribute/609298

Providing these two sensors directly from the integration would be very helpful.

from ha-knmi.

I know there are ideas to support service calls directly in templates, like
{% set forecast = service_call('calendar.get_events', {'entity_id': 'calendar.work', 'start_date_time': today_at(), 'duration': {'hours': 24}}) %} which would get the result directly. I know one of the HA contributors and templates experts want to implement this, but it requires a lot of coding. He mentioned he would like to have this implemented before the depreciation of the forecast attribute. (my example is for the calendar, but for the weather forecast service call it would be similar)

This will allow the response to be directly used in templates, and then no further (template) sensors would be required.

However, before that, to combine 2 weather forecasts I would have to write them to a template or mqtt sensor. It is not possible to iterate over them in a repeat service call, because of the limited scope of the response (it will only be available in the repeat service call). So for now I would like to continue using the forecast attribute.

from ha-knmi.

I think you've seen it, but there is a nice discussion about this subject:

https://community.home-assistant.io/t/petition-dont-delete-the-forecast-attribute/609298

Providing these two sensors directly from the integration would be very helpful.

I wasn't aware of this thread so many thanks for sharing. I'll try to read and comment if needed during the weekend

from ha-knmi.

@TheFes I do understand your issue but adding support back for the deprecated attribute is maybe nice for the time being but not very future proof.

I was actually pretty surprised yesterday to see that built in weather integrations are still supporting the attribute. Even though it shouldn't be used anymore https://github.com/home-assistant/core/blob/dev/homeassistant/components/weather/__init__.py#L553

Let see in the coming days how the thread on the forums evolve, in my opinion the decision should be taken by HA and this integration should simply follow.

Using the previous version of this integration is indeed maybe the best short therm solution

from ha-knmi.

That's because he policy in HA is that things which are depreciated will be supported for 6 months before being removed. So the forecast attributes will be removed in 2024.3, giving people time to adjust

from ha-knmi.

Damn, I was checking why my automations are not working, well now I know 👎 . Is there ANY chance that attributes forecast will return?

from ha-knmi.

Yes you can by creating a template sensor.
A sensor will be created: sensor.knmi_weersverwachting

  template:
    - trigger:
        - platform: time_pattern
          hours: /1
        - platform: homeassistant
          event: start
        - platform: event
          event_type: event_template_reloaded
      action:
        - service: weather.get_forecast
          data:
            type: daily
          target:
            entity_id: weather.knmi_home
          response_variable: forecast
      sensor:
        - name: KNMI weersverwachting
          unique_id: knmi_weersverwachting
          state: "{{ now().isoformat() }}"
          attributes:
            forecast: "{{ forecast.forecast }}"

from ha-knmi.

Yes you can by creating a template sensor. A sensor will be created: sensor.knmi_weersverwachting

  template:
    - trigger:
        - platform: time_pattern
          hours: /1
        - platform: homeassistant
          event: start
        - platform: event
          event_type: event_template_reloaded
      action:
        - service: weather.get_forecast
          data:
            type: daily
          target:
            entity_id: weather.knmi_home
          response_variable: forecast
      sensor:
        - name: KNMI weersverwachting
          unique_id: knmi_weersverwachting
          state: "{{ now().isoformat() }}"
          attributes:
            forecast: "{{ forecast.forecast }}"

Thanks, should this be added in the config or somewhere else?

from ha-knmi.

I see no reason why this integration would not follow the same approach as the core integrations and leave it in until 2024.3
This gives users time to adapt

from ha-knmi.

I see no reason why this integration would not follow the same approach as the core integrations and leave it in until 2024.3 This gives users time to adapt

I agree it was a little rushed, also the communication from HA was not entirely clear plus it was announced for the 2023.8 release and then rolled back and redone in 2023.9.
For future updates, I'll take a bit more time to investigate and make sure to align with built-in integrations.

from ha-knmi.