Copy page

Deutsch

Migration von V1

Die V2 API ändert das Grundprinzip: Statt jede Anfrage über URL-Parameter zu konfigurieren, legen Sie Standorte (Sites) an und fragen sie über ihre site_id ab.

Das neue Grundprinzip

	V1	V2
Konfiguration	Pro Anfrage in der URL	Einmal als Standort gespeichert
Abfrage	/v1/forecast?latitude=…&slope=…	/v2/forecast/{site_id}
Strings	Ein bis zwei Strings über Parameter	Mehrere strings pro Standort
Höhe/Zeitzone/Geländeprofil	Pro Anfrage & Bedarf berechnet	Automatisch ermittelt & gespeichert

Für Anwendungsfälle ohne persistente Standorte (z. B. einmalige Berechnungen) gibt es die Inline-Endpunkte, die der alten URL-Logik am nächsten kommen.

Endpunkt-Mapping

V1	V2
GET /v1/forecast?…	GET /v2/forecast/{site_id} oder POST /v2/forecast/inline
GET /v1/history?…	GET /v2/historical/{site_id} oder POST /v2/historical/inline
GET /v1/recent?…	In GET /v2/historical/{site_id} enthalten
(keine Site-Verwaltung)	POST/GET/PATCH/DELETE /v2/sites

In V2 sind /recent und /history zu einem Endpunkt verschmolzen.

Feldnamen & Antwortformat

Die V2 nutzt durchgängig klare Feldnamen und lokale Zeitstempel.

V1	V2
dtm (UTC)	timestamp (lokale ISO-8601-Zeit, siehe timezone)
spec_watts (W/kWp)	entfällt — V2 liefert direkt pv_power in W
pv_watts	pv_power (W)
GHI / DHI / BNI	ghi / dhi / bni
temp, weather_code	temp, weather_code (unverändert benannt)

Wichtige Unterschiede:

• Zeitstempel sind lokal, nicht UTC. Die IANA-Zeitzone steht im Feld timezone.
• gti / gti_shaded sind pro String und liegen im strings-Block (geneigte Einstrahlung hängt von der Ausrichtung ab) — siehe Prognosen.
• spec_power / spec_watts wird nicht mehr ausgegeben; nutzen Sie pv_power.

required_data → include-Gruppen

Statt einer freien Spaltenliste (required_data=pv_watts,temp) wählen Sie in V2 Feldgruppen über den wiederholbaren include-Parameter:

V1
GET /v1/forecast?required_data=pv_watts,temp,GHI

V2
GET /v2/forecast/{site_id}?include=weather&include=irradiance

Verfügbare Gruppen: default, weather, irradiance, clearsky, strings, variability, all. Details unter Prognosen.

Migrationsschritte

1. API-Key weiterverwenden — derselbe Key funktioniert für V1 und V2.
2. Für jede bisherige Parameter-Kombination einen Standort anlegen (POST /v2/sites).
3. Abfragen auf GET /v2/forecast/{site_id} bzw. GET /v2/historical/{site_id} umstellen.
4. Im Code die neuen Feldnamen und lokalen Zeitstempel berücksichtigen.
5. required_data durch passende include-Gruppen ersetzen.

Die vollständige Endpunkt- und Feldreferenz finden Sie in der API-Referenz.

Migration von Integrationen

Wenn Sie eine Integration wie Solectrus, EVCC oder ioBroker verwenden, müssen Sie auf ein Update der jeweiligen Integration warten, bevor Sie auf die V2 wechseln können. Wir werden den Fortschritt der Entwicklung hier hinterlegen.