[REQ] Other forcast services than OWM

[Kurisutian]

Is your feature request related to a problem? Please describe.
The "problem" is more personal nature. With the OWM API change to 3.0 it is required to provide some credit card information to them even if nothing will be purchased. However the chances exist that if something is configured wrong you end up paying for it. So it would be handy if alternative forecasting services would be working with this service as well.

Describe the solution you'd like
I would love to have services like eg. pirate weather, DWD or any other service which offers a "truly" free forecast service would be working with HA Smart Irrigation so there would be a greater choice to what to use.

Describe alternatives you've considered
The only alternative would be not using any forecasting at all which would be a pity since it was quite handy considering next day rain forecast to be respected in the calculation.

Additional context
Maybe allowing a forecast service in general might be helpful? I checked for my set up services DWD and pirate weather and both offer forecasting so it could be up to any user to choose the forecast weather service which suits best for them.

[jeroenterheerdt]

Great idea, thanks. The issue here is that normal integrations in HA ignore the forecast as they are only interested in current weather. So that would mean we would be integration with the others one by one, like OWM.
Not sure how easy that is (it's not) so not likely that will happen.

Alternatively you can set limits in OWM set up to make sure you never pay, or use a fake credit card number (I did that).

[Kurisutian]

Great idea, thanks. The issue here is that normal integrations in HA ignore the forecast as they are only interested in current weather. So that would mean we would be integration with the others one by one, like OWM. Not sure how easy that is (it's not) so not likely that will happen.

Alternatively you can set limits in OWM set up to make sure you never pay, or use a fake credit card number (I did that).

I think some of the alternatives offer forecasting. So considering a dropdown list of compatible services could also be an option. Just some thought as I generally do not appreciate some stunts like they did with OWM and suddenly require payment data for services which were free in the beginning.
Since there are perhaps some local differences in accuracy as well, it might be interesting to be more flexible as long as requirements are met which could be mentioned in the documentation along with the recommendation to OWM maybe? In that case there would be a working option and anything else is up to the user and still it would not limit things to OWM only eventually.

[jeroenterheerdt]

yeah, but that would mean implementing quite a few things:

1. dedicated libraries to talk to each API
2. a dropdown to select which API to use for forecasting. That should be dependent on the API keys you have set up
3. Complex logic in the HA config flow to ask for which API to set up because we shouldn't be storing the API key in the integration itself.

all in all, interesting idea, but not as easy as it might look

[Kurisutian]

Instead of calling an API from within the integration how about calling an 3rd party weather integration for the forcast values? I was more thinking about that. So calling the weather.get_forecast service and just entering the weather entity from another integration should be revealing the required data and values, wouldn't it? I mean in the end this just needs to be triggered before calculation happening if I am not mistaken. Anyhow it's just an idea how to ease the complexity and not having to deal with that in the integration itself but rather get the required data from other integrations. How about something like that?

[jeroenterheerdt]

I thought about that as well, but that means taking a dependency on setting up other integrations and they actually performing their job correctly. I tried that using the OWM integration, and let me say... that failed.

[jeroenterheerdt]

for example, the OWM integration does not allow you to get to a forecast for tomorrow or the days after. Useless for our purposes. This issue will compound if we start relying on other weather services integrations.
That's why I am saying we should integrate ourselves with those services.

To make some progress here - can you make a list of services including links to their integrations that you'd like to see?

[Kurisutian]

I'm currently using DWD (German Weather Service), Open-Meteo (both seem not to require an API) and Pirate Weather.

I found some more here in the discussion https://community.home-assistant.io/t/definitive-guide-to-weather-integrations/736419 but for me personally these are the ones that serve my purpose.

[jeroenterheerdt]

Looks like pirate weather is the only one that would work for all we need from the forecast.
The rest don't provide what we need. That reduces the scope of the work required.

[Kurisutian]

It would already be awesome to have one true free alternative to OWM and the doubtful path they chose (although cheating out of it works) 😉

Thanks a bunch for considering, I know there are a bunch of people that moved to pirate weather due to the OWN 2.5 API deprecation. So chances are high others will make use of it as well.

[jeroenterheerdt]

here you go - first version with PW support is now in beta. Keep in mind that it's not very smart to install this in production yet, but please try it if you have a test environment!

[Kurisutian]

So I checked out version v2024.6.13 and got the following error:

Logger: custom_components.pirateweather.weather_update_coordinator
Quelle: helpers/update_coordinator.py:344
Integration: Pirate Weather (Dokumentation, Probleme)
Erstmals aufgetreten: 12:37:41 (1 Vorkommnisse)
Zuletzt protokolliert: 12:37:41

Error fetching pirateweather data: Error communicating with API: 500, message='Internal Server Error', url=URL('https://api.pirateweather.net/forecast/<my_API_Key>/49.11390230932526,8.256319463253023?units=si&extend=hourly&version=2')

Also the following warning popped up (which might not be related but still it shows):

Logger: custom_components.smart_irrigation
Quelle: custom_components/smart_irrigation/__init__.py:735
Integration: Smart Irrigation ([Dokumentation](https://github.com/jeroenterheerdt/HASmartIrrigation), [Probleme](https://github.com/jeroenterheerdt/HASmartIrrigation/issues))
Erstmals aufgetreten: 12:17:35 (3 Vorkommnisse)
Zuletzt protokolliert: 13:17:35

Unable to find mapping with id in update all: 0

[jeroenterheerdt]

Thanks, I have seen both. Interestingly it looked like the first one was a PW issue. Can you try calling that same URL with Postman to see what it does? I have had multiple runs where this happened and the URL didn't work in Postman either.

Second: I have seen this as well, but resolved it by making sure all sensor groups on my zones exist. Can you post your config?

[Kurisutian]

Don't have postman on my work laptop so that will take a little while. As for the config, can it be extracted somehow or do you want me to post the screenshots of how it's configured? Checked the URL in the browser and it seems to be fine...

[jeroenterheerdt]

Since downloading diag files seems to be broken best bet if to paste the contents of the smart_irrigation file in `. Storage'

[Kurisutian]

OK, here is what I have configured. I did remove all data though since it would exceed the message length:

{
  "version": 4,
  "minor_version": 1,
  "key": "smart_irrigation.storage",
  "data": {
    "config": {
      "calctime": "23:00",
      "units": "metric",
      "use_weather_service": true,
      "weather_service": "Pirate Weather",
      "autocalcenabled": true,
      "autoupdateenabled": true,
      "autoupdateschedule": "minutes",
      "autoupdatedelay": "0",
      "autoupdateinterval": "30",
      "autoclearenabled": true,
      "cleardatatime": "23:59",
      "starteventfiredtoday": true
    },
    "zones": [
      {
        "id": 2,
        "name": "Beete",
        "size": 64.0,
        "throughput": 18.0,
        "state": "automatic",
        "bucket": 1.7971174837072013e-6,
        "old_bucket": 0,
        "delta": 0,
        "duration": 0,
        "module": 0,
        "multiplier": 1.0,
        "explanation": null,
        "mapping": 0,
        "lead_time": 0.0,
        "maximum_duration": 900.0,
        "maximum_bucket": 50,
        "last_calculated": "2024-06-17T12:21:31.850040",
        "last_updated": "2024-06-17T12:01:50.436378",
        "number_of_data_points": 24
      },
      {
        "id": 1,
        "name": "Rasen",
        "size": 96.0,
        "throughput": 15.0,
        "state": "automatic",
        "bucket": 1.7971174837072013e-6,
        "old_bucket": 0,
        "delta": 0,
        "duration": 0,
        "module": 0,
        "multiplier": 1.0,
        "explanation": null,
        "mapping": 0,
        "lead_time": 0.0,
        "maximum_duration": 2700.0,
        "maximum_bucket": 50,
        "last_calculated": "2024-06-17T12:21:31.889027",
        "last_updated": "2024-06-17T12:01:50.436378",
        "number_of_data_points": 24
      }
    ],
    "modules": [
      {
        "id": 0,
        "name": "PyETO",
        "description": "Die Berechnung der Dauer basiert auf der FAO56-Formel aus der PyETO-Bibliothek.",
        "config": {
          "forecast_days": "2",
          "solrad_behavior": "4"
        },
        "schema": [
          {
            "type": "boolean",
            "name": "coastal",
            "optional": true,
            "default": false
          },
          {
            "type": "select",
            "options": [
              [
                "1",
                "EstimateFromTemp"
              ],
              [
                "2",
                "EstimateFromSunHours"
              ],
              [
                "3",
                "DontEstimate"
              ],
              [
                "4",
                "EstimateFromSunHoursAndTemperature"
              ]
            ],
            "name": "solrad_behavior",
            "required": true,
            "default": "1"
          },
          {
            "type": "integer",
            "name": "forecast_days",
            "required": true,
            "default": 0
          }
        ]
      }
    ],
    "mappings": [
      {
        "id": 0,
        "name": "Lokale Sensoren",
        "mappings": {
          "Dewpoint": {
            "source": "sensor",
            "sensorentity": "sensor.gw1100a_dewpoint",
            "unit": "",
            "aggregate": "average"
          },
          "Evapotranspiration": {
            "source": "none",
            "sensorentity": "",
            "unit": ""
          },
          "Humidity": {
            "source": "sensor",
            "sensorentity": "sensor.gw1100a_humidity",
            "unit": "",
            "aggregate": "average"
          },
          "Precipitation": {
            "source": "sensor",
            "sensorentity": "sensor.gw1100a_daily_rain_rate",
            "unit": ""
          },
          "Pressure": {
            "source": "sensor",
            "sensorentity": "sensor.gw1100a_absolute_pressure",
            "unit": "",
            "aggregate": "last"
          },
          "Solar Radiation": {
            "source": "sensor",
            "sensorentity": "sensor.gw1100a_solar_radiation",
            "unit": "W/m2"
          },
          "Temperature": {
            "source": "sensor",
            "sensorentity": "sensor.gw1100a_outdoor_temperature",
            "unit": "",
            "aggregate": "average"
          },
          "Windspeed": {
            "source": "sensor",
            "sensorentity": "sensor.gw1100a_wind_speed",
            "unit": "km/h"
          }
        }, ...

[jeroenterheerdt]

Interesting because you do have a mapping with ID 0. That sa bug then. Thanks for reporting.

[Kurisutian]

You're welcome. Also I re-triggered the automation to get the forecast (after a restart) and it seems that the error from pirate weather disappeared. Eventually this was just on their end. Maybe there would be a way to make the call more resilient in case of this and maybe retry the call again if the first one failed? For now it seems working with the forecast data.

[jeroenterheerdt]

should be better now, please try. v2024.7.0 and confirm

[Kurisutian]

I updated to v2024.7.2 just now. Will observe things a couple of days. Thanks for the implementation.

[Kurisutian]

So since the first cycle did run, I do not see any issues. Calculation was done as it seems and sprinklers were running. I would presume things are working fine. Shall I close here?