Leistungsprognose für Wechselrichter

DS_Starter · 14 Juli 2023, 20:58:41

Vielen Dank cbl

und es freut mich wenn dir das Modul gefällt und vor allem hilfreiche Dienste leistet.
Den Dank nehme ich gerne auch im Namen der etlichen Mitwirkenden entgegen die sich im Modul mit eingebracht haben. Gerade auch bzgl. der Grafik war und bin ich den Unterstützern sehr dankbar.

Wir machen weiter

DS_Starter · 14 Juli 2023, 21:50:15

Ich habe ein leichtes Bugfixing betrieben ... bitte updaten aus contrib.

kask · 14 Juli 2023, 21:57:34

Hallo,
ich habe einen unheimlich großen (unrealistischen) Verbrauch laut Forecast (immer!).

Code Auswählen

Tomorrow_ConsumptionForecast   57851 Wh

In realität habe ich aber in etwa sowas (-5..+15kw):

Code Auswählen

statEcP_AC_Consumption_valueTotalDay  19.3486849216199062 kWh

wo liegt der Fehler, wo muß ich gucken? Kann mir einer helfen.

Dracolein · 14 Juli 2023, 22:05:18

Was hast du für ein "currentRadiationDev" eingestellt? Im Falle der SolCast-API hast Du dort Accounts angelegt und Deine PV-Flächen dort konfiguriert. Stimmen dort die Parameter ? (Neigung, Himmelsrichtung, etc, pp)

kask · 14 Juli 2023, 22:09:12

Ich habe alle 3 versionen/api's parallel laufen. Der PV Forecast funkioniert wie er soll. Aber der consumption forecast ist fast doppelt so hoch.
Was mich irritiert ist das der consumption forecast schon immer hoch ist/war.
Jetzt bin ich auf der suche warum das so ist.

DS_Starter · 14 Juli 2023, 22:15:27

Rufe dir die pvHistory auf -> "get ... pvHistory".
An jedem Tag gibt es die Stunde 99. Dort der Schlüssel "con" ist der Verbrauch an dem Tag in Wh,

99 => etotal: , pvfc: 28706, pvrl: 31635
confc: 10590, con: 7857, gcon: 218, gfeedin: 23894
batintotal: , batin: 5037, batouttotal: , batout: 4935
wid: , wcc: , wrp: , pvcorrf: , dayname: Di

Die Prognose confc wird aus dem Durchschnitt der "99" con gebildet.

Entweder hast du einen großen Ausreißer der den Durchschnitt versaut oder du hast evtl. bei einem Verbraucher die Einheit im Attribut Schlüssel "etotal" falsch angegeben.
Dann müsstest du jeden Tag einen zu hohen con-Wert finden.

Zusätzlich gibt es noch den Debug "consumption" den du einstellen kannst. Vllt. hilft das bei der Suche.

kask · 14 Juli 2023, 22:37:25

hmmm. Ich habe mir mal die 76_SolarForecast.pm reingezerrt.
Da gesehen das es einen debug für die consumption calculation existiert.
Das jetzt erst einmal scharf gemacht.
Zuvor habe ich mir die pvHistory angetan und die con werte angeschaut. Die alten sehen alle gut und plausible aus.
Das einzige ist der 99'er. Der sagt mit jetzt gerade 21312

Code Auswählen

99 => etotal: , pvfc: 61049, pvrl: 59011
            confc: 56130, con: 21312, gcon: 170, gfeedin: 37769
            batintotal: , batin: 5200, batouttotal: , batout: 5100
            wid: , wcc: , wrp: , pvcorrf: , dayname: Fri

Ich habe keine consumer angelegt und nutze diese funktion auch nicht. Ich benötige erst einmal nur den Forecast.

Edit:
Danke DS_Starter. Das ist das was ich auch heraus gefunden habe. Mein Post hat nur zulange gedauert, da warst du schneller.

kask · 14 Juli 2023, 22:49:48

OK, ich komme weiter.
am 26.06 hatte ich den ausreisser.

Code Auswählen

      99 => etotal: , pvfc: 55933, pvrl: 1153944
            confc: 16368, con: 1119783, gcon: 386, gfeedin: 35347
            batintotal: , batin: 5400, batouttotal: , batout: 6200

aber das ist vorher auch schon passiert.
14.06 und früher habe ich hohe confc werte:

Code Auswählen

99 => etotal: , pvfc: 59191, pvrl: 57761
            confc: 57841, con: 21441, gcon: 206, gfeedin: 35126
            batintotal: , batin: 6400, batouttotal: , batout: 5000

