Hallo zusammen,
SFML, GPM, WFAI und Stats sind mittlerweile zu einer mächtigen Energie- und Analyseplattform herangewachsen.
Für neue User ist es unheimlich komplex geworden korrekt zu verstehen was sie dort sehen. - Ich habe mir daher überlegt das Handbuch grundlegend zu überarbeiten.
Frage: Was sollte aus eurer Ansicht unbedingt mit in das Handbuch aufgenommen werden - neben den Dingen die eh schon drinstehen? - Jeder Vorschlag ist willkommen !
Gerne eine Erklärung zu jeden Sensor.
Das man bei Fragen, gleich eine passende Antwort parat hat.
Und bei Stats auch die Verbindung zu SFML und was genau dahinter steckt.
Da dort immer wieder neue Fragen aufkommen und man dadurch eine Zentrale Anlaufstelle hat, was sich hinter diesen Dingen verbirgt.
Gerne zur Konfiguration, genaue Erklärungen, was benötigt wird.
z.B.: DC Leistung bei Solar Ertrag
oder was muss der Hausverbrauchssensor expliziert enthalten.
Gerne kann man dazu auch Beispiel Templates als Anhang anfügen. (Wenn Sensoren gebaut werden müssen)
Grüße
Edit:
Sehr gute Idee! Ich stimme @Kaysen899 schon mal komplett zu.
Vorschläge von meiner Seite:
Wenn möglich die Erklärungen mit screenshots bebildern.
Wirklich jeden Sensor erklären, mit notwendiger Spezifikation und Bedeutung
Eventuell eine grafische Übersicht wie die Zusammenhänge zwischen Sfml, TFS, Hubble und stats sind.
Und wenn das ganze fertig ist, klar und deutlich kommunizieren,
Lesen ist Pflicht, bevor Fragen gestellt werden.
Ich schreibe gerade bessere Beschreibungen für die Funktionen und welche Sensoren dafür benötigt werden..
Ich denke mal das ist ein Guter Anfang und das können wir dann alle gemeinsam verbessern… ?
Sieht doch mal gut aus. @Kaysen899 stimmte ich auch voll zu. Ich bin hier nur am Lesen und manchmal wird es kompliziert. 
Das verstehe ich zu 100% - leider kommen dabei Features auch viel zu kurz. Ich bekomme ja Rückmeldung aus der ganzen Welt und das am meisten gefeierte Feature sind SMC und S-Plus. Würde ich hier fragen, würden nur die wenigsten verstehen was es ist und warum es aktuell (User-Auswertung) das Killer-Feature ist. S-Plus hingegen ist bei vielen das am meisten genutzte Feature um den Eigenverbrauch zu maximieren, E-Autos zu laden, Heizstäbe zu starten,..
Daher schreibe ich das Handbuch gerade komplett um, mit tieferen Erklärungen, so kann man immer erst einmal darauf verweisen.. das sollte es einfacher machen zu verstehen wie es funktioniert, was wirklich ein BUG ist, welche Sensoren für welche Funktionen benötigt werden… z.B. SMC:
Bezeichnung:
Smart Charge (SMC) – vorausschauende Netzladung eines stationären Akkus bei dynamischem Stromtarif.
Beschreibung:
SMC lädt den Akku nicht allein deshalb, weil der aktuelle Strompreis niedrig ist. Hubble verbindet den effektiven Bruttostrompreis mit Solarprognose, aktueller Wirkleistung, erwartetem Verbrauch, Umwandlungsverlusten, Akku-SoC, Akkukapazität und den konfigurierten SoC-Grenzen. Daraus entstehen ein wirtschaftlich bewerteter Ladezeitpunkt und ein dynamischer Ziel-SoC.
Wozu ist das gut?
Günstige Netzstunden werden genutzt, ohne den Akku unnötig zu füllen und dadurch Platz für den erwarteten Solarüberschuss zu verlieren. Das reduziert teuren Netzbezug und verbessert die wirtschaftliche Akkunutzung.
Hubble und Verluste: Hubble bewertet den aktuellen SMC-Zustand und bezieht Bruttostrompreis, Prognose, Wirkleistung sowie Speicher- und Umwandlungsverluste direkt in Ladeentscheidung und Ersparnisbewertung ein. SMC setzt die daraus abgeleitete Entscheidung über den konfigurierten Netzlade-Schalter um.
| Sensor oder Wert | Status | Anforderung | Aufgabe | Wenn er fehlt |
|---|---|---|---|---|
| Akku-SoC | funktional erforderlich | Sensor, numerisch 0–100 % | Start-/Stoppentscheidung und Zielvergleich | Automatische Ladung wird aus Sicherheitsgründen blockiert |
| Netzlade-Schalter | für automatische Steuerung erforderlich | switch-Entity des Akkus/Wechselrichters |
Schaltet die Netzladung ein oder aus | Nur Analyse und Empfehlung, keine Schaltaktion |
| Gesamtstrompreis | erforderliche Datenquelle | GPM-Dynamikpreis oder Gesamtpreissensor; effektiv ct/kWh | Vergleich mit Maximal- und Force-Charge-Schwelle | Keine belastbare Preisentscheidung |
| Solarprognose | erforderliche SFML-Datenbasis | heutige/morgige Prognose in kWh | Reserviert Platz für erwarteten Solarüberschuss | Ziel-SoC fällt konservativ bis zum Max-SoC zurück |
| Hausverbrauch | für Tages-Force-Charge erforderlich | Leistung in W oder kW | Vergleich mit aktueller Solarleistung | Force Charge am Tag wird bei unbekanntem Defizit blockiert |
| Solar→Haus | für Tages-Force-Charge erforderlich | Leistung in W oder kW | Belegt, ob Solar den aktuellen Hausbedarf deckt | Force Charge am Tag wird bei unbekanntem Defizit blockiert |
| Wirkungsgrad-/Verlustdaten | erforderliche Bewertungsbasis | Wirkungskette von Wechselrichter und Akku | Korrigiert nutzbare Energie und wirtschaftlichen Ladepreis | Keine vollständige verlustbereinigte Ladeentscheidung |
| Alternativer Haupt-SoC | optional | Sensor, numerisch 0–100 % | Fallback bei ungültigem primären SoC | Kein Fallback |
| Wert | Bedeutung |
|---|---|
| Akkukapazität in kWh | Übersetzt erwartete Energie in einen Ziel-SoC. |
| Minimaler und maximaler SoC | Begrenzt den von SMC erlaubten Arbeitsbereich. |
| Maximalpreis | Unterhalb dieser Grenze gilt eine Nachtstunde als günstig. Der Grenzwert selbst zählt nicht als günstig. |
| Force-Charge-Preis | Besonders günstige Schwelle für eine Ladung bis nahe Max-SoC; tagsüber nur bei belegtem Solardefizit. |
Ausgangslage:
10-kWh-Akku, Min-SoC 20 %, Max-SoC 90 %, Maximalpreis 25 ct/kWh, aktueller SoC 35 %. SMC berechnet aus der Solarprognose und dem erwarteten Verbrauch einen Ziel-SoC von 65 %.
Entscheidung:
In einer Nachtstunde kostet Strom 18 ct/kWh. Der Preis ist günstig und der SoC liegt unter der Einschalthysterese. SMC aktiviert den Netzlade-Schalter und lädt bis zum Zielbereich.
Nutzen:
Der erwartete Nachtbedarf wird günstig gedeckt; gleichzeitig bleiben 35 % Speicherkapazität bis zum Max-SoC für den prognostizierten Solarertrag frei.
Zweites Szenario:
Fällt der Preis tagsüber unter die Force-Charge-Schwelle, lädt SMC nur dann aus dem Netz, wenn Hausverbrauch und Solar→Haus-Leistung gemeinsam ein tatsächliches Leistungsdefizit belegen.
so in dem Stil schreibe ich es gerade um..
Kannst du dann bei den Sensoren noch dazu schreiben, ob positiv oder negativ erwartet wird? Das ist immer mein größtes Problem
Sollte eigentlich im aktuellen Handbuch und auch im Config-Flow bereits stehen.. kannst Du das bitte mal prüfen?
Im Configflow sehe ich nur beim “Batterie Leistung (W)” einen Hinweis auf “Lade- und Entladeleistung der Batterie in Watt. Positiv = Laden, Negativ = Entladen. (Optional)”
Bei allen anderen steht nichts explizites dabei, ob Sie nur Positiv oder auch “mal” negativ sein dürfen.
Kann natürlich auch etwas übersehen haben.
Als Außenseiter der versucht halbwegs am Ball zu bleiben… da mein Herz für die „SFML Docker-Version“ schlägt.
Für den Einstieg eine Übersicht über das Ökosystem und deren Abhängigkeiten
Home Assistant
│
▼
Solar-Forecast-ML (Kern)
┌───────────────┼───────────────┐
▼ ▼ ▼
weather-fusion-ai TFS Transformer Solar-Forecast-Stats
Wetterfusion Zusatz-KI Analyse & Dashboard
Hallo @Linos
Ich hoffe sie bald fertig zu haben, grundsätzlich läuft sie bereits. - Aktuell ist jedoch Familien-Zeit angesagt 
Zu deinem Diagramm, dass ist “fast” richtig! Hier die vollständige Abhängigkeit(en) und Datenströme:
SFML ist die Forecast-Instanz und Source of Truth. Es schreibt die endgültigen Stunden-, Tages- und Panelgruppenprognosen.
TFS ist ein Ensemble-Mitglied. Es liest SFML-Daten, berechnet P10/P50/P90 und liefert Ergebnisse über 127.0.0.1:8780 zurück. SFML gewichtet TFS dynamisch und fällt bei Ausfall auf die eigenen Modelle zurück.
GPM ist die Preisinstanz. Es lädt dynamische Strompreise, berechnet den Gesamtpreis und schreibt seine GPM_*-Tabellen in dieselbe SQLite-Datenbank.
STATS ist die Analyse- und Präsentationsschicht. Es liest SFML- und GPM-Daten, ergänzt Energie-, Kosten- und Verbrauchsdaten und bereitet sie für Dashboards, Hubble und Ladeentscheidungen auf.
STATS verändert nicht den SFML-Forecast. Es bewertet, erklärt und nutzt ihn.
Zwischen GPM und TFS besteht keine direkte Verbindung. Ihre Informationen treffen erst bei SFML beziehungsweise STATS zusammen.
Ich hatte mal was gebastelt… vielleicht macht es das deutlicher:
Die Abhängigkeiten sind ähnlich wie Autobahnen benannt:
Hauptpfade / Module haben volle Nummern und Abhängigkeiten / Lieferanten vorangestellt die direkten Hauptmodule
Bsp:
Repro 1 > Lieferant / Zweig Repro 12
Jede volle Nummer ist ein eigenständiges Modul
Also die Module von STATS wenn man sie weiter aufbricht sind
Repro 21 = Dashboard
Repro 22 = Solar-Dashboard
Repro 23 = Energie Dashboard
Repro 24 = Smart Charge
usw…
Das ist mein Architektur-Baum der es einfacher macht an einzelnen Modulen zu Arbeiten und die Pipelines zu verfolgen.. - Ich weiß das es nicht DIN-Konform ist :–) Aber nur so bekomme ich das Wachstum und die Zweige in den Griff
Es ist schon alles sehr komplex.. 
Allein das Attention Modell und der Transformer würden eine ganze Seite füllen.. daher habe ich dafür auch mal eine vereinfachte Darstellung gebaut.. aber nur intern benutzt, da es vermutlich etwas zu komplex ist.. Daher hier mal die “einfache” Darstellung was Hubble macht und was er alles auswertet um in Stats die Anzeigen zu bauen.. (Backend)
Hilft dir das weiter?
Aber nur „fast“ 
Sehr schön – das sollte auf jeden Fall prominent in der „Tech-Ebene“ platziert werden.
Mach dir keine Gedanken um DIN-Konformität, denn die Systemtrennung und die Verantwortlichkeiten sind klar erkennbar.
Mein Eindruck ergänzend dazu:
Für die Non-Tech-Ebene (Einstieg) würde ich einen anderer Ansatz bereitstellen!
Ich würde hier eher den Diagramm-Aufbau wie beim „Hubble Stack“ als First In nutzen.
Wer tiefer einsteigen möchte, bringt in der Regel auch die Bereitschaft mit, ins Handbuch zu schauen / es finden zu wollen
. Dort kann dann mit einem detaillierteren Aufbau – wie bei der „SFML-Systemarchitektur“ – gearbeitet werden.
Deine aktuelle Darstellung folgt stark dem Prinzip: „Das ist wichtig, also zeige ich es auch“.
Für die Tech-Ebene ist das absolut sinnvoll. Für Menschen ohne Berührungspunkte wird es jedoch schnell zu viel am Anfang → die Orientierung geht verloren → immer die gleichen Fragen. So zB geht es mir immer noch mit den Ganzen Abkürzen SFML, GPM, WFAI - aber ich stehe ja noch am Spielfeldrand
Viele Nutzer wollen (und werden) sich nicht lange einarbeiten oder alles im Detail analysieren.
Deshalb sollte die Darstellung konsequent darauf reduziert werden, was tatsächlich eine Installations- oder Nutzungsentscheidung beeinflusst.
Kurz gesagt:
Einfacher Einstieg über reduzierte, verständliche Visualisierung → also weniger erklären und mehr führen für die erste Ebene
Ja danke und Hut ab vor deinem architektonischen Konstrukt. Die Architektur wirkt auf mich so, als würden noch die eine oder andere Idee im Hintergrund lauern.
Ein Glossar. Es gibt so viele Abkürzungen und Fachbegriffe, das man sehr schnell den Überblick verlieren kann.
Einfach das Handbuch aufrufen, da ist ein Glossar enthalten.
Und rate, wer das Korrekturgelesen hat.
Sowas wie der Kofler für Linux, sowas wie selfhmtl?
Keine Ahnung, ich kann nur lesen und möglicherweise verstehen.
Allokation war so‘n Begriff den ich tatsächlich im Lexikon nachschlagen musste.
