Leistungsprognose für Wechselrichter

[DS_Starter]

habe gerade auf die aktuelle Version geupdatet. "set" funktioniert nicht bei "pvCorrectionFactor_Auto"

Das habe ich ehrlich gesagt nicht verstanden. Was funktioniert denn nicht?
Ich kann ein "set .. pvCorrectionFactor_Auto ...." über das Webinterface problemlos ausführen.
Egal mit welchem Argument.

[schwatter]

Morgen,

ja genau das "set .. pvCorrectionFactor_Auto ...." im Webinterface direkt im Device. Egal ob per Mausklick oder am Handy per touch.
Alle anderen funktionieren. Auch "shutdown restart" ändert nichts.
Komisch.

Gruß schwatter

[DS_Starter]

Moin,

ja echt komisch, das liegt bestimmt nicht am Modul. Ist ja ein einfacher Setter, nichts besonderes.
Äußerlich ist lediglich zu sehen, dass das Reading pvCorrectionFactor_Auto entsprechend gesetzt wird, mehr nicht.

[DS_Starter]

Hast du den Browsercache mal gelöscht?

[schwatter]

Aufm Handy ist er frisch, da ich zufällig an dem Tag eine neue CFW eingespielt habe ohne Backup.
PC noch nicht. Melde mich, werde heut Abend noch 1 - 2 Sachen testen.

Gruß schwatter

[DS_Starter]

@all,

in meinem contrib liegt die V 0.83.0.

Das Training der KI wird nun in einem Nebenprozess ausgeführt wenn die benötigte Trainingszeit einen bestimmten Schwellenwert übersteigt. Dadurch wird eine Beeinflussung von FHEM durch eventuelle Blockierungen durch eine lange Trainingszeit vermieden. Jetzt stehen wir mit den Daten noch am Anfang. Aber die Menge der Trainingsdaten erhöht sich permanent.

Im Gegensatz zu der pvHistory, deren Daten sich nach 31 Tagen überschreiben, werden die Trainingsdaten (Rohdaten) über einen Index gehalten. Mit "get ... valDecTree aiRawData" können sie angezeigt werden:

Number of datasets: 256

2023090109 => hod: 09, rad1h: 700.00, wcc: 60, wrp: 00, pvrl: 144, temp: 10
2023090110 => hod: 10, rad1h: 1080.00, wcc: 60, wrp: 00, pvrl: 2762, temp: 15
2023090111 => hod: 11, rad1h: 1420.00, wcc: 70, wrp: 00, pvrl: 3479, temp: 15
2023090112 => hod: 12, rad1h: 1710.00, wcc: 70, wrp: 00, pvrl: 2530, temp: 15
...

Der (rote) Index wird zwar aus Date/Zeit des Datensatzes gebildet, hat aber nur den Zweck der Identifizierung des Alters des Datensatzes. Darüber werde ich noch eine Begrenzung der Datenmenge auf vllt. 2 oder 3 Jahre vornehmen. D.h. mehr als 3 Jahre Daten würden die Trainingsdaten dann nicht umfassen damit die Menge nicht ins Unermessliche wächst. Vllt. stelle ich ein Attr zur Verfügung damit man diese Haltezeit einstellen kann.

Die Training Rohdaten findet ihr übrigens im File:

 

Code Auswählen Erweitern

FHEM/FhemUtils/AIraw_SolarForecast_<Device-Name>
Diese Daten können sehr wertvoll sein weil darin mit der Zeit die Erzeugungseigenschaften eurer Anlage verewigt werden. Wenn ihr FHEM mal neu installiert, umzieht oder dupliziert, könnt ihr diese Datei (und noch andere von SolarForecast in diesem Verzeichnis) auf das neue FHEM kopieren. Sie werden dann in das neue FHEM importiert. Wenn ihr "<Device-Name>" des Files anpasst, könnt ihr diese Daten auch einem anderen SolarForecast Device "unterjubeln" und müsst nicht wieder eine lange Trainingszeit abwarten.

Diese Infos gehören/kommen alle mal ins Wiki.  

[masterpete23]

Hi, ich hatte gerade ein

