Leistungsprognose für Wechselrichter

[dk3572]

Nun ist der neue Setter eingebaut, um die 4h-Vorhersagen auszuwerten / zu signalisieren:

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 powerTrigger_X = on erstellt/gesetzt. Unterschreiten die letzten drei Messungen der 4-Stunden PV Vorhersagen 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> energyH4Trigger 1on=2000 1off=1700 2on=2500 2off=2000 3off=1500

Hallo Heiko,
funktioniert, nur deine Beschreibung ist falsch 
Es werden die Readings energyH4Trigger_x generiert.
Schönen Restfeiertag noch und VG Dieter

[DS_Starter]

@Dieter, danke für die Aufmerksamkeit.  Habe es korrigiert.

@Tom, ja die Readings NextHours_Sum01_PVforecast bis NextHours_Sum04_PVforecast summieren die jeweiligen Vorhersagen auf.
Konkret wenn es jetzt 10:29 wäre, würde NextHours_Sum01_PVforecast den Vorhersagewert von 10:29-11:29 enthalten, NextHours_Sum02_PVforecast den Wert von 10:29-12:29, NextHours_Sum03_PVforecast den Wert von 10:29-13:29 und NextHours_Sum04_PVforecast den Wert von 10:29-14:29.

Natürlich handelt es sich um Schätzungen. Es liegen ja nur Werte für die jeweilige Stunde vor. Also gehe ich vereinfachend von einem linearen Verlauf aus und bin so in der Lage eine solche Schätzung zu erstellen. Logischerweise wird so ein idealer Verlauf nicht unbedingt zutreffen, aber ich gehe trotzdem von einer hilfreichen Funktion aus.

Für den Startwert der aktuellen Stunde werde ich versuchen noch den zum Zeitpunkt X aufgelaufenen Realbetrag zu berücksichtigen, da er u.U. die verbleibende Prognose reduziert. Mal schauen.-> Unfug

[DS_Starter]

Habe vergessen zu erwähnen, dass es auch reset-Kommandos für neuen Setter gibt falls man die wieder loswerden will:

                      set <> reset powerTrigger
                      set <> reset energyH4Trigger

[EinEinfach]

Ansonsten gibt es jetzt zusätzliche Events für das Logging für PVforecast, PVreal mit jeweils für den Wert zutreffenden Timestamp:

Hallo Heiko, mir ist leider nicht klar, wie ich an die Events rankommen kann, sprich was muss gesetzt werden, damit diese in der Datenbank landen.

Gruß
Alexander

[DS_Starter]

Morgen Alexander,

ganz normal wie in FHEM üblich. Es werden ja inzwischen die Readings LastHourGridconsumptionReal, LastHourPVforecast, LastHourPVreal erstellt, die immer ihren zugehörigen Timestamp erhalten. (die zusätzlichen Events wurden in die Readings umgewandelt)

2021-04-06 09:20:52.825 SolarForecast SolCast running
2021-04-06 09:00:00 SolarForecast SolCast LastHourPVforecast: 575 Wh
2021-04-06 09:00:00 SolarForecast SolCast LastHourPVreal: 276 Wh
2021-04-06 09:00:00 SolarForecast SolCast LastHourGridconsumptionReal: 270 Wh
2021-04-06 09:20:52.894 SolarForecast SolCast Today_SunRise: 06:34
2021-04-06 09:20:52.894 SolarForecast SolCast Today_SunSet: 19:56
...

Die loggst du in eine DB und gibst sie mit dem Plot aus.
Hier die DEF:

Code Auswählen Erweitern


defmod SVG_LogDBShort_SolCast SVG LogDBShort:SVG_LogDBShort_SolCast:HISTORY
attr SVG_LogDBShort_SolCast group Solarprognose
attr SVG_LogDBShort_SolCast room Energie
attr SVG_LogDBShort_SolCast sortby 2
attr SVG_LogDBShort_SolCast title "Übersicht solare Vorhersage"


Und das Gplotfile:

Code Auswählen Erweitern


# Created by FHEM/98_SVG.pm, 2021-04-02 22:27:09
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Wh"
set y2label "Wh"
set yrange [0:6000]
set y2range [0:6000]

#LogDBShort SolCast:LastHourPVforecast
#LogDBShort SolCast:LastHourPVreal

plot "<IN>" using 1:2 axes x1y2 title 'PV Vorhersage' ls l6fill lw 1 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'PV Erzeugung' ls l2fill lw 1 with lines


[DS_Starter]

Hallo @all,

die nächste Erweiterung ist implementiert.
Der Setter currentMeterDev ist erweitert um die beiden Schlüssel gfeedin und feedtotal:

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. 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
    contotal    Reading welches die Summe der aus dem Netz bezogenen Energie liefert
    gfeedin    Reading welches die aktuell in das Netz eingespeiste Leistung liefert
    feedtotal    Reading welches die Summe der in das Netz eingespeisten Energie liefert
    Einheit    die jeweilige Einheit (W,kW,Wh,kWh)

Damit ist es nun möglich die real im Haus verbrauchte Leistung zu bestimmen (neues Reading Current_Consumption) und zukünftig auch eine Abschätzung einer Consumption Forecast zu erstellen. Auch die Einspeisung pro Stunde gibt es in den Readings Today_HourXX_GridFeedIn.

