UPDATE // RELASE NOTES Solar Forecast ML

[Tom-HA]

Leider kann ich den obrigen Post nicht mehr ergänzen, daher hier die Updates für SFML:

Mehr Stabilität, intelligentere Fehlerbereinigung & kein Einfrieren mehr zur EOD-Zeit!

Hallo zusammen,

in den letzten Tagen habe ich intensiv unter der Haube gearbeitet, um einige hartnäckige Probleme zu lösen, die mir von euch in der Community gemeldet wurden. Viele dieser Optimierungen betreffen die Stabilität der Datenbank, die KI-Genauigkeit und die System-Performance.

Hier ist eine kurze Übersicht der wichtigsten Neuerungen in der kommenden Version:

---

1. Schluss mit dem Einfrieren von Home Assistant! (Performance-Fix)

• Das Problem: Einige von euch haben bemerkt, dass Home Assistant während des EOD-Workflow-Trainings für einige Sekunden nicht mehr reagiert hat. Das lag daran, dass das CPU-intensive Training der KI-Modelle den Hauptprozess von Home Assistant blockiert hat.
• FIX: Das Modelltraining läuft ab sofort in einem völlig eigenständigen Hintergrund-Prozess ab HA 2026.6.x.
• Die Vorteile:
  • Home Assistant bleibt während des Trainings zu 100 % reaktionsschnell.
  • Ein Sicherheits-Timeout bricht das Training ab, falls es sich jemals aufhängen sollte.
  • Eine Ressourcen-Bremse sorgt dafür, dass die KI nur einen einzigen CPU-Thread nutzt, damit euer Raspberry Pi oder NUC nicht überhitzt.
  • Sollte der Hintergrund-Prozess durch System-Einschränkungen blockiert werden, gibt es einen automatischen Fallback, der das Training sicher im Hauptprozess zu Ende führt.

---

2. „Hubble“ passt auf: Automatische Fehlererkennung & Selbstheilung

Um eure Datenbanken vor „giftigen“ Daten (durch Sensor-Aussetzer, falsche Konfigurationen oder Abstürze) zu schützen, habe ich die Schnittstelle [Hubble] weiter entwickelt. Hubble spricht verständliches Deutsch mit euch im Log und repariert Fehler im Hintergrund:

• Präventiver Sensor-Audit: Wenn ihr versehentlich einen falschen Sensor konfiguriert (z. B. Leistung in Watt statt Energie in kWh), vergiftet es nicht mehr die DB. Hubble erstellt stattdessen einen Eintrag direkt unter System-Probleme (HA Repairs) in euren Home Assistant Einstellungen und erklärt euch verständlich, was zu tun ist.
• Live-Spike-Filter: Liefert ein Sensor plötzlich einen unphysikalischen Riesenwert (z. B. durch einen Übertragungsfehler, Neustart, Fehler), filtert Hubble diesen Wert heraus und ersetzt ihn live durch eine physikalische Näherung. Eure KI lernt dadurch keinen Unsinn.
• Nächtliche Datenpflege (EOD-Hygienist): Hubble scannt jede Nacht die letzten 24 Stunden.
  • Unplausibel hohe Erträge (z. B. durch fehlerhafte Zähler-Sprünge) werden für das Training gesperrt.
  • Datenlücken füllen: Fehlten tagsüber Werte (z. B. durch einen Home Assistant Absturz), rekonstruiert Hubble die Lücke anhand eures täglichen Endzählerstands und verteilt den Ertrag proportional zur Sonnenkurve. Die Lücke in eurer Statistik ist geflickt, aber die KI wird mit diesen künstlichen Werten nicht kontaminiert.

---

3. Korrektur der doppelten Winter-/Sommer-Kompensation (KI-Feinschliff)

• Das Problem: In den Modellen kam es zu einer mathematischen „Doppelkorrektur“ der Saisonalität (Winter/Sommer). Da die KI-Modelle das saisonale Verhalten bereits im Training gelernt haben, führte eine zusätzliche, feste Saisonskalierung im Sommer zu Überprognosen und im Winter zu Unterprognosen.
• Lösung: Die redundante Skalierung wurde entfernt. Die Modelle prognostizieren die Werte nun absolut präzise und nativ auf Basis des gelernten Jahresverlaufs.

---

4. Bessere Wetterdaten-Filter & Schutz vor eingefrorenen Sensoren

• Abregelungs-Schutz: Wenn eure PV-Anlage abgeregelt wird (z. B. weil die Batterie voll ist und nicht mehr eingespeist werden darf), weicht die reale Produktion stark vom Wetterpotenzial ab. Der Wetterschätzer überspringt diese Stunden nun automatisch beim Lernen, damit die KI nicht fälschlicherweise denkt, es sei bewölkt gewesen.
• Freeze-Detection: Wenn ein Sensor (Temperatur, Solar-Strahlung oder Lux) ausfällt und über 3 Stunden exakt denselben Wert einfriert, wird dieser Wert vom System ignoriert und durch meine robusten Wetterschätzungen ersetzt. → @Heatseeker - FIX

---

5. Robustes Verhalten bei Zähler-Resets (z. B. um Mitternacht)

• Das Problem: Viele Wechselrichter-Sensoren setzen sich nicht genau um Mitternacht auf 0 zurück. Das führte bei nachgelagerten Zählerstand-Berechnungen oft zu negativen Ertragssprüngen oder verfälschten Werten für die erste Stunde des neuen Tages.
• FIX: Der Live-Sensor-Reader und die historische Zählerstand-Berechnung erkennen Zähler-Resets nun intelligent und addieren den Ertrag nahtlos weiter ab Null.

Ich denke, damit habe ich alles was ihr gemeldt habt " erwischt"

Zara

[Tom-HA]

Update Weather-Fusion AI

Ich habe die beiden am häufigsten gemeldeten Probleme der Weather Fusion AI Integration analysiert und behoben.

Hier ist eine kurze Übersicht, was genau ich repariert habe:

1. Absturz beim Klick auf das Zahnrad (Fehler 500)

• Das Problem: Wenn man in Home Assistant bei der Integration auf das Zahnrad (Konfiguration/Optionen) geklickt hat, stürzte das Fenster ab. Das lag an Änderungen in neueren Home Assistant-Versionen und an Fehlern, wenn man optionale Sensoren leer gelassen hat.
• Fix Ich habe die Einstellungen komplett an die neuen Home Assistant-Vorgaben angepasst. Der Absturz ist behoben. Ihr könnt die Optionen nun wieder ganz normal öffnen, ändern und speichern – auch wenn ihr nicht alle Sensoren belegt habt.

2. Die Vorhersage-Genauigkeit bleibt dauerhaft bei 0% oder „Nicht verfügbar“

• Das Problem: Viele hatten die Integration schon wochenlang laufen, aber die Genauigkeit wurde nicht berechnet (blieb auf 0% oder “Nicht verfügbar”). Die KI hat scheinbar nichts gelernt. Dafür gab es zwei Gründe:
  1. Nachträgliche Änderungen ignoriert: Wenn ihr eure Sensoren (z. B. für die Temperatur oder den Regen) nachträglich über das Zahnrad geändert habt, hat das System das im Hintergrund nicht richtig übernommen. Es dachte, es gibt keine Sensoren zum Vergleichen, und hat nichts aufgezeichnet.
  2. Zeitzonen-Verschiebung beim ICON: Die Vorhersagen von ICON wurden fälschlicherweise in der Weltzeit (UTC) statt in eurer lokalen Uhrzeit geladen. Dadurch passten die Vorhersagen zeitlich nicht zu den echten Messdaten eurer Wetterstation (im Sommer gab es z. B. eine Verschiebung von 2 Stunden). Die KI konnte die Daten daher nicht miteinander verknüpfen.
• Fix: Ich habe beide Fehler behoben! Die Integration merkt sich nun jede Sensor-Änderung sofort und rechnet die Zeiten des ICON automatisch in eure lokale Uhrzeit um. Die KI kann jetzt fehlerfrei vergleichen. Nach der Mindest-Lernzeit von 3 Tagen wird eure echte Genauigkeit berechnet und angezeigt.

Zara

[Tom-HA]

UPDATE Grid Price Monitor (GPM)

Hallo zusammen,

ich habe ein neues Update für Solar Forecast GPM (Grid Price Monitor) fertiggestellt. In diesem Update habe ich einige nervige Fehler behoben und die Zuverlässigkeit des Batterie-Trackers und die Grundlagen für Smart Charging eingebaut.

1. Zuverlässigerer Batterie-Tracker (Riemann-Summe)

• Keine falschen Spitzen mehr bei Ausfällen: Wenn der Leistungssensor der Batterie kurzzeitig offline war (z. B. Zustand unknown oder unavailable), hat der Tracker nach der Wiederkehr die Energie für die gesamte Ausfallzeit hochgerechnet. Das führte zu riesigen Fehlmessungen (Spitzen). Ich habe das so angepasst, dass Lücken jetzt übersprungen werden und der Zähler danach sauber neu ansetzt.
• Schutz vor Zeitumstellungen: Bei NTP-Zeitsynchronisationen oder der Umstellung auf Sommer-/Winterzeit konnten negative Zeitspannen entstehen, die den Zähler durcheinandergebracht haben. Das ist jetzt abgesichert.
• Automatischer Mitternachts-Reset: Wenn die Batterie nachts gar nicht genutzt wurde (konstant 0 W), wurde der Tageszähler um Mitternacht nicht zurückgesetzt, weil keine neuen Messwerte kamen. Jetzt prüft das System den Datumswechsel alle 5 Minuten im Hintergrund und nullt den Zähler zuverlässig.

2. Smart Charging

• Solarprognose eingebaut: Dieses Update arbeitet nun mit STATS und SFML und Hubble zusammen.
• Schutz vor Abstürzen: Wenn die Batteriekapazität in den Einstellungen fälschlicherweise auf 0 gesetzt wurde, stürzte die Berechnung ab. Hier greift jetzt eine automatische Absicherung.

3. Zeitzonen & Abfragen

