Erste KI-basierte Solarprognose die selbst lernt und deine Anlage kennenlernt - veröffentlicht-!

Vielen Dank für euren Zuspruch und euer Verständnis!

Zur Transparenz und offiziellen Lizenzierung:

Ich habe im Repository die entsprechende Lizenz-Nummer gemäß den Vorgaben zur Nachvollziehbarkeit hinterlegt – und zwar wie empfohlen in einem exakt so benannten Ordner, in dem auch die kompilierten Runtimes liegen.

Für maximale Kompatibilität habe ich – ebenfalls nach Empfehlung und entsprechend der Home-Assistant-Dokumentation – die Runtimes für alle relevanten Architekturen (ARM, x86) und von Home Assistant unterstützten Linux-Varianten bereitgestellt. Diese werden automatisch erkannt, sodass niemand von euch manuell eingreifen muss. Genau diese Vorgehensweise wird von Home Assistant als Best Practice empfohlen und entspricht voll und ganz den Richtlinien.

Dadurch ist auf den ersten Blick klar erkennbar, dass es sich um eine offizielle Lizenz und das offizielle Repository handelt.

Leider bedeutet diese Lösung für mich einen erheblichen Mehraufwand:
Bei jedem Major-Update muss ich die verschlüsselten/obfuszierten Teile neu anpassen und aktualisieren – das ist wirklich immense zusätzliche Arbeit. Auch das Debuggen wird nun erheblich schwieriger, da ich immer zwei Versionen vorhalten muss: eine unverschlüsselte zum Entwickeln und Testen und eine verschlüsselte für die Veröffentlichung.

Vielleicht eine blöde Frage, wie merkt man, dass jemand den Code verwendet?

1 „Gefällt mir“

Mir geht‘s nicht um die Einfachheit. Das ist mir soweit klar, lesen und einiges verstehen kann ich ja.

Mir geht’s um die Sicherheit. Mal die Aussage: Du brauchst nur das updaten laufen lassen, dann geht‘s. Dann: Du musst das update machen und irgendwo Ordner löschen und dann Neustart, oder Neuladung. - Das hat mich komplett verunsichert.

Wie gesagt, nur MEINE unwissende Meinung.

Vielleicht wartest Du einfach ab, bis es aus der BETA ist.

Ich war hier auch teilweise etwas verwirrt, sollte aber nach der BETA-Phase “ruhiger” werden. Dann gibt es sicher keine manuellen Ordnerlöschungen oder so und Du kannst Dich voll auf Deine Sensoren konzentrieren. :vulcan_salute:

1 „Gefällt mir“

Hallo zusammen,

ich hatte seit Dezember Solar Forecast ML “nebenbei” auf meinem HA laufen lassen (meine Werte zur Genauigkeit schwankten zwischen 70-75% - bei dem aktuellen Wetter doch ein recht gutes Ergebnis) und der Entwicklung meiner Werte ab und zu Beachtung geschenkt. Jetzt zum 12.6 Release hatte ich mich entschieden, die bisheriege Fassung zu entfernen (wie oben beschrieben: löschen der beiden Ordner, Deinstallation der Integration und harter Neustart) und die neue Version clean zu installieren. Hintergrund waren verschiedene Entitäten, die nun nicht mehr unterstützt wurden und vgl. Leichen vorlagen.
Nach der Neuinstallation hatte ich alle meine bisher in der Integration genutzen Entitäten wieder eingebaut und entsprechen eines Neustarts wurde mir mitgeteilt, dass alles soweit ordentlich läuft - fein :slight_smile: :

nur nun kam eine Fehlermeldung, die mich stutzig macht:

Angeblich fehlt bei mir die Temperatur bzw. Niederschlag und Bewölkung sind 0…

Zur Temperatur habe ich den Sensor meiner Heizung eingebunden und die weiteren Sensoren vom DWD gefüllt:

Schaue ich mir den Niederschlag an, passt der Wert aktuell:

Zur Bewölkung hatte ich keine Entität eingebunden - dieser Wert scheint aus der Intrgration zu stammen. Schaue ich mir den Wert aus der Entität vom DWD an, ergibt sich:

Ein Blick aus dem Fenster unterstützt diesen Wert :wink:

