Leistungsprognose für Wechselrichter

[dk3572]

Hallo Heiko,
habe etwas den Faden verloren 
Ist nun im Modul ein Batteriespeicher mit berücksichtigt oder kommt das evtl. erst noch?
CO ist bei mir aktuell 0 weil Verbrauch komplett über Batterie läuft.
Danke und VG Dieter

[DS_Starter]

Kommt noch, habe heute zuviel Zeit mit schreiben im Forum verbracht. 

[dk3572]

Kommt noch, habe heute zuviel Zeit mit schreiben im Forum verbracht. 

ok, dann will ich dich bei deiner hervorragenden Arbeit mal nicht weiter stören 

[DS_Starter]

Die Batteriedaten können jetzt auch mit integriert werden. Dazu gibt es einen neuen Setter:

currentBatteryDev <Meter Device Name> pin=<Readingname>:<Einheit> pout=<Readingname>:<Einheit>

Legt ein beliebiges Device und seine Readings zur Lieferung der Batterie Leistungsdaten 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:

    pin    Reading welches die aktuelle Batterieladung liefert
    pout    Reading welches die aktuelle Batterieentladung liefert
    Einheit    die jeweilige Einheit (W,kW)


Sonderfälle: Sollte das Reading für pin und pout identisch, aber vorzeichenbehaftet sein, können die Schlüssel pin und pout wie folgt definiert werden:

    pin=-pout    (ein negativer Wert von pout wird als pin verwendet)
    pout=-pin    (ein negativer Wert von pin wird als pout verwendet)


Die Einheit entfällt in dem jeweiligen Sonderfall.

    Beispiel:
    set <name> currentBatteryDev BatDummy pin=BatVal:W pout=-pin

    # Device BatDummy liefert die aktuelle Batterieladung im Reading "BatVal" (W), die Batterieentladung im gleichen Reading mit negativen Vorzeichen


Habe auch noch einen Fehler in der vorzeichenbehafteten currentMeterDev-Behandlung festgestellt und behoben.
Liegt wieder im contrib.

LG

[DS_Starter]

Hallo,

ich habe jetzt auch die bewölkungsabhängige pvCorrection eingebaut.
Dazu wird die Bewölkung in eine Range von 0..10 eingeteilt. Z.B. ist die Range 0 die Bewölkung von 0-9%, Range 1 von 10-19% usw.
Für die Autokorrektur werden nur noch historische Daten herangezogen, die mit der Bewölkungsrange der aktuellen Stunde übereinstimmen. So werden nur noch ähnliche Bewökungslagen der gleichen Stunden der letzten X Tage miteinander verglichen.
Das Attr numHistDays stellt die Anzahl der einzubeziehenden Tage ein.

Möglicherweise muss ich den Standard für dieses Attr nun noch hochsetzen, aber das werden wir sehen.

Liegt wieder im Contrib (V.034.0)

[DS_Starter]

Moin zusammen,

ich habe noch einiges an der bewölkungsabhängige pvCorrection verfeinert.
Dazu wird eine Matrix der Korrekturfaktoren für jede einzelne Tagesstunde und jeder möglichen Bewölkungsrange gefüllt.

Diese Matrix wird im Laufe der Zeit aufgebaut und ständig aktualisiert wenn Autokorrektur eingeschaltet.
Ihr seht diese Matrix mit

get <> pvCircular

(Schlüssel corr)

Es wird eine Weile dauern bis sich diese Matrix aufgebaut hat, aber im Ergebnis erwarte ich noch genaure Vorhersagen.
Den Standard für  Attr numHistDays habe ich auf 21 hochgesetzt damit die Wahrscheinlichkeit historische Bewölkungsvarianten einzubeziehen zu können statistisch steigt.

Liegt im contrib.

[jual]

Super @DS_Starter, dann werde ich doch gleich mal die neue Version mit der Bewölkungsoptimierung installieren und mal schauen, was die nächsten Tage bringen.

Hast du schon ein Gefühl dafür, was das dann für den CloudFactorDamping bedeutet? Er wird zwar wahrscheinlich nicht überflüssig werden, hat aber vielleicht nun weniger Bedeutung? Oder sehe ich das falsch?

[DS_Starter]

