Leistungsprognose für Wechselrichter

tatu123 · 15 Juli 2023, 15:10:59

Habe gerade auch mit der neuen Funktion spignorecond rumgespielt.

Benutze die jetzt für meine Nulleinspeisung. Dazu habe ich jetzt die Überprüfung des SoC und des momentanen Verbrauchs in der
Funktion ctrlUserExitFn gelegt.

Funktioniert so weit erst mal super.

Damit ist meine Nulleinspeisung aus meiner Sicht abgedecke. Super Job. Vielen Dank

Jetzt bräuchte ich nur noch, wie schon Dracolein in #2727 schreib, ein Mindesteinschaltzeit. Auch mein Luftentfeuchter hat es nicht so gern im z.B. Minutentakt ein- und ausgeschaltet zu werden.

kask · 15 Juli 2023, 15:26:57

Ich stecke da nicht so drinne bei den consumern aber anstatt on=on würde vieleicht ein on="on-for-timer xsec" gehen? und off geht ins nichts?
Je nach Device könnte das doch funktionieren.

So mache ich das woanders um im Falle eines ausfalls von fhem die Geräte sicheheitshalber abschalten zu lassen. Dazu muß das on-for-timer aber immer erneut getriggert werden damit das Gerät nicht im intervall immer and und aus geht.

Oder über ein Dummy.
Den dummy schaltest du über den forecast und ein notify schaltet dein verbraucher anhand des dummys und der Laufzeit. Das wäre nicht im Modul aber so lösbar.

Btw.: @DS_Starter: Dann wäre auch die gesamt Laufzeit interressant zu haben!

DS_Starter · 15 Juli 2023, 17:12:45

@kask

ZitatIch 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.
....
Btw.: @DS_Starter: Dann wäre auch die gesamt Laufzeit interressant zu haben!

Diese Daten werden schon erfasst, unabhängig davon ob das Modul den Consumer schaltet oder extern.
Die Werte stehen in der pvHistory. Für den aktuellen Tag im Datensatz mit dem aktuellen Tagesdatum in der Stunde 99. Man kann sich auch die einzelnen Stunden des Tages anschauen/herausziehen.

Die Laufzeit (hours) und die Anzahl der Schaltzyklen (cycles) für jeden Consumer werden erfasst.
Hier z.B. für den Consumer 02:

cyclescsm02: 1, hourscsme02: 5

Wenn der Bedarf besteht, könnte ich sicherlich über das ctrlStatisticReadings aus diesen Werten zuschaltbare Readings zur Verfügung stellen.

@tatu123,

ZitatJetzt bräuchte ich nur noch, wie schon Dracolein in #2727 schreib, ein Mindesteinschaltzeit. Auch mein Luftentfeuchter hat es nicht so gern im z.B. Minutentakt ein- und ausgeschaltet zu werden.

Ich kann gerne mal schauen ob/wie ich einen Pendant zu locktime implementieren kann.
Scheint ja doch von größerem Interesse zu sein.

kask · 15 Juli 2023, 17:51:40

Ich habe jetzt nicht ins Modul geschaut. Aber ich vermute die Laufzeit aus der Statistik beruht auf Schaltungen des Moduls selbst.
Weil sonst würde ja auch gezählt werden wenn das Modul sagt "Gerät ist an und ich war es nicht".
Somit wäre ja die Anfrage von @Dieter erfüllt.
Und mit einer externen Locktime würde es nur gehen wenn du auf den consumer zustand reagierst und nicht nur steuerst so zusagen closed-loop.
Ich denke das externe (Zeit zählen auch wenn das Modul nicht geschaltet hat) macht schon Sinn, je mehr ich darüber nachdenke. Nicht jedes Gerät mag es wenn man "Ihm den Stuhl unter dem Arsch wegzieht".
z.B. Luftentfeuchter, Nachlauf damit der Kondensator trocken ist zur Schimmelbildung vorbeugung. Und das weiß fhem/modul nicht wann das genug ist. Eventuell ist das Gerät so schlau und misst da unter Umständen was.

DS_Starter · 15 Juli 2023, 18:01:04

