76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

@300P,

nur als Tipp, sowas:

 fhem ("set ".$heater." off");

kannst du ganz einfach so schreiben:

 fhem ("set $heater off");

Sieht doch viel übersichtlicher aus.
Und diese Ausdrücke:

Code Auswählen Erweitern

  my $timestart = "4";    # ab welcher Uhrzeit soll es sein
  my $timeend = "8";      # bis wieviel Uhr soll es sein
  my $minsocbat = "30";   # nur bis mindesten XY SoC aller Batterien

besser so:

Code Auswählen Erweitern

  my $timestart = 4;    # ab welcher Uhrzeit soll es sein
  my $timeend = 8;      # bis wieviel Uhr soll es sein
  my $minsocbat = 30;   # nur bis mindesten XY SoC aller Batterien

Weil die Ziffern bei uns als Integer verarbeitet werden und nicht als String ("4" ist der String 4).

  z.B.  if (5 > $timestart) versus if ("5" ne $timestart) mit $timestart = "4"

LG,
Heiko

[DS_Starter]

@all

die V 1.51.5 ist eingecheckt.
In der Version gibt es ein neues Attr graphicControl und es werden die folgenden Attribute automatisch umgesetzt:

graphicBeamWidth      -> graphicControl->beamWidth   
graphicHourCount      -> graphicControl->hourCount   
graphicEnergyUnit     -> graphicControl->energyUnit   
graphicSpaceSize      -> graphicControl->spaceSize   
graphicHeaderDetail   -> graphicControl->headerDetail
graphicHourStyle      -> graphicControl->hourStyle   
graphicLayoutType     -> graphicControl->layoutType

Nach dem Restart vom FHEM ist die neue Konfiguration nur zu sichern. Damit ist die Umsetzung abgeschlossen.

Grüße,
Heiko 

[300P]

@300P,

nur als Tipp......


LG,
Heiko

DANKE !!
Umgesetzt / geändert im Beitrag

[87insane]

Hey @Heiko,

ich lese hier fleißig mit und finde die ganzen Anpassung echt gut. Wollte aber nochmal kurz auf die "strings=none" Geschichte in setupInverterDev01 aufmerksam machen. Leider kann ich nicht einschätzen wie viel Aufwand das ist.

PS: Ich habe nun mit dem Modul immer mal ein wenig rum gespielt und einiges getestet. Mich wunder die relativ große Abweichung der Prognose. Gestern z.B. 15.8%. Hierzu muss ich sagen, ich habe fast perfekte Süd Ausrichtung (5% Abweichung). Allerdings je nach Jahreszeit/Sonnenstand ab Uhrzeit x (Beispiel 17:30 Uhr) eine Verschattung. Das würde zumindest die abendliche Abweichung erklären.
Über den Tag, bei keiner Verschattung werden aber auch mal 100W zu viel geschätzt oder 300W zu wenig usw. Mir ist klar, dass es nicht 100% genau sein kann aber mir kommen die Differenzen viel vor. Ist dem so oder reden wir hier vom normalem Toleranzbereich? (KI ist bei mir auch aktiv)

Dann noch eine kurze Best Pratice Frage: Wenn ich meine große 10kWp Anlage bekomme. Besser ein zweites SF def anlegen oder alles in das eine rein?

Danke und Gruß,
Kai

[DS_Starter]

Hallo Kai,

Wollte aber nochmal kurz auf die "strings=none" Geschichte in setupInverterDev01 aufmerksam machen.

Das habe ich noch auf dem Schirm. Da hier etwas mehr Auswirkungen zu erwarten sind, habe ich es etwas nach hinten gelegt. Aber gerne daran erinnern, bei mir läuft hier einiges durch ...

Mir ist klar, dass es nicht 100% genau sein kann aber mir kommen die Differenzen viel vor. Ist dem so oder reden wir hier vom normalem Toleranzbereich? (KI ist bei mir auch aktiv)