Bei der Temperatur werden mir -0.1°C lt. Entität angezeigt. Dieser Wert wird anscheinend nicht übernommen.

Daher meine Frage an die Runde - was mache ich hier falsch… Meine Werte, die ich optional angegeben habe, werden wohl nicht übernommen…

Grüße

Thomas

Entweder eigene Sensoren verwenden oder keine Einträge.

SFML holt sich die Wetterdaten. Du erhältst bessere Ergebnisse, wenn Du eine eigene Wetterstation installiert hat. UV, Lux, W/m², Luftfeuchtigkeit, Außentemperatur, Wind und Regen wären da zu nennen.

Das haben wir Anfangs auch falsch gemacht.

2 „Gefällt mir“

Hallo Thomas, nimm mal die Sensoren für Helligkeit und Sonneneinstrahlung raus. Die können Deine Module gar nicht abbilden. Der Rest der Wettersensoren wird von einer eigenen Wetterstation nicht soweit abweichen.

1 „Gefällt mir“

Das ist keine blöde Frage! Es war Kommissar-Zufall, ein Freund hat durch einen Zufall ein Projekt entdeckt, das sich sehr ähnlich angehört hat. Ich habe es nicht selbst entdeckt..

Vorab möchte ich auch noch einmal sagen, DANKE für die Arbeit und diese Mega Integration! Wirklich toll, ich kann es gar nicht in Worte fassen, wie genial ich die Arbeit und das Ergebnis finde! :smiley:

Ich habe eine Frage zum Thema der Berechnung der Stromkosten bzw. Einsparung bzw. möchte mein „Problem“ darstellen, warum die Zahlen die berechnet werden für mich nicht stimmen. Eventuell hat ja noch jemand das Thema. Ich versuche es möglichst einfach zu erklären.

Ich habe durch unter anderem meine Wärmepumpe einen hohen Stromverbrauch und dementsprechend einen hohen Stromverbrauch. Zur Erklärung nehme ich einfach ein paar angenommene Zahlen:

Stromverbrauch: 10.000kWh im Jahr

Wenn ich diese 10.000kWh ohne PV und ohne Akku vom Netz beziehen würde kostet mich das 26cent/kWh.

Dann gibt es in Österreich Energiegemeinschaften. (In DE auch?) Hier gibt es Lokale EEGs und Regionale. Jeder kann dort als Bezieher und/oder Einspeiser beitreten. Abrechnung im 15min Intervall durch die Smartmeter vom Netzbetreiber.

EEGs legen Ihren Strompreis (für Einspeisung und Bezug) fest. Teilweise bessere Konditionen als die Großen Stromlieferanten.

Bei den Lokalen EEGs werden zudem die Netzgebühren für den Bezug reduziert. Kurz gesagt, der lokal erzeugte Strom wird auch lokal verbraucht, was dann günstiger für den Verbraucher ist.

Jeder EEG Teilnehmer muss parallel einen Vertrag mit einem klassischen Energielieferanten haben.

Der in die EEG Eingespeiste Strom wird an die Bezieher aufgeteilt. Wenn der Bedarf nicht durch die Einspeiser der EEG gedeckt werden kann wird vom klassischen Energielieferanten der Strom bezogen. Überschuss das gleiche Thema.

Das bedeutet für die Berechnung meiner Einsparung, dass ich bedingt durch die EEG trotz dem monatlichen fixen Stromtarif somit sozusagen einen „variablen“ Tarif habe, je nachdem wie viel % meines Stromes ich von der EEG beziehe oder dort einspeise. Bei einem variablen Tarif kommt der Effekt in gleicher Form zu tragen.

Also meine „fixen“ 26 cent/kwh für den Bezug variieren jeden Monat.

Zudem sind die Netzgebühren abhängig von der vom Netz bezogenen Energie.

z.B. bei 10.000kWh fallen 13 cent/kwh Netzgebühren an.

Durch meine PV (und Speicher) fällt mein Netzbezug auf 1000kWh im Jahr. Die Netzgebühren steigen auf 25 cent/kwh.

Das bedeutet:

  • Der Kosten für den Netzbezug für die 1000kWh steigen durch die PV von 26 auf 38 cent/kwh.
  • Die Einsparung durch die PV pro kWh ist jedoch nicht 38 sondern 26 cent/kwh.
  • Die Stromkosten variieren definitiv jeden Monat. Teilweise wird (derzeit noch) Jährlich abgerechnet.