15.06 normalisiert sich confc wieder bis zum 26.06:

Code Auswählen

      99 => etotal: , pvfc: 63528, pvrl: 55608
            confc: 17109, con: 14935, gcon: 232, gfeedin: 41205
            batintotal: , batin: 5500, batouttotal: , batout: 5800

mal vorschen was da und warum passiert ist.

DS_Starter · 14 Juli 2023, 22:50:43

Ach, jetzt habe ich mich von den consumern gerade irritieren lassen weil ich gerade daran arbeite.

Wisch es weg.
Derr 99-Wert ist schon richtig, ist aber wiederum die Summe der Stundenwerte con des Tages.
Die findest du natürlich auch in der pvHistory.

Der con Wert jeder Stunde wird wie folgt berechnet:

Code Auswählen

  my $pvrl    = ReadingsNum ($name, "Today_Hour".sprintf("%02d",$shr)."_PVreal",          0);
  my $gfeedin = ReadingsNum ($name, "Today_Hour".sprintf("%02d",$shr)."_GridFeedIn",      0);
  my $gcon    = ReadingsNum ($name, "Today_Hour".sprintf("%02d",$shr)."_GridConsumption", 0);
  my $batin   = ReadingsNum ($name, "Today_Hour".sprintf("%02d",$shr)."_BatIn",           0);
  my $batout  = ReadingsNum ($name, "Today_Hour".sprintf("%02d",$shr)."_BatOut",          0);

  my $con = $pvrl - $gfeedin + $gcon - $batin + $batout;

Diese Readings findest du ja z.B. für den aktuellen Tag.
Vllt. fällt dir da eine Ungereimtheit auf ?

kask · 14 Juli 2023, 23:19:29

Also um 20Uhr am 26.06 kam der Ausreisser vermutlich durch den pvrl wert.
Jetzt mal schauen wie ich den zermamelt habe. Ich vermute das ich es war, da ich ständig an FHEM rumfummel

Code Auswählen

      19 => etotal: 5306483, pvfc: 1633, pvrl: 1460
            confc: 1107, con: 1113, gcon: 4, gfeedin: 451
            batintotal: 608700, batin: 0, batouttotal: 608300, batout: 100
            wid: 2, wcc: 57, wrp: 4.00, temp: 21.5, pvcorrf: 0.82/1
      20 => etotal: 5307963, pvfc: 941, pvrl: 1103687
            confc: 1175, con: 1103542, gcon: 31, gfeedin: 176
            batintotal: 608700, batin: 100, batouttotal: 608400, batout: 100
            wid: 1, wcc: 54, wrp: 4.00, temp: 20.6, pvcorrf: 1031.48/1

DS_Starter · 14 Juli 2023, 23:44:45

Die störende Stunde kannst du dir löschen mit:

set <name> reset pvHistory <Tag> <Stunde> (z.B. set <name> reset pvHistory 08 10)

Wäre sowieso gut wenn man den Korrekturfaktor sieht -> pvcorrf: 1031.48/1

kask · 14 Juli 2023, 23:49:38

Ich wusste da gab es was um die historie zu manipulieren. Wusste aber nicht mehr was oder wie. Jetzt muss ich nicht mehr suchen wie das ging.
Dank Dir.

Ich hatte meine Inverter-Dummy Daten aufgerödelt, und das kam leider dabei raus. Also den Grund auch gefunden!

Dracolein · 15 Juli 2023, 07:40:31

Kurzes Feedback zu spignorecond: es scheint zu funktionieren wie gedacht. Gestern nachmittag war schöner Sonne-Wolken-Mix zum testen.

Code Auswählen

attr PVVorschau consumer01 ShellyPlug5 type=other power=700 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off auto=Automatiksteuerung spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=sani_heating mintime=600 notbefore=11 notafter=20

attr PVVorschau consumer02 ShellyPlug6 type=other power=600 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off auto=Automatiksteuerung icon=sani_heating

attr PVVorschau consumer03 ShellyPlug7 type=other power=430 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off auto=Automatiksteuerung icon=sani_heating

attr PVVorschau consumer04 MQTT2_layzspa type=other power=1950 mode=can on="heater on" off="heater off" pcurr=WATT interruptable=1 swstate=heaterstate:1:0 auto=Automatiksteuerung mintime=SunPath spignorecond=EVCharger22:LadungMitPVUeberschussActive:1 icon=scene_pool notbefore=8 notafter=20

