Leistungsprognose für Wechselrichter

[fichtennadel]

Verständnisfrage zu pvapifc, pvaifc und pvfc in nextHours (bzw. pvCircular):

in der Doku steht:
pvapifc erwartete PV Erzeugung (Wh) der verwendeten API
pvaifc    erwartete PV Erzeugung der KI (Wh)
pvfc    verwendete PV Erzeugungsprognose (Wh)


Ich verwende die SolCast API mit pvCorrectionFactor_Auto=on_simple

meine Interpretation für get ... nextHours:
pvapifc = der Wert, den die SolCast API liefert, entspricht den Werten aus get ... solApiData für die jeweilige Stunde (pv_estimate50: ..)
pvaifc = - leer (da keine KI)
pvfc = der vom Modul berechnete Forecast, auf Basis von pvapifc und dem errechneten Korrekturfaktor, weicht von pvapifc entsprechend der berechneten Korrekturfaktoren ab


Verstehe ich das so richtig?

[DS_Starter]

Moin,

ja genau.
Passt so wie du schreibst. Wenn die KI, falls sie im Einsatz wäre, einen Wert vorschlägt, hätte dieser Vorrang und würde dann als pvfc übernommen.

LG

[fichtennadel]

Bei mir ist aber für die jeweilige Stunde der Wert von pvapifc immer gleich dem von pvfc und ungleich pv_estimate50 aus get ... solApiData .

Ich habe mir die aktuelle Modulversion angesehen, in _transferAPIRadiationValues ab Zeile 5305:

Code Auswählen Erweitern

my $est = __calcPVestimates ($params);
$data{$type}{$name}{nexthours}{$time_str}{pvapifc}   = $est;                            # durch API gelieferte PV Forecast

aber in __calcPVestimates , Zeile 5442

Code Auswählen Erweitern

my $est = SolCastAPIVal ($hash, $string, $wantdt, 'pv_estimate50', 0) * $hc;                    # Korrekturfaktor anwenden
das geht dann über $pv und $pvsum in den return der Funktion und damit ins pvapifc.

Vielleicht übersehe ich etwas, aber dadurch landet doch der schon korrigierte Wert in pvapifc, oder? Das passt auch zu den Werten, die ich bei mir sehe.

[ch.eick]

Hi Max,

Was hältst du davon diese Funktion als eigenständiges Modul aufzubauen?

Ich denke das ist sehr gut möglich.
Dabei unterstütze ich dich gern und würde dir einen Großteil des bisher aufgebauten Know Hows bzw. Codes beisteuern bzw. daran mitarbeiten.
Es gibt in der Bibliothek noch Funktionen die wahrscheinlich erst bei einem breiteren Einsatz ihre Möglichkeiten entfalten. Ich denke dabei an copy_instances(from => $other_tree) oder set_results(\%results) in Verbindung mit "named" Instanzen add_instance(attributes => \%hash, result => $string, name => $string).

Wenn das zum Laufen käme, könnte man die Steuerung der Consumer von den Ergebnissen eines neuronalen Netzes  abhängig gestalten bzw. es ermöglichen dass eine KI Entscheidungen über die Consumersteuerung vorschlägt.
Fällt mir gerade dazu so ein. 

LG

Die Möglichkeiten wären wahnsinnig.
Ich denke an die Steuerung der Wärmepumpe anhand vonnWetterdaten, PV, Speicher und E-Auto. Sind ja alles Consumer in dem Fall

Das fände ich auch super, ich hatte ja zu Beginn des Threads schon mal vorgeschlagen die Prognose von der Planung getrennt zu halten.
Das ermöglicht einen flexibleren Einsatz. Aus dem Grund habe ich dieses Modul auch nicht in Verwendung.
Meine KI Umsetzung in Python würde ich auch gerne zu PERL transferieren, der Python Code wäre ja auch schon da.
Für die Verbraucher Planung müsste man halt überlegen mit welchen Werten man es in der KI in Relation bringt.