Wäre es möglich eine Tabelle einzubauen, um die wirklichen kosten für Bezug und auch Einspeisung monatlich (nach erfolgter Abrechnung, bis dahin mit Dummy Werten) manuell zu pflegen? Auch die „Referenzstromkosten“ für den Jahresbezug ohne PV? Dann wäre die Berechnung und Darstellung korrekt.

Servus Joachim, ich würde an deiner Stelle einfach mal pausieren und ein paar Wochen abwarten. Ich bin auch gerade ausgestiegen, da mir leider die Zeit fehlt, außerdem ist eh gerade keine PV-Saison. Ich glaube es wird schon noch ein bisschen dauern bis alles rund läuft, wenn man aber betrachtet was in ein paar Wochen entstanden ist, kann das Projekt schon sensationell werden.

Wegen unsicher usw., beschäftige dich mit den HA-Backups, dann kann dir ja nichts passieren, ein Backup ist in ein paar Minuten eingespielt und es läuft wieder. VS Code brauchts du auch unbedingt, wenn du nicht nur ein paar Lämpchen schalten willst, damit ist löschen, finden, editieren super einfach!
Dass du dir den Rechner mit HA zerschossen hast, kann ich mir überhaupt nicht vorstellen. Hat das wirklich einen Zusammenhang?

Da in dem Sensor die Daten nicht vorhanden sind habe ich dir schon geschrieben, das du die Samples im MOMENT in der LOG findest. auch wenns es doof klingt, es ist leider gerade so.

Hier ein Beispiel

2026-01-04 23:30:00 - custom_components.solar_forecast_ml.ai.ai_predictor - INFO - AI training started: 1 outputs
2026-01-04 23:30:00 - custom_components.solar_forecast_ml.ai.ai_predictor - INFO - Prepared 54 training samples from 6 days, 1 outputs
2026-01-04 23:30:00 - custom_components.solar_forecast_ml.ai.ai_predictor - INFO - Training with 54 samples, 20 features, 1 outputs
2026-01-04 23:30:00 - custom_components.solar_forecast_ml.ai.ai_tiny_lstm - INFO - Training: 54 samples, 200 epochs, 1 outputs

Ich kann mir auch gerade keinen Reim drauf machen wie HA da was kaputt gemacht haben soll.

1 „Gefällt mir“

Hallo pdengg, auch in Deutschland gibt es Hinweise, das etwas Ähnliches kommt:

Gesetzesänderungen der PV-Branche: Ausblick auf 2026

Besonders relevant wird in der PV-Branche 2026 die weitere Zukunft der Einspeisevergütung - nachdem Wirtschaftsministerin Katherina Reiche bereits im Sommer und Herbst 2025 Andeutungen gemacht hatte, diese abschaffen zu wollen. Da auch aus EU-Sicht eine Neuregelung des Erneuerbare-Energien-Gesetzes (EEG) bis 2027 erforderlich ist, kann die Branche mit hoher Wahrscheinlichkeit damit rechnen, dass es in diesem Bereich weitreichende Änderungen geben wird. Im Detail berichten wir zu diesem Thema in unseren Blogbeiträgen “Ende der Einspeisevergütung? Ausblick auf 2026” und in unserem Artikel zum Solarspitzengesetz, das einige Gesetzesänderungen betrifft, die 2026 in Kraft treten.

Auch die EnWG-Novelle wird 2026 eine große Rolle spielen: so soll ab Juli 2026 Energy Sharing möglich werden, was vor allem für Quartierslösungen eine sinnvolle Möglichkeit dezentraler Energieversorgung darstellen würde - insbesondere seit dem BGH-Urteil zur Kundenanlage aus dem Mai 2025, das die Definition von Mieterstromprojekten verändert hat. Seit November 2025 herrscht auch hier Klarheit - bestehende Kundenanlagen erhalten eine 3-jährige Übergangsfrist. Bis zum Ablauf dieser Frist muss der Gesetzgeber eine dauerhaft unionsrechtskonforme Lösung vorlegen, die den Spielraum des EU-Rechts so weit wie möglich ausschöpfen soll. Betreiber von Mieterstromanlagen können also vorerst aufatmen - für 2026 und auch für die nächsten Jahre herrscht Rechtssicherheit.

