Leistungsprognose für Wechselrichter

[Hausrobot]

Hallo ihr,

einen Thread öffnen? Ich hänge mal meine Frage hier an.

Ich habe folgende Definition. Vermutlich fehlt noch etwas, denn es werden merkwürdige Vorhersagen und blasse Wolken angezeigt. Aber was? Gibt es eine kompakte Übersicht? Das Wiki entsteht ja erst.

Code Auswählen Erweitern

define S30k_SolCast SolarForecast

attr S30k_SolCast beam1Content pvReal
attr S30k_SolCast beam2Content pvForecast
attr S30k_SolCast consumerLegend icon_bottom
attr S30k_SolCast flowGraphicAnimate 1
attr S30k_SolCast flowGraphicSize 400
attr S30k_SolCast follow70percentRule dynamic
attr S30k_SolCast historyHour -12
attr S30k_SolCast layoutType diff
attr S30k_SolCast room PV
attr S30k_SolCast cloudFactorDamping 0
attr S30k_SolCast rainFactorDamping  0
attr Forecast comment update per "wget -qO /opt/fhem/FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"

set S30k_SolCast pvCorrectionFactor_Auto off
set S30k_SolCast currentForecastDev DWD
set S30k_SolCast currentRadiationDev SolCast-API
set S30k_SolCast currentInverterDev SEdge pv=I_AC_Power:W etotal=X_PV_Energy:W capacit=29900
set S30k_SolCast currentMeterDev SEdge gcon=X_Meter_1_M_AC_Power:W contotal=X_M_ImportedToday:W gfeedin=X_M_ExportedToday:W feedtotal=X_PV_Energy:W
set S30k_SolCast inverterStrings GarageS,GarageN,HausS,HausN
set S30k_SolCast modulePeakString GarageS=8.16 GarageN=2.72 HausS=16.32 HausN=13.6
set S30k_SolCast moduleDirection GarageS=S GarageN=N HausS=S HausN=N
set S30k_SolCast moduleTiltAngle GarageS=41 GarageN=41 HausS=41 HausN=41
set S30k_SolCast roofIdentPair GarageS_Pair rtid="a7ec-30d3-945e-xxxx" apikey="qs53x9fL8nnjUVpXYwnYh_o0Bugtxxxx"
set S30k_SolCast roofIdentPair HausS_Pair rtid="d3b4-f556-c0d2-xxxx" apikey="qs53x9fL8nnjUVpXYwnYh_o0Bugt5xxx"
set S30k_SolCast roofIdentPair GarageN_Pair rtid="31c2-b9e6-cae8-xxx" apikey="pEBM5A3dX7AdmCRAAwXnAeDwe-CM5xxx"
set S30k_SolCast roofIdentPair HausN_Pair rtid="cbd6-ec00-3fd8-xxxx" apikey="pEBM5A3dX7AdmCRAAwXnAeDwe-CM5xxx"
set S30k_SolCast moduleRoofTops GarageS=GarageS_Pair GarageN=GarageN_Pair HausS=HausS_Pair HausN=HausN_Pair

set S30k_SolCast plantConfiguration check
Woher kommt die rtid?

Vielleicht kann mir jemand helfen? Jetzt sieht es so aus:

(about:invalid)

Und woher kommt rtid ? Ich habe mir das bei solcast aus dem Pfad zum Abruf meiner Daten herausgeschnitten, weil ich keinen anderen Weg für den hoffentlich richtigen Wert fand.

Viele Grüße
Hausrobot

[DS_Starter]

Guten Morgen,

Woher kommt die rtid?

Das ist die Rooftop ID, oder auch Ressorcen ID.
Wenn du in SolCast dein(e) Dächer anlegst, findest du in der "Site Summary" zu jedem Dach diese Resource Id.

(Deinen Dateianhang sieht man nicht)

LG

[Hausrobot]

Hallo DS_Starter,
danke, das ist der richtige Wert

Irgend etwas missinterpretiere ich aber noch bei den Messwerten:

Code Auswählen Erweitern

set S30k_SolCast currentMeterDev SEdge gcon=X_Meter_1_M_AC_Power:W contotal=X_M_ImportedToday:W gfeedin=X_M_ExportedToday:W feedtotal=X_PV_Energy:W
Hat jemand das schon für Solaredge und den Modulen 76_SolarForecast.pm + 98_SolarEdge.pm gemacht? Ich komme leider nicht so recht mit der Doku zu Solarcast (help device, currentMeterDev) und den Infos aus https://wiki.fhem.de/wiki/SolarEdge_SE10k zurecht.

Sieht noch schlecht aus:

[DS_Starter]

Was konkret hast du in der Doku zu SolarForecast nicht verstanden ?

Ich vermute wegen der Namen aus SolarEdge (z.B. X_M_ImportedToday) dass der logische Inhalt nicht passt.