Hast du schon ein Gefühl dafür, was das dann für den CloudFactorDamping bedeutet? Er wird zwar wahrscheinlich nicht überflüssig werden, hat aber vielleicht nun weniger Bedeutung? Oder sehe ich das falsch?

Noch nicht, aber im Prinzip hast du Recht mit deiner Annahme.
Es kann ja auch User geben die eine manuelle Korrektur verwenden. Und in diesem Kontext hat CloudFactorDamping  dann evtl. doch noch eine Bedeutung um eine Grundeinstellung nahe an der tatsächlichen Erzeugung zu erreichen.

Ich habe gerade eben noch den Hilfetxt für pvCorrectionFactor_Auto angepasst um ungeduldige Neu-Anwender gleich etwas zu bremsen  :

pvCorrectionFactor_Auto <on | off>

Schaltet die automatische Vorhersagekorrektur ein/aus.
Ist die Automatik eingeschaltet, wird nach einer Mindestlaufzeit von FHEM bzw. des Moduls von 24 Stunden für jede Stunde ein Korrekturfaktor der Solarvorhersage berechnet und auf die Erwartung des kommenden Tages angewendet. Dazu wird die tatsächliche Energierzeugung mit dem vorhergesagten Wert des aktuellen Tages und Stunde verglichen, die Korrekturwerte historischer Tage unter Berücksichtigung der Bewölkung einbezogen und daraus ein neuer Korrekturfaktor abgeleitet. Es werden nur historische Daten mit gleicher Bewölkungsrange einbezogen.
Die automatische Vorhersagekorrektur ist lernend und benötigt etliche Tage um die Korrekturwerte zu optimieren. Nach der Aktivierung sind nicht sofort optimale Vorhersagen zu erwarten !
(default: off)

[EinEinfach]

Nun ist auch die diese Variante von EinEinfach möglich:

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

Habe das Update eingespielt, wie zu erwarten funktioniert ohne Probleme! Danke für die Umsetzung!

Gruß

[DS_Starter]

Hallo zusammen,

habe mir nochmal Gedanken zu der Problematik Loggen von Vorhersagedaten in der Zukunft.
Herausgekommen in ein weiteres Reading  AllPVforecastsToEvent welches zusätzliche Events liefert:

Auszug aus dem Eventmonitor:

Code Auswählen Erweitern

2021-04-12 22:11:56.315 SolarForecast SolCast running
2021-04-12 22:59:59 SolarForecast SolCast PVforecast: 0
2021-04-12 23:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 00:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 01:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 02:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 03:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 04:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 05:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 06:59:59 SolarForecast SolCast PVforecast: 19
2021-04-13 07:59:59 SolarForecast SolCast PVforecast: 409
2021-04-13 08:59:59 SolarForecast SolCast PVforecast: 1626
2021-04-13 09:59:59 SolarForecast SolCast PVforecast: 1734
2021-04-13 10:59:59 SolarForecast SolCast PVforecast: 2395
2021-04-13 11:59:59 SolarForecast SolCast PVforecast: 2372
2021-04-13 12:59:59 SolarForecast SolCast PVforecast: 2610
2021-04-13 13:59:59 SolarForecast SolCast PVforecast: 3543
2021-04-13 14:59:59 SolarForecast SolCast PVforecast: 2572
2021-04-13 15:59:59 SolarForecast SolCast PVforecast: 1468
2021-04-13 16:59:59 SolarForecast SolCast PVforecast: 1935
2021-04-13 17:59:59 SolarForecast SolCast PVforecast: 1448
2021-04-13 18:59:59 SolarForecast SolCast PVforecast: 741
2021-04-13 19:59:59 SolarForecast SolCast PVforecast: 107
2021-04-13 20:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 21:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 22:59:59 SolarForecast SolCast PVforecast: 0
2021-04-13 23:59:59 SolarForecast SolCast PVforecast: 0
2021-04-12 22:00:00 SolarForecast SolCast LastHourPVforecast: 0 Wh
2021-04-12 22:00:00 SolarForecast SolCast LastHourPVreal: 0 Wh
2021-04-12 22:00:00 SolarForecast SolCast LastHourGridconsumptionReal: 564 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast Today_SunRise: 06:21
2021-04-12 22:11:56.486 SolarForecast SolCast Today_SunSet: 20:06
2021-04-12 22:11:56.486 SolarForecast SolCast Tomorrow_SunRise: 06:19
2021-04-12 22:11:56.486 SolarForecast SolCast Tomorrow_SunSet: 20:07
2021-04-12 22:11:56.486 SolarForecast SolCast Current_PV: 0 W
2021-04-12 22:11:56.486 SolarForecast SolCast Today_Hour23_PVreal: 0 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast Current_GridConsumption: 533 W
2021-04-12 22:11:56.486 SolarForecast SolCast Current_GridFeedIn: 0 W
2021-04-12 22:11:56.486 SolarForecast SolCast Today_Hour23_GridConsumption: 104 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast Today_Hour23_GridFeedIn: 0 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast Current_Consumption: 533 W
2021-04-12 22:11:56.486 SolarForecast SolCast NextHours_Sum01_PVforecast: 0 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast NextHours_Sum02_PVforecast: 0 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast NextHours_Sum03_PVforecast: 0 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast NextHours_Sum04_PVforecast: 0 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast RestOfDayPVforecast: 0 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast Tomorrow_PVforecast: 22979 Wh
2021-04-12 22:11:56.486 SolarForecast SolCast Today_PVforecast: 8164 Wh
2021-04-12 22:11:56.562 SolarForecast SolCast updated