ZitatIch habe jetzt nicht ins Modul geschaut. Aber ich vermute die Laufzeit aus der Statistik beruht auf Schaltungen des Moduls selbst.
Weil sonst würde ja auch gezählt werden wenn das Modul sagt "Gerät ist an und ich war es nicht".
Somit wäre ja die Anfrage von @Dieter erfüllt.

Doch, das Modul erfasst die Werte unabhängig der Automatik.
Was eben nicht geht, worauf aber Dieter immer hinweist, ist die Darstellung der Restlaufzeit im Fall von no-Automatik.
Damit verhält es sich eben wie ich weiter oben schrieb.

Deswegen meine Nachfrage an Dieter was eigentlich der Use Case ist bzgl. seiner Anforderung.
Vllt. ist es anders zu lösen oder die Lösung ist schon vorbereitet ... mal schauen.

Dracolein · 16 Juli 2023, 12:35:39

Gibts eine Möglichkeit nachvollziehen zu können, weshalb ein Consumer (meine Wallbox) abgeschaltet wird? Lässt sich da etwas mitloggen oder so?

Ich beobachte heute vermehrt Ladestops der Wallbox, die ich nicht nachvollziehen kann. Ich habe mit dem Parameter "power=" (testweise Leistungsangabe erhöht / verringert) und "pcurr=" (testweise gelöscht) schon etwas herumgespielt, konnte aber keine signifikante Änderungen beobachten.

DS_Starter · 16 Juli 2023, 13:36:33

ZitatGibts eine Möglichkeit nachvollziehen zu können, weshalb ein Consumer (meine Wallbox) abgeschaltet wird? Lässt sich da etwas mitloggen oder so?

Ja. Per default werden alle Consumerschaltungen mit verbose 2 und dem Grund im Log protokolliert:

Code Auswählen

2023.07.16 12:40:36.045 2: SolCast - Consumer 'SolarForecast Consumer Dummy' switched on
....
....
2023.07.16 12:55:46.080 2: SolCast - switching Consumer 'SolarForecast Consumer Dummy' to 'off', caution: planned switch-off time reached/exceeded (Automatic = 1)
2023.07.16 12:55:46.082 2: SolCast - Consumer 'SolarForecast Consumer Dummy' switched off

Genauere Informationen bekommt man mit ctrlDebug=consumerSwitching.

Code Auswählen

2023.07.16 12:40:35.883 1: SolCast DEBUG> consumer "01" - PV surplus ignore condition ist set - device: SolCast, reading: Current_PV, condition: .*0.*
2023.07.16 12:40:35.885 1: SolCast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: 533 W, nompower: 600, surplus: 4160 W, isInLocktime: 0, planning state: planned: 2023-07-16 12:37:05 - 2023-07-16 12:52:05, start timestamp: 1689503825
2023.07.16 12:40:35.885 1: SolCast DEBUG> consumer "01" - current Context is switching "on" => swoncond: 1, on-command: on 
2023.07.16 12:40:35.887 1: SolCast DEBUG> SolCast DEBUG> Consumer switch enabled by battery: 1
2023.07.16 12:40:36.042 2: SolCast - switching Consumer 'SolarForecast Consumer Dummy' to 'on' (Automatic = 1)
2023.07.16 12:40:36.043 1: SolCast DEBUG> consumer "01" - current Context is switching "off" => swoffcond: 0, off-command: off
2023.07.16 12:40:36.045 2: SolCast - Consumer 'SolarForecast Consumer Dummy' switched on
...
...
2023.07.16 12:55:46.002 1: SolCast DEBUG> consumer "01" - PV surplus ignore condition ist set - device: SolCast, reading: Current_PV, condition: .*0.*
2023.07.16 12:55:46.003 1: SolCast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: 513 W, nompower: 600, surplus: 4260 W, isInLocktime: 0, planning state: switched on: 2023-07-16 12:40:35 - 2023-07-16 12:55:35, start timestamp: 1689504035
2023.07.16 12:55:46.004 1: SolCast DEBUG> consumer "01" - current Context is switching "on" => swoncond: 1, on-command: on 
2023.07.16 12:55:46.004 1: SolCast DEBUG> consumer "01" - current Context is switching "off" => swoffcond: 0, off-command: off
2023.07.16 12:55:46.080 2: SolCast - switching Consumer 'SolarForecast Consumer Dummy' to 'off', caution: planned switch-off time reached/exceeded (Automatic = 1)
2023.07.16 12:55:46.082 2: SolCast - Consumer 'SolarForecast Consumer Dummy' switched off