attr PVVorschau consumer05 EVCharger22 type=charger power=1400 mode=can on="Param_Betriebsart_Ladevorgang 4719" off="Param_Betriebsart_Ladevorgang 4721" interruptable=1 swstate=Status_Ladevorgang_forSolarForecast pcurr=Leistung_Ladestation mintime=SunPath icon=electric_car_charger

attr PVVorschau consumer06 ShellyPlug1 type=other power=300 mode=can on=on off=off pcurr=power:W interruptable=1 swstate=state:on:off mintime=SunPath locktime=900 notbefore=07 notafter=22 spignorecond=ESPEasy_ESP_Easy1_am2302_sensor:humidity:68 icon=Ventilator_fett

Consumer1 = Klimagerät
Consumer4 = Whirlpoolheizung
Consumer6 = Luftentfeuchter
Consumer5 = Wallbox

Die Geräte schalten bei Überschuss wie gewünscht alle nacheinander ein und Consumer 1/6 bleiben tatsächlich an. Die Wallbox regelt sich (wenn nicht beim Einschaltzeitpunkt schon passend) auf verbliebenen ungenutzten PV-Überschuss ein und lädt das Auto.

Die Wallbox schaltet bei ungenügend Überschuss nun wesentlich (!!) schneller ab, als das SMA-Universum getan hätte. It´s not a bug, it´s a feature! (die SMA-Regelung ist offenkundig sehr lahm, was zu hohen Regelungenauigkeiten und letztlich bei voreingestellten 100% PV-Überschuss-Laden zu unnötigen kWh Netzbezug führt (7-8% bei mir!). Da hier SolarForecast meiner Wallbox bei ungenügend Überschuss einfach die Ladefreigabe entzieht, ist nach < 1 Minute Ladestop.
Werde den heutigen Tag nochmal nutzen, um alles zu beobachten.

DS_Starter · 15 Juli 2023, 08:56:05

Moin,

@Dracolein, das klingt doch erstmal nicht so schlecht. Bin gespannt was du uns noch berichten wirst.

@Dieter (dk3572), habe mich gestern nochmal intensiver mit deinem Wunsch beschäftigt. Es ist tasächlich nicht so trivial wie es zunächst aussieht den Wunsch umzusetzen.
Deshalb vorweg nochmal folgende Überlegung und Frage.
Die Restlaufanzeige zeigt die nach dem Start des Consumers bis zu dessen Stopp verbleibende Restzeit, welches das Modul dann automatisch ausführen wird. Das Verfahren bedingt aber, dass dem Modul erlaubt wird automatisch zu stoppen.
Wenn du wie du schreibst die automatischen Schaltungen durch das Modul untersagst, ist die Restlaufanzeige nicht der Realität entsprechend da sie nicht eingehalten werden kann. Der Consumer läuft einfach weiter.

Jetzt ist die Frage, welche Mehrwert hätte eine Anzeige in diesem Fall wenn sie doch
1. inhaltlich falsch
2. ohne Funktion ist

Bevor ich in diese Sache wirklich noch mehr Zeit investiere beantworte mir doch bitte die Frage welche Funktion eine solche Möglichkeit für dich hätte und welchen Mehrwert du daraus ziehst bzw. wie du diese Information dann nutzen würdest. Kurzum was ist dein Use Case ?

LG,
Heiko

kask · 15 Juli 2023, 11:42:13

Ich vermute der Mehrwert liegt darin das man sieht wie lange das Device schon aktiv war. Bzw. es kann genutz werden um festzustellen wie lange das Gerät aktiv war am Tag.
Das kann man allerdings auch ausserhalb des Modules selber lösen.
Da die automatische Schaltung nicht aktiv ist, soll es vermutlich für soetwas gebraucht oder misssbraucht werden.
Mutmasse ich jetzt einfach mal so. Denn einen Mehrwert was das Modul betrifft würde nur existieren (mMn.) wenn man das Schalten zulassen würde/könnte/dürfte.
Mit Schalterlaubnis könnte man das Device zuschalten bei Bedarf und den Rest würde die Automatik irgendwann nachschieben. Aber dann auch nicht mehr weil zuvor schon was passiert ist.
Könnte mir die Funktion z.b. bei einer Poolpumpe vorstellen.
PV-Überschuß bis der Arzt kommt zu einer Zeit in der sonst geplanscht wird. Keiner im Pool also anwerfen. Da so ein Pool ja seine Pumpen(Filter)laufzeit braucht.
Und die Restumwälz.- Filterzeit kommt aus der Vorhersage. Somit bekomme ich meine Mindestlaufzeit schön abgefrühstückt.