Es werden immer die PV Vorhersagewerte ab der aktuellen Stunde bis zum Ende des kommenden Tages kommuniziert, d.h. im maximalen Fall 48 Werte beim Lauf früh 00.
Es werden die Werte aus dem nextHours-Hash (siehe get <> nextHours) als Reading erstellt und der Timestamp entsprechend passend aufbereitet.

Damit kann man nun "in die Zukunft" loggen und daraus Plots erstellen (hoffe ich  ). 
Probiert es mal aus wenn ihr es möchtet. Die Einschränkungen bei einem vorhandenen PK in der DB hatte ich ja schon erwähnt.

Liegt im contrib.

[DS_Starter]

Für User wie jual oder ch.eick, die auch gern ein eigenes Perl Script verwenden möchten/können, habe ich noch eine Schnittstelle zum nextHours-Hash eingebaut.
Damit kann man sich die PV Forcast mit deren Startzeit abrufen und in eigene Scripte einbauen.

Hier das prinzipielle Beispiel was man so in die 99_myUtils.pm einfügen kann:

Code Auswählen Erweitern


####################################################################################
#       SolarForecast Schnittstelle zum nextHours-Hash
#
#       Aufruf mit: SolCastNext('<Name>','<NextHourXX>')
#       z.B.
#       my ($nhts, $nhfc) = SolCastNext('SolCast5','NextHour13');
#
####################################################################################
sub SolCastNext {
    my $name = shift;
    my $hour = shift;

    my $hash = $defs{$name};

    my $nhts = FHEM::SolarForecast::NexthoursVal ($hash, $hour, "starttime",  "");
    my $nhfc = FHEM::SolarForecast::NexthoursVal ($hash, $hour, "pvforecast", "");

    Log3($name, 1, "$name - Forecast next Hour $hour starttime: $nhts, pvforecast: $nhfc");

return ($nhts, $nhfc);
}


In Verbindung mit DbRep könnte man so recht einfach ein evtl. vorhandenes  PVforecast mit dem Timestring $nhts aus der DB löschen und danach erneut einfügen mit dem Wert $nhfc.
Wie gesagt, das muss dann mit einem externen Script erledigen. Im Modul kann ich nur Events erstellen oder Schnittstellen anbieten.

Ist hochgeladen.

[DS_Starter]

Ich habe mal das neue Reading AllPVforecastsToEvent mit geloggt und den Plot erweitert.
Sieht nun so aus wie im Anhang.
Wen es interessiert hier die DEF und das Gplotfile:

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"


Code Auswählen Erweitern


# Created by FHEM/98_SVG.pm, 2021-04-13 09:53:41
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
#LogDBShort SolCast:AllPVforecastsToEvent

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


[jual]

Damit kann man nun "in die Zukunft" loggen und daraus Plots erstellen (hoffe ich  ).
Probiert es mal aus wenn ihr es möchtet. Die Einschränkungen bei einem vorhandenen PK in der DB hatte ich ja schon erwähnt.

