76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[ch.eick]

@ch.eick: Bin ganz bei Dir: Richtig konfiguriert liefert SF in aller Regel eine wirklich gute Prognose. In meinem vorherigen Beitrag wollte ich auch auch nicht in Richtung Verbesserung der Prognosesoftware SF gehen, sondern in Richtung der erforderlichen Datenquellen für eine gute Prognose durch SF. Insbesondere bei letzteren dürften bei dynamischer Abregelung noch Herausforderungen entstehen, da dann ja eine lieb gewonnene Datenquelle (Einspeiseleistung) nicht mehr in vollem Umfang zur Verfügung steht. Meines Erachtens haben das noch viele Leute überhaupt nicht auf dem Schirm.

Wie Heiko schon geschrieben hat würde das automatische Lernen der KI gestört werden.
Bei meiner Prognose Variante werde ich mal die Abregelung mit in die Datensammlung aus der MySQL einbauen und die Datensätze dann verwerfen.

PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.

Die 0W sind doch am SmartMeter, da wird der Haushalt und der Speicher doch trotzdem versorgt.

[Parallix]

@ch.eick: Bin ganz bei Dir: Richtig konfiguriert liefert SF in aller Regel eine wirklich gute Prognose. In meinem vorherigen Beitrag wollte ich auch auch nicht in Richtung Verbesserung der Prognosesoftware SF gehen, sondern in Richtung der erforderlichen Datenquellen für eine gute Prognose durch SF. Insbesondere bei letzteren dürften bei dynamischer Abregelung noch Herausforderungen entstehen, da dann ja eine lieb gewonnene Datenquelle (Einspeiseleistung) nicht mehr in vollem Umfang zur Verfügung steht. Meines Erachtens haben das noch viele Leute überhaupt nicht auf dem Schirm.

Wie Heiko schon geschrieben hat würde das automatische Lernen der KI gestört werden.
Bei meiner Prognose Variante werde ich mal die Abregelung mit in die Datensammlung aus der MySQL einbauen und die Datensätze dann verwerfen.

Zu einer Störung dürfte es bei einer gut trainierten KI nur dann kommen, wenn nicht erkennbar ist, warum sich Dinge anders verhalten. Daher ist es ganz wichtig, dass die KI weiß, wenn der Fall "Abregelung" vorliegt und wie stark die Abregelung dann ausfällt.

PS:Was auch einige nicht auf dem Schirm haben ist, dass die Ladeleistung bei vielen Wechselrichtern nicht auf 0W sondern auf einen kleinen Wert gesetzt werden sollte, da andernfalls auch eine vom Speicher ausgelöste Notladung vom WR nicht mehr bedient werden kann.

Die 0W sind doch am SmartMeter, da wird der Haushalt und der Speicher doch trotzdem versorgt.

Es ging um die Ladeleistung vom WR in Richtung des DC-gekoppelten Speichers!

[Prof. Dr. Peter Henning]

Daher ist es ganz wichtig, dass die KI weiß, wenn der Fall "Abregelung" vorliegt und wie stark die Abregelung dann ausfällt.

Leute, bitte bedenkt: Eine KI - jedenfalls die Typen, die Ihr verwendet - weiß GAR NICHTS. So etwas wie feste und unumstößliche Regeln könnt Ihr dem System nicht beibringen.

LG

pah

[Parallix]

...
Leute, bitte bedenkt: Eine KI - jedenfalls die Typen, die Ihr verwendet - weiß GAR NICHTS. So etwas wie feste und unumstößliche Regeln könnt Ihr dem System nicht beibringen.

Warum sollte es nicht mittels "Reinforcement Learning" und einem geeigneten Belohnungsschema zu machen sein?

[Max_Meyer]

Verbrauchsprognose vom kommenden Sonnenuntergang bis zum kommenden Sonnenaufgang. Ist der Sonnenuntergang
bereits vergangen, ist es die Verbrauchsprognose ab aktueller Zeit (Nacht) bis zum kommenden Sonnenaufgang.

Hallo Heiko,
zuerst einmal DANKE für die vielen Ideen die du in dieses tolle Modul einfließen lässt!

