76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Ich hatte mir schon sowas gedacht nach ein bisschen nachdenken. Deswegen musste ich die Datenhaltung in der pvHistory erweitern. Man sieht ab V 1.51.3 dort nun auch welche SoC-Prognose es für welche Stunde gegeben hat und den real erreichten SoC, z.B.:

      16 => pvfc: 5147, pvrl: 5280, pvrlvd: 1, rad1h: -
            etotali01: 65022541, etotali02: 3623020, etotali03: -, etotali04: -
            pvrl01: 3820, pvrl02: 1460, pvrl03: -, pvrl04: -
            etotalp01: -, etotalp02: -, etotalp03: -
            pprl01: -, pprl02: -, pprl03: -
            confc: 561, con: 787, gcons: 20, conprice: 0.2958
            gfeedin: 1700, feedprice: 0.1269
            DoN: 1, sunaz: 230, sunalt: 43
            batintotal01: 4866469.18724458, batintotal02: -, batintotal03: -
            batouttotal01: 4747058.20336639, batouttotal02: -, batouttotal03: -
            batprogsoc01: 100.0, batprogsoc02: -, batprogsoc03: -
            batsoc01: 97, batsoc02: -, batsoc03: -
            batin01: 2904, batin02: -, batin03: -
            ...

Damit kann ich jetzt arbeiten. In der bishereigen Balkendarstellung ist für die Zukunft der Prognose-SoC und für die Gegenwart und Vergangenheit der reale erreichte SoC abgebildet. Das hat den Vorteil, dass man nur eine Balkenreihe braucht bzw. für 2 Batterien ein Level "verbraucht". Deswegen will ich diese Option auch verfügbar lassen. Zusätzlich wird es die Möglichkeit geben, in einer Balkenreihe die SoC-Prognose für eine Batterie abzubilden und in der zweiten Reihen dann den real erreichten SoC. D.h. man sieht wie bei Consumption oder PV-Prognose / PV real zwischen beiden Balkenreihen die erreichte Übereinstimmung zwischen SoC Prognose und real.

Das sollte dem Wunsch entsprechen denke ich.

LG 

[MadMax]

Hallo Heiko,

Ja ich bekomme von beiden Fahrzeugen die SOC Werte.
Ab März laden wir nur mit PV Überschuss bis etwa Ende Oktober.
Du meinst die Beiden Wallboxen/Autos als Batterie definieren?
Ganz verkehrt ist es ja nicht die als Verbraucher zu sehen aber die müssen ja nicht immer laden.
Aber das in dein SolarForecast einzubauen halte ich für zu viel.

Gruß
Max

[DS_Starter]

Du meinst die Beiden Wallboxen/Autos als Batterie definieren?

Ja, es sind ja Speicher aus der Perspektive. Aber war nur so eine Idee weil in die Speicher geladene Energie automatisch keinen Verbrauch aus Sicht des Moduls darstellt.
Wenn du mit dem exclude klar kommst, passt das ja auch. Ich würde halt consForecastIdentWeekdays=1 und consForecastLastDays=4 stellen. Dann kann das Modul die genauen Verbräche aus der pvHistory verwenden und sieht genau wann das Auto geladen wurde. Nach 4 Wochen geht es in die pvCircular. Dort sind die einzelnen Verbraucher nicht mehr separat verfügbar.

Und noch ein Gedanke zur Auto als Batterie. In den aiRawData kann/werde ich noch die SoC-Werte der registrierten Batterien speichern. Wenn dann eine KI dafür implementiert ist, kann sie die SoC-Werte sehen und in Beziehung mit den aufgetretenen Verbräuchen setzen. Ich denke das würde dann ein recht gutes Ergebnis liefern.

[300P]

Hallo Heiko,
Ja ich bekomme von beiden Fahrzeugen die SOC Werte.

Ab März laden wir nur mit PV Überschuss bis etwa Ende Oktober.
......
Aber das in dein SolarForecast einzubauen halte ich für zu viel.

Gruß
Max

Wie wäre es die Auto-Batterie als ConsumerXY als"heater" zu definieren.
Dann müsste es n.m.M. schon gehen.
evtl. Zusatzdefinition : Voraussetzung "SOC <= XY %" evtl. einbauen falls die Autos nicht von allein sich "abnabeln"

Ein Heater verbraucht doch auch nur - gibt nix zurück 

Gruß
300P

[DS_Starter]

Dann müsste es n.m.M. schon gehen.
evtl. Zusatzdefinition : Voraussetzung "SOC <= XY %" evtl. einbauen falls die Autos nicht von allein sich "abnabeln"