dk3572 · 16 Juli 2023, 17:37:41

Zitat von: DS_Starter am 15 Juli 2023, 08:56:05Moin,

@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

Hallo Heiko,

sorry für die späte Antwort, war auch mal ne Woche im Urlaub.

Der Mehrwert wäre für mich tatsächlich nur, dass ich die Restlaufzeit sehe und auch abfragen könnte.
Zur Zeit löse ich das mit einem HourCounter.
Schöner wäre es allerdings hier im Modul. Käme auch nicht auf die Minute an.
Ab Beginn des Verbrauchs die hinterlegte Zeit runterzählen reicht vollkommen.

Wenn das alles zu aufwändig ist, möchte ich aber auch keine Umstände bereiten.

Danke und schönen Sonntag noch.
VG Dieter

DS_Starter · 16 Juli 2023, 18:40:52

Hallo Dieter,

ich würde die gerne weiterhelfen.
Deswegen hake ich nochmal nach.

ZitatDer Mehrwert wäre für mich tatsächlich nur, dass ich die Restlaufzeit sehe und auch abfragen könnte.
Zur Zeit löse ich das mit einem HourCounter.

Angenommen du siehst die Zeit, bzw. hast jetzt die Zeit über den Hourcounter.

Was machst du dann damit wenn sie auf 0 gezählt hat?
Schaltest du dann etwas manuell oder bekommst ein Signal?

LG

DS_Starter · 16 Juli 2023, 19:19:56

@all,

in meinem contrib liegt (mal wieder) eine neue Version 0.80.12.

Was ist neu, was hat sich geändert?

- der Consumerschlüssel locktime wurde erweitert und kann jetzt Sperrzeiten sowohl nach Ausschalten als auch
nach dem Einschalten verwalten. Dazu ist das Format des Keys rückwärtskompatibel erweitert in locktime=<offlt>:[<onlt>].
Aus der ComRef:

locktime    Sperrzeiten in Sekunden für die Schaltung des Verbrauchers (optional).
     offlt - Sperrzeit in Sekunden nachdem der Verbraucher ausgeschaltet oder unterbrochen wurde
     onlt - Sperrzeit in Sekunden nachdem der Verbraucher eingeschaltet oder fortgesetzt wurde
     Der Verbraucher wird erst wieder geschaltet wenn die entsprechende Sperrzeit abgelaufen ist.

- Weil die gesammelten Daten immer umfangreicher geworden sind, kann man nun in den gettern pvHistory und
valConsumerMaster direkt auf einen Tag bzw. einen spezifischen Verbraucher verzweigen. Das hilft sehr
bei der Analyse.

- das Debug Log für consumerSwitching wurde erweitert und übersichtlicher gestaltet weil u.U. doch sehr
viele Daten im Log erscheinen. Sie sind jetzt besser voneinander abgegrenzt, z.B.:

Code Auswählen

2023.07.16 15:21:20.073 1: SolCast DEBUG> ############### consumer "01" ############### 
2023.07.16 15:21:20.074 1: SolCast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: 547 W, nompower: 600, surplus: 3414 W, planstate: switched on: 2023-07-16 15:05:02 - 2023-07-16 15:20:02, starttime: 16.07.2023 15:05:02
2023.07.16 15:21:20.075 1: SolCast DEBUG> consumer "01" - isInLocktime: 1, remainLockTime: 223
2023.07.16 15:21:20.076 1: SolCast DEBUG> consumer "01" - current Context is switching "on" => swoncond: 1, on-command: on 
2023.07.16 15:21:20.077 1: SolCast DEBUG> consumer "01" - current Context is switching "off" => swoffcond: 0, off-command: off
2023.07.16 15:21:20.078 1: SolCast DEBUG> consumer "01" - switching off postponed by >isInLocktime<
2023.07.16 15:21:20.078 1: SolCast DEBUG> consumer "01" - current planning state: started 