Trotzdem, jedes neue Feature erzeugt neue Wünsche   - in meinem Falle geht es um prognosegeführte Steuerung der WP - sozusagen der der größte Energiefresser (ca. 3500 kWh/a) unter den Verbrauchern  und 'unglücklicher Weise ist sie gerade im Winter am gefräßigsten - man will ja nicht frieren so gehen über 60% des externen Bezugs   auf die Heizung zurück.
Die WP ist auch dahingehend ein Sonderfall-Verbraucher weil diese sehr saisonal (bei mir nur in der Heizperiode) im Einsatz ist - aber so wie ich das verstanden habe, werden alle Verbraucher gemittelt erfasst - so dass sich der Verbrauch über das Jahr und alle consumer verschleift so das die WP nicht wirklich auftaucht.
Generisch gesehen ist die WP(+Puffer) in gewisser Weise wie eine Batterie - es wird Energie eingespeichert wenn sie günstig ist und entnommen solange was drin ist.
Die Frage ist ob sich sowas (leicht - mit überschaubaren Aufwand) in einem Batterie-ähnlichen Device abbilden lassen würde?
Mir sind dabei 2 Szenarien im Sinn:
- die WP mit der Überschussleistung füttern um den Puffer wärmer zu machen als er müsste solange Sonne scheint (ungeregelt mach ich das seit Jahren WP als Prio1) lässt sich verbessen mit Prognosewerten
- die WP mit einem errechneten Konstantwert (gesamtenergiebetrag pro tag geteilt durch 24) theoretisch 24h mit geringer Leistung durchlaufen zu lassen dadurch steigt der COP (theoretisch 10-20%) bei ungenügenden Sonnenschein. Voraussetzung wäre eine 'Energieprognose'

next topic:

Das wäre im Prinzip identisch den Ertragswert = Prognosewert zu setzen, falls der Abregelungsstatus vorliegt. Kann man machen. SF muß in jedem Fall über den Abregelungsstatus informiert werden. Tritt dieser Status auch nur zu einem gewissen Teil einer Stunde (z.b. 20 Minuten) ein, wäre der Datensatz dieser Stunde als komprimitiert und als entspechend zu behandeln vorzusehen

warum nutzt du nicht den Parameter 'Limit' aus dem setupInverterDevXX? Die Gültigkeit Regel 'Ertragswert = Prognosewert' wäre auch (relativ) simpel. Der Wert (von limit) könnte bei Bedarf dynamisch von user gesetzt werden.

next topic:
ich habe mir mal stichpunktartig die Daten Today_Hourxx_PVforecast in Bezug auf die summierten Readings dazu angeschaut und leichte Diskrepanzen festgestellt --> siehe screens
Abweichung ist nicht groß nur verwunderlich  - ist das plausibel oder hab ich falsch gerechnet?

last topic:
nur zur Info - ich habe mal mit aiTreesPV 'herumgespielt' und die auf 10, 30, 40 gesetzt - auf unterschiedlichen RPI-Devices - hab CPU und RAM mitgeloggt und die Abweichung verglichen - Ergebnis: in keinem Falle wurde mehr als 35% RAM verwendet (für alle Anwendungen) und die war sinnigerweise bei der 10er im Schnitt am besten (gleiche Daten)
Gruß Gerd

[DS_Starter]

Hallo Gerd,

viele Fragen auf einmal ... 

Wärmepumpe:

die WP mit der Überschussleistung füttern um den Puffer wärmer zu machen als er müsste solange Sonne scheint (ungeregelt mach ich das seit Jahren WP als Prio1) lässt sich verbessen mit Prognosewerten

Vermutlich habe ich es noch nicht wirklich verstanden worum es dabei eigentlich geht. Wenn es nur darum geht einen vorhandenen PV-Überschuß in der WP zu "verbrauchen" kann man doch einen Consumer entsprechen konfigurieren. Vllt. kannst du das Anliegen noch etwas anders formulieren.

warum nutzt du nicht den Parameter 'Limit' aus dem setupInverterDevXX? Die Gültigkeit Regel 'Ertragswert = Prognosewert' wäre auch (relativ) simpel.

Du meinst damit sicherlich, dass man "limit" als Signal für die Abregelung der Anlage verwenden könnte? D.h. wird die Anlage abgeregelt, setzt man z.B. limit=0. Im Prinzip ginge das, hätte aber zur Folge dass der User u.U. in allen vorhandenen WR setzen müßte. Anlagen regeln aber nicht unbedingt auf 0, sondern evtl. nur soweit herunter bis ein bestimmter Einspeisewert unterschritten ist. Gibt bestimmt viele Varianten. In jedem Fall ist der Ertrag dann künstlich vermindert und der Datensatz in der Stunde bildet nicht die eigentlich realen Verhältnisse ab. Mir schwebt da schon etwas vor. 