Weitere Details zum BGH-Urteil, die konkreten Auswirkungen auf Mieterstromprojekte und eine Stellungnahme von metergrid als Mieterstrom-Anbieter können in unserem Artikel “BGH-Urteil 2025/2026: Mieterstrom bleibt möglich – politische Klarstellung” nachgelesen werden.

In einigen europäischen Ländern gibt es sowas ja auch schon. Ob das hier in dieser Integration schnell integriert wird, kann ich natürlich nicht sagen. Ich selbst erfasse unterschiedliche Werte (meistens errechnet durch ein Template und anschließenden TagesVerbrauchszähler) in Homeassistant´s EnergieDashBoard. Einmal im Monat (oder Woche, Tag) übertrage ich die Werte in eine Tabellenkalkulation. Gefällt mir sehr gut.

Ja, verstehe ich. Ich wollte vor allem ansprechen, dass es diese Thematik (in AT) gibt. Das macht eine ROI Rechnung nämlich etwas komplexer… :grinning_face_with_smiling_eyes:

Ich tracke die Kosten und Einsparungen auch in meiner Tabellekalkulation, anders ist es bisher für mich nicht möglich. Die einen rechnen ein Monat im Nachhinein ab, die anderen quartalsweise, die anderen jährlich…

ACHTUNG NERD-STUFF: EEG & GESETZESÄNDERUNG AT/DE

Ich antworte euch mal gemeinsam @pdengg @rapahl , da das Thema sehr komplex ist muss ich etwas ausholen… alle Anderen bitte weiterscrollen :slight_smile:

Das Thema wurde vor ca. 8 Wochen schon einmal im Call angesprochen und seit dem bin ich an einer Lösung.

Hintergrund ist, dass diese Änderung der Gesetzeslage umfassend ist und Viele betrifft / betreffen wird - gerade in DE.

Ich habe mit verschiedenen Personen gesprochen und bereits ein Konzept entwickelt, das ich dann nun mit ausrollen werden!

Monatliche Tarif-Verwaltung für EEG und Energy Sharing

Die Anforderungen an Energiegemeinschaften (EEG) in Österreich und das kommende Energy Sharing in Deutschland (ab Juni 2026) zeigen, dass die bisherige Kostenberechnung in Stats für viele von euch nicht mehr ausreichen wird.

Bei variablen Tarifen – etwa durch eine EEG, Mieterstrom oder künftig Energy Sharing – lassen sich korrekte Einsparungen nicht mit einem einzigen Fixpreis ermitteln.

Was kommt im nächsten Update?

Ein neuer Bereich im Dashboard: „Tarife & Abrechnung“. Hier erhaltet ihr eine übersichtliche Ansicht aller Monate des Jahres mit den relevanten Werten:

  • Monat
  • Bezug (kWh)
  • Bezugspreis
  • Einspeisung (kWh)
  • Vergütung
  • Referenzpreis
  • Status

Beispielwerte für vergangene und laufende Monate:

  • Januar: Bezug 234,5 kWh, Bezugspreis 32,47 ct/kWh (automatisch berechnet), Einspeisung 45,2 kWh, Vergütung 8,10 ct/kWh (Standard), Referenzpreis 26,0 ct/kWh (Standard), Status finalisiert.
  • Februar: Bezug 198,3 kWh, Bezugspreis 31,80 ct/kWh (manuell korrigiert), Einspeisung 67,8 kWh, Vergütung 7,50 ct/kWh (manuell korrigiert), Referenzpreis 26,0 ct/kWh (Standard), Status finalisiert.
  • März: Bezug 156,2 kWh, Bezugspreis 29,15 ct/kWh (automatisch berechnet), Einspeisung 123,4 kWh, Vergütung 8,10 ct/kWh (Standard), Referenzpreis 26,0 ct/kWh (Standard), Status in Bearbeitung.

Die Statusangaben erklären sich wie folgt:

  • Automatisch berechnet: SFML Stats ermittelt den Wert selbstständig.
  • Standard: Der einmal konfigurierte Default-Wert.
  • Manuell korrigiert: Ihr habt den Wert basierend auf eurer Abrechnung angepasst.
  • Finalisiert: Der Monat ist abgerechnet, die Werte sind fest.