Weiterhin können zukünftig auch solche Kennzahlen wie Autarkiequote oder Eigenverbrauchsquote ausgegeben werden wenn gewünscht.

Wenn ihr die neue Version 0.31.0 geladen und restarted habt, ergänzt bitte den Setter currentMeterDev  um die genannten Schlüssel !

SMAEM Nutzer geben ein:

  gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh

Hinweis: der Reading Inhalt wird nun durch die langen Namen recht groß und im Browser ist die zweizeilige Ansicht dann nicht mehr so übersichtlich. Ich habe mit deshalb im SMAEM über UserReadings kurze Pendants für die vier Schlüsselnamen im currentMeterDev erzeugt und verwende diese. Damit bleibt es schön übersichtlich.

Ich überlege momentan, ob ich die generelle Angabe des currentMeterDev verpflichtend mache genauso wie currentInverterDev und das entsprechend in den grafischen Hinweis nach der Definition mit aufnehme. Das Meterdevice wird ohnehin für viele Funktionalitäten im Modul gebraucht.
Was meint ihr dazu, macht das Sinn wenn der User darauf hingewiesen wird dieses Setup zu tun ?

Grüße,
Heiko 

[sledge]

[...]
Legt ein beliebiges Device und seine Readings zur Energiemessung fest. 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
    contotal    Reading welches die Summe der aus dem Netz bezogenen Energie liefert
    gfeedin    Reading welches die aktuell in das Netz eingespeiste Leistung liefert
    feedtotal    Reading welches die Summe der in das Netz eingespeisten Energie liefert
    Einheit    die jeweilige Einheit (W,kW,Wh,kWh)
[...]

Frage: feedtotal ist ok, aber mein "gcon / gfeedin" ist ein und das selbe Reading - lediglich mit umgekehrtem Vorzeichen. Also wenn gcon >0, dann Bezug, sonst Einspeisung. Also "userreading" anlegen mit entsprechender Logik?

[DS_Starter]

Also "userreading" anlegen mit entsprechender Logik?

Ja, so passt das dann.

[papa]

Könnte man gfeedin nicht optional machen und, wenn nicht definiert, den negativen gcon Wert nehmen ? Ich möchte gern "überflüssige" Readings vermeiden.

[DS_Starter]

Könnte man gfeedin nicht optional machen und, wenn nicht definiert, den negativen gcon Wert nehmen ?

Optional möchte ich es nicht machen, weil ich sicher gehen will dass der User nichts "vergisst" und auch die Syntax richtig ist um die Zuordnungen richtig und vollständig vornehmen zu können.
Was ich mir vorstellen könnte ist die Variante dass der User in diesem Fall angibt:

         gcon=<Reading>:<Einheit> gfeedin=-gcon

Das könnte ich gut auswerten und würde mir dann -> sagen nimm gcon als gfeedin sofern gcon einen negativen Wert hat.
Wäre das eine Variante ?

[papa]

         gcon=<Reading>:<Einheit> gfeedin=-gcon

Das könnte ich gut auswerten und würde mir dann -> sagen nimm gcon als gfeedin sofern gcon einen negativen Wert hat.
Wäre das eine Variante ?

Perfekt

[DS_Starter]

Ich habe das jetzt mal so umgesetzt und kurz angetestet. Sollte funktionieren. Wenn morgen Einspeisungen vorkommen solltet ihr checken können ob es letztlich so klappt wie gewünscht.
Bei wem gcon/gfeedin das gleiche Reading ist, die Einspeisung aber durch ein negatives Vorzeichen gekennzeichnet ist, kann jetzt currentMeterDev so angeben:

Code Auswählen Erweitern


currentMeterDev <Device> gcon=<Reading>:<Einheit> contotal=<Reading>:<Einheit> gfeedin=-gcon feedtotal=<Reading>:<Einheit>


Liegt im contrib.

[EinEinfach]

Es werden ja inzwischen die Readings LastHourGridconsumptionReal, LastHourPVforecast, LastHourPVreal erstellt, die immer ihren zugehörigen Timestamp erhalten. (die zusätzlichen Events wurden in die Readings umgewandelt)

Passt danke, habe irgendwie übersehen.

[DS_Starter]

Moin zusammen,

@Wzut, @all,
Frage ... in der Grafik gibt es ja zur Zeit den Status der PV Erzeugung (PV =>) und GridConsumption (CO =>).
Inzwischen wird die tatsächliche Consumption über das Reading Current_Consumption bereitgestellt.

Wäre es da nicht angebracht in der Grafiksub auf dieses Reading umzustellen ? 
Alternativ müsste CO eigentlich GCO heißen. Wir müssen ja unterscheiden zwischen dem Netzbezug und dem Verbrauch unter Berückschtigung der erzeugten PV.

Meinungen ?

[sledge]

Der Hausverbrauch (ohne Berücksichtigung der PV-Erzeugung) wäre für mich CO, GCO (oder Netzimport) demzufolge <= CO, da hier noch die entsprechende PV-Erzeugung in Abzug gebracht werden muss. Soweit d'accord.

Bleibt die Fragestellung, welche Information "relevanter "im Kontext der Graphik ist - echter Hausverbrauch (CO) oder der Netzimport (GCO)?

Gruß,
Tom