• Keine Verschiebungen bei Historie-Abfragen: Um Zeitverschiebungen zu verhindern, speichere ich die Preisdaten in lokaler Zeit in der Datenbank ab. Bei den Abfragen für die Historie und Tagesdurchschnittswerte kam es jedoch zu einem Konflikt mit UTC. Ich habe die Abfrage-Logik korrigiert, sodass die Zeitzonen-Offsets nun perfekt übereinstimmen.

4. Bessere Einrichtung (UI)

• MwSt.-Vorauswahl korrigiert: Bei der Ersteinrichtung gab es einen Konflikt bei der Mehrwertsteuer-Auswahl, wodurch die Standardeinstellung (z. B. 19% für Deutschland) im Dropdown-Menü leer blieb. Das ist nun behoben.
• Dynamischer Datenbankpfad: Der Pfad zur geteilten Datenbank wird nun dynamisch über die Home Assistant API ermittelt, statt starr auf /config/... zu verweisen. Das erhöht die Kompatibilität mit verschiedenen Installationen und ist für Smart Charging wichtig

Das Update läuft bei mir bereits im Test.

[Tom-HA]

Update TFS HA

Dieses Update erhöht (so Gott will) vor allem die mathematischen Präzision des Trainingsprozesses, sowie die Harmonisierung von Trainings- und Inferenz-Features sowie der Absicherung der automatischen LoRA-Feinabstimmung. Danke an HA-Dev für das HA Update 2026.6x (!!!)

1. Optimierung des Kalibrierungsverlusts (Calibration Loss)

Die mathematische Formulierung der Klasse CalibrationLoss in losses.py wurde grundlegend überarbeitet. Bisher führte ein harter Schwellenwert-Vergleich (Sprungfunktion) zu einer mathematisch nicht-differenzierbaren Verlustfunktion, was den Gradientenfluss (Backpropagation) blockierte. Durch die Einführung einer, differenzierbaren Sigmoid-Approximation mit kontrollierter Temperatur wird nun sichergestellt, dass die Kalibrierungsinformationen aktiv zur Gewichtsoptimierung des Modells beitragen. Auch an dieser Stelle noch einmal dank an HA-DEV (!!)

2. Harmonisierung der Feature-Skalierung

Die Erstellung des zeitlichen Verlaufstensors über die Methode _build_temporal_tensor in engine.py wurde angepasst. Während in der Trainingsphase die reale Gesamtkapazität der PV-Anlage in die Normalisierung einfloss, war dieser Wert bei der Inferenz auf einen konstanten Platzhalter normiert. Dies führte dazu, dass das Modell zur Laufzeit Werte außerhalb der gelernten Verteilung (Out-of-Distribution) verarbeiten musste. Die Normalisierung wurde vereinheitlicht, indem nun auch in der Inferenz die reale Gesamtkapazität eurer PV-Gruppen übergeben wird.

3. Präzisierung des Wetter-Paddings (Weather Forecast Padding)

Beim Auffüllen unvollständiger Wettervorhersagen über die Hilfsfunktion _pad_weather in engine.py wurde die Logik zur Zeitstempelfortschreibung überarbeitet. Anstelle von geteilten Objekt-Referenzen auf das letzte Wetterelement (was zu Timestamp-Drifts führte) werden nun explizite Kopien der Datenpunkte erzeugt und deren Zeitstempel stündlich inkrementiert. Dies garantiert konsistente Zeitreihen-IDs für nachgelagerte Berechnungen. Ich hoffe das HA zukünfitg nicht wieder an dieser Stelle bricht, aber mit 2026.6 scheint Ruhe eingekehrt zu sein.

4. Integration einer Validierungs-Schranke für LoRA-Adapter

Der Feinabstimmungs-Prozess in finetune.py und runner.py wurde um einen Safeguard ergänzt, ihr kennt das schon von SFML. Vor dem Speichern eines neu trainierten LoRA-Adapters wird dessen Validierungsverlust (val_loss) mit dem Verlust des aktuell aktiven Adapters abgeglichen. Verschlechtert sich der Validierungswert, wird der neue Adapter verworfen (rejected_worse_loss), um Leistungseinbußen durch Überanpassung (Overfitting) zu unterbinden.

Zara

[Tom-HA]

Version 28.0.2 HA-Cache-Fix Update

Einige von euch und auch auf anderen Plattformen haben Meldungen im Protokoll zum letzten Release.
Diese beziehen sich auf ein Caching-Problem in Home Assistant selbst. Dieses Update behebt diesen Fehler in dem der Code das selber übernimmt.

Es ist auch noch ein weiterer Fehler dazugekommen. SMART (wenn es konfiguriert ist) wird nicht auf allen Systemen korrekt angezeigt.

Neue Funktioinen:
Keine

Status:
Im Test

[Tom-HA]

UPDATE SFML / STATS / GPM V28.0.4

Leistungsoptimierungen & Stabilität EOD / KI-Training

Aufgrund der wachsenden Aufgaben des Hubble-KI-Stacks kam es in letzter Zeit bei einigen Systemen mit geringerer Leistung, virtuellen Maschinen (VMs) und Setups, die nahe an ihren Ressourcengrenzen laufen, zu Performance-Problemen.

Um eine durchgehend stabile Systemumgebung zu gewährleisten, wurde die Leistung des KI-Stacks in dieser Version bewusst gedrosselt. Diese Anpassung garantiert, dass SFML inkl. STATS und GPM auf allen von Home Assistant unterstützten Systemen zuverlässig und flüssig läuft.

---

Breaking Changes (Schwerwiegende Änderungen)

• KI-Leistungsbegrenzung: Dieses Update schränkt die maximale Leistung des integrierten KI-Stacks bewusst ein, um den Host-Server vor Überlastung zu schützen.
• Feature-Freeze für KI-Funktionen: In dieser Version (Solar Forecast ML) werden keine weiteren KI-Funktionen hinzugefügt, um die langfristige Stabilität des Host-Systems zu sichern.
• EOD-Zeit: Zum Schutz von Proxmox-basierten Systemen wurde das EOD (End of Day / Task) zeitlich verlängert.

Online via HACS

[Tom-HA]

UPDATE V28.0.6 ist verfügbar (SFML, STATS, GPM)

ich habe soeben das Update auf Version 28.0.6 bereitgestellt! Mit diesem Release behebe ich einige wichtige Punkte, die mir aus der Community gemeldet wurden:

• Zeitzonen-Verschiebung bei dynamischen Strompreisen:
  Einige von euch hatten eine Zeitverschiebung bei der Berechnung der dynamischen Stromtarife bemerkt. Ein großes Dankeschön geht an den User ** @Johnny_1993 ** hier aus dem Forum für den wertvollen Hinweis!
• Eigenständige Zeitzonen-Berechnung (Hubble-Drift behoben):
  Um diesen Fehler dauerhaft zu lösen, berechnet die Integration die lokale Zeitzone nun wieder komplett selbstständig und verlässt sich nicht mehr auf die internen Home Assistant-Hilfsfunktionen. Die Verschiebung hatte leider auch dazu geführt, dass das Hubble-Diagnosemodul und die aufgezeichneten Ist-Werte einen Drift aufwiesen. Das läuft nun wieder absolut synchron.
• Unabhängiges Error-Reporting:
  Ich habe die interne Home Assistant-Funktion zur Fehlermeldung entfernt. Die Integration übernimmt das Abfangen und Aufbereiten von Diagnosemeldungen ab sofort wieder eigenständig.

Vielen Dank für euren fantastischen Support und die Fehlermeldungen, die mir helfen, das Projekt stabil zu halten! Nach dem Update bitte wie gewohnt Home Assistant einmal neu starten, damit alle Änderungen aktiv geladen werden.

[Tom-HA]

UPDATE V 28.0.8 SFML // STATS // GPM

Dieses Release stabilisiert SFML, STATS- und GPM-Funktionen, behebt mehrere gemeldete Fehler und führt die freie Auswahl eines Strompreis-Sensors ein ( @salmunia ).

Änderungen & Bugfixes:

• Robustere Datenbankverbindungen:
  Zentralisierung der SQLite-Konfiguration durch einen verbesserten Auto-Reconnect-Mechanismus zur Vermeidung von Verbindungsabbrüchen.
• Fehler bei Ertragsabruf behoben: (Danke @Joachim-xo für das ausführliche LOG)
  Der Fehler name 'db_path' is not defined beim Abrufen des heutigen Gesamtertrags wurde korrigiert.
• TZINFO Home-Assistant-Zeitlogik:
  Explizite Handhabung der Zeitzonen wieder direkt im Code und nicht via hass, damit Tageswerte und Forecast-Zeiten unter allen Bedingungen stabil und korrekt berechnet werden.
• Scheduler-Fix im Forecast Collector:
  Behebung des Scheduler-Ausfalls, der durch den Fehler function object has no attribute tzinfo verursacht wurde.
• Smart-Charge-Logik:
  Optimierter Fallback bei fehlendem State of Charge (SOC), unvollständigen Forecast-Daten oder lückenhafter Konfiguration.
• Datenvalidierung für Preis-Forecasts (GPM):
  Die Preis-Forecast-Verarbeitung wurde gegen veraltete, unvollständige oder fehlende Datensätze abgesichert.
• Erweiterte Frontend-Zustandsübersicht (Hubble):
  Neue Frontend-Keys zur transparenten Darstellung der Smart-Charge-Entscheidungen und -Zustände.
• Optimierte Home-Assistant-2026.6 Kompatibilität:
  Manuelle Update-Listener für Options-Reloads wurden entfernt und vollständig auf das native OptionsFlowWithReload umgestellt.

Vielen Dank für das tolle Bug-Tracking im größten deutschen Home-Assistant-Forum Simon42 – ohne euch wäre es um ein Vielfaches schwerer, und die gesamte, weltweite SFML-Community profitiert von eurer Arbeit!

ONLINE VIA HACS

[Tom-HA]

UPDATE V 30.0.0 RC1 SFML // STATS // GPM

Aufgrund von Instabilitäten der internen Home Assistant Riemann-Sensoren (kWh-Berechnungen) ist es zu Abweichungen bei der Gesamt-IST-Berechnung gekommen. Der Code hat diese Abweichungen aus GIGO-Gründen (Garbage In, Garbage Out) registriert und die fehlerhaften IST-Werte aus Home Assistant verworfen.