Illegal division by zero at ./FHEM/76_SolarForecast.pm line 6129.

Laut webgui habe ich

FVERSION 76_SolarForecast.pm:v0.74.7-s21735/2022-11-21 TESTING

ich weiß gar nicht woher - wie kann ich korrekt updaten? bzw wie finde ich die wirklich korrekte Version die ich einsetze
Ich vermute da Zusammenhänge

[DS_Starter]

Oh je, die V ist ja adlig. 

Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern

"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"

Manueller Download geht auch aus meinem contrib im Fußtext.
Weil die V schon so alt ist, könnten beim Update Fehler wie ungültige Attribute aufschlagen. Aber i.A. habe ich auf Rückwärtskompatibilität geachtet.
Die eingesetzte V hast du schon richtig identifiziert (Internal FVERSION).
Aktuell ist die

Code Auswählen Erweitern

76_SolarForecast.pm:v0.83.0-s27909/2023-09-19 TESTING

gerade hochgeladen.

[masterpete23]

Danke.
Updatet sie sich jetzt immer automatisch bei einem globalen Update?

[DS_Starter]

Nein. Ich muß das Modul erst noch offiziell einchecken.
Dazu brauche ich noch etwas Zeit bzw. Vorbereitung.
Ich gebe es hier bekannt wenn es soweit ist.

[stefanru]

Hi,

ich habe heute eine knifflige Frage.
Ich habe meine Solaranlage erweitert.
Bisher:
Fronis Gen24 WR + BYD + Smartmeter
Dazu kam:
Symo 15.0.3 M WR

Der Gen24 WR steuert alles, hat aber kein reading für die gesamt Erzeugung.

Beide Wechselrichter frage ich über die Fronius Module ab.
Das geht über TCP und mein Abfrage Intervall ist 15 Sek.

Ich kombiniere die PV Leistung wie hier im Thema beschrieben mit Hilfe eines Inverter Dummys der Gen24 und Symo Erzeugung addiert.
Grid (Einspeisung oder Bezug) bekomme ich vom SmartMeter.
Akku (Ladung oder Entladung vom Gen24).
Load (Eigenverbrauch) muss ich berechnen aus den anderen Werten.

Mein Problem ist aber, dass die Abfragen der beiden WR ja nicht gleichzeitig passieren sondern bis zu 15 Sek versetzt sein können.
Das kann bei wechselnder Bewölkung dann zu Summen für die PV erzeugung führen die nicht zu den anderen Werten Akku und Grid passen.
Und somit wird dann eine seltsame Load berechnet.

Gibt es irgendeine möglichkeit den Symo (also die TCP Abfrage) im selben Takt wie die Abfrage des Gen24 zu machen damit die Werte passen?

Gruß und Danke,
Stefan

[DS_Starter]

Gibt es irgendeine möglichkeit den Symo (also die TCP Abfrage) im selben Takt wie die Abfrage des Gen24 zu machen damit die Werte passen?

Als ich noch das SMA-Modul SMAInverter betreut habe, stand ich vor demselben Problem der Synchronisierung mit SMAEM (Meter).
Gelöst habe ich es dadurch, dass ich im Modul SMAInverter einen Modus ohne regelmäßigen Zyklus, aber dafür über ein "get...data" eingebaut habe.
Über ein notify wird im SMAInverter die Datenabfrage "get ... data" angestoßen, sobald der Meter SMAEM eine Auslesung vorgenommen hat. So läuft es bis heute synchron.

Nun kenne ich die Fronius Module nicht. Wenn die einen Modus wie oben beschrieben haben, könntest du es so lösen. Ansonsten würde ich den Autor bitten einen solchen Getter einzubauen. Du wirst vermutlich nicht der erste User mit dem Problem sein.

[ch.eick]

Zur Synchronität

Ich frage meine WRs mit ModBus/TCP ab und habe "alignTime 00:00" gesetzt.
Anschließend erzeuge ich im Master WR (mit Speicher) über die userReadings die Schwarm Werte zusätzlich, die ich mit dem Prefix SW_ versehen habe. Dabei werden dann mit entsprechender Verrechnung die Werte aus WR_2 geholt. Bei den Werten für einzelne Strings habe ich somit readings SW_Total_DC_Energy_From_PV[1-6] , was dann aussieht, als ob der WR 6 Strings hätte. Das könnte man natürlich auch in einem Dummy machen, was wiederum ein Device mehr wäre.

