Sorry, eben erst gelesen. Klappt es bei Dir oder soll ich Dir meinen Code schicken?
Kein Problem.
Ja, jetzt funktioniert es mit dem Sensor, aber natürlich noch nicht weiter.
Wir müssen da beide auf Tom warten.
Du bist ja bestimmt auch noch nicht weitergekommen.
Nochmal wegen dem max Peak Today das er ja nicht zurückgesetzt wird.
Ich hab ja meine DB vorgestern gelöscht und neu angefangen. Bei mir wurde er jetzt zurückgesetzt, vorher auch nicht
WICHTIGER BUG entdeckt !
Hallo zusammen,
durch die Analyse einer DB ist ein schwerer Fehler im Code aufgetaucht, der auf dem ersten Moment nicht ersichtlich gewesen ist. Ich möchte diesen Fehler kurz beschreiben und was die Maßnahmen dagegen sein werden - sobald ich wieder " aktiv sein kann".
Woran erkennt man den Fehler - ob man betroffen ist:
Latente deutliche Unterprognosen
Wie wird er ausgelöst:
SFML arbeitet auf mehren Schichten mit den Daten der Anlage 4 von 5 laufen 100% korrekt und sauber. Aber die physikalische Schicht in der AI hat einen Fehler auf der Gruppen-Ebene. Wird Mppt-Throtteling, Notereigniss ausgelöst, werden die Stunden korrekt vom AI-Lernen ausgeschlossen. ABER die physikalische Schicht behält ihn ignoriert das Ausschließen.
Kausal-Kette:
Im Laufe der Zeit sammeln sich immer mehr und größere Differenzen zwischen korrektem AI Layer und falschen Physic-Layer an. Die Ki steuert gegen und wird immer konservativer und schlimmer noch der Physik-Layer drosselt die rechnerische Leistung der einzelnen Gruppen. Das läuft mit der Zeit gegen Null! In der geprüften DB wurde die Leistung des Solarzellen-Gruppen auf mittlerweile 70% (Physik-Layer) gedrosselt obwohl die KI korrekt von einer Leistung von 115% ausgeht. - Ohne Korrektur-Eingriff würde Physik-Layer irgendwann gegen 0% laufen.
Auswirkungen:
Da die Layer geblendet werden, zieht ein Layer der 45% von der tatsächlichen Produktion abweicht die Prognose Anteilig herunter. - So kommt es zu den Unterprognosen.
Lösung:
Ich werde das im Code korrigieren und eine automatische Datenbank Bereinigung in das nächste Update einbauen, sowie eine korrekte Kalibrierung der Panelgruppen erzwingen.
Könnt ihr etwas machen?
Nein!
Danke @Johnny_1993 für deine Unterstützung bei der Klärung!
7 „Gefällt mir“
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?
Beei mir läuft alles wieder cremig. Ein Stick hatte sich, warum auch immer, von LAN nach USB umgeschaltet. ZIGBEE konnte das Teil dann natürlich nicht mehr finden.
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.
4 „Gefällt mir“
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 …
1 „Gefällt mir“
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.
1 „Gefällt mir“
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
1 „Gefällt mir“
@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 .
1 „Gefällt mir“