Um ein Gefühl für die Größenordnung zu bekommen: Bei einer Beispiel-Anlage mit 2,0 kWp betrug die Abweichung 140 Wh pro Tag (!!!) – zum Teil entstanden sogar negative Deltas.

Um unabhängiger von Fehlern in Home Assistant zu sein und die Integration grundlegend zu stabilisieren, habe ich sämtliche Rechenoperationen direkt in den Code verschoben.

Mit dieser Maßnahme ist der Code resistent gegen Bugs in Home Assistant selbst. Nutzer müssen nun auch nicht mehr „rumbasteln“ und eigene Tagessensoren anlegen. Da der Code jetzt in Echtzeit live selbst rechnet, reicht die Angabe folgender Sensoren:

• Power-Sensor pro Gruppe → That’s all!

Durch diesen Umbau kann ich Fehler wie Neustarts, Cloud-Sensor-Abbrüche oder unregelmäßige Aktualisierungen direkt am Entstehungspunkt abfangen.

---

BREAKING CHANGE!

Aufgrund der neuen Logik ist dieses Update eine sogenannte Breaking Change.

• Nach dem Update müssen die Gruppen-Sensoren neu angelegt werden.
• Um das zu vereinfachen, gibt es ein neues Eingabefenster mit Dropdown-Auswahl.
• Beim folgenden EOD (End of Day) werden die Gruppen automatisch migriert.

Hinweis: Bei dieser Version handelt es sich um einen Release Candidate (RC1). Das bedeutet, dass trotz intensiver Tests noch Fehler auftreten können, die ich übersehen habe.

---

Weitere Änderungen

Der Code verlässt sich nun nicht mehr auf die internen Home Assistant Threads, sondern nutzt einen eigenen Thread-Manager. Damit sollten Blockaden während des EOD der Vergangenheit angehören.

Durch den " Weggang" von Home Assisatnt kommt die Wahrheit nun direkt aus dem Code. Das bedeutet auch, dass es nun einzelne SQL-Sensoren gibt, die direkt auf die DB zeigen und die Wahrheit anzeigen.

Das hat den Vorteil, dass ich STATS entschlacken konnte, es müssen keine Panelgruppen Sensoren mehr angelegt werden. Die kommen nun automatisch von SFML STATS.

• STATUS: Im Test
• Release: Morgen im Laufe des Tages

[Tom-HA]

Version 32.0.0 SOT – Wichtige Hinweise bitte zwingend lesen!

Ein riesiges Dankeschön geht an die Beta-Tester hier im Forum und rund um die Welt – ohne euren unermüdlichen Einsatz wäre dieser Meilenstein schlicht unmöglich gewesen. Danke euch!

Warum dieser massive Umbau?

Aufgrund von Instabilitäten der internen Home Assistant Riemann-Sensoren (kWh-Berechnungen) kam es zuletzt leider zu Abweichungen bei der Gesamt-IST-Berechnung. Mein Code hat diese fehlerhaften Werte aus Home Assistant aus GIGO-Gründen (Garbage In, Garbage Out) völlig zu Recht verworfen. Auch zahlreiche BUGs von Home Assistant in der Vergangenheit und vermutlich auch Zukunft haben mir Kopfschmerzen gemacht. Die Tester wissen sehr genau wovon ich spreche

Um das Projekt komplett unabhängig von HA-Fehlern zu machen und die Integration radikal zu stabilisieren, habe ich einen harten Schnitt gemacht: Sämtliche kritischen Berechnungen sind ab sofort vollständig von Home Assistant entkoppelt. Bugs in HA schlagen damit nicht mehr auf SFML, STATS oder GPM durch! SFML ist ließt nur noch!

---

Wichtige technische Änderungen (Die neue Architektur)

• SFML ist jetzt die Source of Truth (SOT): Solar Forecast ist der Chef im Ring, der Hubble AI-Stack das zentrale Herz.
• Datenbank-Entkopplung: Die andockenden Apps (Solar Forecast Stats, Grid Price Monitor, TFS HA) habe ich weitestgehend vom Home Assistant Recorder und der HA-Datenbank entkoppelt. SFML verwaltet seine eigene DB und hat als SOT das exklusive Schreib- und Änderungsrecht. Jede Änderung (z. B. von STATS, Sensoren,..) wird von Hubble auf Validität geprüft, bevor sie in die DB wandert.
• Performance-Schub ohne HA-Bremse: Berechnungen laufen im Handumdrehen. Kein Lag mehr durch Home Assistant, kein Einfrieren beim EOD, keine heißgelaufenen Prozessoren! SFML dirigiert die Prozesse nun über einen eigenen Thread-Manager, um die Single-Thread-Bremse im Event-Loop von HA clever zu umgehen – vollkommen hardware- und ressourcenschonend.

---

Was ändert sich nach dem Update?

1. Drastisch vereinfachte Konfiguration

Durch den Architektur-Wechsel fällt tonnenweise Konfigurationsaufwand weg. Es sind für die Solaranlage keine Energiesensoren mehr notwendig, die sich täglich zurücksetzen.
Nach dem Update musst du nur noch die POWER-SENSOREN (W) deiner einzelnen Strings eintragen – das ist alles! Keine Helfer mehr, kein Gebastel, keine Summensensoren. SFML berechnet Power und Energie hocheffizient selbst.

2. Neue, hochpräzise SOT-Sensoren

Weil der Code die Power-Sensoren direkt abfragt und selbst rechnet, gibt es keine Rundungs- oder Intervallfehler mehr (inklusive automatischer Fehlerkorrektur bei Sensorausfällen oder Neustarts). Die neuen SOT-Sensoren sitzen direkt auf der SFML-DB (losgelöst vom HA-Recorder, spiegeln ihre Werte aber natürlich trotzdem in HA), perfekt für Automationen:

• Gruppen- / String-Sensoren: Jeder String erhält einen eigenen, extrem genauen Energie- (kWh) und Power-Sensor (W).
• Gesamtsensoren: Ein Gesamtenergie- und Gesamtpower-Sensor, die penibel auf Genauigkeit überwacht werden. Genauer geht es nicht!

---

Neue Funktionen direkt aus dem Code

SurPlus-Sensor (Überschuss)

STATS stellt einen neuen Binär-Sensor zur Verfügung. Er schaltet auf „an“, sobald Netzeinspeisung stattfindet und die Solarleistung (SOT) größer als der aktuelle Hausbedarf ist. Perfekt, um per Automation Eigenverbraucher wie Heizstäbe oder E-Autos zu steuern. Eine integrierte Hysterese verhindert wildes Hin- und Herschalten.

Smart Charge

STATS bekommt vom Hubble AI-Stack alle notwendigen Informationen, um Akkus intelligent zu laden. Das ist nicht einfach nur Überschussladen, wie man es von einer simplen Automation kennt! Hubble kennt den Solar-Ertrag des kommenden Tages, die Brutto-Strompreise und schaltet intelligent die Netzladung eines Akkus. So ist sichergestellt, dass zu Hochpreiszeiten der Akku oder die Solaranlage die Energie bereitstellen. Dabei betrachtet Hubble auch Wochentage sowie Wochenendtage und berechnet den typischen Verbrauch, um das Optimum aus dynamischen Strompreisen herauszuholen. Selbst die Lade- und Entladeverluste werden einbezogen: Hubble entscheidet dynamisch, ob es gerade nicht besser ist, den günstigen/kostenlosen Netzstrom direkt zu nutzen und Solar exklusiv für den aktuellen Hausbedarf vorzuhalten.

Damit nicht genug! Hubble zeigt dir schwarz auf weiß, ob sich ein Akku lohnt, ob sich eine Vergrößerung auszahlt und wie hoch die Ersparnis wirklich ist. Das macht er nicht einfach durch statische Berechnungen, sondern er schaut ganz genau hin:

• Wann habe ich Strom gekauft und zu welchem Preis?
• Wann habe ich Solarenergie aus dem Akku genommen und wie hoch war der Strompreis zu diesem Zeitpunkt?
• Wann habe ich Akku-Energie genutzt und wie hoch war zu dem Zeitpunkt der Strompreis?
• Wie wird das Wetter die nächsten Tage? Macht es Sinn, Strom im Akku vorzuhalten (z. B. für Wärmepumpen)?

Der maximale und minimale SOC wird dabei völlig dynamisch berechnet und danach zu bestimmten, frei eingebbaren Brutto-Preisen nachgeladen.

Kurzum: Hubble sieht einen Akku nicht als simplen Solarspeicher, sondern als aktives Bauteil in der Energieinfrastruktur und versucht, in Verbindung mit dynamischen Strompreisen das absolute Maximum für dich herauszuholen.

Diagnose-Sensoren 2.0

Die alten Diagnosesensoren sind zurück – aber in einer Version, die nicht mehr mühsam selbst interpretiert werden muss. Hubble bereitet die Daten visuell auf und zeigt immer genau, was er als Herz der Integration gerade tut (z. B. wenn der EOD läuft).

Gridpreis Monitor (GPM) kann nun zeitbasierte Tarife!

Ein großer Community-Wunsch, der mich erreichte, ist umgesetzt: GPM kann jetzt mit zeitbasierten Stromtarifen (z. B. Nachtstrom) umgehen. Er arbeitet nahtlos mit Smart-Charge zusammen, liefert einen eigenen Binär-Sensor sowie Preissensoren. Damit wird das Erstellen von Spar-Automationen zum Kinderspiel.

STATS Lovelace-Karten fürs Dashboard

Schluss mit YAML- und Code-Basteleien! STATS bringt ab sofort zwei (BETA) Dashboard-Karten mit, die die wichtigsten SOT-Informationen out-of-the-box anzeigen.

---

Weitere Änderungen im Überblick

• TZINFO wird nun direkt im eigenen Code geregelt
• Validierungsprüfung für Weights hinzugefügt
• EOD-Thread und Prognose-Berechnung komplett außerhalb des HA-Hauptthreads ausgelagert
• Optimierungen am Energie-Dashboard & Wetter-Anzeige gefixt
• Neue ICON2- und ECMWF-Gewichtungslogik in der KI
• Protokolle aufgeräumt & KI spürbar beschleunigt
• Hubble & Core-Skripte aktualisiert
• DB-Locking Calls vollständig eliminiert
• STATS von DB entkoppelt
• … und vieles mehr!

