Dann melde ich mich auch nochmal zu dem Thema „unusually High Production“
Ich bekomme auch immer noch laufend die Meldung.
Hier jetzt nochmal alle Sensoren und Einträge geprüft wie du vorgeschlagen hast. Funde aber keinen Fehler. Habe nur die eine Gruppe. Und eben die 48,7kw aufm Dach
Die Sensoren und Konfiguration habe ich, wie schon in den anderen Posts erwähnt, überprüft. Diese sind alle korrekt und die Werte plausibel. Die Werte, die von der SFML Integration für den Sensor sensor.solar_forecast_ml_power_sensor_state und für den Sensor sensor.solar_forecast_ml_yield_sensor_state angezeigt werden, sind auch korrekt und plausibel. Das zeigt ja auch, dass die Integration die richtigen Werte erhält.
Zu 1: Die kWp-Konfiguration ist richtig konfiguriert:
Zu 2: Der Energiesensor ist definitiv richtig konfiguriert (siehe Bilder oben). Es gibt auch nur eine Gruppe, somit ist dies die Gesamtproduktion.
Zu 3: Die Sensoreinheit ist auch richtig:
Zu 4 und 5: Nein, auch die Werte sind korrekt. Wie bereits erwähnt tritt das Problem jeden Tag auf, sobald die stündliche Produktion über ca. 10 kWh liegt. Die Vorhersage von SFML sagt selbst für entsprechende Stunden Werte größer als 10 kWh voraus. Trotzdem erhalte ich dann die Meldung, dass die Produktion zu hoch war. Ich bin mir sicher, dass es irgendwo einen Fehler im Code geben muss.
Hier auch nochmal der Sensor für die Leistung:
Die Genauigkeit der Vorhersage und die Abweichung zwischen Prognose und tatsächlicher Produktion wird falsch berechnet.
Vorhersage: 92,3 kWh
tatsächliche Produktion: 105,69 kWh
SFML berechnet eine Genauigkeit von 99% und eine absolute Abweichung von 1,02 kWh → falsch:
Hab heute in meinem Log festgestellt, das ich neuerdings stündlich folgende Meldung habe:
Hat das was mit OpenMeteo z tun, oder ist da was anderes defekt?
2026-04-10 13:25:35 - custom_components.solar_forecast_ml.coordinator - DEBUG - Hourly predictions cache refreshed: 24 today, 24 tomorrow, 24 day_after
2026-04-10 13:25:35 - custom_components.solar_forecast_ml.coordinator - DEBUG - Finished fetching solar_forecast_ml data in 1.757 seconds (success: True)
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.forecast.forecast_weather - DEBUG - Background forecast update starting...
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.forecast.forecast_weather - INFO - Force update - fetching from Open-Meteo API...
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, returning None from fetchone
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
2026-04-10 13:50:33 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Database is closed, skipping execute
Hat die letzten Tage gelegentlich keine Daten zur Verfügung gestellt. War auch in meiner Integration nicht erreichbar.
Database ist closed.
Einfach mal einen roten Neustart machen.
Wenn es dann sofort wieder kommt, gibt es ein Problem.
Beachte: gelbe Neustarts sorgen dafür das die Datenbank ggf. blockiert wird. Lieber einen roten machen, damit SFML kein Problem wirft.
Absoult richtig! Wobei zu beachten ist, dass OpenM nur der Place-Holder ist. In Wirklichkeit werden ECMWF, ICON und co geladen. In den Europäischen Rohdaten gibt es aktuell “vermutlich” API-Probleme.
Ich suche schon nach einer stabilieren Alternative.. Nicht Vergessen: SFML nutz keine “Fertigen” Wetterdaten, sondern Rohdaten und berechnet diese dann selbst für den jeweiligen lokalen Standort und legt sie dann in der DB " fertig" ab und korrigiert die Berechnungslogik in Abstimmung mit der Wetter-KI mittels Gewichtungsverteilung.