currentMeterDev <Meter Device Name> gcon=<Readingname>:<Einheit> contotal=<Readingname>:<Einheit> gfeedin=<Readingname>:<Einheit> feedtotal=<Readingname>:<Einheit>

Legt ein beliebiges Device und seine Readings zur Energiemessung fest. Das Modul geht davon aus dass der numerische Wert der Readings immer positiv ist. Es kann auch ein Dummy Device mit entsprechenden Readings sein. Die Bedeutung des jeweiligen "Readingname" ist:

    gcon    Reading welches die aktuell aus dem Netz bezogene Leistung liefert, also was aktuell tatsächlich aus dem Netz kunsumiert wird.
    contotal    Reading welches die Summe der aus dem Netz bezogenen Energie liefert. d.h. ein stetig steigender Zähler der bezogenen Energie.
    gfeedin    Reading welches die aktuell in das Netz eingespeiste Leistung liefert, also was aktuell tatsächlich in das Netz eingespeist wird.
    feedtotal    Reading welches die Summe der in das Netz eingespeisten Energie liefert, d.h. ein stetig steigender Zähler der eingespeisten Energie.
    Einheit    die jeweilige Einheit (W,kW,Wh,kWh)

[der-Lolo]

Hallo Heiko,
ich hatte bis jetzt die Obis Schnittstelle des EVU Zählers genutzt um Daten abzufragen und hatte diesen Zähler dann auch in der Solarforecast als MeterDev angegeben.
Jetzt habe ich das verändert und den DTSU der Solaranlage als MeterDev angegeben.
Die Leistung hat standardmäßig einen positiven Wert, wenn Strom in das Netz eingespeist wird.

Also habe ich das MeterDev so angelegt:

Sun2000 gcon=PM_Momentanleistung_W:W contotal=PM_Netzbezug_kWh:kWh gfeedin=gcon:W feedtotal=PM_Einspeisung_kWh:kWh

Ergebnis auf dem Screenshot - die Richtung wird nicht richtig dargestellt - zusätzlich verrechnet sich die Prognose hierdurch beim Hausverbrauch vermutlich mit den werten...

Also irgendwie werd ich noch nicht recht glücklich.
Hast Du noch Ideen?

[DS_Starter]

Die Leistung hat standardmäßig einen positiven Wert, wenn Strom in das Netz eingespeist wird.

Dann müsste die Definition m.M. nach so aussehen:

Code Auswählen Erweitern

Sun2000 gcon=-gfeedin:W contotal=PM_Netzbezug_kWh:kWh gfeedin=PM_Momentanleistung_W:W feedtotal=PM_Einspeisung_kWh:kWh

gcon wäre jetzt vermutlich der Wert des Readings PM_Momentanleistung_W sofern es negativ ist, da es ja bei Netzeinspeisung positiv ist. Aber das weißt du sicherlich besser, du kennst deine Anlage.

LG

[der-Lolo]

Ok, ich habs jetzt mal so eingetragen - werde berichten wenn der Akku wieder voll ist und Einspeisung stattfindet.
Hast Du noch eine Idee wie man den DC Speicher berücksichtigen könnte sodass die Ladeleistung nicht die Prognose beeinflusst? Vermutlich wäre es am saubersten wenn ein beam3 die Lade, entladeleistung erfasst und darstellt.

Oder könnte man die Batterie ähnlich wie das BHKW des anderen Users eintragen und darstellen? 

[Hausrobot]

Was konkret hast du in der Doku zu SolarForecast nicht verstanden ?

Ich vermute wegen der Namen aus SolarEdge (z.B. X_M_ImportedToday) dass der logische Inhalt nicht passt.

Ja, genau. X_M_ImportedToday ist vermutlich Quatsch.