VG Christian

[DS_Starter]

Vielleicht übersehe ich etwas, aber dadurch landet doch der schon korrigierte Wert in pvapifc, oder? Das passt auch zu den Werten, die ich bei mir sehe.

Bin jetzt wieder zu Hause ... deswegen nochmal zur Erläuterung.
pvapifc in nextHours ist der mit eventuellen Korrekturen abgewandelte Wert aus der Lieferung der gewählten API.
pvaifc ist ein durch die KI gelieferter Wert sofern vorhanden. Wenn Treffer durch KI -> aihit = 1 sonst 0.
pvfc ist der tatsächlich verwendete Wert abhängig von aihit.

Im folgenden Beispiel mit aihit = 1 wird pvaifc nach pvfc übernommen und verwendet:

Code Auswählen Erweitern

pvapifc: 1311, pvaifc: 517, pvfc: 517, aihit: 1
Und hier wird pvapifc nach pvfc übernommen:

Code Auswählen Erweitern

pvapifc: 844, pvaifc: -, pvfc: 844, aihit: 0
Es wirkt de facto wie eine Auswahlschaltung.

Edit: Im nächtes Update passe ich die Doku dazu an. Dann ist die Bedeutung klarer.

[DS_Starter]

Das fände ich auch super, ich hatte ja zu Beginn des Threads schon mal vorgeschlagen die Prognose von der Planung getrennt zu halten.
Das ermöglicht einen flexibleren Einsatz.

Nö mein lieber Christian, bestimmt nicht. 
Man kann dann evtl. die Logik mit einer KI Entscheidung ergänzen/anreichern.
Ob eine KI bei Anwendung in der Verbrauchersteuerung überhaupt Vorteile bringt (im Amateuerbereich) muß sie erst noch beweisen. Denn Entscheidungen einer KI sind nicht vorhersehbar. Will man das in jedem Fall? Ich bezweifle es.

Überhaupt ist der aktuelle Hype um KI in meinen Augen fragwürdig. Es hat manchmal ein wenig den Anschein als hätte man jetzt den heiligen Gral gefunden und in Zukunft wird man ohne KI keinen Nagel mehr gerade in eine Wand bekommen. Wie hat nur Wissenschaft und Technik bisher ohne KI sich entwickeln und funktionieren können ... einfach unfassbar, oder?

Spaß beseite, zweifellos wird eine KI in bestimmten Fällen Vorteile bringen. Das muß sich aber erst noch zeigen.
Wenn es mal ein KI Modul geben wird, und ich bin relativ zuversichtlich dass Max und ich das hinbekommen, wird es im SolarForecast Modul einen Consumerkey geben mit dem man die Entscheidung einer KI aktivieren/einbinden kann. Welche Trainingsdaten die KI dann bekommt, wird dann auch innerhalb von SolarForecast festgelegt und an das KI Modul übergeben.
Natürlich kann man ein KI Modul auch für eigene Dinge nutzen. Aber das ist hier nicht im Fokus.

LG

[fichtennadel]

pvapifc in nextHours ist der mit eventuellen Korrekturen abgewandelte Wert aus der Lieferung der gewählten API.

Hm, ok, pvapifc also doch mit Korrekturen. Dann wird aber der Korrekturfaktor auf Basis der schon abgewandelten Werte berechnet (in _calcCaQsimple) und das führt meiner Ansicht nach zu einer ungünstigen Berechnung.

Beispiel für pvapifc = pvfc , hier sieht man wie der Korrekturfaktor sogar nach oben geht, obwohl der tatsächliche Wert noch niedriger als vorhergesagt ist:

Code Auswählen Erweitern

SolCast pvapifc pvfc pvrl corr (=pvrl/pvapifc)
Tag 1 1000 1000 1000 750 0,75
Tag 2 1000 750 750 600 0,8
Tag 3 1000 800 800 600 0,75
Diesen Fall hatte ich heute in meinen realen Daten, deshalb habe ich das hier aufgebracht.