@DS_Starter: nur mal so völlig ungeprüft in den Raum geworfen:

Wenn du den nächsten Update-Zeitpunkt, der ja in MODE aufgeführt wird, in ein Reading packst, dann könnte man doch sicherlich ein DOIF basteln, welches beispielsweise 5 Sekunden vorher ein Delete für die geloggten Daten absetzt. Dann gibt es auch kein Problem bei einem PK

[DS_Starter]

Wenn du den nächsten Update-Zeitpunkt, der ja in MODE aufgeführt wird, in ein Reading packst, dann könnte man doch sicherlich ein DOIF basteln, welches beispielsweise 5 Sekunden vorher ein Delete für die geloggten Daten absetzt.

Ja, kann ich machen.

Da fällt mir noch eine recht einfach umzusetzende Variante ein.

Man nehme ein DbRep-Device und stelle es so ein dass ein

Code Auswählen Erweitern

set <> delEntries

immer die relevanten Readings (AllPVforecastsToEvent, Today_HourXX_PVforecast,.. ) löscht.
Die Zeitattribute:

Code Auswählen Erweitern


timestamp_begin  = current_hour_end
timestamp_end = next_day_end


sollten m.M. nach passen. In das DbRep trägt man dann noch im Attr executeAfterProc eine Routine oder einen FHEM-Befehl ein der nach dem Löschen ausgeführt wird, also z.B. dein weiter vorn geschriebens Script. Die Löschung der Daten musst du dann natürlich im SCript entfernen.

Code Auswählen Erweitern


executeAfterProc  =  { <Perl-Routine> }


Im Prinzip ist es das. Nur noch über ein at etc. regelmäßig das DbRep aufrufen und es werden die Daten sauber eingetragen.
Das DbRep führt immer zuerst die Löschung durch und startet wenn der Vorgang fertig ist das angegebene Script. Das stellt sicher, dass die Daten tatsächlich raus sind wenn neue kommen.
Das Ganze ist dann auch noch non-blocking.

Es gibt auch die Möglichkeit

Code Auswählen Erweitern


executeAfterProc  =  get <SolarForecast-Device> data


zu nutzen. Dann wird nach der Löschung ein Update von Solarforecast ausgeführt und es werden die AllPVforecastsToEvent Events erstellt. Die dann nur noch loggen und dann ist man auch fertig.
In diesem Fall stellt man das Update vom Solarforecast auf manuell (interval  = 0), damit es nur über DbRep gestartet wird.

Aber das Reading kann ich noch erstellen 

LG,
Heiko

[DS_Starter]

Hallo,

ich habe wieder eine neue V hochgeladen.
Intern ist einiges für die nächsten Schritte vorbereitet. Unter anderem findet man im

get <> pvHistory

den Schlüssel "con" der den Energieverbrauch des Hauses in der jeweiligen Stunde darstellt. Das ist die Grundlage für die kommende Schätzung des E-Verbrauchs in der Zukunft.

Weiterhin gibt es eine Angabe der Qualität der PV Ertragsschätzung je Stunde. Es steckt in:

get <> pvCircular

Kurze Erläuterung zu den Schlüsseln:

Code Auswählen Erweitern


13 => pvfc: 1534, pvrl: 2164, gcon: 1, gfeedin: 1731, wcc: 80, wrp: 3.00, wid: 2, wtxt: Bewölkung unverändert
      corr: 6=1.14 9=1.58
      quality:6=2


corr zeigt die bisher ermittelten Korrekturfaktoren der Stunde (hier 13) an. Dabei ist bei 6=1.14 der Wert 6 die Bewölungsrange und 1.14 der Korrekturfaktor dazu. Das baut sich nach und nach auf. Im besten Fall gibt es die Ranges 0-10 mit je einem Faktor dahinter. Dauert halt.

quality sagt aus, wieviele Tage welche die jeweilige Bewölkung in der Stunde X (hier 13) hatten und zur Korrekturfaktorermittlung genutzt werden konnten. Je größer desto besser ... max. 30. Im Beispiel hatten 2 Tage in der Stunde 13 eine Bewölkung von 6 und dauas wurde der Faktor abgeleitet.

Das Reading nextPolltime ist auch mit drin.