Leistungsprognose für Wechselrichter

[DS_Starter]

@Guido

Im Bezug auf die verfügbaren 50 API-Calls fände ich eine Anzeige von "24/26" besser oder alternativ  "12/13" Updates-Zyklen.

Wo du recht hast ....

Liegt im contrib.

[cwagner]

Ich hatte die ersten Experimente mit ertragsgesteuerten Verbrauchern zunächst abgebrochen, weil ich auch reihenweise Meldungen ins Log bekam. Da das Thema gerade ansteht, hier meine Beobachtung:

Code: [Auswählen]

2022.10.03 13:19:24 2: SolarVorschau - switching Consumer "A.Kuehltruhe" to "on" (Automatic = 1)
2022.10.03 13:20:34 2: SolarVorschau - switching Consumer "A.Kuehltruhe" to "on" (Automatic = 1)
2022.10.03 13:21:44 2: SolarVorschau - switching Consumer "A.Kuehltruhe" to "on" (Automatic = 1)
2022.10.03 13:22:54 2: SolarVorschau - switching Consumer "A.Kuehltruhe" to "on" (Automatic = 1)

Jedes Mal bekommt wird der eingeschaltete Verbraucher auch noch einmal eingeschaltet, was nur ein Schönheitsfehler ist, solange ich nicht mit einem Funkaktor arbeitete. Da würde ich mir nämlich, vor allem bei mehreren das Sendelimit aufzehren.

Herzliche Grüße
Christian W

[DS_Starter]

@Dracolein, dein gemeldetes Problem konnte ich jetzt auch lösen.
Es lag an einer fehlerhaften Berechnung des resultierenden Überschusses in Abhängigkeit ob im aktuellen Verbrauch die Leistung des betroffenen Verbrauchers bereits entahlten war, d.h. die Abhängigkeit zum aktuellen On/Off Status des Devices hat gefehlt.
Bei kleineren Leistungsaufnahmen in Bezug zur PV Erzeugung ist das nicht aufgefallen.

Korrigierte V liegt im contrib.

[DS_Starter]

@Dracolein, die Lösung war noch nicht umfassend.
Habe nochmal die V im contrib korrigiert.
Bitte nochmal ziehen.

[Dracolein]

Geladen, neugestartet, werde beobachten. Herzlichen Dank für den Aufwand und die Mühe bis hierher.

by the way, was bedeuten die zwei unterschiedlichen Balkenfarben nun eigentlich in der grafischen Balkendarstellung ? 

[DS_Starter]

@Christian W,
das von dir gemeldete Verhalten ist erstmal kein Fehler.
Folgender Sachverhalt ... wenn ein Verbraucher eingeschaltet werden soll, sendet das Modul an den Verbraucher das Einschaltsignal (aus dem Schlüssel "on") und setzt den Status auf "Switching on".
Der Verbraucher sollte nun einschalten. Im nächsten Zyklus wird geprüft ob der Verbraucher wirklich "on" ist.
Das passiert durch Vergleich mit der Angabe im Schüssel "swstate on-Regex".
Der Ablauf im Log ist im Normalfall so:

Code: [Auswählen]

2022.10.03 15:44:39.804 2: SolCast5 - switching Consumer "SolarForecast Consumer Dummy" to "on" (Automatic = 1)
2022.10.03 15:44:39.870 2: SolCast5 - Consumer "SolarForecast Consumer Dummy" switched on
Wenn bei dir mehrfach die Meldung "switching Consumer ... to on" kommt, bedeutet das entweder

- dass der Verbraucher wirklich sehr lange zum Einschalten benötigt. In dem Fall solltest du prüfen ob mit dem Teil (oder dem Steuermodul) etwas nicht in Ordnung ist.

- oder das die Angabe im Schlüssel "on" nicht stimmt

- oder die Angabe zur Prüfung des On-Zustandes im Schlüssel "swstate" nicht ok ist.

Für den Fall des Ausschaltens gilt das Gleiche, nur mit den Schlüssel "off", "swstate off-Regex".
Dieses mehrfache Antriggern für On / Off passiert immer erst nach Prüfung ob der Sollzustand des Consumers erreicht ist.
Das dient der Schaltungssicherheit.

[DS_Starter]

by the way, was bedeuten die zwei unterschiedlichen Balkenfarben nun eigentlich in der grafischen Balkendarstellung ? 

Nun ja es kommt darauf an, was du den Balken zuordnest.
Über die Attr beam1Content  und beam2Content legst du fest welche Werte die Balken darstellen sollen.
Nach deinem Gusto kannst du dann eben auch die Farben auswählen wie sie dir gefallen.