Also grundsätzlich wird sich bei so stabilen Wetter, einer entsprechenden Lauf- und Lernzeit und der hoffentlich gute Übereinstimmung der durch den Wetterdienst vorhergesagte und tatsächlich vorhandene Strahlung/Bewölkung eine Abweichung < 10%, typisch bei mir so zwischen 0,5 und 5% einpegeln.
Bezüglich KI besteht die Herausforderung, dass die KI immer nur durch Auswertung der vergangenen "Erfahrungen" auf die Prognose schließt. Da kommt es stark darauf an wieviel Daten, Entscheidungsmöglichkeiten (Lerngrad) vorhanden sind. Vergleichbar mit der Entwicklung vom Kleinkind über Schulkind zum Experten. 

Bei meinen Devices hat die KI schon einige Daten gesammelt und kommt damit schon recht gut zurecht. Eine ungefähre Vorstellung des Lerngrades kann man sich mit "get ... valDecTree aiRuleStrings" anschauen. Je höher die verfügbaren Regeln und Knoten sind, desto granularer kann die Entscheidungsfindung der KI ausfallen:

Code Auswählen Erweitern

Trained AI Object contains an Ensemble of 10 trees (only the first Tree is printed out)

Tree: 1 -> Number of Rules: 5294 / Number of Nodes: 7132 / Depth: 6
Tree: 2 -> Number of Rules: 5300 / Number of Nodes: 7122 / Depth: 5
Tree: 3 -> Number of Rules: 5290 / Number of Nodes: 7142 / Depth: 6
Tree: 4 -> Number of Rules: 5293 / Number of Nodes: 7121 / Depth: 5
Tree: 5 -> Number of Rules: 5300 / Number of Nodes: 7134 / Depth: 5
Tree: 6 -> Number of Rules: 5290 / Number of Nodes: 7110 / Depth: 6
Tree: 7 -> Number of Rules: 5281 / Number of Nodes: 7136 / Depth: 5
Tree: 8 -> Number of Rules: 5293 / Number of Nodes: 7143 / Depth: 6
Tree: 9 -> Number of Rules: 5297 / Number of Nodes: 7136 / Depth: 6
Tree: 10 -> Number of Rules: 5284 / Number of Nodes: 7126 / Depth: 6


Rules: Liste von Zeichenfolgen, die den Baum in Form von Regeln beschreiben
Nodes: Anzahl der Knoten im trainierten Entscheidungsbaum
Depth: Maximale Anzahl von Entscheidungen, die für eine Klassifizierung getroffen werden müssen

letztes KI-Training: 28.04.2025 17:15:25 / Laufzeit in Sekunden: 3.13943
letzte KI-Ergebnis Generierungsdauer: 0.06 ms
   
Allgemein sind diese Anpassungs- und Korrekturprozesse recht komplex und erfordern auch Zeit. Und es gibt immer wieder Rückschläge weil z.B. die Wetterprognose mit den realen Bedingungen nicht übereinstimmt und somit die gespeicherten Werte verfälscht, deren Auswirkungen wiederum im Modul durch statistische Methoden (Medianberechnung) versucht wird zu verringern.

Dann noch eine kurze Best Pratice Frage: Wenn ich meine große 10kWp Anlage bekomme. Besser ein zweites SF def anlegen oder alles in das eine rein?

Also wenn deine zwei Anlagen in der Anwendung gut zusammenpassen, also beide Anlagen speisen das Hausnetz und laden auch die gleichen Batterien, speisen die gleichen Verbraucher usw., kannst du sie in ein Device integrieren. Ansonsten dann besser zwei Devices vorsehen.

LG,
Heiko

[87insane]

Danke für die schnelle Antwort. Da hat meine KI noch einiges zu lernen.

Code Auswählen Erweitern

Tree: 1 -> Number of Rules: 92 / Number of Nodes: 101 / Depth: 2
Tree: 2 -> Number of Rules: 92 / Number of Nodes: 100 / Depth: 2
Tree: 3 -> Number of Rules: 90 / Number of Nodes: 101 / Depth: 2
Tree: 4 -> Number of Rules: 92 / Number of Nodes: 101 / Depth: 2
Tree: 5 -> Number of Rules: 95 / Number of Nodes: 104 / Depth: 2
Tree: 6 -> Number of Rules: 91 / Number of Nodes: 98 / Depth: 2
Tree: 7 -> Number of Rules: 94 / Number of Nodes: 106 / Depth: 2
Tree: 8 -> Number of Rules: 94 / Number of Nodes: 104 / Depth: 2
Tree: 9 -> Number of Rules: 93 / Number of Nodes: 105 / Depth: 2
Tree: 10 -> Number of Rules: 91 / Number of Nodes: 99 / Depth: 2