Die Sunspec (https://knowledge-center.solaredge.com/sites/kc/files/sunspec-implementation-technical-note.pdf, ab S. 21) unterscheidet mE nicht zwischen aktuell exportiert und aktuell importiert. Das ist nur eine Vorzeichenfrage.
M_AC_Power | int16 | Watts |  Total Real Power (sum of active phases)

Ich versuche es mal mit

Code Auswählen Erweitern

set S30k_SolCast currentMeterDev SEdge gcon=X_Meter_1_M_AC_Power:W contotal=X_Meter_1_M_Imported:W gfeedin=X_Meter_1_M_AC_Power:W feedtotal=X_Meter_1_M_Exported:W

[Hausrobot]

Legt ein beliebiges Device und seine Readings zur Energiemessung fest. Das Modul geht davon aus dass der numerische Wert der Readings immer positiv ist.

Hm, fliegt 76_SolarForecast wiederholt ab, Vermutlich wegen der bei mir auch negativen Werte?

Code Auswählen Erweitern

Illegal division by zero at ./FHEM/76_SolarForecast.pm line 6199.
2023.04.23 20:28:12 1: reload: Error:Modul 99_myUtils deactivated:
 syntax error at ./FHEM/99_myUtils.pm line 14, near "sub logProxy_dwd2Plot($$$$;$$$)
"
Can't use global @_ in "my" at ./FHEM/99_myUtils.pm line 15, near "= @_"
syntax error at ./FHEM/99_myUtils.pm line 173, near "}"

2023.04.23 20:28:12 1: Including fhem.cfg
2023.04.23 20:28:12 1: reload: Error:Modul 99_myUtils deactivated:
 syntax error at ./FHEM/99_myUtils.pm line 14, near "sub logProxy_dwd2Plot($$$$;$$$)
"
Can't use global @_ in "my" at ./FHEM/99_myUtils.pm line 15, near "= @_"
syntax error at ./FHEM/99_myUtils.pm line 173, near "}"

Muss ich X_Meter_1_M_AC_Power teilen, falls negativ, dann Bezug usw.?

[DS_Starter]

Das

Code Auswählen Erweitern

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

muß ich im Modul abfangen.
Hast du die aktuelle Version v0.75.2 im Einsatz ? Bei der Version kann der Divisionsfehler m.M. nach nicht auftreten.

[DS_Starter]

@der-Lolo,

Oder könnte man die Batterie ähnlich wie das BHKW des anderen Users eintragen und darstellen? 

Ich habe den Post gerade nicht vor Augen, hast du die Nummer (#) ?

Extra Beam ist nicht zielführend. Die Beams stelle nur intern berechnete Werte dar.
Meinst du die Verbrauchsprognose oder die PV Erzeugungsprognose ?

Die PV Erzeugungsprognose ist lediglich abhängig von der Angabe der Strings und natürlich den Werten von DWD bzw. SolCast. Dann gibt es noch den Korrekturfaktor. Wenn der durch eine evtl. falsch ermittelte reale Erzeugung ebenfalls falsch berechnet und dann auf die Prognosedaten angewendet wird, kann die Prognose verfälscht werden.
Deswegen muß die reale PV Erzeugung richtig ermittelt werden.

[Hausrobot]

Hast du die aktuelle Version v0.75.2 im Einsatz ? Bei der Version kann der Divisionsfehler m.M. nach nicht auftreten.

Ich denke ja, vor ein paar Tagen gezogen.
# $Id: 76_SolarForecast.pm 21735 2023-02-12 23:53:24Z DS_Starter $

Update dieses Posts: nein
FVERSION   76_SolarForecast.pm:v0.75.1-s21735/2023-02-12 TESTING

Ich aktualisiere ...

Habe, von https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm
- unverändert:

# $Id: 76_SolarForecast.pm 21735 2023-02-12 23:53:24Z DS_Starter $

[DS_Starter]

Ich habe die V 0.75.3 soeben hochgeladen.
Teste bitte mit der nochmal deinen Case.

LG

[der-Lolo]

Naja - ich habe halt immernoch Hoffnung das sich die Leistung die von der Sonne kommt der Prognose annähert...
Auffällig ist halt - das der DC anteil der als Ladestrom in den Speicher wandert nicht im Content von den Beams landet - obwohl attr beam1content PVreal gesetzt ist.
Gestrige Änderung am meterDEV gcon=-gfeedin:W hat geholfen, in der Grafik scheint nun allet schick zu sein.
Bis auf dei etotal bei den Consumern - darauf kann ich aber auch verzichten.

DankeDir!

[DS_Starter]

Auffällig ist halt - das der DC anteil der als Ladestrom in den Speicher wandert nicht im Content von den Beams landet - obwohl attr beam1content PVreal gesetzt ist.

Die Darstellung wird aus der PVHistory genommen. Mit "get ... pvHistory" kannst du dir die Werte anschauen.
"pvrl" ist die reale Erzeugung. pvrl wird aus currentInverterDev dem Reading im Schlüssel etotal genommen und daraus der Stundenwert berechnet.
Wenn also in dem etotal-Schlüssel etwas fehlt, muß man über ein userReading oder einen anderen Mechanismus dafür sorgen dass dieses Reading komplett alles enthält.

Ich mache mir aber noch Gedanken ob ich noch einen Setter für einen oder mehrere DC-MPPT Loader bereitstellen kann. Deren Werte würde ich dann im Modul dem etotal automatisch hinzuaddieren.

Beispeil für heute 13 -14 Uhr:

14 => etotal: 51713501, pvfc: 3461, pvrl: 3579
            confc: 1222, con: 1326, gcon: 14, gfeedin: 2267
            batintotal: 0, batin: 0, batouttotal: 0, batout: 0
            wid: 2, wcc: 70, wrp: 1.00, temp: 15.1, pvcorrf: 1.26/1
            minutescsm01: 0
            minutescsm02: 0
            minutescsm03: 0
            minutescsm04: 55
            minutescsm05: 55
            minutescsm06: 60
            minutescsm07: 15
            minutescsm08: 15
            minutescsm09: 60