Wie funktioniert das?

  1. Automatische Berechnung (läuft eigenständig): SFML Stats ermittelt für jeden Monat den gewichteten Durchschnittspreis. Dabei wird nur der tatsächliche Bezug berücksichtigt.
    Beispiel: Mittags bei hohem PV-Ertrag kein Bezug, daher irrelevant für den Preis. Abends ohne PV: Bezug von 1,2 kWh zu 38 ct/kWh. Der Durchschnitt berücksichtigt ausschließlich die Stunden mit realem Stromkauf – nicht die teuren Stunden, die die PV-Anlage abdeckt.

  2. Einmalige Konfiguration (einmalig von euch): Im Setup legt ihr eure Standardtarife fest:

    • Referenzpreis: Kosten pro kWh ohne PV-Anlage (z. B. 26 ct/kWh).
    • Standard-Einspeisevergütung (z. B. 8,1 ct/kWh).
    • Optional: Spezifische EEG-Tarife für Energiegemeinschaften.
      Diese Werte dienen als Vorschlag für jeden Monat.
  3. Monatliche Korrektur (nach eurer Abrechnung): Sobald die Stromrechnung eintrifft, wählt ihr den Monat aus und tragt die tatsächlichen Werte ein:

    • Realer Bezugspreis (inkl. EEG-Anteil, Netzgebühren usw.).
    • Tatsächliche Einspeisevergütung.
    • Netzgebühren (falls separat ausgewiesen).
      Anschließend markiert ihr den Monat als finalisiert. SFML Stats aktualisiert dann alle historischen Berechnungen mit den korrekten Preisen.

Was bringt das konkret?

Eine präzise Einsparungsberechnung: Bisher galt Einsparung = Eigenverbrauch × aktueller Bezugspreis (bei Dynamischen Tarifen stundengenau). Allerdings ist es nichtt dazu geeignet der neuen Regelung Rechnung zu tragen, da der Bezugspreis durch die PV-Anlage verzerrt wird (weniger Netzbezug führt zu höheren Netzgebühren pro kWh).

Neu: Einsparung = Eigenverbrauch × Referenzpreis. Der Referenzpreis entspricht den Kosten, die ohne PV für den gesamten Verbrauch anfallen würden – das ist die tatsächliche Ersparnis.

Praxisbeispiel:

  • Ohne PV: 10.000 kWh Bezug zu 26 ct/kWh → 2.600 € Stromkosten.
  • Mit PV: 1.000 kWh Bezug zu 38 ct/kWh (höhere Netzgebühren) → 380 € Stromkosten.
    Aktuelle Berechnung: 9.000 kWh × 38 ct = 3.420 € Einsparung (falsch).
    Neue Berechnung: 9.000 kWh × 26 ct = 2.340 € Einsparung (realistisch, da ohne PV mehr gezahlt worden wäre).

Zusätzliche Features

Ich hatte bereits im letzten Call angekündigt das ein CSV-Export kommen wird.

  • CSV-Export: Alle Monatsdaten für eigene Auswertungen in Tabellenkalkulationen.
  • Netzgebühren-Schätzung: Basierend auf dem Jahresverbrauch.
  • EEG-Anteil: Automatische Ermittlung des Prozentsatzes aus der Energiegemeinschaft.

Für wen ist das gedacht?

  • Mitglieder von Energiegemeinschaften (EEG) in Österreich.
  • Nutzer von Mieterstrom oder Quartierskonzepten.
  • Alle mit variablen Tarifen (z. B. aWATTar, Tibber).
  • Alle, die nach der Jahresabrechnung reale Werte nachtragen möchten.
  • Alle, die Daten in Excel oder ähnlichen Programmen exportieren wollen.

Mehr kann ich da aktuell nicht leisten, da es gerade in DE noch alles ein wenig “Unklar” ist. Aber ich denke es ist ein guter Anfang / Kompromiss der so viel wie möglich abdeckt.

Voraussetzung ist, das die Sensoren korrekt konfiguriert sind UND es wird nur auf x86 Systemen funktionieren!