---

Credits

• Ein riesiges Lob an die tapferen User im Beta-Test-Forum und im Update-Thread!
• Danke an die beiden Jungs (mittlerweile echte Freunde), die meinen Frust und mein Gemecker während der Entwicklung ertragen und von Tag eins an dieses Projekt geglaubt haben.
• Danke an die vielen helfenden Hände beim Testen rund um den Globus!

und nicht zuletzt an meine Familie, die wirklich vieeeel mitmacht!

**Bitte gebt den Usern im Beta-Test Thread ein Herz.. einfach mal vorbeischauen, sie tragen maßgeblich dazu bei das es hier weitergeht! Auch die Zahlreichen Helfer die supporten und unterstützen verdienen ein Herz wenn sie euch helfen **

Beta -Thread : SFML + STATS v32

Hier siehts soweit auch unspektakulär aus. Mal schauen was passiert, wenn die Sonne kommt.

**Mein Kaffe ist leer… **

BITTE. NICHT VERGESSEN NACH DEM UPDAT E IN SFML DIE PANELGRUPPEN SENSOREN EINZUGEBEN (WATT)

STATUS: Pentration und Sicherheitstest
RELASE-DATUM: Heute im Laufe des Tages

[Tom-HA]

Info: SFML Update V32.0.2

Dieses Update adressiert die Datenintegrität bei der Physics-Kalibrierung (sie BUG-Thread) und führt ein neues Werkzeug zur Quarantänisierung von fehlerhaften Datenräumen bei Anlagenausfällen ein. siehe Post / Vorschlag von @dietmar1968

1. Physics-Kalibrierung & Automatisierte Datenbereinigung

Die Logik des Physics-Learnings wurde optimiert, um eine Verfälschung der Kalibrierungsfaktoren durch spezifische Betriebszustände zu verhindern.

• Filterung der Lernbasis:
  Ausgeschlossene Stunden, MPPT-gedrosselte Werte und ausgeschlossene Panel-Gruppen fließen ab dieser Version nicht mehr in die Kalibrierung ein.

• One-Time-Migration:
  Das Update enthält eine einmalige, automatische Migrationsroutine für bestehende Installationen.

• Fehlerhafte Gruppenflags werden automatisch korrigiert.

• Kontaminierte Physics-Kalibrierungsartefakte werden aus der Datenbank entfernt.

• Automatischer Rebuild: Nach dem ersten Systemstart unter V32.0.2 wird ein einmaliger Rebuild der Physics-Faktoren auf Basis der bereinigten Historie ausgelöst.

• Fallback-Verhalten: Sollte nach der Bereinigung keine ausreichende Historie mehr zur Verfügung stehen, startet die Physics-Kalibrierung sauber mit den Standard-Default-Faktoren und beginnt ab dem nächsten Tagesabschluss neu zu lernen.

2. Neuer Emergency Service: emergency_outage_quarantine

Zur Absicherung gegen akute Anlagen-, Sensor- oder Wechselrichterausfälle wurde ein neuer Notfalldienst integriert. Ziel des Services ist es, fehlerhafte Zeiträume gezielt zu isolieren, damit die Integration in Ausfallphasen keine falschen Ist-Werte oder Nullwerte lernt. → die Daten werden NICHT gelöscht sondern nur isoliert!

Der Service ist explizit als Notfall-Werkzeug gekennzeichnet und kann auch nachträglich für bereits in der Vergangenheit liegende Zeiträume aufgerufen werden. Wir im entsprechenden Post erklärt, DARF dieser Service nur unter sehr speziellen und abgegrenzten Bedingungen eingesetzt werden, da er MASSIV in die DB und AI eingreift. →

Ich bitte dringend darum ihn nur nach Absprache zu nutzen, niemals damit eigenmächtig zu testen / spielen. Es besteht die Gefahr eure gesamte AI zu zerstören und das unwiderruflich! Auch kann eine falsche Bedienung die HA Recorder Datenbank negativ beeinflussen!!

Funktionsumfang des Services:

• Zeitraumdefinition:
• Markierung frei wählbarer Zeiträume (einzelne Stunden oder komplette Tage) als Anlagen-/Sensor-Ausfall.
• Lernstopp:
• Temporäre Aussetzung der Lernlogik für die betroffene Phase.
• Evaluationsschutz:
• Ausschluss des Zeitraums von der Clean-Evaluation.
• Backfill-Sperre:
• Blockierung von nachträglichen Datenimporten für diese Spanne.
• Datenbehandlung:
• Wahlweises Belassen der vorhandenen Daten oder gezieltes Entfernen von ungültigen Null- und Fehlerwerten.
• Artefakt-Invalidierung:
• Optionale Ungültigerklärung betroffener Lernartefakte mit anschließendem, optionalem Retraining.
• Sicherheitsfunktionen:
• Integration eines Dry-Runs zur Vorab-Prüfung der betroffenen Datensätze sowie eine optionale, automatische Datenbank-Backup-Funktion bei Live-Ausführung.
• Auditierung:
• Jede Ausführung wird revisionssicher und auditierbar protokolliert.

Kernschutz & Wirkungsbereiche

Der primäre Schutzmechanismus verhindert für quarantänisierte Zeiträume jeglichen Backfill. Dies unterbindet den nachträglichen Import von Null- oder Fehlerwerten bei physischen Defekten oder Sensorstörungen.

Der Schutz greift tiefgreifend in folgenden Systembereichen:

• Reguläre Lernlogik & Panel-Group-Learning
• Clean-Evaluation & Performance-/Drift-Auswertungen
• Repair- und Korrekturservices
• Tagesabschluss-Hygiene
• Shadow- und Backfill-Mechanismen

---

Status:

Aktuell “Blindflug” da ich keine Option zum Testen habe… Code und Datenbank-Operationen funktionieren, aber Live-Test steht aus

[Tom-HA]

UPDATE V32.0.4 SFML + STATS

Hier sind die Details zu den Änderungen:

1. Physics-Kalibrierung & automatische Datenbereinigung

Ich habe die Datenbasis für die Kalibrierung repariert, damit die AI nicht mehr durch blockierte oder gedrosselte Werte verfälscht wird.

• Saubere Lernbasis: Ausgeschlossene Stunden, MPPT-gedrosselte Werte und deaktivierte Panel-Gruppen fließen ab jetzt nicht mehr in die Kalibrierung ein.
• Einmalige Migration: Beim ersten Start unter V32.0.4 stösst das System eine automatische Bereinigung der Datenbank an. Fehlerhafte Gruppen-Flags werden korrigiert und kontaminierte Kalibrierungs-Überbleibsel gelöscht.
• Automatischer Rebuild: Nach dem Bereinigen baut das System die Physics-Faktoren einmalig auf Basis der korrigierten, sauberen Historie neu auf.
• Fallback-Schutz: Sollten nach dem Aufräumen nicht mehr genug historische Daten übrig sein, startet die Physics-Kalibrierung sicher mit den Standard-Defaults und lernt ab dem nächsten Tagesabschluss neu.

2. Neuer Notfall-Dienst: emergency_outage_quarantine

Um das System bei akuten Ausfällen von Wechselrichter, Anlage oder Sensoren abzusichern, habe ich einen Quarantäne-Service integriert. Damit könnt ihr fehlerhafte Zeiträume gezielt isolieren, damit die AI in dieser Phase keine falschen Ist- oder Nullwerte lernt. Die Daten werden dabei nicht gelöscht, sondern nur ausgeklammert.

WICHTIG (NUR AUF ANWEISUNG): Bitte spielt oder testet damit nicht eigenmächtig herum! Bei falscher Anwendung könnt ihr euch die komplette AI-Datenbasis unwiderruflich zerschießen oder den Home Assistant Recorder belasten. Nutzt den Service bitte nur in Absprache oder wenn ihr genau wisst, was ihr tut.

• Zeitraum wählen: Markiert flexibel einzelne Stunden oder ganze Tage als Ausfallzeit.
• Lernstopp & Schutz: Die Lernlogik pausiert für diesen Zeitraum. Die Daten fließen nicht in die Clean-Evaluation oder den Backfill.
• Daten-Optionen: Ihr könnt wählen, ob vorhandene Daten stehen bleiben oder ungültige Nullwerte gezielt entfernt werden sollen.
• Sicherheit eingebaut: Es gibt einen Dry-Run zur Vorab-Prüfung sowie eine Option für ein automatisches DB-Backup vor der Live-Ausführung. Jedes Ausführen wird sauber im Log protokolliert.

3. Stabilitäts- und Integritätsfixes

An diesen Stellen habe ich nachgebessert, um vor allem Datenbank-Locks und Probleme beim Tageswechsel zu verhindern:

• Tagespeak-Reset: Der Sensor für den maximalen Peak von heute setzt sich jetzt absolut zuverlässig um Mitternacht zurück (zentral über den Production-Time-Tracker und doppelt abgesichert per Midnight-Scheduler).
• Keine verschachtelten Transaktionen: Die Transaktionsverwaltung für SQLite wurde gehärtet. Der Fehler cannot start a transaction within a transaction beim Update des SFML-Live-Ist-Zustands ist behoben.
• Legacy-Pfad entschärft: Der primäre Stunden-Writer bleibt die Morning-Routine.
• STATS-Datenbank-Locks: Die Schreibpfade von STATS laufen jetzt serialisiert mit Retries über den zentralen Connection-Manager. Kurzzeitige SQLite-Locks erzeugen keine unnötigen Fehlermeldungen mehr in euren Logs.

4. Hybrid-Forecast

Der Hybrid-Forecast wurde logisch aufgeräumt und gegen parallele Ausführungen abgesichert.

