76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Gibt es einen Weg, die Stunden-Startwerte über den Neustart hinweg zu erhalten, etwa durch Persistenz im Cache?

Das wird bereits getan. Die Grundlage verschiedenster Berechnungen ist die pvHistory (get ... pvHistory ...).
So wird z.B. der Startwert der Batterie In/Outs in batintotalXX bzw. batouttotalXX gespeichert:

Code Auswählen Erweitern

            batintotal01: 9116571.19359986, batintotal02: -, batintotal03: -
            batouttotal01: 9061517.26325829, batouttotal02: -, batouttotal03: -

Somit ergeben sich Differenzberechnungen mit aktuellen Lieferwerten der Devices. Daraus entstehen z.B. die relevanten Stundenreadings.
Die pvHistory selbst  (wie andere auch) wird regelmäßig ca. alle 15 Minuten in das Filesystem persistiert. Zusätzlich werden alle flüchtigen u. relevanten Caches bei einem regulären Shutdown in das Filesystem weggeschrieben und beim Start wieder geladen. Insofern sollte es kein logisches Problem geben.

Wenn du das Problem reproduzieren kannst, wäre ein Restart mit gesetzten ctrlDebug=collectData, sowie einem Auszug von "get ... pvHistory" der aktuellen und letzten Stunde sinnvoll um etwas mehr zu sehen.

[50watt]

OpenMeteoDWDEnsemble-API: HTTP 500 seit 12.10.2026 – Global EPS betroffen

seit dem 12.10.2026 erhalte ich bei meinem SolarForecast-Device PVForecast regelmäßig:

PVForecast - ERROR - Open-Meteo API server response: Something went wrong.

Ich verwende SolarForecast 2.10.8:

76_SolarForecast.pm:v2.10.8-s31766/2026-10-11

Strahlungs- und Wetterquelle sind beide auf OpenMeteoDWDEnsemble-API eingestellt.

Die durchgehenden Fehler sind in meinem Log spätestens ab 12.10., 17:42 Uhr sichtbar, bereits vor dem FHEM-Update und Neustart am Abend. Mit ctrlDebug apiCall zeigt sich HTTP 500 vom Ensemble-Endpunkt. Das Abfragelimit ist nicht ausgeschöpft.

Ich habe die Abfragen anschließend unabhängig von FHEM mit Python getestet:

* icon_seamless_eps und dwd_icon_seamless_eps: jeweils HTTP 500.
* Sowohl die vollständige Modulabfrage als auch eine Minimalabfrage nur mit temperature_2m scheitern.
* Eine Verkürzung auf 48 Stunden bzw. einen Prognosetag hilft nicht.
* Der Fehler tritt für Wien und Berlin auf.
* Auch elevation=nan ändert nichts.

Der Vergleich der Teilmodelle für Wien ergibt:

dwd_icon_global_eps: HTTP 500
dwd_icon_eu_eps:    HTTP 200, 24 Stunden, 960 nichtleere Temperaturwerte
dwd_icon_d2_eps:    HTTP 200, 24 Stunden, 480 nichtleere Temperaturwerte

Die deterministische DWD-Abfrage mit models=icon_seamless funktioniert ebenfalls und liefert die acht vom Modul angefragten Wetter- und Strahlungsfelder.

Eine minimale Reproduktion mit der öffentlichen Berlin-Beispielkoordinate:

curl --silent --show-error --max-time 30 --include \
'https://ensemble-api.open-meteo.com/v1/ensemble?models=dwd_icon_global_eps&latitude=52.52&longitude=13.41&hourly=temperature_2m&forecast_days=1';

Am 13.10.2026 um 05:11 UTC kam darauf HTTP 500 mit:

{"error":true,"reason":"Something went wrong."}

Beim DWD wurde zum 6. Oktober eine Gitteränderung für ICON-EPS angekündigt. Open-Meteo dokumentiert die Umstellung auf native Ensemble-Gitter und erklärt, dass die bisherigen Modellnamen weiter verwendet werden können. Ob das mit dem Fehler zusammenhängt, ist bislang nur eine Vermutung.

DWD-Ankündigung:
https://www.dwd.de/DE/leistungen/opendata/neuigkeiten/opendata_juli2026_2.html

Open-Meteo-Dokumentation:
https://open-meteo.com/en/docs/ensemble-api

Ist das Problem bereits bekannt oder bei euch ebenfalls reproduzierbar? Die Tests sprechen für einen Fehler im globalen Ensemble-Zweig bei Open-Meteo, nicht für einen ausschließlich in FHEM auftretenden Fehler.

Zusätzlich fällt auf: PVForecast zeigt weiterhin state=updated und Prognosewerte an, obwohl die API-Abrufe scheitern. Gibt es bereits eine Möglichkeit, das Alter der letzten erfolgreich bezogenen Prognosedaten sichtbar zu machen?

Viele Grüße
50watt

[DS_Starter]

Moin,

Ist das Problem bereits bekannt oder bei euch ebenfalls reproduzierbar?

Der neuerliche Fehler der API ist noch nicht aufgefallen, ist ja ganz frisch.  Aber ich kann die Meldung bestätigen.
Mit der v2.10.5 vom 28.09. hatte ich schonmal die Ensemble API anpassen müssen, die bis dato ihren Dienst getan hat.
Ich schaue mir das im Laufe des Tages an was nun wieder angepasst werden muß.
Ggf. wechsle temporär auf OpenMeteoDWD-API.

Zusätzlich fällt auf: PVForecast zeigt weiterhin state=updated und Prognosewerte an, obwohl die API-Abrufe scheitern.

Das ist richtig so und gewünscht. Das funktioniert solange sich vorausgegangene Abrufdaten im Speicher befinden. Sonst wäre bei jedem kleinen API Aussetzer keine Prognose vorhanden.
Die gespeicherten Daten schmelzen aber langsam ab wenn die Abrufe der API scheitern. Dann gibt es auch keine Prognose mehr.

Gibt es bereits eine Möglichkeit, das Alter der letzten erfolgreich bezogenen Prognosedaten sichtbar zu machen?

Für Wetterdaten gibt es das bereits mit dem Signalpunkt rechts neben Sonnenuntergangssymbol. Für die Strahlungsdaten gibt es jetzt nur den aktuellen Status im Signalpunkt der API. Dort könnte ich den letzten erfolgreichen Aufruf im Hoover-Text mit hinterlegen wenn das gewünscht ist.

LG,
Heiko

[DS_Starter]

Jetzt wollte ich mich gerade auf die Suche nach dem API-Fehler der ensemble-api.open-meteo.com machen und habe bemerkt, dass diese API wieder problemlos läuft.
Kannst du / könnt ihr es bestätigen?