Habe ich deine Frage so richtig verstanden ?

EDIT: mit layoutType kannst du auch "single" setzen um nur einen Balken anzuzeigen.

[cwagner]

Wenn bei dir mehrfach die Meldung "switching Consumer ... to on" kommt, bedeutet das entweder

- dass der Verbraucher wirklich sehr lange zum Einschalten benötigt. In dem Fall solltest du prüfen ob mit dem Teil (oder dem Steuermodul) etwas nicht in Ordnung ist.

- oder das die Angabe im Schlüssel "on" nicht stimmt

- oder die Angabe zur Prüfung des On-Zustandes im Schlüssel "swstate" nicht ok ist.

Für den Fall des Ausschaltens gilt das Gleiche, nur mit den Schlüssel "off", "swstate off-Regex".
Dieses mehrfache Antriggern für On / Off passiert immer erst nach Prüfung ob der Sollzustand des Consumers erreicht.
Das dient der Schaltungssicherheit.

Donnernlütctchen: Das ist a) eine Superantwort auf meine falsche Fehlermeldung und b) wirklich gut durchdacht. Damit bindest Du natürlich auch unidrektionale Aktoren Mit Rückkopplung ein, die man sonst nur mit fire & forget & hope ansteuern kann bzw. sich die Überprüfung durch ein DOIF o.ä. selbst bastelt. Klasse! Und danke, dass Du mir aufgezeigt hast, wo ich die Beschriebung noch nicht richtig verstanden habe. Habe jetzt mal ein swstate=state:ON:OFF eingebaut.

Danke
Christian W

[DS_Starter]

  ... betreibe das Geschäft ja schon ein Weilchen. 


Zur Info ... in der aktuellen contrib-Version ist das Reading Today_PVreal hinzugekommen. Durch den Vergleich mit Today_PVforecast kann man am Ende des Tages die Abweichung feststellen und ggf. über die verschiedenen Stellschrauben nachjustieren. Bei SolCast API zum Beispiel die Anlageneffizienz (Efficiency factor) justieren.

 

[Dracolein]

Nun ja es kommt darauf an, was du den Balken zuordnest.
Über die Attr beam1Content  und beam2Content legst du fest welche Werte die Balken darstellen sollen.

Ah okay, das bedeutet vermutlich, defaultmäßig ist pvForecast und pvReal gesetzt?
Die genannten Attribute habe ich nicht verwendet, sah aber nach einem Modulupdate, dass in einem balken 2 Werte dargestellt sind.
Finde ich cool, wollte nur wissen, was es ist.

Ich finde das Modul ebenfalls als extrem hilfreich. Je tiefer ich mich damit beschäftige,um so besser werden die Verflechtungen. Allein der "auto" Parameter für Consumer-Devices, sehr hilfreich. Habe meine IR-Heizungen nun damit gekoppelt, dass sie deaktiviert werden, wenn Fensterkontaktsensoren einen entsprechenden Status haben oder z.B. dass ebenfalls deaktiviert wird, wenn meine Wallbox das Auto lädt (--> max Power zum Auto).

[DS_Starter]

Ah okay, das bedeutet vermutlich, defaultmäßig ist pvForecast und pvReal gesetzt?

Ja genau. beam1Content => pvReal, beam2Content => pvForecast.

Wenn du übrigens im global Device language = DE einstellst, werden viele Angaben in der Grafik deutsch dargestellt und du bekommst auch gleich die deutsche Hilfe bei den Modulen (sofern vorhanden).

Das Modul ist intern schon wirklich sehr komplex geworden und ich habe mir fest vorgenommen mal ein Wiki dazu anzufangen wenn ein relativer Endzustand der Entwicklung erreicht ist. Sonst ist es einfach viel zu zeitfressend.

[SparcWolf]

Bei SolCast API zum Beispiel die Anlageneffizienz (Efficiency factor) justieren.

Dazu habe ich direkt zwei Fragen:
* Wo wird die Effizienz eingestellt (SolCast Portal, FHEM)?
* Ich habe das Autotuning (pvCorrectionFactor_Auto) eingeschaltet. Das ist ja ein ähnlicher Ansatz. Hast Du hierzu schon eine Empfehlung (Beides / Entweder-oder)?

VG,
  Guido.

[Dracolein]

Gibt es eine Option, registrierte Consumer untereinander zu priorisieren? 

