Leistungsprognose für Wechselrichter

[DS_Starter]

Moin,

@Guido,

Tagsüber werden alle Werte ohne Nachkommastellen oder mit einer Nachkommastelle angezeigt.
So fände ich das auch am Abend für <Today_PVreal> gut.

Ja, passe ich in kommenden Check In mit an.

@Stefan,

Ich denke da die conForecast Daten nur stündlich vorliegen wird nur stündlich aktualisiert und unter der Stunde keine Korrektur vorgenommen, richtig?

Ja, richtig.

Könnte man den Wert für die Stunde nicht einfach durch die Zeit teilen um auch eine aktualisierung und genaueren Wert auch während einer laufenden Stunde zu haben?

Schaue ich mal wieviel Aufwand das bedeuten würde. Allerdings ist es ohnehin eine Schätzung auf Grundlage vergangener Werte.

Grüße,
Heiko

[stefanru]

Hi Heiko,

ok danke für die Info.
Ja das es eine Schätzung ist ist klar und unter der Stunde würde mir einfach eine lineare reduktion genügen.
Wenn man den Wert mit dem aktuellen Akku Stand, der ja nach Sonnenuntergang ständig weniger wird, verrechnet, gibt das halt blöde Sprünge und taugt zur Anzeige auf dem UI nicht. Es wäre super wenn der Wert sich auch unter der Stunde reduzieren würde.
Das ist natürlich der goldene Wasserhahn, den wahrscheinlich auch nicht viele brauchen, für mein Usecase wäre es aber perfekt

Vielen Dank und Gruß,
Stefan

[kask]

Kann man nicht die Tagesabweichung auch die ganze Zeit anzeigen und nicht erst wenn die Sonne weg ist? (Hatten Wir schon einmal, aber da hieß es das würde nicht gehen weil der Wert am Ende erst feststeht. So aus meiner Erinnerung. Das sehe ich ich jetzt anders.)
Ich habe mir ein UserReading gebastelt der das macht und das funktioniert soweit auch garnicht so schlecht.

Code Auswählen Erweitern

Accuracy { sprintf("%.1f", 100-(100 / ReadingsNum($name,"Today_PVforecast",'0') * (ReadingsNum($name,"RestOfDayPVforecast",'0') + ReadingsNum($name,"Today_PVreal",'0'))  ))." %" ;; }


[DS_Starter]

Hatten Wir schon einmal, aber da hieß es das würde nicht gehen weil der Wert am Ende erst feststeht. So aus meiner Erinnerung. Das sehe ich ich jetzt anders

Nicht gehen war nicht der Punkt, sondern nicht sinvoll eine Tagesabweichung (Today_PVdeviation) vor Ende des Sonnentages zu berechnen.
Wenn es von allgemeinem Interesse ist, kann ich eine solche fortlaufende Abweichung gerne als Statistik-Reading zuschaltbar zur Verfügung stellen.

[DS_Starter]

Die bisherige Testversion 1.0.5 ist jetzt eingecheckt und morgen früh im Update enthalten.
@Guido, dein Hinweis ist auch enthalten.

@Stefan, die "minutengenaue" Prognose conForecast  habe ich nun auch mit eingecheckt.

[stefanru]

Perfekt, dann teste ich mal.

Vielen Dank!

[ChristianOS]

Guten Morgen,
ich habe gestern das Modul neu eingerichtet und bin am Abend auf das Problem gestoßen, dass die Batterienutzung nach Sonnenuntergang zum PV-Ertrag zugerechnet wird. Somit stimmt über Nacht natürlich die Prognose von 0 nicht.
Den Fehler konnte ich bisher nicht ausmachen, warum BatOut als PV Ertrag gerechnet wird.

Meine Anlage:
Fronius Gen24 10.0
Fornius Smart Meter TS 65A-3
Speicher BYD Battery-Box Premium HVM

Quelle für das SolarForcast Modul sind die Werte vom Modul 98_Fronius.

Meine Settings:
currentBatteryDev: Fronius pin=-pout:W pout=PowerFlow_Site_P_Akku:W charge=Storage_0_Controller_StateOfCharge_Relative

currentInverterDev: Fronius pv=PowerFlow_Site_P_PV:W etotal=PowerFlow_Inverters_1_E_Total:Wh capacity=10000
   
currentMeterDev: Fronius gcon=Meter_0_PowerReal_P_Sum:W contotal=Meter_0_EnergyReal_WAC_Sum_Consumed:W gfeedin=-gcon:W feedtotal=Meter_0_EnergyReal_WAC_Sum_Produced:W


Laut plantConfiguration check ist alles OK.
Auch der Reading Wert Current_PV mit 1W passt. Je nachdem wie hell es nachts ist, kommt von der Anlage 0,5W oder so, das wird dann meist auf 1W aufgerundet.

Oben im Modul scheint es auch richtig angezeigt zu werden. Erzeugung aktuell 1W, Verbrauch aktuell 520W.

Für mich sind die angezeigten Werte/Readings plausibel. Komisch nur, dass halt die Batterienutzung als PV Ertrag berechnet wird, obowhl Current_PV nachts passt.

Hat einer eine gleiche Anlage und hat das Modul richtig konfiguriert bekommen?

[stefanru]

Hi Christian, ja hatte das selbe Problem.

PowerFlow_Inverters_1_E_Total zählt auch ohne PV weiter, also hier ist die Batterie mit drin.
Darf es aber nicht.

Ich habe mir dazu ein eigenes reading erzeugt das den PV Strom selbst aufsummiert.
Die logik dazu wurde auch hier im thread diskutiert. Muss ich noch suchen.