2023.07.16 15:21:20.080 1: SolCast DEBUG> ############### consumer "02" ############### 
2023.07.16 15:21:20.081 1: SolCast DEBUG> consumer "02" - general switching parameters => auto mode: 1, current Consumption: 547 W, nompower: 450, surplus: 3414 W, planstate: planned: 2023-07-16 07:00:00 - 2023-07-16 07:15:00, starttime: 16.07.2023 07:00:00
2023.07.16 15:21:20.081 1: SolCast DEBUG> consumer "02" - isInLocktime: 0
2023.07.16 15:21:20.082 1: SolCast DEBUG> consumer "02" - current Context is switching "on" => swoncond: 1, on-command: on 
2023.07.16 15:21:20.082 1: SolCast DEBUG> consumer "02" - current Context is switching "off" => swoffcond: 0, off-command: off
2023.07.16 15:21:20.083 1: SolCast DEBUG> consumer "02" - current planning state: planned 

2023.07.16 15:21:20.084 1: SolCast DEBUG> ############### consumer "03" ############### 
2023.07.16 15:21:20.084 1: SolCast DEBUG> consumer "03" - general switching parameters => auto mode: 1, current Consumption: 547 W, nompower: 200, surplus: 3414 W, planstate: planned: 2023-07-16 07:00:00 - 2023-07-16 07:15:00, starttime: 16.07.2023 07:00:00
2023.07.16 15:21:20.085 1: SolCast DEBUG> consumer "03" - isInLocktime: 0
2023.07.16 15:21:20.085 1: SolCast DEBUG> consumer "03" - current Context is switching "on" => swoncond: 1, on-command: on 
2023.07.16 15:21:20.086 1: SolCast DEBUG> consumer "03" - current Context is switching "off" => swoffcond: 0, off-command: off
2023.07.16 15:21:20.086 1: SolCast DEBUG> consumer "03" - current planning state: planned

- es sind Vorbereitungen zur Verwaltung von Verbrauchern eingebaut, die über getrennte Devices für
Energiemessung und Schaltung anzusprechen sind. Es ist noch etwas Arbeit nötig, aber wesentliche Schritte
in diese Richtung sind schon enthalten.

- etliche kleine Fixes und Verbesserungen die eher im Hintergrund werkeln

LG und allen einen schönen Sonntag Abend

PhyTHZ · 16 Juli 2023, 20:33:37

Hallo,

ich bin dabei die im Wiki beschriebene dynamische Ladestromsteuerung für meinen Wechselrichter anzupassen. Auch auf die Gefahr hin mich zu blamieren: Kann mir bitte jemand die folgende Bedingung erklären?

Code Auswählen

if ($cpv && $solh && $ahrem && $ahrem < $fcdiff) {...} # Ladeanforderung und Überschuss übersteigt Lademenge
Und warum wird

Code Auswählen

my $fcdiff = ($pvfc - $cofc) * $spcorr; # Korrektur der noch aktuell prognostizierten Überschussenergie , also (RestOfDayPVforecast – RestOfDayConsumtion) * Korrekturfaktor gerechnet? Wäre nicht eigentlich (RestOfDayPVforecast – RestOfDayConsumtionTillSunset) * Korrekturfaktor sinnvoller? (wobei RestOfDayConsumtionTillSunset ist nur ausgedacht ist).

LG Gunnar

DS_Starter · 16 Juli 2023, 20:56:25

ZitatKann mir bitte jemand die folgende Bedingung erklären?

Code Auswählen
if ($cpv && $solh && $ahrem && $ahrem < $fcdiff) {...} # Ladeanforderung und Überschuss übersteigt Lademenge

Die Bedingung legt lediglich fest das folgendes erfüllt sein muß um die in der Klammer vorhandenen Kalkulationen / Entscheidungen durchzuführen.
D.h. es muß PV erzeugt werden ($cpv), es muß noch eine Zeit bis Sonnenuntergang vorhanden sein ($solh), die Battrie muß noch Ladebedarf haben ($ahrem) und der Ladebedarf muß kleiner sein als die aktuell prognostizierte Überschussenergie bis Ende des Tages bzw. bis Sonnenuntergang.

Nur dann findet eine Herabstufung der Ladeleistung statt, ansonsten wird der maximale Ladestrom eingestellt ($maxcspc).

Zitat, also (RestOfDayPVforecast – RestOfDayConsumtion) * Korrekturfaktor gerechnet? Wäre nicht eigentlich (RestOfDayPVforecast – RestOfDayConsumtionTillSunset) * Korrekturfaktor sinnvoller?

