Du hast recht! Das ist im kommenden Update gelöst 
→ das ist genau der Fix
Hallo @Tom-HA , Nachtrag zu meinem Bericht vom 31.08.: Unter V46.0.0 ist der Promotionsfehler unverändert, und die EOD-Migration hat die fehlende Tabelle nicht angelegt.
Installiert V46.0.0, Neustart 03.09. um 01:33, erster EOD danach um 23:30 durchgelaufen. Keine manuellen DB-Eingriffe.
Der Fehler tritt jetzt in zwei Pfaden auf
Beim Start (Retry des aufgezeichneten GO):
01:33:06 ERROR Failed to resume model candidate gate after startup
File "<frozen production_scheduled_tasks>", line 310, in resume_pending_model_candidate_gate
File "<frozen production_scheduled_tasks>", line 335, in _promote_model_candidate_once
File "<frozen ai_predictor>", line 1810, in promote_model_candidate
File "<frozen db_manager>", line 9208, in promote_model_candidate
sqlite3.OperationalError: no such table:
main.ai_model_candidate_dispositions_legacy_v20260804
Im EOD als regärer Schritt:
23:30:16 End-of-day workflow partial (13/16):
… AI model: verified model candidate promotion failed for c17b1935-…:
no such table: main.ai_model_candidate_dispositions_legacy_v20260804 …
Die Zeilennummern haben sich gegenüber V44.2.2 verschoben (9208 statt 7907, 1810 statt 1712) — es läuft also der neue Code, der Fehler ist wörtlich derselbe.
Zur Migration
Ich hatte gehofft, die einmalige Migration beim ersten EOD nach dem Update würde die Tabelle miterzeugen. Sie tut es nicht. Auf dieser Installation ist bekanntlich seit dem 13.07. überhaupt keine Migration mehr im Ledger angekommen — migration_applied steht unverändert auf fünf Einträgen mit ai_v300 als jüngstem, während alle neuen Tabellen per CREATE TABLE IF NOT EXISTS außerhalb des Ledgers entstanden sind. Der Promotionspfad referenziert dagegen einen Namen mit _legacy_v20260804, also offenbar aus genau so einem Migrationsschritt.
Das dürfte über meine Installation hinausgehen: Jede Installation, deren Ledger seit Juli steht, wird beim ersten GO an derselben Stelle hängen. Meine ist vermutlich nur die erste, die so weit gekommen ist.
Stand des Kandidaten
Das GO für c17b1935 vom 30.08. (361 Samples, R² 0,888, sieben gültige Tage) ist weiterhin persistiert, aber seit fünf Tagen nicht promotet. Der Retry-Mechanismus funktioniert wie von dir beschrieben und greift bei jedem Start — er läuft nur jedes Mal in dieselbe fehlende Tabelle. Ich lege sie ausdrücklich nicht von Hand an.
Nebenbefund, vermutlich erwartetes V46-Verhalten
Weather Expert Learning: immutable per-provider cloud forecast provenance
is not available; static expert weights remain active
Lese ich als das angekündigte Fail-Closed bis zum Vorliegen von Snapshots. Falls das anders gemeint ist, sag Bescheid.
Installation bleibt unangetastet. Wenn du das Schema der Legacy-Tabelle oder eine bestimmte Abfrage brauchst, liefere ich sofort.
Fehlermeldung nach EOD
Dieser Fehler stammt von einer benutzerdefinierten Integration
Logger: custom_components.solar_forecast_ml.production.production_scheduled_tasks
Quelle: runner.py:289
Integration: Solar Forecast ML (Dokumentation, Probleme)
Erstmals aufgetreten: 23:30:00 (2 Vorkommnisse)
Zuletzt protokolliert: 23:37:45
Weather MLP training failed [weather_mlp_precision_pipeline_invariant]: Weather MLP pipeline invariant failed: 743 measured W/m² observations produced no weather precision samples
End-of-day workflow partial (14/16): Weather MLP: Weather MLP pipeline invariant failed: 743 measured W/m² observations produced no weather precision samples; Weather Expert Learning: immutable per-provider cloud forecast provenance is not available; static expert weights remain active
Hey
deine KI liegt leider etwas daneben, was aber auch nicht verwunderlich ist.
Weather Expert Learning: immutable per-provider cloud forecast provenance
is not available; static expert weights remain active
Das ist völlig korrekt! und kein " Nebenbefund" auch macht der EOD keine Migration.
Korrekt, wenn der Kandidat nicht besser ist für die aktuelle Lage und auch vor dem Hintergrund was ich als Breaking-Change beschrieben habe.. ist das alles grün!
Das ist nicht korrekt! Sie liegt falsch beim Ledger! Es hängt nicht am Ledger, sondern daran, ob beim ersten Start der neuen Version eine ai_model_candidate_dispositions mit altem CHECK-Constraint vorlag. Nur dann feuert der Rename-Zweig. Frisch aufgesetzte Installationen bekommen die Tabelle direkt mit allen vier Enum-Werten und sind daher sauber.
Fazit:
Die KI hat es nicht korrekt erkannt und liegt daneben - ABER beim Prüfen ist mir ein anderer Fehler aufgefallen, den ich dringend abstellen muss!
Der sanity-check prüft nur, dass die Tabellen existieren. Genau das ist hier ja der Fall — kaputt sind die Trigger-Bodies und das merkt er nicht. Ich muss den Test also erweitern…
Zara
Kein Fehler, sondern die benannte Breaking-Change und meine Hinweise auf " muss gelernt werden"
1 „Gefällt mir“
@Tom-HA Kurz vorweg: Unter V46.0.2 (installiert heute 04:31) ist der Fehler unverändert — gleicher Traceback, gleiche Zeilennummern, und die beiden Trigger zeigen laut sqlite_master weiterhin auf die Legacy-Tabelle. Der erweiterte Startup-Check erkennt sie noch nicht.
Danke für die Korrektur — die Ledger-Theorie war falsch, ich nehme sie zurück. Die DB zeigt es sogar direkt: migration_applied hat inzwischen acht Einträge, deine drei V46-Wettermigrationen vom 02.09. 23:30 sind sauber protokolliert. Das Ledger war nie das Problem.
Deine Diagnose mit den Trigger-Bodies ist dagegen exakt richtig. Ich habe meine Datenbank vollständig durchgesehen und kann dir die Stelle nennen:
Die Dispositions-Tabelle ist sauber
ai_model_candidate_dispositions hat den neuen CHECK mit vier Werten inkl. superseded_by_promotion, alle vier eigenen Trigger sind korrekt. Der Rename-Zweig ist bei mir also gelaufen, …_legacy_v20260804 existiert nicht mehr.
Kaputt sind zwei Trigger auf den Reconsideration-Tabellen
Beide referenzieren im WHEN-Teil die gelöschte Legacy-Tabelle:
CREATE TRIGGER ai_model_candidate_reconsiderations_insert_guard
BEFORE INSERT ON ai_model_candidate_reconsiderations
WHEN NEW.candidate_id = NEW.keeper_candidate_id OR NOT EXISTS (
SELECT 1 FROM "ai_model_candidate_dispositions_legacy_v20260804" disposition
WHERE disposition.candidate_id = NEW.candidate_id
AND disposition.disposition = 'migration_superseded'
AND disposition.replacement_candidate_id = NEW.keeper_candidate_id
)
BEGIN SELECT RAISE(ABORT, 'invalid migration candidate reconsideration'); END
CREATE TRIGGER ai_model_candidate_reconsideration_closures_insert_guard
BEFORE INSERT ON ai_model_candidate_reconsideration_closures
WHEN NEW.candidate_id = NEW.replacement_candidate_id OR NOT EXISTS (
SELECT 1
FROM ai_model_candidate_reconsiderations reconsideration
JOIN "ai_model_candidate_dispositions_legacy_v20260804" disposition
ON disposition.candidate_id = reconsideration.candidate_id
AND disposition.disposition = 'migration_superseded'
AND disposition.replacement_candidate_id = reconsideration.keeper_candidate_id
JOIN ai_model_promotion_events event
ON event.candidate_id = NEW.replacement_candidate_id
WHERE reconsideration.candidate_id = NEW.candidate_id
AND reconsideration.candidate_id != reconsideration.keeper_candidate_id
)
BEGIN SELECT RAISE(ABORT, 'invalid candidate reconsideration closure'); END
Ein Scan über die gesamte sqlite_master findet genau diese zwei Verweise auf _legacy_v20260804, sonst keine.
Warum die Promotion genau dort scheitert
Bei mir sind zwei Reconsiderations offen (812162c9 und e3101d12, beide vom 07.08. mit keeper ce397b5f). Die Promotion von c17b1935 muss sie schließen — INSERT in reconsideration_closures → der Guard feuert → JOIN auf die fehlende Tabelle → no such table → Rollback. Die Tabelle hat 0 Zeilen und kann so nie eine bekommen. Plausibel entstanden die Trigger, während die Legacy-Tabelle noch existierte, und wurden beim Aufräumen nicht mit umgeschrieben.
Zur Einordnung des GO: ac3294eb, 30.08. 23:30, 102 auswertbare Stunden, 7 Tage, reason_codes: []. ai_model_promotion_events steht auf 0.
Falls du für den erweiterten Sanity-Check eine einfache Prüfung suchst: Alle in Trigger-SQL referenzierten Tabellennamen gegen sqlite_master abgleichen würde genau diesen Fall fangen.
Offen bleibt für mich nur: Geht das aufgezeichnete GO nach dem Trigger-Fix noch durch, oder wird es wegen des Breaking Change ohnehin neu bewertet? Installation weiterhin unangetastet.
Bitte den EOD abwarten! Dann sollte es alles passen
V46.0.2 seit 4.9. 22:49, EOD um 23:30 gelaufen (12/16). Der Promotion-Fehler besteht unverändert, gleicher Traceback (db_manager:9208, ai_predictor:1810). Die Trigger-Reparatur ist auf meiner Installation im EOD nicht erfolgt. Kandidat 2253aa49 seit 22.08. nicht befördert, serving weiterhin legacy_fallback vom 29.07.
Alles geprüft mit Claude Code
Same here:
Der EOD vom 04.09. ist durch: erneut decision=GO um 23:30:03, und um 23:30:08 wieder no such table: …_legacy_v20260804. Zweites GO, zweite blockierte Promotion, unter V46.0.2 mit identischen Zeilennummern. Es löst sich also nicht über einen EOD-Lauf. Ich habe die Ursache in meiner DB lokalisiert, siehe oben.
- System: Proxmox
- HA-Version: 2026.7.4
- Modul / Integration: Solar Forecast ML Vers. 46.0.2
Dieser Fehler stammt von einer benutzerdefinierten Integration
Logger: custom_components.solar_forecast_ml.production.production_scheduled_tasks
Quelle: runner.py:289
Integration: Solar Forecast ML (Dokumentation, Probleme)
Erstmals aufgetreten: 4. September 2026 um 23:30:01 (2 Vorkommnisse)
Zuletzt protokolliert: 4. September 2026 um 23:30:14
Weather MLP training failed [weather_mlp_precision_pipeline_invariant]: Weather MLP pipeline invariant failed: 744 measured W/m² observations produced no weather precision samples
End-of-day workflow partial (14/16): Weather MLP: Weather MLP pipeline invariant failed: 744 measured W/m² observations produced no weather precision samples; Weather Expert Learning: immutable per-provider cloud forecast provenance is not available; static expert weights remain active
Hier auch, es liegen zu wenige oder keine Daten vor wie es ausschaut.
2026-09-04 23:30:02 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Weather precision calculated for 2026-09-04
2026-09-04 23:30:02 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - ERROR - Weather MLP training failed [weather_mlp_precision_pipeline_invariant]: Weather MLP pipeline invariant failed: 743 measured W/m² observations produced no weather precision samples
2026-09-04 23:30:02 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Night cleanup: VACUUM disabled (DB auto-optimizes)
2026-09-04 23:30:02 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - EOD training uses already persisted actuals
Ich meine das nicht böse, nicht abwertend, nicht arrogant, auch sind mir Fehler / BUGS wirklich wichtig, ABER ich werde KEINE KI-Meldungen mehr beantworten!
Ich habe es schon so oft gesagt " Weder Claude, ChatGPT, CoPilot,.. können valide Aussagen zu vermeintlichen Fehlern / BUGS / … treffen. Das hängt damit zusammen, dass die entscheidenden Stellen im Code verschlüsselt sind, damit die amerikanischen Tec-Unternehmen nicht meine Ideen, Arbeit klauen.
Ich habe mehrfach darum gebeten meinen Code NICHT durch eine KI zu jagen. Besonders vor dem Hintergrund das 7/10 Usern nicht die verstehen wie eine KI funktioniert, das sie z.B. immer eine Antwort gibt - egal ob sie Sinn macht oder nicht. Sorry…
Wenn ein Fehler vermutet wird, dann bitte das LOG nutzen, Screenshot oder Beschreibung. Das ist die einzige Option wirklich eine ehrliche und klare Antwort zu bekommen! - Danke für das Verständnis.
3 „Gefällt mir“
Hallo @suedschwede // @Flori
das hatte ich bereits beantwortet: Das ist genau die Breaking Change und kein Fehler. Es wird in eine Shaddow-Table weitergelernt und wenn genügend Daten (Wetter) korrekt identifiziert sind automatisch gewechselt. Bitte dazu die Update-Informationen lesen.
ABER: ich habe bereits im kommenden Update einen Diagnose-Sensor eingebaut und das LOG angepasst so das es klarer ist.
2 „Gefällt mir“
Ich lasse Claude das Log lesen, weil ich selbst darauf keinen Bock habe. Du kannst mich gerne ignorieren, wenn du willst.
Die ehrliche Antwort hast du aber bekommen: Es kommt weiterhin der Fehler, dass die Tabelle fehlt:
Zuletzt protokolliert: 4. September 2026 um 23:30:40
AI model training failed: verified model candidate promotion failed for 2253aa49-2ddf-466e-be47-a19e2366d67d: no such table: main.ai_model_candidate_dispositions_legacy_v20260804
Es hat nichts mit Ignorieren zu tun, sondern das ist eine technische Antwort und eine Frage des gegenseitigen Respekts!
Weder Claude noch irgendeine andere KI kann dir in 9 von 10 Fällen wirklich helfen oder eine Antwort geben. Eine KI wird IMMER etwas antworten, egal wie dumm das ist. Das ist der Punkt – und sonst nichts. Ich habe das auch schon mehrfach erklärt.
Leider tauchen in Foren immer mehr Beiträge auf, bei denen klar erkennbar ist, dass sie in Wirklichkeit von einer KI stammen.
Der Entwickler oder Fragesteller weiß oft selbst nicht, was die KI da schreibt oder wie der eigene Code funktioniert.
Manches Mal ist das geradezu lachhaft (du oder andere hier sind damit ausdrücklich nicht gemeint):
Nutzer kopieren den Output einer KI als vermeintlichen Fehler, als Frage oder als Antwort stumpf in einen Thread. Der Threadersteller nimmt den Krempel, wirft ihn in seine eigene KI und kopiert den nächsten Output zurück. Aus gutem Grund werden solche Nutzer im offiziellen Home Assistant Forum inzwischen abgemahnt und gebannt, das ist mittlerweile in fast allen technischen Foren der Fall. Andere Foren sperren KI`s komplett aus, damit sie nicht das Forum indizieren oder “vermeintliche Entwickler” den Link in eine KI kopieren frei nach dem Motto " Hey Mustererkennungsmaschine verfasse eine Antwort auf den Beitrag xyz".
Ein Forum ist für Menschen:
für echten Austausch, Gedanken, Hilfestellung, gemeinsame Hobbys, Aha-Momente und Freude an Erfahrungen. Kein AI-Slop und kein Copy/Paste. Das zerstört über kurz oder lang jedes Forum. Es ist die Entmenschlichung von Gesprächen und erinnert eher an einen Call-Center-Bot.
Davon distanziere ich mich in aller Deutlichkeit. Darum geht es.
Es macht einfach keinen Sinn, dass ich direkt oder indirekt mit einer KI schreibe, indem ich Fragen beantworte, die offensichtlich von einer KI stammen, die keinen Plan hat.
Fragen von Menschen beantworte ich sehr gerne. Ich erkläre sie, telefoniere, wenn es zu komplex wird, und biete an jedem letzten Sonntag im Monat die Möglichkeit, mir persönlich Fragen zu stellen.
Auch bemühe ich mich, komplexe technische Vorgänge so zu erklären, dass sie jeder verstehen kann.
Aber was bringt es einem Nutzer, der AI-Slop postet, wenn ich im selben Stil oder rein technisch darauf antworte? Dann kann ich gleich direkt mit einer KI diskutieren.
Würdest du es ohne KI verstehen – die den Code ohnehin nicht kennt –, wenn ich dir jetzt von Ledger und Gates erzähle? Dann ist es doch besser, KI-Schrott zu ignorieren und dir einfach zu sagen: Es ist alles okay. Das ist eine normale und gewünschte EOD-Meldung. Alles gut.
Zara
PS:
Ja mein Code hat Fehler.. große und kleine die ich übersehe (übersehen kann), dafür ist er aber ehrlich - darum geht es! Ich bin mehr als Dankbar für jeden BUG, Fehler,.. den ich reproduzieren kann. Ich sehe es nicht als Kritik, nicht als versagen, sondern als das was es ist: Etwas das ich übersehen habe und vor allem als eine Wertschätzung meiner Arbeit - da sich jemand die Mühe macht mich darauf hinzuweisen.
Ich möchte mal meinen alten Professor (vor 25 Jahren) zitieren: " Sie lernen am Besten und Meisten, wenn Sie Dinge anderen Menschen erklären müssen, so sehen Sie ebenfalls leichter logische Fehler in dem was Sie sich ausgedacht / Erarbeitet haben"
7 „Gefällt mir“
Hallo, seit den Update 46.0.2 zeigt er mir nicht mehr in stats den Ertrag an. Die Solarleistung zeigt er aber korrekt an… ich pausiere mal das lernen für heute…
Ich verstehe, dass dir andere mit KI Lösungen auf den Sack gegangen sind. Ich habe dir lediglich ehrlich mit reingeschrieben, dass mir Claude das so zusammengesucht hat.
Dein Projekt ist eine geniale Idee, aber ehrlich gesagt bin ich seit Wochen frustriert. Von Beginn an habe ich KI Drift Warnung. Dann plötzlich wilde Sprünge im Forecast, weil ein Tagessensor gesponnen hat. Hab dann anfang Juli alles weggeworfen und neu gemacht. Last AI Training steht auf vor 2 Monaten und gerade eben sehe ich in Stats, dass meine Schattendaten der letzten 2 Monate nicht mehr da sind.
Und immer wieder frag ich mich: “Was hab ich falsch konfiguriert, wo hab ich scheisse gebaut?”
Kannst du verstehen, dass ich dann angefangen habe mit Claude mein System zu analysieren? Nicht um deinen Code zu durchsuchen, sondern um zu verstehen, was ich nicht durch lesen verstehen kann?
Hallo @vsa
Das passiert, wenn IST-Werte nicht korrekt geschrieben werden! Hier gibt es mehrere Möglichkeiten.
a) Der Gruppensensor hat ein Problem - dass kann passieren wenn z.B. eine 3rd Party Integration ein Update erhalten hat und nun andere Werte / Klassen liefert.
Mach bitte mal einen Screenshot, was die einzelnen von Dir hinterlegen Sensoren pro Gruppe aktuell liefern. Wichtig: es müssen die Sensoren sein die du in die Konfiguration eingetragen hast.
@TelosNox
Das verstehe ich besser als Du vermeintlich annimmst! SFML ist keine einfache Integration, sie ist sehr komplex und eine Mischung aus innovativer AI-Technik und deren Fachbegriffe sowie der Versuch komplexe technische Vorgänge so einfach wie möglich aufzubereiten und darzustellen. Sowohl “Nerds” als auch Nutzer finden eine große Spielwiese. Das ist aber nicht immer einfach!
Um den zu begegnen, hat Basti eine Suche in den Hilfebereich eingebaut. Regelmäßig (je nach Zeit) aktualisiere ich diesen mit den häufigsten Fragen / Problemen.
Gibst Du dort in die Suche " Drift" ein bekommst Du folgende Antwort:
Genauso ist es mit den Sensoren, jeder Sensor ist dort beschrieben und was er macht. Das ist eine gute Anlaufstelle um zu schauen wo es dran liegen könnte.
Es ist extra so gemacht, dass man nach " Bereitgestellten Sensoren" und Erforderliche Sensoren und der jeweiligen Integration unterteilt dargestellt und erklärt wird.
Zusätzlich gibt es eine Suche.. gebe ich hier “Drift” ein kommt:
Aber auch hier gilt: Es kann Fehler enthalten, Dinge fehlen.. ich bin aber sehr bemüht es immer wieder aktuell zu halten. → es ist eine Zeitfrage und aktuell ist das Thema WP, AI, Wetter AI,.. Prio Nr 1
Kurzum zu deiner Frage:
Drift-Warning ist ein gutes Zeichen! - Die KI erkennt das sie nicht richtig lag und lernt.
Auch der aktuelle Stand ist dort immer aufgeführt…
Das Gate-Thema ist dort auch angesprochen..