Ein Heater verbraucht doch auch nur - gibt nix zurück 

Ja, sollte passen. Wichtig ist eben, dass der registrierte (vergangene) Verbrauch nicht automatisch in die Prognose hineininterpretiert wird, was bei so großen Verbrauchern natürlich unweigerlich zu Übertreibungen führt.
Ist nicht so einfach mit den E-Autos. 

[300P]

Ich hab da mal eine Idee:

Mein ConsumerXY "Heater" für WW-Erhöhung (Temperaturfühler - max 80 Grad) funktioniert tagsüber mit dem PV-Überschuss schon sehr gut.

Code Auswählen Erweitern

FBDECT_fbahahttp_E8_DF_70_07_42_0B
type=heater
power=2200
mode=can
icon=sani_buffer_electric_heater_side@orange
mintime=SunPath
on=on
off=off
asynchron=0
notbefore=08:00
notafter=19:00
locktime=300:300
pcurr=power:W
etotal=energy:Wh
surpmeth=10
interruptable=1Da habe ich nun eine "Zusatzanforderung für den sehr frühen Morgen......

Wegen anstehender "Duschorgien" am Morgen wird im Sommer sicherlich öfters mal ein WP-Lauf in den frühen Morgenstunden allein fürs WW anstehen.
Den könnte man vermeiden wenn die Batterie evtl. (noch) genügend voll wäre und an dem Tag so oder so viel zu viel PV-Ertrag anstehen würde.

Wie kann bzw. könnte ich das einem ConsumerXY beibringen ?

Starte Prüfung um 02 / 03 / 04 / 05:00 Uhr
Stoppe Prüfung auf jeden Fall immer spätestens um 08:00 Uhr mit "off"
Aber nur dann, wenn Batterie(n) voller als XY % ist/sind
               und der PV-Gesamtertrag im Laufe des heutigen Tages mehr als 100 % Batterieladung "beträgt"
               und dann auch nur für XYZ Minuten
               schalte dann "an" - und nach XYZ Minuten bitte "off"

Dank im Voraus für Anregungen

Gruß
300P

[DS_Starter]

Bezieht sich das:

Starte Prüfung um 02 / 03 / 04 / 05:00 Uhr
Stoppe Prüfung auf jeden Fall immer spätestens um 08:00 Uhr mit "off"

auf die WP? Denn der Heater geht ja wegen notbefore=08:00 ohnehin nicht vor 8:00 los.

Du könntest den Heater ohne deine Definition zu verändern mit der "Spezialanforderung" übersteuern.
Dazu kannst du eine sub im Attr ctrlUserExitFn nutzen.
Mal ins unreine:

Code Auswählen Erweitern

{
  my $dt    = timestringsFromOffset (time, 0);
  my $hour  = $dt->{hour};                                 # aktuelle Stunde in 24h format (00-23)
 
  if (int $hour >= 7 && int $hour < 10) {
    my $soctotal = CurrentVal ($name, 'batsoctotal', 0);     # SoC über alle Bat als Durchschnitt
    my $pvtot = ReadingsNum ($name, 'Today_PVforecast', 0);  # PV Prognose total heute in Wh
    my $caps  = CurrentVal ($name, 'batcapsum', 0);          # Summe installierte Bat Wh
    my $need  = $caps - ($soctotal/100 * $caps);             # benötigte Ladeenergie Bat bis 100% Ladung
 
    if ($soctotal >= XX && int $hour >= 8 && int $hour < 9 && $pvtot >= $need) {  # SoC Vorgabe erfüllt und ab 08:00 bis max. 9:00
        # send "on"-Kommando an Heater Device if(ne "on");
    }
    else {
        # send "off"-Kommando an Heater Device if(ne "off");
    }
  }
}

Es werden teilweise Funktionen des Moduls verwendet (CurrentVal, timestringsFromOffset).
Könnte so funktionieren. Syntax-Fehler inklusive. 

Edit: besser als  ReadingsNum ($name, 'Today_PVforecast', 0) wäre m.M. nach ReadingsNum ($name, 'RestOfDayPVforecast', 0) um die noch verfügbare PV-Prognose des Tages zu erhalten.                   

LG

[300P]

Viele Dank - teste es heute Nacht     

[Max_Meyer]

Wie kann bzw. könnte ich das einem ConsumerXY beibringen ?

Hallo 300P,
wie wäre das den Verbraucher von 'can' auf 'must' umzuschalten? geht ja als reading
Gruß Gerd

[Max_Meyer]