Im Endeffekt ist es ein User Reading am WR:
User_Produced_PV:PowerFlow_Site_P_PV.* integral {ReadingsVal("$name","PowerFlow_Site_P_PV","0")/3600000}

und im Forecast Device:
etotal=User_Produced_PV:kWh

Ich kann dir aber empfehlen auch dummy Devices einzuführen, so wie in Heikos Anleitung beschrieben.
Wenn du mal die Anlage erweiterst mit 2 WRs kann Fronius hier auch keine Summen über die WRs bilden.
Das musst du dann in so einem Dummy erledigen.

Gruß,
Stefan

[Heatseeker]

Moin,
Ich wollte gerade ein Consumer anlegen. Einen Lufttrockner. Jedoch soll es noch zwei Bedingungen geben:
Humidity > 70 und DoorState =closed
Bekomme ich das mit dem interuptable hin, oder muss ich das über ein doif machen...

[ChristianOS]

Hi Christian, ja hatte das selbe Problem.

PowerFlow_Inverters_1_E_Total zählt auch ohne PV weiter, also hier ist die Batterie mit drin.
Darf es aber nicht.

Ich habe mir dazu ein eigenes reading erzeugt das den PV Strom selbst aufsummiert.
Die logik dazu wurde auch hier im thread diskutiert. Muss ich noch suchen.

Im Endeffekt ist es ein User Reading am WR:
User_Produced_PV:PowerFlow_Site_P_PV.* integral {ReadingsVal("$name","PowerFlow_Site_P_PV","0")/3600000}

und im Forecast Device:
etotal=User_Produced_PV:kWh

Ich kann dir aber empfehlen auch dummy Devices einzuführen, so wie in Heikos Anleitung beschrieben.
Wenn du mal die Anlage erweiterst mit 2 WRs kann Fronius hier auch keine Summen über die WRs bilden.
Das musst du dann in so einem Dummy erledigen.

Gruß,
Stefan

Hi Stefan,
vielen Dank für deine schnelle Antwort und den wertvollen Tipp. Damit klappt es. Danke.

Tolles Modul, danke dafür, Heiko!

[DS_Starter]

Jedoch soll es noch zwei Bedingungen geben:
Humidity > 70 und DoorState =closed
Bekomme ich das mit dem interuptable hin, oder muss ich das über ein doif machen...

Es kommt darauf an, ob diese beiden Bedingungen nur unterbrechen und nicht den Consumerzyklus beenden sollen.
In Interuptable kann man nur eine Bedingung angeben. 
Ich persönlich würde mir dazu über das Attr userExitFn ein wenig Code einfügen der bei Humidity > 70 und DoorState =closed ein Reading (im SolarForecast Device) auf 1, anderenfalls auf 0 setzt. Dieses Reading und den Regex (auf "1") gibt man dann im Key interuptable an.
Das kann man natürlich auch mit einem DOIF machen und das auszuwertende Reading damit setzen. Du solltest aber mit dem DOIF nicht direkt den Consumer ein/aus schalten damit auch die Einplanungszeiten eingehalten werden können.

[kask]

Nicht gehen war nicht der Punkt, sondern nicht sinvoll eine Tagesabweichung (Today_PVdeviation) vor Ende des Sonnentages zu berechnen.
Wenn es von allgemeinem Interesse ist, kann ich eine solche fortlaufende Abweichung gerne als Statistik-Reading zuschaltbar zur Verfügung stellen.

Ok, sehe ich denoch anders. Ich will mich ja auch nicht streiten. Eine kontinuierliche/mehrmalige Auswertung im Tagesverlauf finde ich schon interessant.
Aber könnte man nicht eine Abweichung Stundenweise einbringen. Das wäre dann ja weniger "unsinnig" bzw. noch aussagekräftiger da bei dem gesamten Tag immer Folgefehler auftreten würden. Sowas wie "Today_PVdeviationLastHour".

[kask]

Oh, gerade gesehen, Falls es einer verpasst hat oder noch nicht bemerkt wurde.
Morgen Abend die Sonnenbrille nicht vergessen und eincremen 

[DS_Starter]

Aber könnte man nicht eine Abweichung Stundenweise einbringen.

Ja sicher. Ich habe ja auch oben geschrieben, dass ich gerne ein zuschaltbares Reading implementiere welches fortlaufend die Abweichung ausgibt. Nur eben nicht Today_PVdeviation, sondern vllt. continuous_PVdeviation.

Edit: Oh wow, morgen wird die Batterie voll

[DS_Starter]

Hallo kask, @all,

ich habe mich mit deinem Vorschlag und der Thematik nochmal etwas näher befasst.
In der Version 1.0.6 habe ich ein neues Attribut ctrlGenPVdeviation implementiert.

Mit diesem Attribut kann man sich die Methode der Abweichungsberechnung einstellen wie man sie haben möchte.

ctrlGenPVdeviation
Legt die Methode zur Berechnung der Abweichung von prognostizierter und realer PV Erzeugung fest. Das Reading Today_PVdeviation wird in Abhängigkeit dieser Einstellung erstellt.

    daily                Berechnung und Erstellung von Today_PVdeviation erfolgt nach Sonnenuntergang (default)
    continuously  Berechnung und Erstellung von Today_PVdeviation erfolgt fortlaufend

In Abhängigkeit der Methode wird auch der Text der Anzeige im Grafikheader geändert.
Deinen Ansatz habe ich etwas geändert übernommen, damit die Berechnung sich nahtlos in den bisherigen Kontext (+- Abweichungen) einordnet.

Die Version ist zunächst in meinem contrib zum Test verfügbar.
Ich hoffe damit eine größtmögliche Flexibilität zu erreichen und sich jeder wiederfindet.

LG