• Service-Klarstellung: Die gewünschten Forecast-Zeitpunkte wurden nun restart-fest. Das Aktivieren löst keinen sofortigen manuellen Forecast mehr aus.
• Neuer Status-Sensor: Schluss mit der Blackbox. Der neue Sensor Hybrid Forecast Status zeigt euch genau an, ob der Modus aktiv ist, welche Zeiten geplant sind und wann der letzte bzw. nächste Lauf stattfindet.
• Future-only & Parallelitätsschutz: Der Hybrid-Forecast verändert niemals bereits vergangene Stunden (hier gab es zuvor instabiles Verhalten). Zudem blockieren sich parallele Läufe jetzt gegenseitig, um konkurrierende Schreibvorgänge auf der Datenbank zu verhindern.

5. STATS-Zeitlogik & lokale Forecast-Sicherheit

• Lokale Zeit als Wahrheit: STATS rechnet Forecasts, Tageswechsel, Graphen und Auswertungen jetzt konsequent in der Home-Assistant-Zeitzone. Browser-, Mac- oder Kunden-Lokalzeit können die Prognosen nicht mehr verschieben.
• Sauberer Tageswechsel: Heute, morgen und historische Tageswerte werden sauber aus der HA-Local-Time abgeleitet. Dadurch werden keine Vortagsdaten mehr fälschlicherweise angezeigt.
• Forecast- und Hybrid-Abgrenzung: Die Tagesprognose bleibt die volle Tagesprognose. Die Hybrid-Prognose wird separat als operative Reforecast-/OPS-Sicht behandelt und nicht mehr still mit der statischen Tageskurve vermischt.

6. Tagesprognose vs. IST: Saubere Prognosegüte

• Bewertete Stunden statt ganzer Tag: Die heutige Prognosegüte wird jetzt nur noch aus den bereits abgeschlossenen und verwertbaren Stunden berechnet. Zukünftige Stunden und die aktuell laufende Teilstunde ziehen den Wert nicht mehr künstlich nach unten.
• Verworfene Stunden bleiben draußen: Technisch verworfene Stunden, MPPT-/Clipping-Ausschlüsse und harte Exclusions werden nicht in die Clean-Evaluation gerechnet.
• Live-Abweichung bleibt separat: Die volle Tagesabweichung bleibt sichtbar, wird aber nicht mehr mit der eigentlichen Prognosegüte verwechselt.
• Chart-Fix: Fehlende IST-Werte werden im Tageschart nicht mehr als 0 gezeichnet. Dadurch fällt die grüne IST-Linie nicht mehr künstlich auf Null ab.

7. Panel-Gruppen & Home-Dashboard

• Bessere Panelgruppen-Darstellung: Die Panelgruppen-Kacheln brechen jetzt sauber um. Bei vier Gruppen wird eine übersichtliche 2x2-Ansicht genutzt, statt alles in eine zu enge Zeile zu quetschen. Keine überlaufenden Texte mehr bei Legenden, Prognosewerten und Gruppenlabels.
• Zusätzliche Statuswerte im Energiefluss: Im Home-Energiefluss wurden neue kompakte Statuspunkte ergänzt:
  • W-Stability: Wetter-/Bewölkungsstabilität aus SFML.
  • P-Time: Heutige Produktionszeit aus SFML.
  • SMC: Zeigt an, ob Smart-Charging aktiv ist.
  • S-Plus: Zeigt an, ob aktuell PV-Überschuss verfügbar ist.

8. Smart-Charge Sicherheitslogik

• Fail-Closed bei fehlendem SOC: Wenn kein gültiger Akku-SOC verfügbar ist, schaltet Smart-Charge nicht mehr gutgläubig weiter. Das System blockiert sicher, statt blind eine Netzladung zu erlauben.
• Sicheres Abschalten: Wenn Smart-Charge dynamisch deaktiviert wird, wird der konfigurierte Ladeschalter jetzt aktiv auf off gesetzt, bevor der Manager entfernt wird.
• Preislogik korrigiert: 0.0 ct/kWh wird jetzt korrekt als gültiger Preis behandelt und nicht mehr als fehlender Preis interpretiert.
• Bessere Ziel-SOC-Hysterese: Niedrige Ziel-SOC-Werte werden sauberer verfolgt. Das verhindert unnötiges Überladen bei kleinen Zielbereichen.
• Ladeempfehlungen sichtbar: Das Smart-Charge-Dashboard zeigt zukünftige empfohlene Ladefenster jetzt getrennt von tatsächlich gemessener Netzladung.

9. Smart-Charge Netzladeenergie

• Netzladung wird robuster erkannt: Die geladene Energie aus dem Netz in den Akku wird jetzt nicht mehr nur aus dem stündlichen Power-Pfad abgeleitet.
• Recorder-Fix: Die Integration von Watt-Werten aus dem Home-Assistant-Recorder wurde korrigiert. Plateaus und der letzte Zustand bis zum Stundenende werden jetzt sauber berücksichtigt.
• Tageszähler als Fallback: Wenn der stündliche Pfad leer oder offensichtlich zu niedrig ist, gleicht Smart-Charge gegen den Tages-kWh-Sensor für Netzaufladung ab.
• Keine verschuckte Netzladung mehr: Wenn der Tageszähler Netzladung erkannt hat, Smart-Charge aber im Stundenpfad 0.0 kWh sieht, wird dieser Wert jetzt über den Fallback abgesichert.
• Diagnosewert: Die API liefert zusätzlich daily_fallback_kwh, damit nachvollziehbar ist, wie viel Energie über den Tageszähler gerettet wurde.

10. Sure-Plus Steuerung

• Universelle Verbraucher-Schaltung: Ich habe die Logik in der Tiefe verbessert. Neben Heizstäben lassen sich nun auch alle anderen Arten von Verbrauchern absolut zuverlässig und automatisiert über das System schalten.

Spenden für Kaffee sind wilkommen

Release: Online via HACS

[Tom-HA]

UPDATE für Home Assistant OS 18.1 & HA 2026.7

Das fehlerhafte HA OS 18.0 Update wurde für bestimmte Systeme (u. a. Raspberry Pi / ARM) zurückgezogen / als unstable markiert und durch HA OS 18.1 ersetzt– das erforderte auch meinerseits ein paar schnelle Anpassungen.

Änderungen in SFML

• Anpassungen an HA 2026.7
• Anpassungen Config-Flow auf V2
• Anpassungen auf OS 18.1

Das ist neu in STATS:

• Fehlerbehebungen: Diverse Anpassungen und Korrekturen im Hintergrund.
• Preisanpassung: Preise können ab jetzt individuell angepasst werden.
• Energiedashboard: Umstellung auf eine völlig neue Berechnungslogik.

Hinzugekommen ist nun auch, wie oft angefragt die Tagesübersicht für Akkus, sofern sie korrekt konfiguriert sind.

Release: so schnell es geht um Probleme zu vermeiden!

ACHTUG: HA Update 2026.7 bricht SMTP! ist nun an anderer Stelle aufgehängt

[Tom-HA]

Release v32.1.0

Dieses Update unterstützt das heute erschienene Home Assistant (HA) Release 2026.7.1 sowie ältere HA-Versionen.

Solar Forecast ML

Fehlerbehebungen

• Fehler im P10-Sensor behoben.
• Berechnung des P10-Sensors verbessert.
• Fehler in der MDC (Midday Correction) behoben.

STATS

Verbesserungen

• Verschiedene UI-Verbesserungen.
• P10-Kurve zu den Diagrammen hinzugefügt.
• Den Hybrid-Sensor auf dem Dashboard durch den P10-Sensor ersetzt.

Sonstiges

• Weitere kleinere Optimierungen und Fehlerbehebungen

Würde mich über einen Kaffee freuen!

Release: Online via HACS

[Tom-HA]

V32.1.2 P10 Fix

Verbesserungen am P10-Sensor

Einige Nutzer berichteten, dass der P10-Sensor unter bestimmten Umständen nicht korrekt aktualisiert wurde und stattdessen einen veralteten Wert beibehielt.

Dieses Update behebt die Ursache grundlegend:

• Die Berechnung und Speicherung des P10-Wertes wurden vollständig von Home Assistant entkoppelt.
• Die SFML-Datenbank ist nun die primäre Lese- und Schreibquelle für den P10-Wert.
• Der Home Assistant Recorder dient nur noch als sekundäre Speicherung (Backup).
• Es wurde ein Schutzmechanismus implementiert, der verhindert, dass der P10-Wert bei Problemen oder Verzögerungen in Home Assistant unbeabsichtigt überschrieben / nicht aktualisiert wird.

Der P10-Sensor liefert damit wieder zuverlässig die untere Quantile der Prognose und stellt eine konservative, garantierte Mindestprognose der zu erwartenden PV-Erzeugung bereit.

Release: im Laufe des Tages

[Tom-HA]

Update Release: Version 32.2.0

Dieses Update bringt wichtige Stabilitätsfixes für SFML sowie ein großes Feature-Paket für den STATS-Bereich, das deine Energie- und Finanzübersicht noch smarter und flexibler macht.

---

SFML (System & Community)

• Gruppeneingabe korrigiert:
• Ein Fehler bei der Verarbeitung von Gruppeneingaben wurde behoben.
• Community-Fixes:
• Verschiedene Optimierungen und Fehlerbehebungen direkt aus dem Feedback der Community integriert.

---

STATS (Energie- & Finanzübersicht)

Dieses Update bringt tiefere Einblicke und smarte Funktionen, um deinen Verbrauch und deine Finanzen noch besser zu verstehen.

Was ist neu?

• Historischer Blick:
• Du kannst Tagesgraphen nun einen Tag zurückblättern. Perfekt, um Werte vom Vortag zu prüfen, selbst wenn die Anzeige nachts automatisch zurückgesetzt wurde.
• KI-gestützte Amortisationsanzeige:
• Sieht voraus, wann sich deine Anlage voraussichtlich bezahlt macht. Die Anzeige visualisiert die Entwicklung von Ersparnis, Investition und laufenden Kosten.
• Der Verbrauchsatlas:
• Behalte den Überblick, wo im Haus der Strom fließt. Du kannst eigene Verbraucher wie TV, Kühlschrank, Internet, Shelly-Geräte oder andere Watt-Sensoren flexibel hinzufügen.
• Startwerte für Geräte:
• Für Verbraucher im Verbrauchsatlas kann jetzt ein Startwert in kWh eingetragen werden. Ideal für Geräte, die schon länger laufen und nicht bei null anfangen sollen.
• Optimierter CSV-Export:
• Die Export-Funktion wurde komplett überarbeitet und ist nun deutlich übersichtlicher strukturiert.

