Leistungsprognose für Wechselrichter

[DS_Starter]

Ändere bei mal bitte die Zeile über "if(IsNumeric ($wcc)) {" bei dir so ab:

Code Auswählen Erweitern


my $wcc = $hfcg->{$i}{wcc} // "-";                                                                 # Bewölkungsgrad ergänzen


wie sieht es dann aus ?

LG

[kaizo]

Super!

Mit dieser Korrektur habe ich in den letzten Minuten keine Fehlermeldungen im Log. Passt.

Danke!

[DS_Starter]

Danke dir. Ich übernehme die Korrektur in die nächste Version.
Konnte ich gerade nicht direkt machen weil ich mitten in der Integration der SolCast API bin.

LG

[kaizo]

SolCast-API?

Hört sich gut an, die habe ich auch am laufen und vergleiche schon mal die Prognosen zwischen DWD, SolCast und Fronius.

Bin gespannt...

[giulup]

Es gibt da die Möglichkeiten der Setter:

energyH4Trigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Generiert Trigger bei Über- bzw. Unterschreitung der 4-Stunden PV Vorhersage (NextHours_Sum04_PVforecast).
Überschreiten die letzten drei Messungen der 4-Stunden PV Vorhersagen eine definierte Xon-Bedingung, wird das Reading energyH4Trigger_X = on erstellt/gesetzt. Unterschreiten die letzten drei Messungen der 4-Stunden PV Vorhersagen eine definierte Xoff-Bedingung, wird das Reading energyH4Trigger_X = off erstellt/gesetzt.
Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.

    Beispiel:
    set <name> energyH4Trigger 1on=2000 1off=1700 2on=2500 2off=2000 3off=1500



powerTrigger <1on>=<Wert> <1off>=<Wert> [<2on>=<Wert> <2off>=<Wert> ...]

Generiert Trigger bei Über- bzw. Unterschreitung bestimmter PV Erzeugungswerte (Current_PV).
Überschreiten die letzten drei Messungen der PV Erzeugung eine definierte Xon-Bedingung, wird das Reading powerTrigger_X = on erstellt/gesetzt. Unterschreiten die letzten drei Messungen der PV Erzeugung eine definierte Xoff-Bedingung, wird das Reading powerTrigger_X = off erstellt/gesetzt.
Es kann eine beliebige Anzahl von Triggerbedingungen angegeben werden. Xon/Xoff-Bedingungen müssen nicht zwingend paarweise definiert werden.

    Beispiel:
    set <name> powerTrigger 1on=1000 1off=500 2on=2000 2off=1000 3on=1600 4off=1100


Damit kann man auch arbeiten. Alternativ wäre es auch kein Hexenwerk ein Reading Today_MaxPVForeCastValue bzw. Today_MaxPVForeCastTimeStamp einzubauen sofern man soetwas noch benötigen sollte.

Grüße,
Heiko

Hallo,

Heute war mal wieder ein Tag an dem ich es hätte gebrauchen können. Deswegen kam ich auf die Idee mal wieder hier reinzuschauen.
Die Trigger würden mir leider nicht helfen, da ich dann nicht weiss ob es in Zukunft evtl mehr Erzeugung gibt.
Hilfreich wäre Tatsächlich eins der Readings  Today_MaxPVForeCastValue bzw. Today_MaxPVForeCastTimeStamp einzubauen.
Damit könnte ich dann eine Bedingung bauen, dass zu der Zeit mit maximaler Leistung wenigstens möglichst viel genutzt wird.

Heute ist ein sehr wechselhafter Tag bei uns und die Wärmepumpe hat wie vorgesehen um 12:30 Uhr Warmwasser gemacht obwohl jetzt der Himmel deutlich klarer ist und das Forecast das auch angezeigt hat. Wie könnte ich dann das neue Reading nutzen?

[DS_Starter]

Hilfreich wäre Tatsächlich eins der Readings  Today_MaxPVForeCastValue bzw. Today_MaxPVForeCastTimeStamp einzubauen.
Damit könnte ich dann eine Bedingung bauen, dass zu der Zeit mit maximaler Leistung wenigstens möglichst viel genutzt wird.

Bin gerade mit der SolCast API beschäftigt. Wenn ich damit durch bin baue ich diese Readings gerne mit ein.

Es ist natürlich zu beachten, dass die Vorhersage dynamisch ist und sich über den Tag verändern kann. Schnell wechselnde Bewölkung ist immer eine Herausforderung den besten Zeitpunkt zu erwischen.