ich habe mir mal stichpunktartig die Daten Today_Hourxx_PVforecast in Bezug auf die summierten Readings dazu angeschaut und leichte Diskrepanzen festgestellt --> siehe screens
Abweichung ist nicht groß nur verwunderlich  - ist das plausibel oder hab ich falsch gerechnet?

Wahrscheinlich ein Mißverständnis. Die Today_HourXX_PVforecast beeinhalten die PV Prognose für die Stunde des Tages. Die NextHours_SumXX_PVforecast die Summe der PV Prognose für die nächsten XX Stunden, wobei die verstrichenen Minuten berücksichtigt werden, also z.B. von jetzt 19:23 bis 20:23 bei NextHours_Sum01_PVforecast. Natürlich ist es wiederum nur eine Näherung, denn die PV-Verteilung innerhalb einer Stunde ist (insbesondere zu dieser Tageszeit) nicht linear. Aber für bestimmte Anwendungen war dies mal ein User-Wunsch den ich gern umgesetzt habe.

LG,
Heiko
   

[DS_Starter]

Im Wiki habe ich die Steuerungsreadings des Moduls für die Batteriesteuerung in einem Abschnitt zusammengefasst erläutert.

[Parallix]

...
Anlagen regeln aber nicht unbedingt auf 0, sondern evtl. nur soweit herunter bis ein bestimmter Einspeisewert unterschritten ist
...

Da letzteres zumindest die vom VNB ggf. zu bedienende Forderung ist, ist dies die Abregelung, die in aller Regel gemeint ist. Die die dann noch maximal zulässige Einspeiseleistung (Toleranzen mal ausgenommen) bestimmt sich dann stets auf einen Prozentwert der Modulleistung. Im Relais-Fall wären das 0%, 30%, 60% und 100% und im EEBUS-Fall alle Werte in [0%,100%]. Hieraus lässt sich entnehmen, dass die Nutzung von EEBUS zur Steuerung gegenüber dem Relais-basisertem Verfahren u.a. Einspeisevorteile hat bzw. haben kann. Denn bei einer fiktiven beispielhaften Forderung einer Abregelung auf nur 90% müsste ein nicht EEBUS verwendendes System bereits auf 60% abregeln.

[Max_Meyer]

vermutlich habe ich es noch nicht wirklich verstanden worum es dabei eigentlich geht. Wenn es nur darum geht einen vorhandenen PV-Überschuß in der WP zu "verbrauchen" kann man doch einen Consumer entsprechen konfigurieren. Vllt. kannst du das Anliegen noch etwas anders formulieren.

Hallo Heiko,
du hast recht - ich habe das ziemlich oberflächlich beschrieben - was ich meine ist das eine WP mit Puffer im Prinzip die gleichen Steuersignale braucht wie eine Batterie die konstant geladen werden soll. Um zu verdeutlichen was ich gern erreichen will habe ich ein typisches Schaltspiel eines Heiztages rangehangen und skizziert was ich gern erreichen möchte. Die Idee kam mir bei der Diskussion zu den zusätzlichen Bat-Readings. Falls meine Gedanken abwegig sind und/oder eine Implementation viel Aufwand verursacht ist es auch kein Problem meine bestehende Logik mit vorhanden Signalen aus SF verfeinern - aber eben ohne KI-Unterstützung

Du meinst damit sicherlich, dass man "limit" als Signal für die Abregelung der Anlage verwenden könnte? D.h. wird die Anlage abgeregelt, setzt man z.B. limit=0. Im Prinzip ginge das, hätte aber zur Folge dass der User u.U. in allen vorhandenen WR setzen müßte. Anlagen regeln aber nicht unbedingt auf 0, sondern evtl. nur soweit herunter bis ein bestimmter Einspeisewert unterschritten ist. Gibt bestimmt viele Varianten. In jedem Fall ist der Ertrag dann künstlich vermindert und der Datensatz in der Stunde bildet nicht die eigentlich realen Verhältnisse ab. Mir schwebt da schon etwas vor. 

ja das hatte ich gedacht - es ist wie Parallix schreibt - gilt aber für die komplette Anlage - ich bin gespannt was dir einfällt

Gruß Gerd

[DS_Starter]

@all,

ich habe die Arbeit von Wzut mit den neuen Batteriesymbolen implementiert und den Ladezustand an das Icon gebracht. Im Anhang seht ihr das Ergebnis.
Ich persönlich finde die Darstellung mit diesen Icons moderner. Danke Wzut!

Wenn es gewünscht ist, kann ich die SoC-Beschriftung optional gestalten.

Version 1.52.19 liegt in meinem contrib.


@Gerd,
deine WP-Geschichte schaue ich mir morgen nochmal an. Heute bekomme ich keinen gescheiten Gedanken mehr hin. 

