Skip to content

Fix forecast attribution priority: prefer actual data source over configured provider - #306

Open
smeisens wants to merge 1 commit into
OpenSprinkler:masterfrom
smeisens:fix-forecast-attribution-priority
Open

Fix forecast attribution priority: prefer actual data source over configured provider#306
smeisens wants to merge 1 commit into
OpenSprinkler:masterfrom
smeisens:fix-forecast-attribution-priority

Conversation

@smeisens

Copy link
Copy Markdown

Description

OSApp.Weather.showForecast() in www/js/modules/weather.js (line ~798) builds the
forecast page's attribution text using:

OSApp.Weather.makeAttribution(
    OSApp.currentSession.controller.settings.wto?.provider ||
    OSApp.currentSession.weather.wp ||
    OSApp.currentSession.weather.weatherProvider
)

weather.weatherProvider is a mandatory field on the WeatherData interface in
OpenSprinkler-Weather — every provider implementation sets it to its own identifier
("OpenMeteo", "local", "Apple", etc.), and the /weatherData endpoint always
passes it through unchanged. It reliably reflects the actual source of the displayed
forecast data.

controller.settings.wto.provider, by contrast, reflects the configured main
provider — which is checked first here and, being almost always present, wins before
weather.weatherProvider is ever consulted.

Why this matters

For every setup to date, these two values have always been identical (a single
provider serves the whole response), so the priority order has been harmless in
practice. However, prioritizing configuration over actual data origin is a latent
inconsistency: it assumes the two always match rather than reflecting what was
genuinely returned.

This stops being harmless once a backend can serve forecast data from a source
different from the main configured provider — for example,
OpenSprinkler/OpenSprinkler-Weather#184 adds an independently
configurable FORECAST_WEATHER_PROVIDER for the rain-forecast restriction and
forecast display, decoupled from the main WEATHER_PROVIDER used for Zimmerman/ETo.
With that change, a user could have WEATHER_PROVIDER=local (their own PWS) and
FORECAST_WEATHER_PROVIDER=Apple — and the App would display "Powered by your Local
PWS" for data that actually came from Apple WeatherKit, which could be a problem
under Apple's attribution requirements.

Fix

Swap the priority so the actual data source is preferred when available, falling
back to the configured provider only if the response doesn't specify one:

OSApp.Weather.makeAttribution(
    OSApp.currentSession.weather.weatherProvider ||
    OSApp.currentSession.weather.wp ||
    OSApp.currentSession.controller.settings.wto?.provider
)

This is a no-op for every existing setup (the two values have always matched), and
fixes the display correctly for backends that can source forecast data
independently.

Testing

Manually verified with a local OpenSprinkler-Weather instance running
WEATHER_PROVIDER=local + FORECAST_WEATHER_PROVIDER=OpenMeteo — attribution now
correctly shows "Powered by Open Meteo" instead of "Powered by your Local PWS".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant