Geographic coverage: price data is Europe-only; plan internationalisation

[HuggeK]

Summary

FTW's external data sources have different geographic reach. Device control, weather forecasting and the self-learning PV twin work worldwide. Price-driven planning works only where a price provider exists, which today means Europe. Since #1219 the Weather tab shows which sources cover the pinned location, so the limit is no longer silent. What remains is a price path for the rest of the world.

Where it stands, 2026-09-18

Spot prices: Europe only (price.provider)

Provider	Coverage	Key
sourceful	European day-ahead (cached ENTSO-E), Nord Pool fallback when stale (#1044)	No
elprisetjustnu	Sweden, SE1–SE4	No
entsoe	ENTSO-E member markets	Yes

Every European bidding zone is billed in its own currency since #748. There is no provider outside Europe and no flat-rate or time-of-use option.

Weather / PV forecast: worldwide (weather.provider): met_no, openweather, open_meteo, forecast_solar.

Coverage shown in the UI: done. go/internal/coverage and GET /api/data-sources declare area and countries per source. The Weather tab renders that for the current pin and flags sources that do not apply (#1219, merged 2026-09-17).

Scrapped: STRÅNG PV scoring and Lantmäteriet roof geometry. The owner removed the STRÅNG, roof geometry and panel drawing stack from Core scope (#1214, 2026-09-12); #734, #735, #826 and #1052 are closed. No PV performance scoring ships, so nothing is Nordic-only any more. Normal setup must work without irradiance-source selection, azimuth or panel layouts. An optional extension is undecided.

What a non-European site loses

Price-driven optimisation. Everything else works.

Open

1. Static / time-of-use price provider. The one change that unlocks flat-rate and TOU markets worldwide with no third-party integration. feat(prices): static / time-of-use tariff so planning works outside Europe #1051 carries it but was parked behind feat(weather): add STRÅNG as an irradiance source and declare source coverage #734 and now overlaps the merged coverage code; it needs a rebase down to just the provider.
2. Non-European market adapters (AEMO/Amber for Australia, US ISO feeds) only if there is appetite. They should not block 1.
3. Is worldwide support a goal? The owner's call, and it decides how much of 2 is worth building.

[frahlg]

The coverage table that #718 was going to add, plus the product API and the UI so the limitation is not silent: #1051

That is proposal 4 and the documentation. It does not implement a static/TOU price provider, Open-Meteo Archive irradiance, or non-European market adapters — those questions still stand. STRÅNG is documented as not shipped rather than advertised, because there is no client for it on master.

#734 already carries a later version of the same registry plus STRÅNG. If #1051 lands first, #734 should rebase and add STRÅNG to the registry rather than reintroduce it.

[frahlg]

Course correction on #1051: the coverage API/UI is dropped (that surface belongs to #734). In its place is proposal 1 from this issue — price.provider: static, a flat rate or time-of-use schedule, so price-driven planning works outside Europe without a market adapter.