Nutzen könnte man diese Readings zum Beispiel in folgender Weise:

- Man registriert den Consumer mit den üblichen Parametern die man möchte, setzt aber den auto -Parameter auf ein Reading (in dem Consumerdevice) welches den Wert 0 hat. Das bedeutet das Modul plant so wie die Logik es vorgibt, schaltet aber nicht ein weil auto nicht freigegeben ist solange der Readingwert 0 ist.

- Mit einer eigenen Routine wertet man das Reading Today_MaxPVForeCastTimeStamp aus und zum gegebenen Zeitpunkt veranlasst:
    * setze auto-Reading = 1  (im Consumerdevice)   und
    * set ... consumerImmediatePlanning <Verbrauchernummer>

Damit wird der Verbraucher veranlasst zu der von dir bestimmten Zeit zu starten und schaltet automatisch entsprechend der sonst gegebenen Bedingungen im Consumer-Attribut wieder aus.

LG

 

[giulup]

Nutzen könnte man diese Readings zum Beispiel in folgender Weise:

- Man registriert den Consumer mit den üblichen Parametern die man möchte, setzt aber den auto -Parameter auf ein Reading (in dem Consumerdevice) welches den Wert 0 hat. Das bedeutet das Modul plant so wie die Logik es vorgibt, schaltet aber nicht ein weil auto nicht freigegeben ist solange der Readingwert 0 ist.

- Mit einer eigenen Routine wertet man das Reading Today_MaxPVForeCastTimeStamp aus und zum gegebenen Zeitpunkt veranlasst:
    * setze auto-Reading = 1  (im Consumerdevice)   und
    * set ... consumerImmediatePlanning <Verbrauchernummer>

Damit wird der Verbraucher veranlasst zu der von dir bestimmten Zeit zu starten und schaltet automatisch entsprechend der sonst gegebenen Bedingungen im Consumer-Attribut wieder aus.

LG

Leider habe ich mich noch nicht mit den Consumern beschäftigt und finde in der Commandref und der Device specific help noch keine Infos zum Modul. Wo kann ich mich dazu weiter informieren?

[DS_Starter]

Wenn du ein SolarForecast Device definiert hast gibt es eine sehr ausführliche Hilfe zu dem Modul mit

Code Auswählen Erweitern


help SolarForecast de


in der FHEMWEB Kommandozeile.
Das Modul ist noch nicht offiziell eingecheckt, deswegen gibt es noch keinen Eintrag in der commandref.
Device specific help geht auch sofern du attr language DE im global Device eingestellt hast. Dann werden auch diverse Anzeigen des Moduls in deutsch vorgenommen.

Fragen natürlich gerne hier.

[giulup]

Wenn du ein SolarForecast Device definiert hast gibt es eine sehr ausführliche Hilfe zu dem Modul mit

Code Auswählen Erweitern


help SolarForecast de


in der FHEMWEB Kommandozeile.
Das Modul ist noch nicht offiziell eingecheckt, deswegen gibt es noch keinen Eintrag in der commandref.
Device specific help geht auch sofern du attr language DE im global Device eingestellt hast. Dann werden auch diverse Anzeigen des Moduls in deutsch vorgenommen.

Fragen natürlich gerne hier.

Ah so klappts. Dann gönne ich mir mal das neue Wissen.

[giulup]

Bin gerade mit der SolCast API beschäftigt. Wenn ich damit durch bin baue ich diese Readings gerne mit ein.

Es ist natürlich zu beachten, dass die Vorhersage dynamisch ist und sich über den Tag verändern kann. Schnell wechselnde Bewölkung ist immer eine Herausforderung den besten Zeitpunkt zu erwischen.

Nutzen könnte man diese Readings zum Beispiel in folgender Weise:

- Man registriert den Consumer mit den üblichen Parametern die man möchte, setzt aber den auto -Parameter auf ein Reading (in dem Consumerdevice) welches den Wert 0 hat. Das bedeutet das Modul plant so wie die Logik es vorgibt, schaltet aber nicht ein weil auto nicht freigegeben ist solange der Readingwert 0 ist.

- Mit einer eigenen Routine wertet man das Reading Today_MaxPVForeCastTimeStamp aus und zum gegebenen Zeitpunkt veranlasst:
    * setze auto-Reading = 1  (im Consumerdevice)   und
    * set ... consumerImmediatePlanning <Verbrauchernummer>

