Leistungsprognose für Wechselrichter

[fichtennadel]

Gegenfrage ... aus welchem Grund sollte der Faktor deiner Meinung nach 0.26 und nicht 0.52 sein?

SolCast heute:

Code Auswählen Erweitern

2023-09-29 08:00:00 => pv_estimate50: 5650
Ist-Werte heute:

Code Auswählen Erweitern

pvfc: 2938, pvrl: 1512
1512/5650 = 0.2676

Oder versteh ich was falsch?

[DS_Starter]

Aus der history rechnen:

pvfc: 2938, pvrl: 1512  -> 1512/2938 = 0,52 (gerundet) -> Abschlag für pvfc da zuviel geschätzt

Der Faktor 0,52 wird für den kommenden Tag verwendet wenn die weiteren Rahmenbedingungen zutreffen.
Das ist aber nur vereinfacht wenn es lediglich einen Wert in der history gibt. Ansonsten werden die verfügbaren Tage im Durchschnitt ermittelt, u.U. in Abhängigkeit der Bewölkungslage. 

[DS_Starter]

Wenn das System länger läuft, sieht man mit "get ... pvCicular" eine Übersicht der kalkulierten Korrekturfaktoren die Verwendung finden:

Code Auswählen Erweitern

09 => pvapifc: 637, pvaifc: -, pvfc: 637, aihit: 0, pvrl: 738
      batin: 0, batout: 0, confc: -1, gcon: 20, gfeedin: 8, wcc: 53, wrp: 1.00
      temp: 13.8, wid: 1, wtxt: Bewölkung abnehmend
      corr: 4=1.50 5=1.50 6=1.33 8=0.66 9=0.79 11=1.50 12=1.48 13=1.50 14=1.18 15=1.50
            16=0.67 18=1.19 19=0.88 21=1.50 23=0.69 24=0.72 26=0.68 27=1.20 29=0.81 30=0.74
            33=0.77 34=0.59 35=1.38 37=1.50 38=1.25 40=1.50 43=1.50 44=1.21 45=1.14 46=0.77
            48=0.96 49=1.13 50=1.04 51=0.98 52=1.55 53=1.26 54=1.51 56=1.15 58=1.78 59=1.45
            60=0.76 61=1.50 62=0.48 65=0.96 66=1.13 68=1.46 69=0.78 70=1.19 71=0.78 72=0.62
            73=0.94 74=0.81 75=1.00 77=1.50 79=1.02 80=1.00 81=1.10 83=0.92 84=0.50 85=1.50
            86=1.16 87=0.69 88=0.64 89=1.50 91=0.90 92=0.98 95=1.45 96=0.53 100=0.97
            percentile=2.37
      quality: 4=0.64 5=0.66 6=0.75 8=3 9=2 11=0.57 12=0.68 13=0.52 14=0.61 15=0.64
               16=1 18=0.45 19=0.87 21=0.28 23=1 24=1 26=1 27=0.83 29=0.77 30=0.00
               33=0.7 34=0.30 35=0.59 37=0.46 38=0.65 40=0.61 43=0.50 44=0.83 45=0.29 46=1
               48=0.96 49=0.88 50=0.97 51=0.98 52=0.65 53=0.79 54=0.44 56=0.00 58=0.49 59=0.69
               60=0.69 61=0.62 62=0.00 65=1 66=0.89 68=0.68 69=0.72 70=0.29 71=0.71 72=0.40
               73=0.84 74=0.76 75=0.54 77=0.57 79=0.77 80=0.00 81=0.91 83=0.80 84=0.00 85=1
               86=1 87=1 88=1 89=0.50 91=0.89 92=0.98 95=0.69 96=0.13 100=0.97
               percentile=0.62

Die Hilfe dazu beschreibt die Bedeutung der Schlüssel.

[fichtennadel]

Aus der history rechnen:

pvfc: 2938, pvrl: 1512  -> 1512/2938 = 0,52 (gerundet) -> Abschlag für Forecast da zuviel geschätzt

Ok, aber dann verstehe ich den Gedanken dahinter nicht:

SolCast schätzt 5650, SolarForecast schätzt 2938, real kommem 1512.

Dann müsste doch die Schätzung von SolCast für morgen mit 0.26 skaliert werden, damit ein realistischer Wert entsteht. Die 0,52 beziehen sich ja schon auf den skalierten Wert für heute.

pvCicular

Code Auswählen Erweitern

09 => pvapifc: 1731, pvaifc: -, pvfc: 1731, aihit: 0, pvrl: 1512
      batin: -, batout: -, confc: 304, gcon: 16, gfeedin: 1216, wcc: 42, wrp: 3.00
      temp: 19.1, wid: 1, wtxt:
      corr: 0=0.76 9=0.80 28=0.77 33=0.72 71=0.79
            percentile=0.52
      quality: 0=0.06 9=0.36 28=0.13 33=0.00 71=0.31
solApiData

Code Auswählen Erweitern

2023-09-30 08:00:00 => pv_estimate50: 3329
Das ist wieder der Faktor 0.52 zwischen SolCast und SolarForecast für morgen, wie schon gestern und heute. Real ist der aber 0,27.

[DS_Starter]

Die Werte in der pvhistory sind vergangene Werte und spiegeln die Realität des Tages X Stunde 09 wider.
Es wurden geschätzt 2938, real 1512  produziert.

Was SolCast liefert (5650) bezieht oder bezog sich zum Zeitpunkt der Lieferung auf die Zukunft.
Dieser Wert wird dann (wenn eingestellt) mit dem aus historischen Vorfällen ermittelten Korrekturfaktor korrigiert.
Welcher Faktor angewendet wird, steht in NextHours bzw. als gesamter Wertevorrat in pvCircular.
Ansonsten verweise ich auf die Programmroutinen calcValueImproves, ___readCandQ nebst Unterroutinen wenn du dich näher mit der Materie auseinandersetzen möchtest.

Ergänzung: das Ganze lebt natürlich. Wenn festgestellt wird, dass der Faktur 0.52 nicht ausreicht, weil z.B. für morgen SolCast 5650 liefert und wieder nur
1512  real produziert werden, wird der Faktur natürlich sukzessive nach unten korrigiert. Ansonsten andere Richtung. Das ist ein ständiger Prozess der zu jeder Stunde ausgeführt wird.

[fichtennadel]

Ergänzung: das Ganze lebt natürlich. Wenn festgestellt wird, dass der Faktur 0.52 nicht ausreicht, weil z.B. für morgen SolCast 5650 liefert und wieder nur
1512  real produziert werden, wird der Faktur natürlich sukzessive nach unten korrigiert. Ansonsten andere Richtung. Das ist ein ständiger Prozess der zu jeder Stunde ausgeführt wird

Mein Edit hat sich mit Deiner Antwort überschnitten

Das "nach unten korrigiert" hat mir gefehlt, danke. D.h. es wird schon auch SolCast-API mit real verglichen und nicht nur Forecast mit real, korrekt?

[DS_Starter]

Ja. Im Prinzip ist es ein stufiger Prozess, als konstruiertes Beispiel:
SolCast liefert (5000) der Ausgangsfaktor ist 1 -> Schätzung 5000, produziert 2500 -> Korrekturfaktor 0,5.
SolCast liefert wieder 5000 -> Korrekturfaktor 0,5 angewendet -> Schätzung 2500 , produziert 2600 ->
     
      jetzt Schätzung (7500/2) / produziert (5100/2) -> 2550 / 3750 -> neuer Faktor 0,68

....

Ist natürlich vereinfacht. SolCast liefert mit hoher Wahrscheinlichkeit keine identischen Werte an zwei Tagen zur selben Stunde aufeinanderfolgend. Bewölkung kommt auch noch hinzu (bei complex).
Vllt. jetzt verständlicher.