Was die Best Practice angeht:
Das Eine ist ein BKW, Einphasig mit kleiner BAT.
Das Andere ist eine 10kWp Anlage, 3 Phasig mit größerer BAT und Notstrom/Ersatzstrom.

Hatte das Modul aber so verstanden, das ich bei den verschiedenen Attr fast überall wo es wichtig ist, auch sagen kann was ist z.B. der richtige String an welcher Batterie usw. Ich bin mir nicht sicher ob ich das besser trenne oder nicht. Nicht alle deiner Ansätze, machen die Anlagen so.
- Unterschiedliche Akkus,
- Einphasig/Dreiphasig,
- Ja - es wird das gleiche Netz bespeist,
- Die Verbraucher sind zumindest auf der einen Phase, natürlich die gleichen. Wird aber ja eh im Stromzähler zusammen gezählt.

Ich glaub ich mach einfach zwei def´s.

Gruß,
Kai

[DS_Starter]

Hatte das Modul aber so verstanden, das ich bei den verschiedenen Attr fast überall wo es wichtig ist, auch sagen kann was ist z.B. der richtige String an welcher Batterie usw. Ich bin mir nicht sicher ob ich das besser trenne oder nicht.

Ja, so ist es auch. Ich vermute, dass sich 90% aller Fälle in einem Device abbilden lassen. Einphasig/Dreiphasig ist egal solage die registrirten Zähler alles richtig liefern.
Du kannst sogar alles in einem Device abbilden und zusätzlich noch ein weiteres Device nur mit deiner neuen Anlage erstellen. Dann kannst du vergleichen.

Zu beachten ist eben auch nochmal die KI. Wenn du jetzt eine Anlage zubaust und damit mehr Leistung im gleichen Device hast, wird die KI anfangs immer zu wenig prognostizieren, weil sie ja davon ausgeht ... aha, es ist soviel Strahlung, Bewölkung, Temperatur usw. pronostiziert -> dann wird es nach meiner Erfahrung X Wh geben. Sie lernt dann zwar auch das wieder, aber der Faktor Zeit spielt eine Rolle.
Die API (z.B. OpenMeteo) reagiert auf diese Anlagenänderung sofort.

[300P]

Was die Best Practice angeht:
Das Eine ist ein BKW, Einphasig mit kleiner BAT.
Das Andere ist eine 10kWp Anlage, 3 Phasig mit größerer BAT und Notstrom/Ersatzstrom.


- Unterschiedliche Akkus,
- Einphasig/Dreiphasig,
- Ja - es wird das gleiche Netz bespeist,
- Die Verbraucher sind zumindest auf der einen Phase, natürlich die gleichen. Wird aber ja eh im Stromzähler zusammen gezählt.

Ich glaub ich mach einfach zwei def´s.

Gruß,
Kai

Hallo Kai,

wenn dein aktuelles BKW sauber eingerichtet ist - sag / zeig mal wie es konfiguriert ist.


Wichtig wäre dabei auch noch zu wissen, ob dein BKW sein Leistung komplett "durch" die Batterie in dein Hausnetz weiterreicht oder ob die Batterie als separates Device zu sehen ist das keinen Einfluss auf die Leistungswerte der BKW-WR hat.
EDIT : fällt mir grad noch ein ->> das ist ja schon bekannt 
Gruß
300P

[DS_Starter]

Wir hatten es vorhin bezüglich KI und Trefferquote.
Meine KI mit OpenMeteo erreichte heute 1,4 % und gestern 3,6 % Tagesabweichung.

Da ich eine Victron-Anlage habe, kann ich auch die von Victron bereitgestellte KI-basierte PV-Prognose nutzen. Sie basiert auf dem SolCast-Dienst, den wir im Modul ebenfalls nutzen können. Leider haben neuere Accounts nur noch 10 freie Calls pro Tag.