Die Alternative mit pvapifc 1:1 aus der API wäre aus meiner Sicht schlüssiger:

Code Auswählen Erweitern

SolCast pvapifc pvfc pvrl corr (=pvrl/pvapifc)
Tag 1 1000 1000 1000 750 0,75
Tag 2 1000 1000 750 600 0,6
Tag 3 1000 1000 600 600 0,6

Edit: das war die vereinfachte Darstellung, die Berechnung von corr=sum(pvrl)/sum(pvapifc) ändert zwar die konkreten Werte, aber der Effekt ist derselbe:

Code Auswählen Erweitern

SolCast pvapifc pvfc pvrl corr (=sum(pvrl)/sum(pvapifc))
Tag 1 1000 1000 1000 750 0,75
Tag 2 1000 750 750 600 0,77
Tag 3 1000 800 800 600 0,76


SolCast pvapifc pvfc pvrl corr (=sum(pvrl)/sum(pvapifc))
Tag 1 1000 1000 1000 750 0,75
Tag 2 1000 1000 750 600 0,68
Tag 3 1000 1000 600 600 0,65


[DS_Starter]

Die Alternative mit pvapifc 1:1 aus der API wäre aus meiner Sicht schlüssiger:

Auf den ersten Blick sieht es so aus.
Allerdings gibt es da mehrere Unsicherheiten. Eine ist, dass die gelieferten Ausgangswerte der API daneben liegen. Wir gehen also immer davon aus dass die gelieferten grundsätzlich fehlerbehaftet sind.
Und wenn es mal einen Tag gibt der voll daneben liegt, würde er über die Maßen durchschlagen.

Deswegen wird bei dem Korrekturansatz nicht nur die Abweichung des letzten Tages zum Ansatz gebracht, sondern der Durchschnitt aller vergangenen Prognosen und realen Erzeugungen.
Deswegen wird gerechnet:

 ((750 + 600 + 600) / 3) / ((1000 + 750 + 800) / 3) ->  650 / 850 -> 0,76

Das Schema kannst du ändern indem du über das Attr affectNumHistDays die zu berücksichtigenden Tage änderst.
Bei affectNumHistDays = 1 basiert die Korrektur nur auf dem Ergebnis des letzten Tages. Dann hast du wahrscheinlich was du möchtest. Beachte auch das Attr affectMaxDayVariance.

Ich habe in der nun mittlerweile 3 jährigen Entwicklungszeit des Moduls einige Korrekturvarianten getestet.
Man kann davon ausgehen dass die aktuelle Variante einen guten Kompromiss darstellt.
Und weil sich die Vorgehensweise bewährt hat, werde ich auch nichts daran ändern.

[stephan-221]

Ein klasse Modul!

Ich brauche noch einen Forecast für meine Heizstäbe. Damit meine Gasheizung das Brauchwasser mehr oder weniger aufheizt. Das hatte ich über den Sommer statisch. Nun habe ich hier ein Modul, was noch wesentlich mehr bietet.

Bei der ersten Einrichtung bin ich auf eine Ungenauigkeit bei mir gestoßen.
Ich habe zwei Hoymiles Wechselrichter mit openDTU und einen SMA Hybridwechselrichter. Der SMA Hybridwechselrichter hat aber keine eindeutigen AC Werte (pac), da eben die Ladung direkt per DC erfolgt und in der AC Leistung nicht nur die Versorgung ins Hausnetz sondern auch direkt die Versorgung aus der Batterie enthalten ist. Der Ersatzstrom zumindest wird glaube ich nicht separat betrachtet.

Ich habe heute auch schon in meinen Diagrammen für die Addierung der Gesamterzeugung aller Wechselrichter bei DC-Werten / 1100 genommen um etwa 10% Verlust einzurechnen.

Code Auswählen Erweitern