[Heatseeker]

@Heatseecker - hier ist auch Huawei im Einsatz, wenn die Energie aus dem Akku entnommen wird wird sie aber wieder als solare erzeugung gezählt... Ich hab das problem mit Heiko bereits diskutiert - die Daten anders zu erfassen ist zu umständlich.

DC gekoppelte Akkus sind hier nur schlecht abzubilden.

Moin,

Also ich musste etwas experimentieren, aber inzwischen kann ich meine Erzeugung recht gut berechnen und für SolarForecast nutzten.
Bei meinem Huawei System habe ich einen monotonic userreading erzeugt mit
Erzeugung = WR_Gesamtertrag + ESS_Energieladung_ges - ESS_Energieentladung_ges

Das klappt recht gut. Ladungen der Luna gehen auf den Zähler rauf und bei der Entladung bleibt der Zähler quasi in Waage...

Nur so als Tip für andere Huawei User...

[der-Lolo]

Ja, aber damit nimmst Du den Akku ( das was Du entnimmst ) ja komplett aus der Berechnung heraus, oder?

[MadMax]

4.) Weiterhin gibt es für das Attr ctrlStatisticReadings folgende weitere Elemente:

    - todayConsumptionForecast -> die Verbrauchsprognose aufgeschlüsselt pro Stunde des aktuellen Tages (01-24) wird als einzelne Readings 
                                                        statistic_todayConsumptionForecast_XX erzeugt
    - conForecastTillNextSunrise -> die Verbrauchsprognose von aktueller Stunde bis zum kommenden Sonnenaufgang

Die Changes 4.) entsprechen den Wünschen von @Max und @Stefan. Ich hoffe es passt so für euch.

Hallo Heiko,

vielen Dank, die Werte helfen mir sehr gut weiter.

Gruß
Max

[fichtennadel]

Frage zur Consumer Integration:

ich habe drei (Test-)Verbraucher:

Code Auswählen Erweitern

attr PVForecast_DWD consumer01 SolCastDummy3 icon=sani_buffer_electric_heater_side type=heater mode=can power=2500 auto=automatic on=on off=off mintime=sunpath interruptable=1
attr PVForecast_DWD consumer02 SolCastDummy2 icon=vent_ventilation type=heater mode=can power=500 auto=automatic on=on off=off mintime=sunpath interruptable=1
attr PVForecast_DWD consumer03 SolCastDummy icon=vent_ventilation type=heater mode=can power=1000 auto=automatic pcurr=actpow:W on=on off=off mintime=15 asynchron=1 locktime=300:1200 interruptable=1

consumer03 wird aber schon den zweiten Tag nicht eingeschalten, weil (so vermute ich) zum Zeitpunkt der Einplanung nicht ausreichend Leistung vorhanden ist:

Code Auswählen Erweitern

2023.10.02 08:01:59 1: PVForecast_DWD DEBUG> consumer "03" - general switching parameters => auto mode: 1, current Consumption: 380 W, nompower: 1000, surplus: 47 W, planstate: planned: 2023-10-02 07:47:59 - 2023-10-02 08:02:59, starttime: 02.10.2023 07:47:59
2023.10.02 08:03:09 1: PVForecast_DWD DEBUG> consumer "03" - general switching parameters => auto mode: 1, current Consumption: 380 W, nompower: 1000, surplus: 47 W, planstate: planned: 2023-10-02 07:47:59 - 2023-10-02 08:02:59, starttime: 02.10.2023 07:47:59
[...]
2023.10.02 09:50:31 1: PVForecast_DWD DEBUG> consumer "03" - general switching parameters => auto mode: 1, current Consumption: 532 W, nompower: 1000, surplus: 7103 W, planstate: planned: 2023-10-02 07:47:59 - 2023-10-02 08:02:59, starttime: 02.10.2023 07:47:59
später wäre dann genug Leistung, aber das Planungszeitfenster ist schon vorbei (siehe 3. Zeile).

Ich hätte gerne, dass consumer03 für mintime läuft, sobald nach consumer01 + consumer02 noch ausreichend Überschuss vorhanden ist.

Wie lässt sich das lösen?

[DS_Starter]

Moin,

da gibt es sicherlich einige Ansätze.
Ich würde folgenden Weg versuchen.

Setze dir zunächst das Attr ctrlConsRecommendReadings für den Verbaucher 03.
Dann wird es ein Reading

 consumer03_ConsumptionRecommended

geben, welches man auswerten kann. Es wird immer dann "wahr" (1) sein, wenn die Einschaltung des Consumers empfohlen ist unabhängig des kalkulierten Einplanungszeitraums.
Dann brauchst du eigentlich nur noch eine Verknüpfung mit dem aktuellen Einplanungsstatus.
Dazu bietet sich eine kleine Routine im Attr ctrlUserExitFn an.

Ich gebe mal ein Beispiel ohne es getestet zu haben. In das Attr ctrlUserExitFn fügt man den Code in {...} eingeschlossen ein.

Code Auswählen Erweitern

{
  my $rcm  = ReadingsVal ($name, 'consumer03_ConsumptionRecommended', 0);   # Empfehlungsstatus einschalten
  my $stat = ReadingsVal ($name, 'consumer03', '');                         # Status von Consumer 03

  if ($stat =~ /planned/xs && $rcm) {
      fhem ("set $name reset consumerPlanning 03");                         # Neueinplanung durch Modul
     
      # oder
      # fhem ("set $name consumerImmediatePlanning 03");                    # sofortige Neueinplanung,d.h. Sofortstart
      #
  }
 
  Log3 ($name, 3, "$name - Consumer 03 wurde durch userExitFn neu geplant/gestartet")
}

Der Code und die abhängigen Verknüpfungen ließen sich natürlich noch beliebig ausbauen nach Bedarf.
Im obigen Beipiel wird Consumer 03 neu geplant wenn Einschalten des Verbrauchers sinnvoll ist und wenn der Planungsstatus immernoch "planned" ist. Dadurch wird verhindert, dass ein bereits laufender 03 immer wieder neu geplant wird und wenn er fertig ist dann auch aus bleibt.

[DS_Starter]

Hallo zusammen,

es ist geschafft. 
Durch das verlängerte Wochenende bin ich schneller vorangekommen als gedacht und konnte das Modul nun
in das Repo einchecken.

Das Modul wird also ab morgen früh im FHEM Update ausgerollt.

Bitte macht dieses Update zeitnah, damit ihr den aktuellen Stand habt auf den weitere Entwicklungen aufsetzen werden.
Kleinere Änderungen werde ich wie üblich über das Update verteilen.
Größere Änderungen oder neue Features stelle ich euch gern hier zum Testen vorab zur Verfügung. Diese Entwicklungsversionen zieht ihr euch dann bitte wie bisher aus meinem contrib Verzeichnis.

Wer es noch nicht kennen sollte ... damit eine lokal geänderte Version nicht beim nächsten FHEM Update überschrieben wird, ergänzt im global Device das Attr exclude_from_update entsprechend mit dem Modulnamen 76_SolarForecast.

[MadMax]

Hallo Heiko,
klasse 

Ich habe mir das mit deiner AI/KI Implementierung mal angesehen und die Bibliothek dazu auch.
Was hältst du davon diese Funktion als eigenständiges Modul aufzubauen? Ich würde das mal versuchen wollen.
Ich denke das könnte man ja Großteiles aus deinem übernehmen.
Hier könnten noch andere Vorhersagen und Automatisierte Prozesse von selbstlernenden Funktionen Profitieren.

Gruß
Max

[DS_Starter]

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