Beispiel anhand meines Szenarios:
Consumer 01 = 500W IR-Heizung, Raum selten genutzt
Consumer 02 = 1200W IR-Heizung, Raum häufig genutzt
Nun wechselt das Wetter, es entsteht langsam ansteigender PV-Überschuss. Zuerst wird Consumer 01 aktiviert, weil rund 500W Überschuss relativ schnell erreicht sind. Damit auch Consumer 02 aktiviert wird, sind nun zusätzliche (!) 1200 Watt erforderlich (= mind. 1700W Überschuss). Das wird schon deutlich seltener erreicht, obwohl Consumer 02 im Vergleich wünschenswerter wäre.

Mein Gedankenexperiment:
Wenn das Modul den aktuell realen PV-Überschuss kennt und ebenfalls weiß, dass Consumer 01 mit 500W bereits aktiviert ist, könnte das Modul berechnen, ob ohne aktivierten Consumer 01 eventuell ausreichend Überschussstrom vorhanden ist, um Consumer 02 einzuschalten.

[DS_Starter]

* Wo wird die Effizienz eingestellt (SolCast Portal, FHEM)?

Es gibt unterschiedliche Verfahren je nachdem ob man als Quelle für die Strahlungsinfo DWD oder die SolCast API nutzt.

Bei Nutzung von DWD empfehle ich die Autokorrektur gleich einzuschalten. Es dauert ohnehin sehr lange bis das Modul gelernt hat und die vielen möglichen Werte der Bewölkung und deren Auswirkung zu speichern und dann für eine Korrektur zu nutzen.
Die Attr cloudFactorDamping und rainFactorDamping (gewissermaßen auch maxVariancePerDay ) dienen in Grenzen dazu die Auswirkungen der gemeldeten Bewölkung / Regen auf die Anlage zu justieren.

Es kommt eigentlich sehr darauf an wie zuverlässig und exakt die DWD Informationen vor allem in Bezug auf die Bewölung an deinem Standort sind.
An einem vollsonnigen Tag ohne Wolken wird man sehr gute Vorhersegen bekommen.

* Ich habe das Autotuning (pvCorrectionFactor_Auto) eingeschaltet. Das ist ja ein ähnlicher Ansatz. Hast Du hierzu schon eine Empfehlung (Beides / Entweder-oder)?

Bei Nutzung des DWD würde ich es nutzen (siehe oben).
Bei Nutzung des SolCast API würde ich pvCorrectionFactor_Auto erstmal ausschalten und versuchen mit dem Efficiency factor in dem Roof Top Editor (SolCast) einen optimalen Punkt zu treffen.

Vermutlich ist bei der SolCast API die pvCorrectionFactor_Auto nicht so hilfreich weil wir dadurch die SolCast Information mit der Info des DWD-Dienstes bezüglich der Bewölkung und des Regens vermischen.
Aber ich bin mir noch nicht sicher, das müssen wir beobachten und ausprobieren.

Auch die SolCast API hat ja auch noch ein Schwankungsbreite. Wenn ihr euch mit "get ... solCastData" die Daten anschaut findet ihr Angaben pv_estimate (die verwendet werden), aber auch pv_estimate10 und pv_estimate90.

Diese Daten stellen Abweichungen dar. Je enger sie beieinander liegen, desto hoher ist die Wahrscheinlichkeit dass pv_estimate zutrifft.
Aber es wird auch bei SolCast beschrieben, dass je nach Lage eher die Werte Richtung pv_estimate10 bzw. pv_estimate90 zutreffen.
In späteren Releases habe ich vor diese Möglichkeiten für den User nutzbar bereitzustellen. Ich muß aber noch mehr bei SolCast zu dem Thema lesen.

LG

[DS_Starter]

Gibt es eine Option, registrierte Consumer untereinander zu priorisieren?

Beispiel anhand meines Szenarios:
Consumer 01 = 500W IR-Heizung, Raum selten genutzt
Consumer 02 = 1200W IR-Heizung, Raum häufig genutzt

Momentan wird ein Priorisierung bei der Planung vorgenommen. Diese richtet sich einfach nach der Consumernummer, also consumer01 vor consumer02 vor consumer03 .... unter Berücksichtigung der sonstigen Rahmenbedingungen (ForeCast, must/can, usw.)

Was du beschreibst ist sozusagen die nächste Stufe der "Eskalation". Ich verstehe das Ziel und ich hatte mich schon daran versucht. Aber die Komplexität steigt je mehr Verbraucher registriert sind. Bei zwei geht das ja noch, denke mal an vllt. 10.
Aber manchmal braucht es nur einen guten Einfall bzw. ein gutes mathematisches Modell.
Manchmal passiert es über Nacht.