NEW Hybrid weather data - local & online

[smeisens]

Hybrid weather data (local history + external forecast)

This PR introduces a hybrid weather mode that combines:

• local weather data for the past 7 days and today
• external weather data for upcoming forecast days

The goal is to improve watering decisions by using accurate local observations for historical calculations while still relying on forecast data for future days.

Key points:

• Hybrid mode is optional and does not change existing behavior
• Works with existing weather adjustment methods (Zimmerman / ETo, depending on data availability)
• Keeps scope limited to hybrid weather handling to avoid larger structural changes

Notes:

This PR does not strictly depend on other open PRs

• PR add persistence to docker #144 mainly affects data persistence across container restarts
• PR Support multiday for local provider #170 adds multi-day local weather data; hybrid works independently but benefits from consistent multi-day handling

[smeisens]

Weather Underground requires an API key. Since I don't have one, unfortunately I can't test it; but theoretically it should work.

[rayshobby]

@smeisens: if you'd like to test the Wunderground feature, you can follow our support article to create an API key:
https://openthings.freshdesk.com/support/solutions/articles/5000017485-using-weather-underground-wu-
it doesn't require you to own any hardware. Or alternatively, send an email to ray@opensprinkler.com and I can give you my API key.

[rmloeb]

Ray, I have an API key for Wunderground. I need to wait until the ground thaws before I can do a real test :-)

[smeisens]

I have created an API key and successfully stored it in OSPi.

However, the log reports that no data from WunderGrund is currently being used.

I'll look at it in the coming days to see what it is. I already had a similar problem with openMeteo.

Presumably the hybrid.ts will have to be adapted so that it filters and takes over the data of WunderGround differently. I will then also check it with the other weather providers and adjust it if necessary.

[smeisens]

I’d like to add some context on the current state of this PR and how I see possible next steps.

The current implementation is a stable intermediate step and works well for my setup. The main goal was to make hybrid weather data usable in a predictable way while keeping the scope limited and reviewable.

I intentionally stopped here, as going further would require broader structural changes that are likely better discussed and implemented step by step. While working on this, a few limitations and follow-up topics became apparent:

• External weather providers differ significantly in what data they deliver and how it is structured. Because of this, not all providers work identically out of the box, and additional alignment would be required for fully consistent behavior.
• ETo calculations are not always possible, depending on data availability; Zimmerman is generally more robust in this regard.
• Restriction handling depends on consistent multi-day data and could benefit from further consolidation.

From my perspective, a reasonable way forward could be:

1. Introduce a small internal normalization layer so all providers expose a consistent minimal data set
2. Align existing external providers to that normalized structure
3. Clarify and improve ETo fallback behavior (ETo vs. Zimmerman)
4. Unify restriction handling across local, external and hybrid modes

Regarding other open PRs:

• PR add persistence to docker #144 is not required for the hybrid functionality itself and mainly affects data persistence across container restarts
• PR Support multiday for local provider #170 adds multi-day support for local weather data; hybrid works independently, but benefits from consistent multi-day handling

I wanted to surface these points explicitly rather than silently evolving the structure. I’m happy to adjust scope, split things up, or keep this PR focused purely on hybrid handling, depending on what makes most sense for the project.

[FranzStein]

@smeisens: Great work. I've installed the OpenSprinkler Hybrid weather data updates on my Raspberry PI 3. It works as expected. However, if I look at the watering results they are too high for the current weather situation here in Germany. I recognized that this is caused by the fact that no humidity forecasts are generated by most Weather Forecast Providers.

Please note that Weather Underground provides humidity forecast data. Relative humidity is provided within the 5-day forecast as day and night forecasts, day = 7am to 7pm and night = 7pm to 7am. The following code changes are needed for WUnderground.ts:

	........
	// Added humidity day and night forecasts, day = 7am to 7pm and night = 7pm to 7am
       for ( let index = 0; index < forecast.dayOfWeek.length; index++ ) {
             weather.forecast.push( {
                    temp_min: Math.floor( forecast.temperatureMin[index] ),
                    temp_max: Math.floor( forecast.temperatureMax[index] ),
                    humidity_day: Math.floor( forecast.daypart[0].relativeHumidity[index * 2] ),
                    humidity_night: Math.floor( forecast.daypart[0].relativeHumidity[index * 2 + 1] ),
                    precip: forecast.qpf[index] + forecast.qpfSnow[index],
                    date: forecast.validTimeUtc[index],
                    icon: this.getWUIconCode( forecast.daypart[0].iconCode[index] ),
                    description: forecast.narrative[index]
                    } );
             }
	     return weather;
	}
	........

and HybridWUndergroundProvider.ts

        ........
        // Convert forecast array to WateringData format
        const allForecastData: WateringData[] = weatherData.forecast.map(day => ({
            weatherProvider: "WUnderground",
            periodStartTime: day.date,
            temp: (day.temp_min + day.temp_max) / 2,  // Average temperature
            humidity: (day.humidity_day + day.humidity_night) / 2, // Relative humidity
            precip: day.precip,  // Already combined (qpf + qpfSnow) in WU provider
            minTemp: day.temp_min,
            maxTemp: day.temp_max,
            minHumidity: day.humidity_day,  // Relative humidity from 7am to 7pm
            maxHumidity: day.humidity_night,  // Relative humidity from 7pm to 7am
            solarRadiation: undefined,  // Not available in daily API
            windSpeed: undefined  // Not available in WU daily forecast API
        }));
        .........

I like the Hybrid approach as it makes perfect use of running the OpenSprinkler weather service locally on a Raspberry PI.
It is maybe worth adding these changes.

[FranzStein]

Two additional suggestions:

Enhancing Data Reliability: To improve the accuracy of water level calculations for multi-day cycles, it is recommended to reduce the dependence on long-term weather forecasts, which are often unreliable for predicting exact rainfall totals. For example, if a 3-day watering schedule is active, forecasted weather is the only data used to estimate water levels. By introducing a FORECAST_DAYS environment variable, users can limit the calculation to a more trustworthy timeframe. Integrating historical observations alongside short-term forecasts would yield more robust results.

Flexible Sensor Requirements: Since wind speed data is not currently factored into the Zimmerman formula, its validation should be made optional. This ensures compatibility with a wider range of hardware, as some weather stations don’t include anemometers. I recommend modifying the validation logic to mirror the current handling of solar radiation data.