Bei den WR Statistiken, die meine Kostal WRs liefern frage ich diese über eine API ab, wobei der WR_2 kurz vor dem WR_1 abgefragt wird und der WR_1 dann wiederum die Schwarm korrekturen in SW_ readings macht.

Bei der Darstellung im FhemWeb sieht alles plausibel aus, wenn man es mit Prüfsummierungen auch mal näher anschaut.
Auch eine Dashboard Darstellung über Grafana zeigt keine auffälligen Abweichungen, da man dort ja auch durchaus mal runden darf

VG   Christian

[kask]

Kurze Rückmeldung von mir, was ich bis jetzt mit dem Modul so beobachte bzw. beobachtet habe.
Alle Devices haben die selben Einstellungen.

Das DWD Modul funktionierte ohne KI gut bei schlechter Wetterlage. Mit KI scheint es genauso gut bzw.,es kommt mir momentan besser vor wie früher (aber ist noch zu jung für eine gute Aussage) ,zu sein.
Momentan bei mir die beste Vorhersage (schlechtes Wetter).

Das SolcastAPI verfahren ist in letzter Zeit echt miserabel geworden. Bei gutem Wetter ist es recht gut bei schlechter Wetterlage kann man auch fast raten.
Im Sommer war es recht genau bei mir. Jetzt zum Spätsommer - Herbst werden Werte von bis zu 100% differenz ausgegeben. Also es wird mehr Prognostiziert wie in Realität kommt.

Das ForecastSolarAPI device scheint mir bis jetzt am beständigsten zu sein. Allerdings recht ungenau bzw. mit großer toleranz. Aber bei schlechter oder guter Wetterlage gleich (schlecht/ungenau).

Das VictronVRM ist wie auch das SolcastAPI device bei schlechter Wetterlage nicht so genau. Bei guter Wetterlage aber am genauesten. (Ok, sollte auch so sein da Victron ja alles von meiner Anlage hat, was die anderen Module nicht Wissen). Allerdings wundert es mich doch das das VictronVRM device besser ist wie das SolcastAPI Modul da es doch eigentlich da mit rein spielt. Vermutlich trumpft das VictronVRM damit einfach mehr zu wissen von der Anlage.

Alles in allem ist es so wie ich es schon vor Monaten einmal beobachtet und mitgeteilt habe. Das DWD Modul funktioniert bei mir besser wenn das Wetter schlechter ist.
Das VictronVRM device bei guter Wetterlage, bei mir, am besten.

Alles in Allem funktioniert das Modul aber sehr gut.
Und wer mal die Wetterberichte verfolgt, wird feststellen, dass diese sich leider auch stündlich ändern können.
Da kann auch die beste KI momentan nix dran machen, wenn zig tausende Metereologen das auch nicht genau auf die Kette kriegen.
Und die haben sicher auch KI's im petto.

[kask]

Gibt es irgendeine möglichkeit den Symo (also die TCP Abfrage) im selben Takt wie die Abfrage des Gen24 zu machen damit die Werte passen?

So wie ich das sehe, geht das so mal eben nicht. Aber beim überfliegen des Modules sollte es eigentlich kein großes Problem sein das variabel zu machen.
Also das Modul umschreiben. Man könnte über ein attribut den internen timer ausführen (normal, jetzt. oder das intervalattribut auf -1 oder sonstwas) oder eben über ein set command den Request ausführen lassen.
So um die Zeile 225 im Modul.
Dann könnte man ein device mit internen timer nutzen für den Interval. Und das andere Device über das set command abfragen lassen nach dem die werte des ersten device sich geändert haben.
Mit der Rückmeldung des zweiten kannst du dann dein inverter dummy befeuern.
Man müsste mal den developer @michael.winkler dazu befragen, ob er das umsetzen möchte. Ich denke das wird anderen auch nützen. Bei einer Anlagen Erweiterung.