Summary
FTW's external data sources have very different geographic reach, and today that
isn't written down anywhere. The practical effect is that price-driven
planning only works in Europe and PV performance scoring only works in the
Nordics, while device control and weather forecasting work worldwide.
This issue documents the current picture and asks how far we want to take
internationalisation. A reference table has been added in
docs/data-coverage.md
(PR #718).
Current coverage
Spot prices — Europe only (price.provider)
| Provider |
Coverage |
Key |
sourceful |
European day-ahead (cached ENTSO-E) |
No |
elprisetjustnu |
Sweden only, SE1–SE4 |
No |
entsoe |
ENTSO-E member markets |
Yes |
There is no provider for any market outside Europe, and no manual or
fixed-tariff option to stand in for one. Prices are also stored internally in
öre, with ENTSO-E's EUR/MWh converted via ECB FX rates.
Weather / PV forecast — worldwide (weather.provider): met_no,
openweather, open_meteo, forecast_solar are all global. No gating.
PV performance scoring — Nordics only: the new STRÅNG scorer depends on an
SMHI product whose domain is the Nordic region. Outside it, scoring produces no
rows and the dashboard overlay stays hidden — and since the same scoring now
feeds the forecast calibration factor, those sites also lose measured
calibration.
Roof geometry (planned, #717) — Sweden only: Lantmäteriet data.
What a non-European site loses
Control, safety, telemetry, dashboard, forecasting and the self-learning PV twin
all work. What does not: price-driven optimisation (no source), PV
performance scoring and calibration (outside STRÅNG), and automatic roof
geometry (Sweden only).
That is a significant chunk of the value proposition, and it fails by silent
absence rather than by a clear "not available in your region" signal.
Proposals
1. A manual / fixed-tariff price provider — highest value, lowest effort.
A static provider taking either a flat öre/kWh or a time-of-use schedule would
immediately unlock every flat-rate and TOU market on earth, which covers most
US residential utilities and much of Asia-Pacific. It needs no third-party
integration and reuses the existing storage path.
2. Global historical irradiance via a source we already talk to.
Open-Meteo's Archive API serves historical shortwave_radiation globally, free
and keyless — and the Open-Meteo client already exists in internal/forecast.
Adding it as a fallback irradiance source behind the existing pvperf interface
would make performance scoring and calibration work worldwide, with STRÅNG kept
as the higher-resolution option inside its domain.
Other historical-irradiance options considered
- PVGIS (JRC) — SARAH/ERA5 hourly, free, keyless, near-global.
- NASA POWER — genuinely global and keyless, but coarse (~0.5°).
- CAMS Radiation Service — high quality over the Meteosat disk (Europe,
Africa, Middle East), free but requires registration.
Open-Meteo Archive is proposed first purely because the HTTP client, the
parsing and the retry behaviour are already in-tree.
3. Non-European market adapters, if there's appetite.
Australia has a clean public option (AEMO/Amber). US real-time LMP would need
per-ISO work or an aggregator; that's a much larger commitment than 1 and 2 and
probably shouldn't block them.
4. Surface the limitation in the UI.
Whatever we support, the Weather and Price settings tabs could say plainly when
a chosen location falls outside a source's domain, instead of leaving the
operator to infer it from an empty chart.
Questions
- Is a
static / time-of-use price provider something you'd accept, and should
it live in internal/prices alongside the fetching providers?
- Should
pvperf grow a provider interface for historical irradiance (STRÅNG +
Open-Meteo Archive), mirroring how forecast.Provider works today?
- Is worldwide support an actual goal for FTW, or is Europe/Nordics the
intended scope? That answer changes how much of the above is worth building.
Summary
FTW's external data sources have very different geographic reach, and today that
isn't written down anywhere. The practical effect is that price-driven
planning only works in Europe and PV performance scoring only works in the
Nordics, while device control and weather forecasting work worldwide.
This issue documents the current picture and asks how far we want to take
internationalisation. A reference table has been added in
docs/data-coverage.md(PR #718).
Current coverage
Spot prices — Europe only (
price.provider)sourcefulelprisetjustnuentsoeThere is no provider for any market outside Europe, and no manual or
fixed-tariff option to stand in for one. Prices are also stored internally in
öre, with ENTSO-E's EUR/MWh converted via ECB FX rates.
Weather / PV forecast — worldwide (
weather.provider):met_no,openweather,open_meteo,forecast_solarare all global. No gating.PV performance scoring — Nordics only: the new STRÅNG scorer depends on an
SMHI product whose domain is the Nordic region. Outside it, scoring produces no
rows and the dashboard overlay stays hidden — and since the same scoring now
feeds the forecast calibration factor, those sites also lose measured
calibration.
Roof geometry (planned, #717) — Sweden only: Lantmäteriet data.
What a non-European site loses
Control, safety, telemetry, dashboard, forecasting and the self-learning PV twin
all work. What does not: price-driven optimisation (no source), PV
performance scoring and calibration (outside STRÅNG), and automatic roof
geometry (Sweden only).
That is a significant chunk of the value proposition, and it fails by silent
absence rather than by a clear "not available in your region" signal.
Proposals
1. A manual / fixed-tariff price provider — highest value, lowest effort.
A
staticprovider taking either a flat öre/kWh or a time-of-use schedule wouldimmediately unlock every flat-rate and TOU market on earth, which covers most
US residential utilities and much of Asia-Pacific. It needs no third-party
integration and reuses the existing storage path.
2. Global historical irradiance via a source we already talk to.
Open-Meteo's Archive API serves historical
shortwave_radiationglobally, freeand keyless — and the Open-Meteo client already exists in
internal/forecast.Adding it as a fallback irradiance source behind the existing
pvperfinterfacewould make performance scoring and calibration work worldwide, with STRÅNG kept
as the higher-resolution option inside its domain.
Other historical-irradiance options considered
Africa, Middle East), free but requires registration.
Open-Meteo Archive is proposed first purely because the HTTP client, the
parsing and the retry behaviour are already in-tree.
3. Non-European market adapters, if there's appetite.
Australia has a clean public option (AEMO/Amber). US real-time LMP would need
per-ISO work or an aggregator; that's a much larger commitment than 1 and 2 and
probably shouldn't block them.
4. Surface the limitation in the UI.
Whatever we support, the Weather and Price settings tabs could say plainly when
a chosen location falls outside a source's domain, instead of leaving the
operator to infer it from an empty chart.
Questions
static/ time-of-use price provider something you'd accept, and shouldit live in
internal/pricesalongside the fetching providers?pvperfgrow a provider interface for historical irradiance (STRÅNG +Open-Meteo Archive), mirroring how
forecast.Providerworks today?intended scope? That answer changes how much of the above is worth building.