Proposal for an Extensible Weather Provider Interface

[kaerbr]

Hello everyone,

I'm a big fan of this project and was inspired to contribute by making it more flexible and open to future expansion. My main goal was to refactor the way weather data is fetched so that our community can easily add new weather providers in the future.

To achieve this, I've introduced a generic interface for weather APIs. This means the core application no longer needs to know the specific details of OpenWeatherMap, making the whole system more modular.

What I've Done:

1. Created a Generic Data Model: The include/model/WeatherData.h struct is now API-agnostic. It serves as a standardized data model for all weather information, regardless of the source. The renderer uses this single format, simplifying the display logic.

2. Defined a Provider Interface: I've created an abstract class in include/provider/WeatherProvider.h. This acts as a contract, defining a simple fetchWeatherData function that any new provider must implement.

3. Refactored the OpenWeatherMap Provider: The existing OpenWeatherMapProvider.cpp has been updated to implement the new interface, demonstrating how the new structure works without losing any functionality.

4. Added Open-Meteo as a New Example: To prove the concept, I've added a completely new OpenMeteoProvider.cpp. This shows how straightforward it is to integrate a new API from scratch.

Why This is Useful:

• Extensibility: Anyone can now add support for a new service (e.g., a national weather service, AccuWeather, etc.) just by creating a new class that implements the WeatherProvider interface plus configuring it in WeatherProviderFactory.cpp and setting the correct variable in config.h.
• Maintainability: By decoupling the data-fetching from the rendering logic, future changes to one part won't break the other.
• Lower Barrier to Contribution: This makes it significantly easier for other developers to contribute new weather providers to the project.

I believe these changes lay a strong foundation for the project's growth and make it even more versatile. I'm looking forward to your feedback and thoughts on this proposal.

An Open Question for Discussion: Weather Icons

While implementing this new interface, I identified a remaining architectural issue in src/display_utils.cpp. The function getConditionsBitmap() is implemented twice, using an #ifdef to switch between a version for OpenWeatherMap's specific weather codes and another for the more generic WMO codes used by for example Open-Meteo.

This current approach forces the display logic to be aware of provider-specific details, which undermines the goal of creating a truly agnostic rendering layer.

The responsibility for mapping a weather condition to a specific icon should ideally be moved into each provider. This would fully decouple the renderer from the data source.
For now I did not have the time / the right idea to implement this.
As of now I used the proposal of @j-era (https://github.com/j-era) (#146)

The code can be found here: https://github.com/kaerbr/esp32-weather-epd/tree/new-weather-provider-interface

The following issues / PRs are related:

• support of open-meteo #115
• Feature/open-meteo #146
• Support for NOAA weather API (or other sources)? #180