Ist das hier ggf das Problem bei dir?
Ich habe trotz intensiver Suche nichts finden können.
Ist das ggf auch das Problem bei Dir gewesen?
DB-Code-Script getestet, Selbstkorrektur durch Hubble funktioinert.
Für alle die Code lesen / verstehen können, hier der Intepreter-Lauf und Ausgabe:
>>> import database_cleaner
>>> db = database_cleaner.connect(target="production_physics_db")
>>> # 1. Execute panel group row repairs and remove telemetry anomalies
>>> repair_summary = db.repair_panel_groups()
>>> print(f"Panel group rows repaired: {repair_summary['repaired']}")
Panel group rows repaired: 300
>>> purge_summary = db.purge_contaminated_physics_history()
>>> print(f"Contaminated physics history removed: {purge_summary['removed']}")
Contaminated physics history removed: 554
>>> # 2. Flush physics calibration cascade tables
>>> db.tables.physics_calibration_groups.purge()
physics_calibration_groups removed: 1
>>> db.tables.physics_calibration_hourly.purge()
physics_calibration_hourly removed: 16
>>> db.tables.physics_calibration_buckets.purge()
physics_calibration_buckets removed: 9
>>> db.tables.physics_calibration_bucket_hourly.purge()
physics_calibration_bucket_hourly removed: 99
>>> # 3. Audit operational exclusion logs (Snapshot: PRE-PURGE)
>>> db.get_exclusion_status(snapshot="pre_purge")
Pre-purge open exclusions:
full_battery_zero_export: 245
demand_limited_zero_export: 33
missing_reason_code: 21
suspected_battery_curtailment: 1
>>> # 4. State validation and recalculation (Snapshot: POST-PURGE)
>>> db.recalculate_exclusions()
>>> db.get_exclusion_status(snapshot="post_purge")
Post-purge active state:
open_parent_exclusions_group_level: 0
contaminated_physics_history_count: 0
>>> # 5. Low-level structural database integrity verification
>>> db.execute_raw("PRAGMA integrity_check;")
PRAGMA integrity_check: ok
>>> print("--- DATABASE AUDIT COMPLETED SUCCESSFULLY ---")
--- DATABASE AUDIT COMPLETED SUCCESSFULLY ---
Ihr müsst euch also um nichts kümmern, der Code wird das beim kommenden Update bei jedem selbstständig erledigen und einen FLAG setzen, damit es nicht bei jedem Neustart erneut ausgeführt wird. Beim darauffolgenden EOD wird dann neu “gelernt”
@thomasz : Einwände 
wird auch auf Docker-Installationen funktionieren.
Warum auch nicht 
. Am Ende läuft HA-Core mit seinen Integrationen ja ebenfalls als Docker Container auf einem Buildroot-Linux, überwacht von Supervisor. Cool, dass du den Fehler durch DB-Analyse gefunden hast! Da bei mir die Prognosen aktuell sehr gut sind, vermute ich, dass ich nur wenige Sesorfehler hatte. Schaun mer mal …
Ich weiß nicht ob das ein Fehler ist:
Am Mittwoch DB gelöscht und komplett neugestartet. Seitdem EOD dauer jedes mal 0 Sekunden oder einmal 1 Sekunde. Samples bleiben bei 0.
Samples müssen erst gesammelt werden. Bei 50 geht es los.
Ca. 5 Tage.
Ach jo vorher zeigt er die ganze Zeit ja 0 an. Vergessen
Nein. Kein PI und kein Dongle.
Zur Kenntnis 
Servus Tom,
Wann kommts online? Aktuell zeigt Hacs nur 32.0.0 an.
Liebe Grüße
Mike
steht am Ende des Beitrags
Ahh. Danke. Das hatte ich dann falsch verstanden. Kam bei mir so an, konnte es nicht testen, aber lass es trotzdem mal raus. Mein Fehler.
Gruß
Könnte doch wieder als Beta kommen wie letztens, das würde ich gut finden.
Das macht mikey0000 von Mammotion-HA auch so mit den Betas
@Tom-HA Moin, mir ist gerade eine Merkwürdigkeit in der Version 32.0.0 aufgefallen. Es ist nun gerade 11:21 Uhr, die 11. Stunde ist vollendet, die Berechnung der actuals sollte abgeschlossen sein für diese Stunde. Aber da gibt es einen Versatz um eine Stunde, als würde der Prozess noch in CET leben:
2026-06-29 11:05:00 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG - Panel group actuals updated for 2026-06-29_10: 3 groups (stored=3/3)
group actuals updated for 2026-06-29_10 heißt für mich, dass er die 10. aber nicht die 11. Stunde bearbeitet und gespeichert hat. Das passt auch zum Datenbankinhalt:
sqlite> select prediction_id, group_name, ai_kwh, actual_kwh from prediction_panel_groups where prediction_id like '2026-06-29%' order by group_name,prediction_id limit 60;
2026-06-29_04|Gruppe 1||0.0
2026-06-29_05|Gruppe 1|0.1397|0.0052
2026-06-29_06|Gruppe 1|0.0952|0.0088
2026-06-29_07|Gruppe 1|0.2142|0.0474
2026-06-29_08|Gruppe 1|0.3332|0.2804
2026-06-29_09|Gruppe 1|0.8218|1.0549
2026-06-29_10|Gruppe 1|1.5017|0.8558
2026-06-29_11|Gruppe 1|3.04|
2026-06-29_12|Gruppe 1|4.5057|
...
Und zur Darstellung:
Ich habe danach mal in meinem ältesten Logfile gesucht und gefunden:
2026-04-21 05:05:00 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG - Panel group actuals updated for 2026-04-21_04: 3 groups
Das war anscheinend schon immer so. Ich halte das für einen Fehler, anders kann ich mir das nicht erklären. Habe ich Recht?
Hallo @thomasz
Nein, Du hast nicht recht (diesmal) - oder ich habe dich missverstanden! → Der Log ist auf die abgeschlossene Vorstunde bezogen.
Um 11:05 wird die Stunde 10:00-10:59 als 2026-06-29_10 geschrieben. Die laufende Stunde 11 ist um 11:21 noch nicht abgeschlossen und wird erst nach 12:00, regulär um ca. 12:05, aktualisiert.
Ah, it’s not a bug but a feature! 
Dann ist es schlicht Konvention im Programm und so beabsichtigt. Aus meiner Sicht gehört alles >10 und <=11 in die 11. Stunde des Tages. Deshalb ist die weit (auch bei mir) verbreitete Art, z. B. “Viertel vor Elf” zu sagen, eigentlich falsch. In allerlei Gegenden in Deutschland sagt man dazu “dreiviertel Elf”, was korrekterweise (aus meiner Sicht) sagt, “3/4 der elften Stunde sind vergangen”.
Die Konvention von SFML sagt tatsächlich, dass der Ertrag der 11. Stunde im Datensatz mit der Kennung 10 gespeichert wird. Erinnert mich an die “Jahrtausendwende”, als (fast) alle meinten, dass mit dem 01.01.2000 ein neues Jahrtausend beginnt. Tatsächlich war das aber der 1. Tag des 1. Monats des 2000. Jahres …
Anyway, da ich’s nun weiß, kann ich die Zahlen ja im Kopf transponieren .
das geht nicht… deiner Logik folgend wäre es keine abgeschlossene Stunde sondern die aktuelle und die Berechnungen können ja nur retrospektiv durchgeführt werden, also wenn die Stunde angeschlossen ist. .. Schau mal in den Beta-Thread da haben wir das im Januar schon einmal sehr genau und im Detail durchdiskutiert und im Kopf musst Du da auch nichts transportieren, es ist die Logik der Sache, dass eine Berechnung auf Stundenbasis nur in der retrospektive erfolgen kann.. ebenso die Bewertung bedingt eine Vergangenheit, da es sich im kWh handelt muss die Stunde abgeschlossen sein.-> oder reden wir hier von zwei unterschiedlichen Dingen?
Nein, wir sprechen schon über die selbe Sache :). Ich schaue auf die Stunden eines Tages nur nicht wie auf ein Array in “C”. Für mich hat ein Tag 24 h, und wenn ich die Energieproduktion der 11. Stunde sehen möchte, würde ich unter 11 suchen, und nicht unter 10 wie in SFML, weil für mich die Stunden von 1-24 durchnummeriert werden, und nicht von 0-23 :). Ob es dafür eine DIN-Norm gibt, weiß ich schlicht nicht . Als Mensch zähle ich beginnend bei 1. Wenn ich Äpfel zähle, beginne ich bei 1, nicht bei 0. Vielleicht macht das meine Sichtweise deutlich.
Wenn ich mir die Attribute des Sensors “prognose_heute” anschaue, sehe ich dass die Stundenwerte wie ein Array von Dictionaries beginnend bei 00:00 gelistet werden, was insofern mit der Anzeige konsistent ist:
Ich hätte es so gemacht und habe es so auch erwartet:
hours:
1: 0
2: 0.234
3: 0.678
...
24: 0
Du siehst schon, das Beispiel wäre eine Prognose für irgendwo knapp südlich des Polarkreises im Sommer auf der Nordhalbkugel .
Aufgefallen ist mir meine bisherige Fehlinterpretation aber erst heute. Ist schon witzig, was man alles nicht wahrnimmt, wenn es von einer Erwartungshaltung maskiert wird …
Wenn ich auf die SFML page schaue, sehe ich z. B. das:
Unten ist die 10 markiert, im popup steht 10:00 Uhr als headline, aber der kumulierte Ist-Wert für das Ergebnis ist der der Stunde 11, die erst ab 11:00 beendet ist. Den habe ich heute Vormittag kurz nach 11 gesucht und nicht gefunden . Jetzt weiß ich, wo ich suchen muss …
Ich hoffe, es ist nun verständlich, wo meine Verwirrung her rührte, und warum ich das für einen Fehler gehalten habe …
Nochmal zum Thema “suspected_battery_curtailment”
Bei mir werden jetzt diese beiden Stunden immer in die Quarantäne geschoben!
Da ich hier eine Verschattung habe und keine Abregelung durch Batterie oder MPPT
Wird das noch gelernt oder sind die Daten vergiftet? bzw. kommt er nicht mehr runter von der “Meinung”?
Curtailment learning quarantine 2026-06-27 H15: actual=0.211 kWh, theoretical=0.424 kWh, reason=suspected_battery_curtailment
Curtailment learning quarantine 2026-06-27 H16: actual=0.101 kWh, theoretical=0.268 kWh, reason=suspected_battery_curtailment
@thomasz
Alles gut… einfach immer merken: Bewertungen können nur retrospektiv und da wir über Energie sprechen zur vollen Stunde angestellt werden. Das ist vermutlich die einfachste Erklärung