Verbesserungen & Optimierungen

• Smarteres Laden: *
• Smart Charging* berücksichtigt externe Strompreise jetzt absolut korrekt. Liegt der echte Gesamtpreis über deiner eingestellten Grenze, wird der Ladevorgang zuverlässig gestoppt.
• Präzisere Abrechnung:
• Die Karte „Laufende Stromkosten pro Monat“ startet ab sofort exakt passend zu deinem individuell eingestellten Abrechnungszeitraum.
• Design-Feinschliff:
• Die Energie- und Finanzseite wurde funktionell erweitert, bleibt durch ein cleanes Layout aber weiterhin auf die wichtigsten Kerninformationen fokussiert.

Verbrauchsatlas für den Abrechnungszeitraum incl Eingabe eines Startwertes.

CSV-Export von Kerndaten:

Anlagen Amortisation incl KI

Vortag ansehen:

Release: Heute Abend

HINWEIS ich bin ab Morgen unterwegs. Erst am Sonntag können Bugs gefixt werden!

[Tom-HA]

SFML Revisions-Update V32.2.2

Nach dem immer mehr Nutzer SFML erfolgreich nutzen, die Grundstruktur funktioniert, die Ergebnisse meine kühnsten Erwartungen immer wieder übertreffen - habe ich mir überlegt eine Revesionschicht einzubauen, um gezielter restliche Probleme und auch Funktionen zu überprüfen ohne immer wieder dem kompletten Code anzufassen.

Auf die Idee bin ich durch dein Beitrag von @Joachim-xo gekommen. Es ist also kein Funktionsupdate sondern ein reines Revisions-Update, das eine “Prüfschicht” für Entwickler und AI-Coder hinzufügt.

Geändert wurde nicht die Prognoselogik, sondern die technische Infrastruktur, mit der ich künftig einfacher prüfen kann, ob Hubble in bestimmten Situationen schlechter als die reine Physik arbeitet.

Gab ein Problem.. ?

JaEin eine Analyse hatte gezeigt:

• Der Standard-Forecast ist insgesamt besser als die reine Physik. Das ist sehr sehr gut und gewünscht
• In bestimmten Stunden, besonders bei niedriger Sonnenhöhe und geringer Leistung, verschlechtert das Ensemble leider die Physik → viel weniger als noch vor Monaten!
• Ein möglicher Safe-Guard habe ich geprüft, war aber statistisch noch nicht stabil genug um ihn endgültig einzuführen. Eine saubere prospektive Prüfung dieses neuen Safe-Guards war nicht möglich, weil die dafür notwendigen Daten nicht revisionssicher gespeichert wurden. Bisher gab es dafür keinen Grund.

Es fehlten insbesondere:

• ein unveränderlicher Morning-Forecast-Batch,
• eine persistierte Shadow-Entscheidung,
• eine versionierte Bewertung bei später korrigierten Istwerten,
• eine sichere Wiederaufnahme nach Neustarts,
• eine saubere Trennung zwischen produktivem Forecast und hypothetischem Shadow-Forecast.

Was wurde geändert?

1. Neue rein beobachtende Shadow-Evaluation.

Es gibt einen “nur lesen” Code der mir zeigt was wäre die Auswirkung gewesen.
Für jede Standard-Morning-Prognose wird jetzt zusätzlich gespeichert:

• finale Ensemble-Prognose,
• reine Physikprognose,
• Sonnenhöhe,
• TFS-Wert und TFS-Gewichtung,
• ob die eingefrorene Shadow-Regel ausgelöst hätte,
• welcher hypothetische Wert dann verwendet worden wäre.

Die Regel lautet unverändert:

sun_elevation_deg <= 27.67
AND
tfs_weight >= 0.38

Löst sie aus, wird nur hypothetisch angenommen:

shadow_prediction = physics_kwh

Der produktive Wert bleibt immer:

prediction_kwh

2. Persistente Morning-Batches

Jeder Morning-Forecast-Lauf erhält eine UUID als morning_batch_id.

Zusätzlich gibt es eine Batch-Verwaltung mit:

• running
• completed
• failed

Ein unterbrochener laufender Batch kann nach einem Neustart wiederverwendet werden. Ein abgeschlossener neuer Lauf erhält dagegen eine neue UUID.

3. Neue revisionssichere Tabellen

Für die Reversionsschicht habe ich separate Tabellen eingeführt:

• ensemble_shadow_batches
• ensemble_shadow_evaluations
• ensemble_shadow_evaluation_versions

Dabei enthält die Evaluation den unveränderlichen Morning-Snapshot. Spätere Istwertbewertungen werden versioniert gespeichert. → so kann ich besser vergleichen und Fehler finden.

4. Append-only und Versionierung

Forecast-Snapshots und Evaluationsergebnisse, dürfen dabei nicht überschrieben oder gelöscht werden, sonst sind sie wertlos.

Wird ein Istwert später repariert oder geändert:

• bleibt die erste Bewertung erhalten,
• es wird eine neue Evaluationsversion angelegt,
• die Änderung bleibt vollständig nachvollziehbar.

Identische Wiederholungen erzeugen keine unnötigen Duplikate.

5. Zentrale Clean-Evaluation / Reversionshandling

Die Shadow-Auswertung verwendet nun dieselbe zentrale Stundenklassifikation wie die bestehende Genauigkeitsauswertung.

Dadurch werden beispielsweise korrekt ausgeschlossen:

• Zero Export,
• Batterie- oder Exportbegrenzung,
• Curtailment,
• MPPT-Begrenzungsgründe,
• Backfills,
• manuelle Reparaturen,
• ungültige oder fehlende Istwerte.

Hier lag ein missing-link den ich beim Umbau auf “Code-only” schlicht vergessen habe und der die Beobachtungen von @suedschwede und @Joachim-xo z.T. erklären

6. Sichere Zielstunden-Zuordnung

Zielstunden werden über nun einen kanonischen UTC-Epoch-Wert identifiziert.

Dadurch kann innerhalb eines Batches dieselbe Zielstunde nicht (mehr) mehrfach gespeichert werden, selbst wenn unterschiedliche Source-IDs oder Zeitformatierungen verwendet werden. Ich hoffe mit diesem Ansatz alle möglichen Zeitzonen besser abzudecken.

7. Ungültige Istwerte werden abgefangen

Werte wie:

• None
• unknown
• NaN
• Infinity
• negative Erträge

brechen die Auswertung nicht mehr ab. Sie werden ausdrücklich als nicht evaluierbar gespeichert. Dadurch kann ich sie besser identifizieren und finden.

8. Build und Migration

Das neue Reversions-Modul wurde in den Build aufgenommen.

Zuvor fehlte data_ensemble_shadow.py im Build-Artefakt, obwohl die Morning Routine es importierte. Das hätte ohne die Anpassung nach einem Deploy einen ModuleNotFoundError verursachen können.

Die Migration wurde außerdem mit:

• SQLite-Savepoint,
• Schema-Prüfung,
• hartem Fehler bei inkompatiblen Tabellen

abgesichert. So vermeide ich die Fehler aus der Vergangenheit und ich habe noch einmal async genau kontrolliert - ich habe immer noch Alpträume - @Op3ra7or262 wird sich bestimmt noch genau daran erinnern read/write Probleme - sollten wir uns jemals persönlich begegnen spendiere ich Dir ein Bier.. ich habe es nicht vergessen!

9. Kritischer Fehler in der Morning Routine

Ein Fehler wurde behoben:

Ein Fehler beim Schreiben der Shadow-Daten konnte die produktive Morning-Routine abbrechen. Das ist aktuell nur theoretisch passiert, nie im realen Leben.

Jetzt werden Shadow-Schreibfehler isoliert behandelt. Die produktive Forecast-Persistierung läuft weiter.

Zusätzlich wurden die vorherigen Infrastrukturfehler behoben:

• fehlendes Build-Modul,
• unsichere Teilmigration,
• instabile Batch-Identität nach Neustart,
• dauerhaft eingefrorene Bewertung eines später reparierten Istwerts,
• doppelte Clean-Logik,
• unzureichende Zielstunden-Eindeutigkeit.

Was ändert sich?

Nach dem Update beginnt ab dem nächsten Morning-Forecast eine neue, revisionssichere Shadow-Historie.

Das System wird dann für jede geeignete Stunde beantworten können:

• Was prognostizierte das Ensemble?
• Was prognostizierte die reine Physik?
• Hätte die eingefrorene Regel auf Physik zurückgeschaltet?
• Welche Variante war im Nachhinein genauer?
• Wie viel Fehler hätte der hypothetische Guard vermieden?
• Wie viel legitime Ensemble-Verbesserung hätte er zerstört?

Über einen ausreichend langen Zeitraum lässt sich damit belastbar entscheiden, ob der angedachten Safe Guard:

• sinnvoll ist,
• angepasst werden muss,
• oder ich meinem Motto treu bleibe “verworfener Code ist machen mal der bester Code”

Unverändert bleiben:

• Standard-Forecast,
• Ensemblelogik,
• Physikmodell,
• P10,
• Reforecast,
• Adaptive Correction,
• Tagesprognosen und Sensorwerte.

Fazit:
Das Update schafft zunächst nur die Datengrundlage für eine spätere Entscheidung.

STATS:

Es wurden einige Darstellungsfehler für mobile Endgeräte korrigiert und Hubble hat nun die Möglichkeit zu “zeigen” wie der heutige Tag lief..

[Tom-HA]

Großes Major Update Solar Forecast ML und Solar Forecast STATS V32.2.4

Hallo zusammen,

ein paar Worte vorneweg: Dieses Update bringt ein paar Breaking Changes mit sich. Grundsätzlich führt dieses Update weitere Funktionen in STATS hinzu und bringt entsprechende Anpassungen in SFML.

---

Autarkieberechnug

Wer die Diskussionen zu diesem Themenkomplex in den vergangenen Monaten verfolgt hat, der weiß, dass ich kein Freund der meisten Berechnungen bin. Sie sind mathematisch schlicht falsch.