fhem "setreading InverterDummy total_pac ".sprintf("%.3f",(ReadingsNum("MQTT2_OpenDTU","1111_0_power",0)/1000)+(ReadingsNum("MQTT2_OpenDTU","2222_0_power",0)/1000)+(ReadingsNum("STP8SE","DC_Leistung",0)[color=red]/1100[/color]));

Damit ich dennoch $wert6 berechnen kann, lese ich direkt die BYDBox aus. Dort bekomme ich die Akkuleistung als negativen/positiven Wert.

Code Auswählen Erweitern

my $wert6 = sprintf("%.3f",((ReadingsNum("BYDBox","BatteryPower",0)/1000)));

Nur so als Idee, falls jemand vor dem gleichen Knoten im Hirn steckt


Jetzt muss ich mal beobachten, ob das Modul alle Daten korrekt bekommt.
Im nächsten Schritt kommen die Verbraucher und die Gasheizung rein.

[moskito]

N´abend,
ich hätte da leider mal ein Problem:
Beim Versuch ein Solarforecast Device (offizielle Modulversion) mit Victron-KI anzulegen, schmiert mir immer das komplette FHEM nach Eingabe der Victron Zugangsdaten ab.
Letzter Eintrag im Log:

Code Auswählen Erweitern

Not an ARRAY reference at ./FHEM/76_SolarForecast.pm line 3673.
Dabei zerschiesst es mir auch immer noch ein Attribut von 2 anderen Devices, aber das sind wahrscheinlich Kollateralschäden.
Wundert mich, weil es doch schon einige mit Victron am laufen haben.

Gruß
Danny

[DS_Starter]

Hallo Danny,

ich habe jetzt eine Weile darüber nachgedacht und bin der Meinung, dass es nicht an der Eingabe der Zugangsdaten liegt sondern an den Daten die dein Victron VRM liefert.
Schau mal im VRM Portal ob bei dir überhaupt Vorhersagedaten vorliegen.

Dessen ungeachtet muß ich natürlich einen solchen Fehler abfangen.
Melde mich wieder.

[moskito]

Habe jetzt bei Victron nochmal nachgeschaut und wahrscheinlich liegst du richtig.
Ich habe zwar Strahlungsdaten in der erweiterten Ansicht, aber die eigentliche Anzeige im Dashboard ist nicht verfügbar.
Das ist also erstmal ein Problem auf meiner Seite.

Trotzdem besten Dank - auch für das Modul an sich!

Gruß
Danny

[DS_Starter]

Habe die Korrektur eingecheckt. Ist morgen früh im Update.
Dieser Fehler sollte nun abgefangen werden.

[DS_Starter]

Ich habe zwar Strahlungsdaten in der erweiterten Ansicht, aber die eigentliche Anzeige im Dashboard ist nicht verfügbar.

Die Voraussetzungen hast du im VRM Portal sicher eingerichtet. Bei mir hat es einige Tage gedauert bevor das Portal Vorhersagedaten geliefert hat.
Musst du mal verfolgen.

Edit: Was geliefert wird siehst du wenn du dir ctrlDebug apiCall,apiProcess aktivierst.

[stefanru]

Hi Heiko,

ich versuche gerade meine Batterieladesteuerung von DOIF auf UserExit umzustellen.
Dabei möchte ich deinem Coding folgen und mal schauen was es berechnet da mein DOIF coding die letzten Tage etwas versagt hat.

Zu deinem Beispiel habe ich eine Frage.
Was ist:
my $mppt1  = 'MQTT2_cerboGX_c0619ab34e08_solarcharger_Common';              # SmartLoader Device
Ein zusätzlicher Stromabnehmer, den du raus rechnen willst, wie eine Autoladestation?
$cspc = sprintf "%.2f", ($cspc - $mppt1c);      # SmartLoader IST berücksichtigen

Brauche ich das auch?
Wenn das wirklich so ist geht die Hausbatterie bei mir vor.

Danke und Gruß,
Stefan