Moin zusammen,
ich habe im Juni komischerweise extreme werte gehabt.
kann ich die irgendwie noch an anderer Stelle korrigieren?
Es war ein kurzzeitiger Lock der Datenbank oder ein anderer HA Prozess der kurz blockiert hat. Bitte weiter beobachten!
Würde mich interessieren, was es bedeutet…
Dieser Fehler stammt von einer benutzerdefinierten Integration
Logger: custom_components.solar_forecast_ml.ai.ai_predictor
Quelle: runner.py:290
Integration: Solar Forecast ML (Dokumentation, Probleme)
Erstmals aufgetreten: 20. August 2026 um 23:30:10 (1 Vorkommnis)
Zuletzt protokolliert: 20. August 2026 um 23:30:10
Panel-group training diagnostics: health=CRITICAL, samples=966, real_targets=707 (73.2%), direct_real_targets=707, residual_completed_targets=0, current_mixed_fallback=0, current_capacity_fallback=259, current_fallback_ratio=26.8%, legacy_topology_fallback=0, legacy_partial_fallback=0, legacy_fallback_ratio=0.0%, sum_mismatch_hours=0, partial_sum_exceeds_total_hours=0, range_rejections=0, topology_rejections=271, legacy_unknown_topology_rejections=0, invalid_value_rejections=0, training_range=2026-06-22..2026-08-20, current_fallback_range=2026-06-22..2026-07-07, legacy_fallback_range=none, affected_range=2026-06-22..2026-07-07
Kurze Erklärung:
Die Tagesprognose läuft. Das neue Neutrale-Netz darf die Anfangswochen nicht voll als „so produzieren die Gruppen wirklich“ lernen.
Sobald dieses Fenster aus der Trainingsgeschichte rausrutscht (oder die Schwelle unterschritten wird), sollte health wieder OK/WARN sein.
Das ist also Label-Rauschen im linken Rand der Zeitreihe, kein Live-Sensor-Ausfall.
22.06.–07.07. — nur die ersten ~16 Tage. Ab 08.07. sind die Labels echt. CRITICAL kommt daher, dass der Fallback-Anteil über der Schwelle liegt (hier 26,8 %), nicht weil der 20.08. kaputt wäre.
Handlungsbedarf nur, wenn aktuelle Tage in affected_range wandern — hier tun sie das nicht.
Kein BUG, kein FEHLER nur eine Info
Rückmeldung zu V44.2.2: Der Stillstand ist weg und 7/7 ist erreicht.
Seit dem Wechsel läuft die Evidenzsammlung wieder sauber durch — auch die beiden Tage, die vorher hängengeblieben waren, sind nachgekommen:
eligible_independent_days: 7 / 7
post_midnight_runs: 9
pre_sunrise_runs: 10
candidate: ce397b5f (R² 0,815, 163 Samples)
bootstrap_active: true
Zur Erinnerung: Vor der Version stand der Zähler zwei Tage bei 6/7 fest, inklusive eingefrorener eligible_common_hours=50 über vier Messpunkte. Das ist vollständig behoben, seitdem zählt jeder Tag.
Die waiting_message hat einen zweiten Satz:
Waiting for eligible paired shadow evidence: 7/7 independent days;
no promotion before evaluation.
Waiting for adequately powered critical weather regimes.
Inhaltlich leuchtet mir das sofort ein — ein Modell nur an klaren Sommertagen zu validieren wäre wenig wert. Nach dem EOD heute Nacht steht der Satz unverändert da, es löst sich also nicht durch weitere Tage derselben Art.
Drei Fragen dazu, falls du kurz Zeit hast:
eligible_weather_regimes: 2/4 im selben Attributblock wäre vermutlich überschaubarer Aufwand. Es ist strukturell dieselbe Lücke wie vorher bei den Tagen: Es gibt einen Zähler für das eine Kriterium, aber keinen für das andere. Und wer nicht in die Datenbank schaut, kann nicht unterscheiden, ob das System wartet oder hängt.Ich bin jetzt nicht sicher, ob ich hier richtig bin:
Der EAI Wettersensor gibt mir die Meldung: „Hohe Regenwahrscheinlichkeit zwischen 11.00 und 13:00 Uhr“. Prima, das trifft auch zu!
Von SFML bekomme ich eine Wettermeldung, daß wegen unexpected_rain die Stunde ausgeschlossen wird.
Da scheinen zwei AI‘s wohl nicht miteinander zu kommunizieren.
Ist sicher nicht wichtig, deswegen hat die Antwort auch Zeit bis nach dem Urlaub ![]()
Absolut korrekt! - Das würde wenig Sinn machen! Aber ein wichtiger Punkt: Wetter wird weiter gelernt und “hängt” nicht. Im Kern ist es das Jahreszeiten-Lernen das ein separater Pfad ist um die Jahreszeit-Korrekturen parallel zu lernen.
Einen Zähler dafür gibt es nicht, ist auch nicht notwendig aus meiner Sicht. Sind 4 Jahreszeiten ![]()
Aber Du hast einen Punkt, ich schaue es mir noch einmal an, ist aber ehrlich gesagt auf der “Prio-Liste” sehr weit hinten.
Danke für deine Arbeit!
Guten Morgen ![]()
Das ist im Kern korrekt. Solar-Wetter ist etwas anderes als " Wetter", aber Du hast natürlich einen Punk. Besser wäre wenn die Meldung heißen würde " Wegen Regen vom Lernen ausgeschlossen"
Hallo zusammen,
nachdem ich leider beruflich wenig Zeit hatte nach der Beta-Phase das ganze auf einem Raspberry-Pi neu einzurichten habe ich es am Wochenende endlich geschafft. Um es kurz zu machen ich bin von SFML-Stack begeistert. Habe mich an die Anleitung der neuen Homepage gehalten und zuerst SFML eingerichtet. Bevor ich weiteres einrichte, kurze Nachfrage in der Anleitung steht, das zuerst die Wärmepumpe als Verbraucher in STATS eingerichtet werden soll.
Ich habe einen eigenen externen Zähler für die Wärmepumpe. Ich würde diesen verwenden. UND erwartet STATS dafür positive oder negative Werte? Ist das hier der richtige Platz?
Perfekt, ich habe jetzt den Sensor eingetragen. Hat jemand hier auch das Problem das der Rohdatenwert negativ ist? Ich habe mir einen Helfer erstellt.
Hat jemand auch eine Stiebel Eltron mit ISG in EAI eingebunden? Wenn ja, was habt ihr hier eingetragen. Ich habe einen Brauchwasserspeicher und einen Pufferspeicher.
Guten Morgen,
wie und wo kann ich denn den Lizenzschlüssel für EAI bekommen, noch über eine PN hier im Forum oder gibt es mittlerweile einen anderen Weg? Leider findet sich dazu nichts auf der Homepage und hier gibt es nur einen älteren Beitrag dazu…
Danke,
Klayman
Danke. Aber ich stehe noch auf dem Schlauch, die Menüleiste links sehe ich nicht. Bin auf der URL http://DEINE_IP_ADRESSE:8123/api/sfml_stats/dashboard
Hast Du die EAI Integration schon eingerichtet?
ja, als Demo eingerichtet und mit allen Sensoren versehen die ich finden konnte ![]()
Mal ein update gemacht? Die ist ja aus dem Völkerkundemuseum-