Die Felder sind editierter “fingen crossed”

5 „Gefällt mir“

ist kein problem.

hab letzte nacht, auch die ersten AI model trainingsdaten bekommen.

custom_components.solar_forecast_ml.production.production_scheduled_tasks - WARNING - AI model training incomplete: Need 50 samples, got 8

3 „Gefällt mir“

Bin Dir “weit” voraus…. :zany_face:

AI model training incomplete: Need 50 samples, got 27

Hi Tom,

Siehst du eine Möglichkeit, für SFML-Stats-LITE zumindest für

dort auch die Einspeisevergütung einstellbar ist, da ja auch BKW´s hier keine bekommen und das ja dann die Einspeisung nicht in die Berechnung mit einfliest

und

man zumindest dort für die angezeigte Statistik die Möglichkeit hat, Werte zu korigieren durch Abweichungen z.B. zwischen Anker Smart Meter und Zähler?

Hallo Johnny

Das geht via GRID PRICE MONITOR (GPM)

Das ist ein Bekanntes Problem von HA Riemann-Summernsensor, das entsteht durch die unregelmäßigen Updates durch die Anker Integration. Auch kann man Riemann-Sensoren nicht mit einem Startwert-Versehen:
Lösung: SQL Sensor der direkt die Datenbank ausliest und Leistung in Energie umrechnet. Denn kann man auch mit einem Off-Set versehen und regelmäßigen RESET um Mitternacht ohne Zwischenschritte

Kommt das dann noch mit einem der nächsten Updates? Bis jetzt hab ich das noch nicht gefunden oder stell mich zu blöd an :sweat_smile:

SQL Sensor

Hab ich tatsächlich schon probiert, als du dass das erste mal hier erwähnt hast und das über längere Zeit auch miteinander laufen lassen und verglichen.

Mit dem Ergebnis, das beide keine Abweichung haben, das ist bei mir einfach die Ungenauigkeit von dem Anker Smartmeter (und bei Shelly soll das wohl auch sein dass die Streuen). Und Zähler kann ich auch nicht abnehmen, da dort der Anbieter an der IR-Schnittstelle für einen dynamischen Tarif mit seiner Box hängt, da ich nur ne Moderne Messeinrichtung statt einem Smart Meter habe… :thinking:

Als Beispiel Dezember:

  • Anker App, nicht mal HA: Netzbezug 135,41 kWh
  • Energy-Dashboard: Netzbezug 135,48 kWh
  • Anbieter über Stromzähler: 140,61 kWh

Allein wenn ich das vergleiche und das gleiche Ergebnis mit SQL-Sensoren habe, muss ich einfach hier von einem funktionierenden Integralsensor ausgehen und dann kann es nach ausschlussverfahren nur noch an einer Messungenauigkeit des Anker Smart Meter sein.

Bei mir funktionieren die Benachrichtigungen zum Schnee/Frost seit dem letzten Update nicht mehr.
So sah das Logbuch noch am 01.01 aus und es gab eine Benachrichtigung.

2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 1 hour 9, bucket=snowy, ratio=1.13, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 1 hour 10, bucket=snowy, ratio=0.65, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 1 hour 11, bucket=snowy, ratio=0.90, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 1 hour 12, bucket=snowy, ratio=4.55, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 2 hour 9, bucket=snowy, ratio=1.99, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 2 hour 10, bucket=snowy, ratio=1.45, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 2 hour 11, bucket=snowy, ratio=1.28, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 2 hour 12, bucket=snowy, ratio=8.13, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 3 hour 10, bucket=snowy, ratio=0.56, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 3 hour 11, bucket=snowy, ratio=1.26, snow_covered_panels=True
2026-01-01 23:30:35 - custom_components.solar_forecast_ml.physics.physics_calibrator - DEBUG - Snowy calibration sample: Gruppe 3 hour 12, bucket=snowy, ratio=4.27, snow_covered_panels=True

Die letzten Tage gab es keine Benachrichtigung mehr, obwohl die Platte komplett zu sind.

2026-01-04 23:30:28 - custom_components.solar_forecast_ml.data.data_weather_expert_blender - DEBUG - No snow predictions to learn from on 2026-01-04

Ist das so richtig oder lernt die KI jetzt komplett falsch?