Zusätzlich wird es die Möglichkeit geben, in einer Balkenreihe die SoC-Prognose für eine Batterie abzubilden und in der zweiten Reihen dann den real erreichten SoC. D.h. man sieht wie bei Consumption oder PV-Prognose / PV real zwischen beiden Balkenreihen die erreichte Übereinstimmung zwischen SoC Prognose und real.
 

Hallo Heiko,
ist den Post so zu verstehen so dass es möglich wäre auch den Ist- und Sollwert aller Batterien (siehe screen) im graphicBeam...content auswählbar zu machen? Das würde mir, mit mehr als einer Bat sehr entgegenkommen.
Gruß Gerd

[DS_Starter]

Hallo Gerd,

Sollwert ... weiß ich nicht so recht ob der Begriff richtig ist, sondern es ist die SoC-Prognose die das Modul für eine/jede Batterie ausrechnet.

Man könnte dann z.B. in Level 2 im primären Balken die SoC-Pronose für Bat1 anzeigen lassen und im sekundären Balken den erreichten realen Soc-Wert der Bat1.
In Level 3 könnte man das identisch für die Bat2 einrichten.

Ich denke jetzt sind die Möglichkeiten besser ausgedrückt. Passt das für dich, oder meinst du noch etwas anderes?

LG
 

[300P]

Wie kann bzw. könnte ich das einem ConsumerXY beibringen ?

Hallo 300P,
wie wäre das den Verbraucher von 'can' auf 'must' umzuschalten? geht ja als reading
Gruß Gerd

Ja könnte u.U. auch irgendwie gehen - aber da wird "nix" an Zusatzbedingung beachtet und bei leerer Batterie wird trotzdem Energie (vom EVU) verbraucht.....und ich hätte den Consumer 2 X (1 x Tagsüber / 1 x Nachts)

[Max_Meyer]

t ... weiß ich nicht so recht ob der Begriff richtig ist, sondern es ist die SoC-Prognose die das Modul für eine/jede Batterie ausrechnet.

Man könnte dann z.B. in Level 2 im primären Balken die SoC-Pronose für Bat1 anzeigen lassen und im sekundären Balken den erreichten realen Soc-Wert der Bat1.
In Level 3 könnte man das identisch für die Bat2 einrichten.

Ich denke jetzt sind die Möglichkeiten besser ausgedrückt. Passt das für dich, oder meinst du noch etwas anderes?

Guten Morgen Heiko,
ja du hast recht das war sehr unglücklich formuliert - was ich meine ist die Frage ob es, jenseits der batsocforecast_xx (SOC-Prognose) und batsocconsumtion_xx (real eingetretener Wert), noch einen Parameter mit 'gewichteten' Durchschnittswert über alle Batterien für jeden der beiden o.g. Zustände geben kann (analog der Darstellung in der Grafik (screen von 22:09) - wo ja die Batterie auch nur einmal mit einem Wert zu sehen ist - gleichgültig wie viele Bat-devices definiert sind. Der andere screen (22:18) sollte meine derzeitige Abbildung und das Problem mit der 3 Bat. im Lev.3 dokumentieren. Die beiden anderen Level nutze ich für PV-Forecast vs. PV-real und Verbrauch-Forecast - vs.realer Verbrauch
Gruß Gerd

[300P]

Viele Dank - teste es heute Nacht     

War heute Nacht nichts mit Probelauf.
-> Die Warmwasserzurkulation hatte die WW-Temperatur so reduziert das so kurz nach 3 Uhr einen WP-Start verursacht wurde.
Werde mal die Zirkulation nachts ausschalten - ohne das meine bessere Hälfte was davon erfährt..... 

[Max_Meyer]

könnte u.U. auch irgendwie gehen - aber da wird "nix" an Zusatzbedingung beachtet und bei leerer Batterie wird trotzdem Energie (vom EVU) verbraucht.....und ich hätte den Consumer 2 X (1 x Tagsüber / 1 x Nachts)

Guten Morgen 300P,
das reading welches 'can' und 'must' umschaltet, könnte ja mit den notwendigen Randbedingungen hergeleitet werden.
In meiner Anlage habe ich das Problem mit den 'Duschorgien' hardwareseitig gelöst - habe einen E-DLH parallel geschaltet und nehme den immer dann mit dazu wenn im Puffer die Temperatur unter die 'Duschwohlfühltemperatur' sinkt - so wird das Wasser aus dem Puffer nur minimal erwärmt - hat in den letzten 12 Monaten keine 20 kWh gebraucht - ist aber immer warmes Dusch-Wasser da.
Gruß Gerd