Ja wäre es. Aber diesen Wert habe ich nicht zur Verfügung. Deshalb diese Annäherung.

EDIT: das war übrigens ein guter Hinweis.

Vllt. gelingt es mir doch im Modul ein zuschaltbares Reading bereitzustellen welches die Verbrauchprognose bis Sonnenuntergang bereitstellt.

Ganz nebenbei läuft das bei mir nun schon einige Zeit sehr gut. Habe das Verfahren inzwischen noch erweitert um einen SmartLoader PV -> Battrie (nur Gleichstrom) zu berücksichtigen der vorrangig behandelt werden soll weil er ohnehin wenn die BAT voll ist vom System abgeregelt wird (Nulleinspeisung).
Das war jetzt sozusagen der Gegencheck aus der Realität.

PhyTHZ · 16 Juli 2023, 21:34:45

Hallo,

inhaltlich ist mir klar was passieren soll, nur nicht wie Perl die Bedingung verarbeitet - also mehr ein Perl-Verständnisproblem:

Code Auswählen

if ($test1 && $test2 && 500 < 501) {print "wahr"}; ~~gibt immer ,,wahr", egal welchen Wert $test1 oder $test2 haben. Genauso ist diese Bedingung nie erfüllt:~~

Code Auswählen

if ($test1 && $test2 && 501 < 501) {print "wahr"};
EDIT: o.k. nun endlich verstanden: "Egal welcher Wert" simmt nicht (wenn $test1,2= 0)

ZitatJa wäre es. Aber diesen Wert habe ich nicht zur Verfügung. Deshalb diese Annäherung.

Im Winter ist der Unterschied natürlich viel größer, aber da reicht die PV Energie ohnehin nicht um den Speicher voll zu bekommen. Wie lief es in der Übergangszeit?

ZitatEDIT: das war übrigens ein guter Hinweis. Vllt. gelingt es mir doch im Modul ein zuschaltbares Reading bereitzustellen welches die Verbrauchprognose bis Sonnenuntergang bereitstellt.

Das fände ich gut - ich meine die Frage danach habe ich hier in anderem Zusammenhang schon gelesen.

Ich möchte noch etwas ,,Netzdienlichkeit" einbauen, so dass zur Mittagszeit der Ladestrom am höchsten ist.

LG

DS_Starter · 16 Juli 2023, 22:09:51

ZitatIm Winter ist der Unterschied natürlich viel größer, aber da reicht die PV Energie ohnehin nicht um den Speicher voll zu bekommen. Wie lief es in der Übergangszeit?

Die hatte ich noch nicht. Kommst erst noch

Aber nach der Logik wird in diesen Fällen der höchste Ladestrom eingestellt. D.h. es geht rein was die Sonne hergibt, keine künstliche Reduzierung.
Der Sinn des Ganzen ist den Akku über den Tag so schonend wie möglich zu laden, aber am Ende des Tages gefüllt zu haben sofern genügend PV vorliegt natürlich.
Am Anfang hatte ich am Vormittag vollen Power, Mittag war die Bat voll. Den Vorgang wollte ich über den Tag ausdehnen/gleichmäßig verteilen..

Edit: Und ich wollte auch die Möglichkeiten der Nutzung von ctrlUserExitFn an einem Beipiel zeigen.

dk3572 · 17 Juli 2023, 09:04:29

Zitat von: DS_Starter am 16 Juli 2023, 18:40:52Hallo Dieter,

ich würde die gerne weiterhelfen.
Deswegen hake ich nochmal nach.
ZitatDer Mehrwert wäre für mich tatsächlich nur, dass ich die Restlaufzeit sehe und auch abfragen könnte.
Zur Zeit löse ich das mit einem HourCounter.
Angenommen du siehst die Zeit, bzw. hast jetzt die Zeit über den Hourcounter.

Was machst du dann damit wenn sie auf 0 gezählt hat?
Schaltest du dann etwas manuell oder bekommst ein Signal?

LG

Hallo Heiko,

in Erster Linie, dass ich eine Info erhalte wann die Maschine fertig ist, bzw. wie lange sie noch läuft um die nächste zu starten. Aber alles manuell. Die Maschinen geben eine Vorprogrammierung leider nicht her.

VG Dieter