Eine Autarkie nur anhand des Vergleiches von Einspeisung und Bedarf zu berechnen, ist grundlegend falsch. So wird der Eigenverbrauch der Anlage komplett unterschlagen. Der Eigenverbrauch sind ebenfalls Kosten – und zwar “Betriebskosten”.
Daher zeigt STATS ab sofort sowohl die “echte” Autarkie als auch die Netzautarkie an.

Effizienzberechnung

Effizienz ist nicht trivial und auch nicht einfach zu berechnen. An dieser Stelle kommen zahlreiche Faktoren zusammen:

• Umwandlungsverluste von DC / AC
• Speicherverluste
• Netzladung AC/DC
• Standbyverbrauch
• Lastabhängige Wechselrichterkurven (im Teillastbereich ist ein WR am schlechtesten vom Wirkungsgrad)
• Internetanbindungen
• Sensorbereitstellungen
• Wärmeverluste
• MPPT-Leistungsverluste
• Speicherqualität
• Kabellängen
• Temperaturen
• Alterung

STATS zeigt die Effizienz ab sofort getrennt nach WR und AKKU an. Diese “echte” Effizienz fließt unmittelbar auch in die “echte” Autarkie ein.

Grundsätzlich berechnet Hubble AI diese Werte schon seit Monaten, da genau sie zur Entscheidungsfindung “Netzladen ja / nein” von höchster Wichtigkeit sind.
Der SMC-Schalter ist also kein einfacher Schalter, der stur nach Strompreis an- und ausschaltet, sondern Hubble bezieht die Effizienz, die Prognose und die Verluste direkt mit ein, um zu beurteilen ob sich Netzladen überhaupt lohnt.
Diese Werte sind ab jetzt für euch sichtbar.

HINWEIS: Für eine korrekte Berechnung sind ZWINGEND folgende Sensoren notwendig:

1. DC Eingang am WR (Leistung der Solarzellen)
2. AC Ausgang am WR (z.B. Shelly)
3. Die Anzeige aktualisiert sich alle 1:10std, um HA nicht zu überlasten es ist also keine Echtzeit
4. Cloud angebundene Anlagen / Sensoren laufen meist nicht synchron da ist eine verlässliche Aussage erst am Tagesabschluß möglich
5. Cloudangebundene Systeme haben einen deutlich schlechteren “echte” Autarkewert als andere, durch die Verzögerungen

---

Wo kein Licht, da Schatten…

Die Schattenlogik wurde komplett überarbeitet und neu gedacht. Das führt dazu, dass sie zum Teil neu gelernt werden muss. Das ist also ein “Breaking Change”.

---

Bezeichnungen und Wording

Generell wurde die Sprache an vielen Stellen nachgeschärft und angepasst.

---

Statistiken

Der Fehler das die Wetter-Statistik nicht vergangene Monate, .. anzeigte wurde behoben

Auch die Exportfunktion wurde noch einmal verbessert und liefert nun die komplette Historie aus der DB in einzelnen Spalten und Zeilen.

---

Das Wichtigste zum Schluss

STATS hatte von Anfang an mit einer Vielzahl von Sensoren zu kämpfen. Durch Anpassungen und die Verlagerung von Berechnungen in den Code werden nun insgesamt 11 Sensoren eingespart.

Es müssen ab sofort KEINE kWh-Sensoren mehr gebildet werden. Es reichen einfache Watt-Sensoren und Hubble AI macht den Rest.

Bitte unbedingt auf die Vorzeichen achten!

---

Status:

RUFF = Grün
PyTest = Grün
Penetration = Grün
Build = Grün
PyAmor = Grün
Build = Grün
Q/A = Grün
PEP = Grün
EOD = ausstehend
MDC = ausstehend
MR = ausstehend

Geplanter Release: Nach EOD und Pre-Forecast

[Tom-HA]

Großes STATS- UI Update und erweiterte KI-Funktionen

Ein Wort vorweg:

Immer mehr User binden STATS in eine Website oder auf einem Tablet ein. Um diesem besser gerecht zu werden, habe ich eine spezielle und sehr umfangreiche Oberfläche entwickelt. Diese lässt sich in der Konfiguration von STATS erweitern. Die Oberfläche ist in hell / dunkel / automatisch vorhanden.

Die UI zeichnet sich durch eine eigene Navigation und weitere / tiefere Einsichten aus. Selbstverständlich kann die neue Ansicht auf Wunsch auch im Home Assistant eingebunden werden.

Einige Beispiele:

Viel Spaß beim entdecken und Spielen…

Release:

heute gegen 19:00 Uhr

[Tom-HA]

SFML V40 & STATS V40 & GPM V40 & EAI V40

KEPLER AI ist da! Das große Update für SFML & STATS

Ein paar Worte vorweg: KEPLER AI ist fertig und wird mit diesem Update offiziell eingeführt!

Was ist Kepler AI?

Wie bereits im Januar angekündigt, soll SFML weit mehr sein als nur eine reine Solar-Prognose. Nun ist es endlich so weit: Der bewährte Hubble AI-Stack bekommt Unterstützung vom brandneuen Kepler AI-Stack!
Damit schlage ich ein neues Kapitel auf und erweitere das System um grundlegende neue Funktionen. Kurzum: STATS kann jetzt auch Wärme und E-Mobilität (Wallboxen)!

---

Deine Wärmepumpe / Wallbox. Dein Haus. Deine Daten. Deine KI.

Solar Forecast Energy AI – powered by Hubble & Kepler

Kepler erstellt mithilfe einer maßgeschneiderten KI-Architektur einen digitalen Zwilling deines spezifischen Heizsystems / Wallbox. Das System läuft vollständig lokal auf deiner Home Assistant-Hardware und greift auf den Hubble-KI-Stack von SFML zurück.

Was Kepler macht:
Er erlernt kontinuierlich das thermische Verhalten deines Gebäudes, die Effizienz deiner Wärmepumpe, die individuelle Wetterempfindlichkeit sowie euer Heizverhalten. Das Ergebnis: Präzise stündliche Verbrauchsprognosen für die nächsten 3 Tage (72 Stunden). Ebenso deinen Bedarf für die E-Mobilität.

• Ganz ohne Cloud
• Ohne Abonnements
• Ohne Datenlecks

Reine lokale Intelligenz – so wie du es von SFML und STATS gewohnt bist. Deine Daten = Deine Sicherheit keine Kompromisse

---

Warum? Was ist das Problem herkömmlicher WP-Systeme?

Die meisten Energiemanagementsysteme nutzen statische Regeln oder einfache Gradtag-Berechnungen.

Solar Forecast Energy AI ist die Evolution dieser Systeme.

---

Das Herzstück: Der KI-Stack „Kepler“ (based on Hubble KI-Stack)

Im Zentrum der Integration steht ein von mir eigens entwickeltes KI-Ensemble namens Kepler, das speziell für die Verbrauchsprognose von Wärmepumpen und Wallboxen gebaut wurde und die bewährte Architektur von Hubble weiterführt.

Kein TensorFlow, kein PyTorch – sondern schlanke, extrem effiziente KI direkt auf deinem Home Assistant 100% nach den Richtlinien von Home Assistant und nur mit originalen von Home Assistant gepflegten Bibliotheken. Bewusst als Integration für maximale Sicherheit durch die internen Mechanismen von Home Assistant. - Pure Python.

Es handelt sich hierbei nicht um ein einzelnes Modell, sondern um ein ausgetüfteltes Zusammenspiel spezialisierter KIs – eine gezielte Weiterentwicklung des SFML Hubble KI-Stacks:

Wärmepumpen:

• Thermodynamische Kalibrierung: Kepler erlernt den tatsächlichen Wärmeverlustkoeffizienten (U-Wert) deines Gebäudes aus realen Verbrauchsdaten und erstellt dynamische Korrekturfaktoren für 5 Temperaturbereiche (mild, moderat, kalt, Frost, extreme Kälte).
• COP-Kurven-Modellierung: Nutzt typspezifische COP-Kurven (für Luft-, Sole- oder Wasser-Wärmepumpen) inklusive Abtau-Minderungen und Windchill-Effekten bei Luft-Systemen.
• Stufenweise Schutzabsicherung („Graduated Safeguard“): Keine KI-„Halluzinationen“. Weichen die KI-Modelle zu stark ab, greift die Thermodynamik-Engine (reine Physik) als Sicherheitsanker ein. Die KI weiß exakt, wann sie sicher ist – und wann sie an die Physik abgeben muss.
• Effizienz-Drift-Erkennung: Überwacht den realen COP-Wert, erkennt Leistungsabfälle, saisonale Verschiebungen sowie Anomalien und warnt dich rechtzeitig, wenn etwas nicht stimmt.
• Selbstüberwachung für Langzeitpräzision:
• Drift Monitor & Seasonal Adjuster: Erkennt Abweichungen und lernt saisonale Muster aus Realdaten (nicht starr aus dem Kalender).
• Grid Search „The Professor“: Vollautomatische Hyperparameter-Optimierung für dein individuelles Setup.

Wallboxen:

• Ladezustand und benötigte Energie bis zur Abfahrt
• empfohlener Ladebeginn und empfohlenes Zeitfenster
• erwarteter PV-Anteil
• geschätzte Ladekosten
• Vergleich „Sofort laden“ gegen „empfohlenes Zeitfenster“
• animierte 24-Stunden-Timeline mit PV-Prognose, Strompreis, Wärmepumpenbedarf und Fahrzeugladung
• Abfahrtsbereitschaft und Risikoanzeige

Beispiel:
Abfahrt morgen 07:00 Uhr
Benötigt: 18,4 kWh
Sofort laden: 7,82 €
Empfohlenes Ladefenster: 11:20–15:10 Uhr
Erwartete Kosten: 3,14 €
PV-Anteil: 71 %
Rechnerisches Sparpotenzial: 4,68 €

---

Realitätsnah: Mehr als nur Charts

Während andere Systeme kaum Kontext haben und alles gleich behandeln, überwacht Kepler die realen Umweltbedingungen, die deinen Verbrauch tatsächlich beeinflussen:

• Frost- & Abtau-Logik: Erkennt Abtauzyklen bei Luft-Wärmepumpen (unter 5 °C), kalkuliert den COP-Nachteil ein und erkennt Frostrisiken über präzise Taupunkt- und Luftfeuchtigkeitsanalysen.
• Windchill-Effekte: Berücksichtigt, dass starker Wind die Effizienz von Luft-Wärmepumpen deutlich reduziert, und passt die Prognosen entsprechend an.
• Temperaturbereichs-Lernen (5 Zonen): Unterscheidet das Gebäudeverhalten gezielt bei milden (>10 °C), moderaten (5 bis 10 °C), kalten (0 bis 5 °C), frostigen (-5 bis 0 °C) und extrem kalten (<-5 °C) Bedingungen.
• Thermisches Gebäudemodell: Lernt den realen U-Wert aus deinen Verbrauchsdaten und versteht Speichermasse, Isolierungsqualität und Heizverhalten.
• Multi-Wetter-Intelligenz: Kombiniert den Hubble Wetter-KI-Stack mit weiteren Wetterquellen via Experten-Gewichtung. Auch Wolkentrends, Luftfeuchtigkeit und Luftdruckveränderungen fließen direkt ein.
• Warmwasser-Erkennung (DHW): Erkennt Zyklen zur Brauchwassererwärmung automatisch, da diese ein völlig anderes Verhalten aufweisen als das normale Raumheizen.

---

Vorhersagen & Prognosen Wärmepumpe

• 72-Stunden-Prognose (stündlich aufgeschlüsselt) für heute, morgen und übermorgen.
• Dynamische Zeitpläne basierend auf realen Bedingungen.
• Adaptives Re-Forecasting mittags bei starken Wetterumschwüngen.
• Stündlich aktualisierte Resttag-Verbrauchsprognosen.

Lokale KI (Deine Daten verlassen nie dein System)

• Kepler-Ensemble mit Attention-AI
• Automatisches, tägliches Training und Hyperparameter-Tuning.
• Feature-Importance-Analyse zeigt dir transparent, was deinen Verbrauch primär antreibt.
• 25+ entwickelte Features speziell für Wärmepumpen und Hausisolierung.
• Intelligente Datenfilterung für Anomalien (z. B. Sensorausfälle oder ungewöhnliches Heizverhalten).

Wetter-Intelligenz (powered by Hubble KI-Stack und Weather Forecast AI)

• Mehrstufige Korrekturen: Gleitende Abweichungen, stündliche Anpassungen und zustandsspezifische Feineinstellungen.
• Verfolgung von Wolkentrends und Volatilität zur exakten Abschätzung des Heizbedarfs.

Thermodynamik-Engine (powered by Kepler + Hubble)

• Spezifische COP-Kurven für Luft-Wasser-, Sole-Wasser- und Wasser-Wasser-Wärmepumpen.
• Kontinuierliche Selbstkalibrierung durch ständige Rückkopplung mit dem tatsächlichen Verbrauch.

Erkennung & Datensicherheit

• CUSUM-basierte Drift-Erkennung gegen schleichende Leistungsabfälle des KI-Modells.
• Frühzeitige Frostwarnungen via Taupunkt und Sichtweitenanalyse.
• Absturzsichere, transaktionale SQLite-Datenbank mit automatischer Wiederherstellung und 30-Tage-Backup-Speicherung.

Saisonale Intelligenz

• Automatischer Wintermodus mit Anpassungen für niedrige Temperaturen.
• Sommer-Modus (nur Brauchwasser): Erkennt reduzierte Heizphasen zuverlässig.
• Fortlaufende Effizienzverfolgung für langfristiges Leistungsmonitoring.

---

Voraussetzungen

• Korrekt konfiguriertes Solar Forecast ML und Solar Forecast Stats.
• Entsprechende Sensoren der Wärmepumpe (sowie ggf. Heizstäbe) in Home Assistant.

---

Wichtiger Hinweis & Transparenz (Disclaimer)

DISCLAIMER: Aktuell warte ich noch auf eine Rückmeldung/Entscheidung von Simon, ob SFML EAI hier im Forum offiziell supported und unterstützt werden kann/darf.

Hintergrund
Dieses Add-on verursacht keinerlei monatliche Kosten oder Abonnements für euch. Um jedoch die API-Abrufe der notwendigen externen Wetter- und Trainingsdaten zu refinanzieren und das Projekt für mich kostenneutral zu halten (abgesehen von den unzähligen Stunden an Entwicklungsarbeit), erhebe ich eine einmalige Gebühr von 10 EUR.

Ich denke, das ist fair und unkompliziert. Und damit niemand „die Katze im Sack“ bekommt, gibt es vorab eine ausführliche Demo, damit ihr euch selbst ein Bild machen könnt!

---

Wie sieht das Ganze aus? (Einige Einblicke)

Das wichtigste zu erst: SFML Stats “The wild one” ist Pflicht und war die Vorbereitung. EAI funktioniert nur im modus “modern”

Bereitgestellte Sensoren und ihre Funktionen:

Prognose- und Empfehlungssensoren

• Empfohlene Aktion
  Zeigt die aktuell von EAI empfohlene Maßnahme: keine Aktion, Warmwasser, Heizen, thermischen Speicher nutzen oder Betrieb verschieben.
• Grund der Empfehlung
  Erklärt die Entscheidung, beispielsweise PV-Überschuss, niedriger Strompreis, Komfortbedarf, hoher Strompreis oder unzureichende Daten.
• Vertrauen der Empfehlung
  Bewertet die Verlässlichkeit der Empfehlung in Prozent. Grundlage sind Datenqualität und Prognosequalität.
• Nächster empfohlener Start
  Zeitpunkt, zu dem das erkannte PV-, Tarif- oder Komfortfenster beginnt.
• Empfehlung gültig bis
  Kennzeichnet, bis wann eine Empfehlung für Automationen verwendet werden sollte.
• Empfohlene Dauer
  Vorgeschlagene Dauer des erkannten Betriebsfensters in Minuten.
• Verbrauch nächste Stunde
  Prognostizierter elektrischer Verbrauch der Wärmepumpe für die nächste Stunde in kWh.
• Erwarteter Verbrauch heute
  Erwarteter elektrischer Tagesverbrauch der Wärmepumpe in kWh.
• Erwarteter Verbrauch morgen
  Prognostizierter elektrischer Verbrauch für den folgenden Tag in kWh.
• Erwarteter PV-Überschuss
  Erwartete PV-Energie, die nach Abzug des prognostizierten Wärmepumpenverbrauchs im empfohlenen Stundenfenster verbleibt.
• Geschätzter Kostenvorteil
  Berechnet den möglichen finanziellen Vorteil des empfohlenen Zeitfensters. Optional können Strompreis und Einspeisevergütung in EUR/kWh oder ct/kWh eingebunden werden. Der Wert ist eine Entscheidungshilfe und keine Abrechnung.
• Datenqualität
  Zeigt in Prozent, wie vollständig, aktuell und belastbar die zugeordneten Eingangsdaten sind.
• Modellstatus
  Zeigt, ob das EAI-Modell noch lernt, bereit oder aktuell nur eingeschränkt verfügbar ist.

Binärsensoren für Automationen

Diese Sensoren liefern klare Ein-/Aus-Zustände und eignen sich direkt als Trigger oder Bedingungen:

• Automation bereit
  Ist aktiv, wenn Lizenz, Konfiguration, Prognose, Datenqualität und Master-Freigabe einen sicheren Einsatz der Signale erlauben.
• PV-Fenster aktiv
  Meldet ein aktuell nutzbares PV-Überschussfenster.
• Warmwasser empfohlen
  Signalisiert, dass das aktuelle oder bevorstehende Energiezeitfenster bevorzugt für die Warmwasserbereitung genutzt werden kann.
• Heizen empfohlen
  Wird bei erkanntem Komfort- beziehungsweise Heizbedarf aktiv.
• Thermischer Speicher empfohlen
  Meldet ein geeignetes Zeitfenster zur Nutzung eines vorhandenen thermischen Speichers.
• Niedrigpreisfenster aktiv
  Wird aktiv, wenn der aktuelle Strompreis unter der individuell festgelegten Niedrigpreisgrenze liegt.
• Betrieb verschiebbar
  Signalisiert, dass ein Betrieb aus analytischer Sicht verschoben werden könnte, beispielsweise bei einem hohen Strompreis ohne akuten Komfortbedarf.
• Kritisches Datenproblem
  Warnt vor fehlenden, veralteten oder widersprüchlichen Daten, die eine belastbare Automation verhindern.

Zugehörige Sicherheitsschalter

• Automationssignale freigeben
  Zentrale Freigabe für die triggerfähigen Binärsensoren. Der Schalter ist bei der ersten Einrichtung standardmäßig ausgeschaltet.
• PV-Signale
  Aktiviert oder deaktiviert die Berücksichtigung von PV-Überschussfenstern.
• Tarif-Signale
  Aktiviert oder deaktiviert die Berücksichtigung von Strompreisfenstern.

Wallbox- Mobilität

Sensoren für E-Mobilität:

• Empfohlene Ladeaktion
• Nächster empfohlener Ladestart
• Empfohlenes Ladeende
• Benötigte Ladeenergie
• Erwarteter PV-Ladeanteil
• Geschätzte Ladekosten
• Rechnerischer Kostenvorteil
• Abfahrtsbereitschaft
• Datenqualität
• Ladefenster aktiv
• PV-Laden empfohlen
• Niedrigpreis-Laden empfohlen
• Abfahrtsziel gefährdet

RELASE: Nach der Entscheidung von Simon

Status:

• PyTest = Grün
• RUFF = Grün
• Safeguards (AI) = Grün
• Rails (AI) = Grün
• Interpreter = Grün
• Mocking = Grün
• HA Async = Grün
• PEP = Grün
• SQL = Grün
• Penetration = Grün
• LSTM = Grün
• GRID = Grün
• Attention = Grün
• API-Calls = Grün
• HA Recorder API = Grün
• HA Build = Grün
• Crossfunction SFML = Grün
• Crossfunction STATS = Grün
• Crossfunction GPM = Grün
• Crossfunction WFAI = Grün
• Export-Functions = Grün

Over all Status: Ready insgesamt 41 Regressionstests bestanden

ZARA