Jedenfalls hatte meine Victron-Instanz gestern eine Tagesabweichung von 0! Prozent, also 100% Übereinstimmung von Prognose und Realität. Das hatte ich bisher noch nie! Heute hat diese Instanz auch wieder -5,2 % Tagesabweichung.

Ich persönlich bin mit diesen Ergebnissen hoch zufrieden. Bei instabilen Wetterlagen und Bewölkungen sind solche Übereinstimmungen nicht so leicht zu erreichen und fallen üblicherweise durchaus höher aus. Auch damit muß man leben auch wenn wir an stetigen Verbesserungen arbeiten.

[300P]

Bei mir ist die Prognose / Trefferquote auch relativ treffsicher im gleichen Bereich immer etwas unterhalb der Vorhersage. Das kommt durch Erweiterung eines neuen PV-String im März und dauert halt seine Zeit.

Beim Verbrauch gibts logischerweise z.Z. keine guten Treffer
Der Grund
->> Eine Umstellung von Gas/Brennstoffzelle auf Elektr.-WP muss sich erst in den Verbrauchswerten langsam einfinden....

Anbei meine Werte:

Gruß
300P

[DS_Starter]

Interessant ... wir fast den geichen Haus(grund)verbrauch. 

[300P]

Hab dein System für solche Zwecke "gehacked"   

[tobi01001]

Interessant ... wir fast den geichen Haus(grund)verbrauch. 

Meinst du die 473 W? Die hab ich auch
Du darfst diesen Dateianhang nicht ansehen.

Aber mal was anderes:
Ich habe eine Prognose für Verbrauch.
Ich habe eine Prognose für Produktion.
Ich habe eine Prognose für den SoC der Batterie.

Kann man auch eine (stündliche) Prognose des Netzbezugs haben? Damit könnte ich mir in Verbindung mit Tibber die Kosten vorhersagen und im zweiten Schritt (mache ich bereits über einige andere Berechnungen) Verbraucher nach PV, SoC und Strompreis steuern.

Bei der Batterie habe ich da zudem folgende Herausforderung:
Über den WR kann ich das Entladen der Batterie unterbinden.
Das benutze ich gestaffelt um Kapazität für gewisse Strompreise aufzuheben. (Dadurch wird in teuren Phasen die Energie aus der Batterie bezogen und nicht vom Netz).

Allerdings führte das bei dem aktuellen Wetter dazu, dass nachts die Batterie gesperrt wurde und morgens dann noch mehr als nötig in der Batterie war, unnötig vom Netz bezogen wurde und dann auch noch ins Netz gespeist wurde...

Das würde ich gerne optimieren. Im Moment nutze ich die komplette SoC Vorhersage in Kombination mit Produktionsvorhersage und Verbrauchsvorhersage.
Ist morgige Produktion > Verbrauch und ist der vorhergesagte SoC niemals 0%, wird die Batterie unabhängig Strompreis etc. freigeschalten. Andernfalls greift die Staffelung / Zuordnung SoC / Strompreis.

Eventuell hat da jemand bereits was ähnliches umgesetzt oder eine Idee das weiter zu optimieren?

Und letztendlich bleibt da noch die Wärmepumpe als theoretischer Großverbraucher. Der Verbrauch der WP hängt dabei maßgeblich von Außentemperatur (wegen Heizung) und Warmwasserverbrauch ab. Gibt es (eventuell in einer fernen Zukunft) die Möglichkeit ein Verbrauchsvorhersage über die KI mit der Wettervorhersage in Verbindung zu bringen?

Das sind so die Dinge die sich aktuell angesammelt haben...

Danke für das Super Modul und noch einen schönen Abend,
Tobi

[DS_Starter]

Hallo Tobi,

heute Abend bin ich nicht mehr in der Lage tiefere Überlegungen anzustellen.
Aber ich habe mir deinen Post-Link für eine spätere Bearbeitung abgespeichert.

LG,
Heiko

[tpm88]

Auch ich bin begeistert ob der Trefferquote. Die Abweichung betrug jetzt den dritten (!!) Tag in Folge < 1% 

OpenMeteo API, Dachanlage mit zwei Strings ( Süd, Nord ) in Kombination mit einem BKW mit Mikroinverter.

Ein fettes DANKE für das Modul und die stetige Weiterentwicklung!