PV Forecast — 7-Tage-PV-Ertrag (Standort)
GET /v1/plant/pv-forecast — 7-Tage-Solarertrag (kWh). Loxone: PV Forecast Guide. Offene REST-API; Community 200 billable Anfragen/Tag (PV zählt in denselben Fair-Use-Pool — empfohlen stündlich).
Was macht diese Funktion?
PV Forecast schätzt, wie viel Solarstrom Ihre Anlage an Ihrem Standort in den nächsten Tagen liefern wird — in kWh pro Tag (optional auch stündlich).
Alltagsbeispiel: „Heute ca. 18 kWh, morgen 22 kWh, übermorgen bei Wolken nur 8 kWh.“
Dieselbe Schätz-Engine wie unter Anlagenprognose und in Hours Demand — kein zweiter Rechner. Nach Hours-Decide speichert der Server ein PV-Pack mit Modell-FC (Tages-/Stundenwerte + pv_hash). GET und Outlook preferieren ein frisches Pack (≤6 h, gleiches Profil, Weather nicht neuer / Cache nicht midday-stale, Stundenreihe vorhanden, days[0] = heute). Serve: Mit optionalem PV-Ertragszähler ist D0 (heute) in GET/loxone.d0_kwh und Portal/Sparvo Ist + Prognose (derselbe Calendar-Meter-Blend, keyed nach Kalenderdatum); Folgetage und pv_hash bleiben Modell-FC. loxone.d0_soc_eod / txt_d0 SoC werden bei jedem GET und bei SOC-Telemetrie aus dem aktuellen Live-SoC neu gerollt. PV und geplante Netz-kWh der laufenden Stunde zählen nur die Restminuten, die Last dieser Stunde bleibt ganz. Wird neu geschätzt (z. B. nach Open-Meteo-Refresh), schreibt der Server das Pack (FC) nach — die Anzeige folgt dem Serve-Blend. Scheitert der Live-Estimate nach Invalidate, bleibt ein altersgültiges Pack (Fingerprint + ≤6 h) verfügbar — Serve alignt D0 auf heute (pad/strip; fehlendes Heute → synthetisches D0); kein hartes weather_missing, solange das Pack noch passt. Kill HOURS_PV_METER_REFINE=0 → kein Scale; Ist wird trotzdem gemalt.
Wann nutzen?
- Anzeige im Smart Home (z. B. Loxone Merker „Heute / Morgen …“)
- Skripte, die den erwarteten PV-Ertrag brauchen
Nicht nötig, wenn Sie nur Strompreise wollen → Forecast.
Endpoint
GET https://api.spotpriceapi.com/v1/plant/pv-forecast
Header:
X-API-Key: sf_live_YOUR_KEY
Mindestens Community-Zugang. Anonymer Basic-Key → pv_status: not_available.
Query-Parameter
| Parameter | Default | Werte | Bedeutung |
|---|---|---|---|
granularity | daily | daily \ | hourly \ |
days | 7 | 1…7 | Kalendertage ab heute in der Response (days/hours/totals); Live-Estimate + Pack speichern immer 7 FC-Tage (kurze Query zero-füllt das Pack nicht) |
timezone | Profil / Europe/Vienna | IANA | Taggrenzen; bei Pack-Serve gewinnt die Pack-/Serve-TZ im JSON (Query überschreibt Taggrenzen nicht) |
locale | aus TZ abgeleitet | z. B. de, en | Texte in portal_hint |
Standort & kWp aus dem Portal
Geo und Anlagengröße kommen aus dem Anlagenprofil Ihres API-Keys — nicht aus der Query.
Tragen Sie unter Standort & Profil ein:
- Adresse / Koordinaten (beim Speichern werden Koordinaten aus der Adresse geprüft/gesetzt, sofern nötig)
- PV-Größe (kWp)
Fehlt etwas → pv_status: incomplete_input plus portal_hint und portal_url.
| Lage | pv_status | Was tun? |
|---|---|---|
| Lat/Lon oder kWp fehlen | incomplete_input | Portal füllen |
| Wettercache noch leer | weather_missing | später erneut versuchen |
| Alles ok | ok | days / loxone nutzen |
| Basic-Key | not_available | Registrieren |
Minimal-Beispiel
curl -s "https://api.spotpriceapi.com/v1/plant/pv-forecast?granularity=daily&days=7&timezone=Europe/Vienna" \
-H "X-API-Key: sf_live_YOUR_KEY"
{
"pv_status": "ok",
"pv_engine": "pv_forecast_v1",
"quota_class": "pv",
"timezone": "Europe/Vienna",
"days": [
{ "date": "2026-08-12", "label": "D0", "pv_kwh": 18.4 },
{ "date": "2026-08-13", "label": "D1", "pv_kwh": 22.1 }
],
"totals": { "pv_kwh_horizon": 124.6 },
"loxone": {
"d0_kwh": 18.4,
"d1_kwh": 22.1,
"d2_kwh": 19.0,
"d3_kwh": 8.2,
"d4_kwh": 15.6,
"d5_kwh": 21.3,
"d6_kwh": 20.0,
"week_kwh": 124.6,
"d0_load_kwh": 21.5,
"d1_load_kwh": 18.3,
"d0_soc_eod": 16.5,
"d0_tmax": 24.8,
"d0_tmin": 12.8,
"txt_d0": "Mo 12.08.2026 · PV 18,4 kWh · Last 21,5 kWh · SoC 16,5% · 13-25°",
"txt_d1": "Di 13.08.2026 · PV 22,1 kWh · Last 18,3 kWh · SoC 23,7% · 14-26°",
"txt_status": "OK"
},
"missing": [],
"portal_hint": null
}
Antwortfelder (Alltag)
| Feld | Einfach |
|---|---|
pv_status | ok = Werte brauchbar |
days[].pv_kwh | Erwarteter Ertrag dieses Tages (kWh). D0 mit PV-Zähler: Ist+Prognose; Folgetage: Modell-FC |
days[].pv_kind | Optional: meter_blend oder forecast (D0) |
days[].pv_meter_today_kwh | Optional: Ist heute bisher (bei meter_blend) |
loxone.d0_kwh … d6_kwh | Dieselben Tageswerte flach für PicoC (d0_kwh = Serve-D0 wie oben) |
loxone.week_kwh | Summe der 7 Tage |
loxone.d0_load_kwh / d1_load_kwh | Last heute/morgen, nur wenn Profil oder Zähler da. Heute = dieselbe Schätzung wie Hours/Portal (Typical + Same-Day-Overlay); morgen = reines Typical. Die Hours-Stundenreihe kann davon abweichen |
loxone.d0_soc_eod | Speicherstand-Tagesende heute (%), nur mit Speicher+SoC. Start = aktueller Live-SoC (auch wenn das Decide-PV-Pack noch frisch ist). Lastform wie die Anlagenprognose (Zähler/Profil, D0 ab aktueller Stunde; flat 1/24 nur Fallback). Die Last der laufenden Stunde bleibt der volle Blend-Rest. PV und geplante Netz-kWh dieser Stunde zählen nur die Restminuten (LOXONE_EOD_OPEN_HOUR_FRACTION=0 stellt die ganze Stunde wieder her). Spätere Stunden bleiben ganz. Netz-kWh nur aus frischem Hours-day_plan mit energy_kwh > 0 (Snapshot ≤ 6 h); sonst nur PV gegen Last. Pack-η 0,95 |
loxone.d0_tmax / d0_tmin | Höchst/Tiefst heute (°C) aus dem Plant-Wetter-Cache |
loxone.txt_d0 / txt_d1 | Fertige Klartextzeilen für Loxone Txt2/Txt3 (fehlende Teile weggelassen) |
hours[] | Nur bei hourly / both: { start, pv_kwh } |
plant.kwp / pv_quality | Anlagengröße; Qualität oft indicative |
missing / portal_hint / portal_url | Was fehlt + Link zum Portal |
Ablauf
Portal: Standort + kWp
↓
GET /v1/plant/pv-forecast?granularity=daily
↓
days[] + loxone.d0…d6
↓
Anzeige / EMS / Loxone Merker
Kontingent
Kontingent-Klasse pv (Logging): zählt in denselben Billable-Pool wie Forecast/Hours/Decision (Community 200/Tag). Softcap 48/Tag entfällt (Kill-Switch QUOTA_UNIFIED_BILLABLE=0 stellt ihn wieder her).
Stündlich pollen reicht — Auto-Fetch um :05 im Loxone-Guide.
Die Strahlungs-/Wetter-Quelldaten kommen aus dem Plant-Wetter-Cache (Open-Meteo, Timer 05:20 + 12:20 Wien; Freshness: Morgen-Slot ab ~05:00, Mittag ab ~11:00 — siehe Weather).
Häufige Anfängerfehler
| Problem | Lösung |
|---|---|
incomplete_input | Standort + kWp speichern |
| Basic-Key | Community-Konto + persönlicher Key |
| Riesige JSON in PicoC | granularity=daily statt hourly |
| Doppelte GETs in Loxone | Virtual Output: Digitalausgang an, Befehl AUS leer |
Nächste Schritte
- Loxone PV Forecast — Schritt für Schritt mit PicoC
- Weather — Standortwetter (Anzeige)
- Hours Demand — Ladeplan mit PV-Bilanz
- Code-Beispiele
Community registrieren oder Code-Beispiele mit Ihrem persönlichen Key.