Aus Solar Forecast ML
Das sind nur die IST Werte.
Ich benötige aber die einzelnen Prognosewerte welche SFML berechnet
Oder liege ich hier völlig falsch?
Die Sensoren sind ganz gut in den Projekt beschrieben.
Bei mir sieht das so aus.
Beispiel für Gruppe 1
SELECT '7d' as state,
(SELECT json_group_object(target_date, hourly_json) FROM (
SELECT hp.target_date,
json_group_array(json_object(
'hour', hp.target_hour,
'pred', ROUND(ppg.prediction_kwh, 4),
'actual', ppg.actual_kwh
)) as hourly_json
FROM hourly_predictions hp
JOIN prediction_panel_groups ppg ON hp.prediction_id = ppg.prediction_id
WHERE hp.target_date >= date('now', 'localtime', '-7 days')
AND hp.target_date < date('now', 'localtime')
AND ppg.group_name = 'Gruppe 1'
GROUP BY hp.target_date ORDER BY hp.target_date
)) as history_data
Da sind dann die Daten im Sensor
Ich habe den Beitrag gelöscht!
Vielen Dank!
Die Attribute habe ich nicht beachtet.
1 „Gefällt mir“
Nabend,
mal eine Frage am Rande:
Ich plane eine PV verbauen zu lassen. Könnte ich mithilfe eines Angebots SFML nutzen und mir vorausschauend Kosten/Nutzen/Auslegung erzeugen ? Alles nur Theorie, keine Frage. Mich würde aber schon interessieren, Wieviel die Anlage zu welcher Zeit bringen würde, welcher Akku ggf. Sinnvoll wäre um auch mit dem aktuellen Verbrauch über die Nacht zu kommen. Oder gibt es da noch andere Möglichkeiten das detaillierter in Erfahrung zu bringen ? Danke schon einmal 
Dafür nimmt man (der Solarteur) professionelle Planungstools wie PV*Sol. Ich hatte mich damals in 2020 in die vierwöchige Test-Vollversion eingearbeitet und unsere 3-Seiten PV mit 28kWp geplant und 12 Monate im 5-Minutentakt inkl. eingezeichnete Abschattungsobjekte wie Bäume und Nachbargebäude simuliert. Die simulierten Jahreswerte passen heutzutage zu 90-110% zum realen Ertrag (und Netzbezug im Winter), inkl. Wallboxen, Batteriespeicher und E-Auto. Wärmepumpe geht auch, war/ist aber noch kein Thema für uns.
Mein Tip sowieso - plane/baue eine systemoffene Anlage und rüste Speicher ggf. nach 1-2 Jahren PV-Erfahrung nach. SFML ist aktuell sicher (noch) kein PV-Planungstool.
Schaue Dir jetzt Mitte April den Nachtverbrauch kWh am Hauszähler in der Zeit eine Stunde vor Sonnenuntergang bis 1 Stunde nach Sonnenaufgang an. Wenn da 5kWh zusammenkommen, wäre ein erster guter Richtwert ein Speicher mit max. Faktor 2, 10kWh Kapazität (sofern die PV groß genug ist, also ab >= 10kWp) Einen größeren Speicher bekommst Du ansonsten im Sommer nie leer und im Winter während 4 Monate nie (selten) voll.
3 „Gefällt mir“
Das war sogar vor dem Posting erstellt per super intelligente KI. Da noch keine Daten vorhanden ist der Apex Chart halt gerade leer, aber mal schauen was morgen bei rum kommt. Die Ki hat mithilfe von Azimut und Elevation ein paar Faktoren gebastelt und mir dann irgendeine Dumme Hochrechnung erstellt. In dem vorliegenden Angebot sind ja schon einige Hochrechnungen, Amortisationszeiten etc. aufgeführt aber alles nur mit monatlichem Bezug. Eine Tägliche pi*
Ansicht wäre halt gerade interessant. Und nur zum Verständnis, ich möchte die Anlage nicht planen sondern nur einen Solar Forecast (hehe) von einer theoretischen Anlage. Aber ich habe schon die benötigten Sensoren entdeckt und das bekomme ich nicht hin. Aber danke.
Aber die Sache ist ja auch, SFML lernt über die Zeit - Tage, Wochen Jahreszeiten, erst ab Start die Eigenheiten der Anlage kennen - z.B. Verschattungen, Dachneigung, etc. und passt sich dann in seiner Prognose darauf an.
Anders herum PVSol. Da sehe ich sogar in der Simulation die Verschattung der südlichen Bäume von uns, sowie Nachbargebäude inkl. hohem Schorstein auf den Modulen, etc., etc. auf den Tag genau. Die mtl.- und Jahresprognose von PV*Sol auf Basis der 365-Tage-Simulation ist sehr genau.
Du solltest Dein Thema vielleicht aber besser in einem extra Beitrag adressieren, ggf. das Angebot/die Anlage inkl. Dachbelegung, Satelliten-Aufnahmen im deutschen PV-Forum vorstellen und nachfragen. Wer sich etwas mit PV auskennt, kann dann schon relativ gut beurteilen, was pro Jahr an Ertrag zu erwarten ist (zumindest wenn es kein BKW ist, sondern eine richtige PV >10-15kWp).
1 „Gefällt mir“
Das ist ein sehr spannendes Thema! Bereits sehr früh in der Entwicklung von Solar Forecast ML kam ein Solateur auf mich zu und wir haben gemeinsam einen Use-Case entwickelt der genau die Frage addressiert.
Um es kurz zusammenzufassen: Es gibt eine SFML-Version, die seit 4 Monaten im Test ist und das kann. ABER das ist keine Home Assisitant Integration, sondern ein Standalone Tool. Im Beta Thread hatte ich die Version mal kurz vorgestellt und die entsprechenden Skripte. → Ein Teil aus der Version, die es in HA geschafft. hat ist zum Beispiel die Schattenerkennung, die Alterung,..
Um das zu verstehen, muss man sich mit den Unterschieden befassen.
PV*SOL
PV*SOL ist im Grunssatz ein Planungstool vor der Installation — es simuliert deterministisch 8.760 Stunden (= 1 Jahr) und berechnet:
- Jahresertrag (kWh/Jahr) und spezifischen Ertrag (kWh/kWp/Jahr)
- Monatliche Aufschlüsselung der Produktion
- Performance Ratio (PR)
- Verlust-Diagramm (Verschattung, Temperatur, Inverter, Kabel…)
- Eigenverbrauch & Autarkie (mit Batterie-Simulation)
- Finanzanalyse (ROI, Amortisation, LCOE)
Die Eingangsdaten sind statische TMY-Wetterdaten (Typical Meteorological Year) aus Meteonorm/PVGIS/DWD, kombiniert mit Panel-Datenblättern, Inverter-Kurven und 3D-Verschattung.
Was SFML-Prognosis anders macht
Der entscheidende Unterschied: PV*SOL hat keine echten Daten der Anlage. Es rechnet mit Datenblatt-Werten und statistischen Wetterjahren. SFML-Pro hat dagegen:
| Datenquelle | PV*SOL | SFML |
|---|---|---|
| Echte Produktionsdaten | Nein | Ja, täglich |
| Echte Wetterdaten (lokal) | Nein (TMY) | Ja, 5 Quellen |
| Panel-Degradation real gemessen | Nein (%-Annahme) | Ja (Drift Monitor) |
| Verschattung real gelernt | Nein (3D-Modell) | Ja (Shadow Pattern Learning) |
| Inverter-Verluste real | Nein (Kurve) | Implizit in IST-Daten |
Aber es gibt einen wesehentlichen Unterschied, SFML-Pro ist eher ein Tool zur Wirtschaftlichkeit, Planung, Erweiterung einer bestehenden Anlage.
Mit TFS ändert sich das aber Grundlegend, da mit TFS 18 Jahre Historische Wetterdaten und auch Klima und Strahlungsdaten “einziehen”.
TFS ist aus dem Need " Vorschau ohne Anlage" entstanden mit dem Seiteneffekt Gaps zu schließen (schnelle Wetterwechsel,..) von SFML.
Daher wird es eben auch die Standalone Docker-Version geben, die m.E: deutlich besser als alle aktuellen Planungs-Tools standortbezogene Daten berechnen kann.
Genau aus diesem Grund, die Roadmap.
Fazit:
Ja, SFML kann bereits jetzt eine Jahreprognose erstellen → Braucht aber Daten / Lernen
Ja SFML-TFS kann Jahresprognosen erstellen → Braucht aber eine HA installation
JA TFS-DO kann Prognosen unabhängig von HA Jahres-Prognosen erstellen
Zusammengefast: SFML nur mit bestehender Installation und Daten. SFML + TFS Ja
Beispiele: Was SFML-Pro aktuell kann:
Monatliche Ertragsübersicht (IST + Hochrechnung)
Monat │ Ø Tag │ Min │ Max │ Σ Monat │ Peak W │ Prod-h │ Quelle
──────────┼─────────┼───────┼────────┼─────────┼────────┼────────┼──────────
Jan │ 1.16 │ 0.01 │ 3.73 │ 36.0 │ 388 │ 6.8 │ ✅ Messung
Feb │ 2.08 │ 0.15 │ 6.55 │ 58.2 │ 572 │ 9.4 │ ✅ Messung
Mär │ 5.96 │ 1.95 │ 8.68 │ 184.8 │ 1.495 │ 11.7 │ ✅ Messung
Apr * │ 7.92 │ 1.75 │ 11.27 │ 237.6 │ 1.698 │ 13.4 │ 🔶 12d + Hochrechnung
Mai * │ 9.50 │ 3.00 │ 13.50 │ 294.5 │ 1.900 │ 15.0 │ 📐 Physics + Klima
Jun * │ 10.20 │ 4.00 │ 14.50 │ 306.0 │ 1.975 │ 16.2 │ 📐 Physics + Klima
Jul * │ 9.80 │ 3.50 │ 14.00 │ 303.8 │ 1.950 │ 15.8 │ 📐 Physics + Klima
Aug * │ 8.40 │ 2.50 │ 12.50 │ 260.4 │ 1.850 │ 14.2 │ 📐 Physics + Klima
Sep * │ 5.80 │ 1.50 │ 9.50 │ 174.0 │ 1.500 │ 12.0 │ 📐 Physics + Klima
Okt * │ 3.20 │ 0.50 │ 6.50 │ 99.2 │ 950 │ 9.5 │ 📐 Physics + Klima
Nov │ 0.84 │ 0.49 │ 1.49 │ 25.2 │ 400 │ 7.7 │ 🔶 3d + Hochrechnung
Dez │ 1.35 │ 0.15 │ 3.07 │ 41.9 │ 450 │ 7.7 │ ✅ Messung
──────────┼─────────┼───────┼────────┼─────────┼────────┼────────┤
JAHR │ 5.52 │ │ │ 2.022 │ 1.975 │ │
*** = Monate ohne vollständige Messdaten — Hochrechnung via Physics-Baseline × Calibrator-Faktor × klimatologische Bewölkung (Berlin DWD TRY)**
Saisonales Profil (kWh/Monat)
320 ┤
280 ┤ ██ ██ ██
240 ┤ ██ ██ ██ ██ ██
200 ┤ ██ ██ ██ ██ ██ ██
160 ┤ ██ ██ ██ ██ ██ ██ ██
120 ┤ ██ ██ ██ ██ ██ ██ ██
80 ┤ ██ ██ ██ ██ ██ ██ ██ ██ ██
40 ┤ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
0 ┼──Jan─Feb─Mär─Apr─Mai─Jun─Jul─Aug─Sep─Okt─Nov─Dez──
36 58 185 238 295 306 304 260 174 99 25 42
Degradations-Tracking (SFML-Exklusiv — das kann PV*SOL nicht)
| Panel-Gruppe | Calibrator-Faktor | Samples | Konfidenz | Status |
|---|---|---|---|---|
| Gruppe 1 | 1.656 | 775 | 100% | Stabil |
| Gruppe 2 | 1.308 | 752 | 100% | Stabil |
→ Über die nächsten Jahre kann SFML hier Degradation (typisch 0.5%/Jahr) erkennen und die Jahresprognose automatisch anpassen.
Konfidenzband (SFML-Exklusiv)
Jahresertrag: 2.022 kWh (Erwartungswert)
├── Optimistisch (sonniges Jahr): ~2.300 kWh
└── Pessimistisch (trübes Jahr): ~1.750 kWh
Berechnet aus der täglichen Varianz der Messdaten — kein statisches ±5% wie PV*SOL. Daher auch immer wieder mein Einwand: SFML ist deutlich mächtiger als allgemein wahrgenommen wird, und genau das ist der Grund, warum ich so stark auf Datenschutz und rein lokale Datenverarbeitung setze.
Im Beta-Thread hatte ich entsprechende Skripte für genau diese Art der Auswertung bereitgestellt, die mittlerweile natürlich nicht mehr funktionieren. Hinzu kommt, dass solche Berechnungen andere Bibliotheken erfordern, die HA nur eingeschränkt und auf ARM überhaupt nicht anbietet. Die alten Hasen erinnern sich sicher noch an das Fiasko, als ich damals die Bibliotheken auf ARM hinzugefügt hatte. 
Es ist außerdem eine Frage des Verständnisses: Es handelt sich nicht um eine statistische Hochrechnung, sondern um eine rein KI-getriebene Einschätzung — etwas grundlegend anderes. Meiner Meinung nach ist das nichts für das HA-Forum.
Fairerweise muss ich aber sagen, dass ich schon länger überlege, Teile davon in STATS einzubauen. Mein Problem dabei: Viele verstehen das Wesen einer Solarprognose nicht korrekt und glauben bei 20 % Abweichung an einzelnen Tagen bereits, dass etwas nicht funktioniert — was wissenschaftlich und im Hinblick darauf, wie SFML die Genauigkeit berechnet (ohne Schwellenkorrektur), schlicht falsch ist.
Eine standortspezifische, lokale Prognose mit einer durchschnittlichen Abweichung von unter 20 % ist eine Sensation und wissenschaftlich valide — die Betonung liegt auf Durchschnitt.
Um diese Diskussion zu umgehen, habe ich es bislang nicht umgesetzt.
Das ist das aktuelle Modell OHNE TFS..
Würde ich es in Stats “einhängen / aktivieren” würde es so aussehen:
Die Frage ist, ob das wirklich gewollt ist – es wäre die PROGNOSE von SFML für das laufende Jahr: für den eigenen Standort und die eigene Anlage, inklusive Verschattung, Besonderheiten und Alterung – also kein klassischer statistischer Annahmewert.
@Kaysen899 @Joachim-xo @CaptSonic @dietmar1968 @Astrofreak85 @MartyBr @alteMade @nobbilie (leider ist es beschränkt wen ich hier anhängen kann)
Was denkt ihr? - soll ich es aktivieren?
8 „Gefällt mir“
Ernsthaft? Ich würde die Prognose zu Geld machen und an Solateure verkaufen… 
Ja bitte, die Prognose in STATS/DEV einbauen: mein Dank wird Dir ewig nachschleifen…
Gerne Aktivieren, mit Erklärung, damit es gar nicht eher zu Fragen kommt.
Und erstmal unter der DEV Option verstecken?
Das sieht natürlich klasse aus und ich hätte nichts dagegen wenn du es aktivierst in der DEV Version. 
Wenn dann Dev.
Bin momentan so in der Zwickmühle zwischen: “Besser haben als brauchen” und “macht es für die Mehrheit der Nutzen es nicht zu komplex und fördert noch mehr nachfragen “
Wenn dann nicht in der “normalen” Version
3 „Gefällt mir“
Das sieht klasse aus. Ich bin ja eher ein Zahlenmensch und fühle mich mit Tabellen wohl. Die Grafiken visualisieren das ganze für den schnellen Überblick.
Ich vermisse ja in Stats noch die finanziellen Auswertungen. Grundlagendaten sind ja vorhanden.
Also meine Meinung ist: Bitte aktivieren!!!
2 „Gefällt mir“
Vielen Dank für eure schnellen Rückmeldungen! - Ich füge es ein, allerdings für alle nicht nur für DEV.. das würde zuviel Aufwand bedeuten und ich denke das das Risko eines brechen des Codes zu groß ist. ..
Es passt auch gut zu dem kommenden Update zum Beispiel in der Prognose Ansicht. Die nun Umfangreicher ist:
@MartyBr ich bin da tatsächlich dran, aber die gefühlt “minütlichen” Bug-Fixes von HA machen es gerade schier unmöglich größere Änderungen am Code durchzuführen. → unabsehbare Konsequenzen, da die Energieberechnung ein echtes Brett ist.. nicht trivial und ein eches Code-Monster. Wenn etwas bricht bekomme ich den Blame und nicht die DEV von HA..
Zara
4 „Gefällt mir“
Gerne aktivieren, als zusätzlichen Benefit, falls nicht zu aufwendig, würde ich gerne die Option sehen, seine eigenen mtl. Estimates, z.B. aus PV*Sol, einzugeben. So hätte man gleich die Möglichkeit zu erkennen, ob die Anlage in Ihren mtl. Specs. läuft. Nutze das auch unter pvoutput.org
Und hier sieht man auch mal in der Praxis wie gut die PV mtl. die „damalige“ PV*Sol Simulation trifft:
Ich werde dann auch die Monatsstatistik mit “einhängen” ohne ForeCast sondern IST.
Später dann wenn HA sich beruhigt hat incl. Monatlicher Aufschlüsselung .. hier ein Bild aus dem Test-System..
Das denke ich passt thematisch gut zusammen und macht Sinn.. und schafft eine schnelle Übersicht
7 „Gefällt mir“
Kein Problem, ich kann warten. Aktuell warte ich auf den Elektriker. Ich lasse einen zweiten Wechselrichter anschliessen, der meinen Akku laden soll. Mein zentraler WR ist ein reiner String WR, der meine drei Strings bedient. Beide tauschen sich über den Kostal Smart Energy Meter aus. Nun fehlte gerade hier ein Steckerchen (0,50 €) für den Anschluss der zweiten WR.
Ergebnis:
Die Notstromumschaltung kann nicht in Betrieb genommen werden
Ein Strang ist auf den neuen Wechselrichter geschaltet und damit außer Betrieb.
Ich warte seit Ende Dezember auf die Installation…
Nun soll Donnerstag die Installation abgeschlossen werden.. 
Also alles gut. Wenn du soweit bist, dann kann ich es hier im Forum lesen.
Wie ich weiter oben schon geschrieben habe ist mein Docker betriebsbereit für die Installation deiner SFML-Docker Lösung.
Vielen Dank für deine Arbeit und die Initiative hier im Forum.
VG
Martin
2 „Gefällt mir“
Hallo
Ich erweiter meine Module von 4 auf 8. Wie gehe ich hier am besten vor? Kann ich die Datenbank löschen und neu starten?
Danke für eure Hilfe