LG,
Heiko

[Prof. Dr. Peter Henning]

ich habe die Arbeit von Wzut mit den neuen Batteriesymbolen implementiert und den Ladezustand an das Icon gebracht. Im Anhang seht ihr das Ergebnis.

Wie immer, Danke für die Arbeit. Mal aus ergonomischer Sicht betrachtet.

Wettersymbole nicht ausreichend voneinander unterscheidbar. Unterschiedliche Farbgebung Wolken/Sonne könnte das verbessern - da müsste mal jemand eine Fleißarbeit machen.
 
Batterieymbole und Beschriftung OK, etwas weniger Helligkeitskontrast beim Icon würde die Erkennbarkeit der Zahlen verbessern. Warum nicht die Schrift kleiner machen und horizontal anordnen?

Balkendiagramm: Wie schon gesagt, ist das wegen der abwechselnden Anordnung (mal oben, mal unten) ebenfalls schwer zu erfassen.

LG

pah

Warum sollte es nicht mittels "Reinforcement Learning" und einem geeigneten Belohnungsschema zu machen sein?

Weil Statistik immer Statistik bleibt. Neuronale Netze kennen keine festen Regeln.

LG

pah

[Wzut]

Wettersymbole nicht ausreichend voneinander unterscheidbar.

Warum nicht die Schrift kleiner machen und horizontal anordnen?

a. ja die Wetter Icons, wir hatten damals nach der SMA Umstellung und den Wechsel zu DWD nicht genug passende Wetter Icons in FHEM. Also war die erste Überlegung welche der vielen möglichen Codes von DWD wir überhaupt verwenden wollen und welche Symbole uns daher noch fehlen. Da ich nun leider ein lausiger Maler bin und eher der Typ gnadenloser Kopierer, habe ich vorhande Wettersymole verändert. Zum Teil durch löschen von Elementen oder kopieren von Teilen von einem Icon zum anderen.

b. ja mir persönlich gefällt es auch besser die Schrift im Innernraum des Icons zu haben, aber wie bereits geschrieben ist dann wieder das Problem der optimalen Farbe für den möglichen Rot-Grün und Style möglichen Hintergrund. Aber Heiko schrieb ja auch das die Art der Darstellung hauptsächlich ein Ersatz der fehlenden Hoover Funktion beim Tablet/Handy sein soll.

[DS_Starter]

Moin,

Warum nicht die Schrift kleiner machen und horizontal anordnen?

Ich habe das auch mal umgesetzt (siehe Screenshots) und die V ins contrib geladen.
Wenn ich die Beschriftung optional gestalte (ein Schlüssel im setupBatteryDevXX) ist eine Auswahl ohne/links daneben/unterhalb der Batterie kein Problem. Dann kann der User selbst bestimmen was er gern hätte. Diese Option wäre übrigens ganz hilfreich, da man ja auch Differenzwerte zwischen den Balkenwerten in der Grafik andrucken kann, was in diesem Fall eine Darstellung des SOC neben den Batterien als bessere Variante erscheinen lässt.

Balkendiagramm: Wie schon gesagt, ist das wegen der abwechselnden Anordnung (mal oben, mal unten) ebenfalls schwer zu erfassen.

Deine Anmerkung von weiter vorn habe ich noch auf dem Plan. graphicControl->scaleMode kann zur Zeit lin, log. Hinzu kommen könnte noch ein "staple". Vllt. hat jemand (Wzut?) schonmal Zeit und Lust sich diese Variante mal anzuschauen?

LG,
Heiko

[Wzut]

Vllt. hat jemand (Wzut?) schonmal Zeit und Lust sich diese Variante mal anzuschauen?

Kein Problem , sag mir was ich konkret tun soll. Im Moment versteh ich es nämlich nicht, auch was Peter mit "mal oben mal unten" meint. IMHO steht die Zahl immer oben am Ende das Balkens und der kleinere steht immer vor dem größeren.

[DS_Starter]

Peter hatte die Idee, die beiden Balken quasi als "Stapel aufeinandergestellt" darzustellen, also z.B. im unteren Bereich immer den primären Balken, darüber immer den sekundären Balken mit ihren jeweiligen Werten und Farben. Dabei müsste man sich vermutlich noch um eine Normierung Gedanken machen damit die Höhe beider Anteile zusammen nicht grösser wird wenn man den größten Einzelwert = 100% annimmt.
Nur mal so ins unreine gesprochen ... bei der Umsetzung kommen dann vermutlich die Gedanken ....