Damit wird der Verbraucher veranlasst zu der von dir bestimmten Zeit zu starten und schaltet automatisch entsprechend der sonst gegebenen Bedingungen im Consumer-Attribut wieder aus.

LG

Ok nachdem ich mich eingelesen habe ist mir noch etwas unklar warum ich die Wärmepumpe als Consumer anlegen soll. Kann ich denn nicht direkt das timestamp aus dem Reading Today_MaxPVForeCastTimeStamp nutzen um die Wärmepumpe zu schalten?

Zusätzliche Frage: Wenn ich dem Consumer vorgebe, dass er 2 Std laufen muss, werden diese Std am Stück laufen gelassen oder erlaubt die Einstellung dem Gerät die Zeit auf den Tag zu verteilen?

[DS_Starter]

Ok nachdem ich mich eingelesen habe ist mir noch etwas unklar warum ich die Wärmepumpe als Consumer anlegen soll. Kann ich denn nicht direkt das timestamp aus dem Reading Today_MaxPVForeCastTimeStamp nutzen um die Wärmepumpe zu schalten?

Ja, natürlich. Ich ging davon aus, dass du die Consumerschaltlogik des Moduls nutzen möchtest. Man kann, muß natürlich nicht.

Zusätzliche Frage: Wenn ich dem Consumer vorgebe, dass er 2 Std laufen muss, werden diese Std am Stück laufen gelassen oder erlaubt die Einstellung dem Gerät die Zeit auf den Tag zu verteilen?

Bedingt ...
Der Consumerschlüssel interruptable erlaubt es das Device innerhalb der geplante Start- und Endezeit unter Auswertung externer Bedingungen temporär auszuschalten. Bei geschickter Parametriesierung könnte man so eine Planung über fast  den gesamten Tag erstellen lassen und die "Ein"-Zeiten über "interruptable" steuern.

[giulup]

Super. Danke für die Antwort.
Dann warte ich gespannt auf das update. Der interruptableschlüssel ist interessant, ich überlege mir mal ob ich mögliche Szenarien habe in denen ich das brauche.

[DS_Starter]

Mal schauen ob ich noch vor meinem Urlaub nächste Woche dazu komme.
Um ein bisschen mit der Consumersteurung warm zu werden empfiehlt sich erstmal mit einem Dummy zu über wie ich es in #1478 beschrieben habe.

[DS_Starter]

Hallo zusammen,

im contrib liegt die V 0.68.0.
Mit dieser Version ist nun die SolCast API integriert.

Um die API zu aktivieren, schaltet man currentRadiationDev  auf SolCast-API.
Wie gewohnt wird man durch das Setup geführt.
Es gibt neue Setter und Getter: roofIdentPair , moduleRoofTops  , roofTopData , solCastData .

Alles ist wieder genau dokumentiert. Die Daten von der API sieht man mit solCastData. Automatisch werden die Daten jede Stunde zwischen Sonnenauf- und Untergang abgerufen (siehe Reading nextSolCastCall).
Manuell geht der Abruf jederzeit mit roofTopData.
Denkt daran ... man hat pro Tag nur 50 Calls frei. 

Ich denke ihr kommt mit dem Setup problemlos klar, bitte lest euch zu jedem Step die Hilfe genau durch.
Ansonsten fragen ... dann weiß ich auch wo noch etwas unklar sein sollte.

Ich verwende momentan das gelieferte pv_estimate. Die ersten Ergebnisse waren bisher noch nicht so überzeugend.
Allerdings liefert die API auch noch pv_estimate10 und pv_estimate90. Diese Werte stellen eine Streuung bzw. eine untere bzw. obere Grenze der zu erwartenden PV dar. Ich tüftele noch daran dem User über ein Attr die Möglichkeit zu geben seine Anlage in Richtung pv_estimate10 oder pv_estimate90 zu verschieben oder eine Mischkalkulation zu fahren.

Aber ich muß selbst noch einige Erfahrungen sammeln, die Zeit war zu kurz bisher.

Viel Spaß !
Heiko

[DS_Starter]

Also heute spielt die SolCast API gegenüber dem DWD seine Vorteile voll aus. DWD meint hier fällt leichter Regen (mit entsprechender Bewölkung), dabei scheint zur Zeit die Sonne und kaum Wolken.
SolCast API erkennt diesen Zustand problemlos und passt die estimate Werte an.
Gefällt mir ....