Leistungsprognose für Wechselrichter

[ambiman]

Ggf. schalte bei die mal ctrlDebug -> consumerSwitching ein um genauer zu sehen was passiert.

Habe ich soeben getan und werde morgen berichten

Es ist schwierig zu beurteilen ob ein Verbraucher länger als geplant eingeschaltet bleiben soll. Nicht unbedingt ist es der Wunsch bzw. sinnvoll, z.B. bei einer Waschmaschine. Es müsste also klar definierte Kriterien geben anhand deren entschieden werden kann ob ein Verbraucher über mintime hinaus eingeschaltet bleiben soll.
Ich kann die Intension hinter dieser Idee verstehen, jedoch fehlt mir aktuell ein solcher Kriterienkatalog.

Was ich aber erkannt habe ist die Problematik der initialen Einplanung in der ersten Stunde des Tages. Meistens ändern sich die Vorhersageverhältnisse bis zum Sonnenaufgang (und danach). Deswegen denke ich aktuell darüber nach den Einplanungslauf auf z.B. eine Stunde vor oder nach Sonnenaufgang zu verlegen bzw. nach dem ersten SolCast API Abruf nach Sonnenaufgang (bei SolCast Nutzung).

Ja, in meinem Fall ist es ein Elektrokonvektor der den Solarüberschuss in Wärme umwandelt, von daher kann er ruhig so lange heizen wie Überschuss da ist .
Was würde prinzipiell dagegen sprechen, die Consumption-Planung mehrfach (ggf. konfigurierbar) unter Berücksichtung der entsprechenden Parameter notbefore/notafter etc. über den Tag verteilt, durchzuführen ?

VG,

ambiman

[DS_Starter]

Was würde prinzipiell dagegen sprechen, die Consumption-Planung mehrfach (ggf. konfigurierbar) unter Berücksichtung der entsprechenden Parameter notbefore/notafter etc. über den Tag verteilt, durchzuführen ?

Naja, der gleiche Grund wie schon genannt ... es gibt zur Zeit keine Kriterien / Bedingungen die dem Modul sagen "die Einplanung soll automatisch nach Ende eines Zyklus wiederholt werden".
Deswegen kann der User es in eigener Regie einfach wieder einplanen lassen mit  "set ... reset consumerPlanning <xx>".

Wenn jemand eine Idee für eine allgemein gültige Bedingungen für eine automatische Replanung hat schaue ich mir die gerne an. 

[DS_Starter]

Jetzt wo ich darüber nachdenke könnte vllt. ein optionaler Schlüssel "replan" im Consumerattribut eine solche Aufgabe übernehmen.

[ambiman]

Jetzt wo ich darüber nachdenke könnte vllt. ein optionaler Schlüssel "replan" im Consumerattribut eine solche Aufgabe übernehmen.

Klingt gut

[DS_Starter]

Ich werde die Idee mal im Hinterkopf behalten.

[DS_Starter]

Also morgen solltest du speziell zum Ende der geplanten Einschaltzeit ein Auge auf dein Logfile haben. Wenn der Consumer nicht wie geplant ausschaltet sollte etwas zu finden sein. Das Debug Attribut zu setzen macht eigentlich auch erst kurz vor der Zeit Sinn.

[der-Lolo]

Ich finde bei den Verbrauchern würde ein aufteilen in geplante und "Regelenergie" sinn machen -
Heizungen im Winter, und Poolpumpen im Sommer kurzfristig abschaltbar = Regelenergie

wenn vielleicht doch ne wolke vorbeikommt - oder die 70% Regel zuschlagen würde und Bezug entstehen würde, Regelenergie Verbrauche abschalten.

Waschmaschinen und Geschirrspüler, Heizungen die im Programmablauf nicht mehr ausgeschaltet werden dürfen wäre die andere Kategorie.

[DS_Starter]

Dafür gibt es doch den optionalen Schlüssel "interruptable" den man setzen kann wenn ein Verbraucher in deinen beschriebenen Fällen unterbrochen werden darf. Erfüllt der deinen Use Case nicht ?
Möglicherweise habe ich es auch nicht richtig verstanden.

[der-Lolo]

Dachte mir schon das Du sowas im Code bereitstellst - ist ja naheliegend.

interruptable wäre ja dann das richtige für ambiman - interessant wäre vielleicht noch wenn interruptable noch eine Mindest/Tageslaufzeit hätte.

Kann zwar unterbrochen werden - am Ende des Tages soll die Heizung aber bitte 5 Std. Laufzeit haben, oder die Poolpumpe...

Heiko ich bastel ja immernoch am behavior - und werde nicht vor Januar ans Netz gehen mit meiner Anlage, trotzdem lese ich hier mit um vorbereitet zu sein.

[Dracolein]

Ggf. wären ein paar mehr Beispiele für Consumer-Konfigurationen in der Hilfe sinnvoll?
(dies könnten wir Nutzer dem DS_Starter hier zur Verfügung stellen, also richtige funktionale Praxisbeispiele)

[ambiman]

Habe ich soeben getan und werde morgen berichten

Ich hatte aus Interesse gestern auch das Debug für das Consumer Planning aktiviert.
Und heute Nacht wurde Folgendes geplant:

Code Auswählen Erweitern


2022.11.14 00:00:48.020 1: PV_Forecast DEBUG> consumer "01" - Consider consumption forecast in consumer planning: no
2022.11.14 00:00:48.025 1: PV_Forecast DEBUG> consumer "01" - epiece1: 1250.00
2022.11.14 00:00:48.026 1: PV_Forecast DEBUG> consumer "01" - mode: can, relevant hash: mtimes
2022.11.14 00:00:48.026 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 167, starttime: 2022-11-14 08:00:00, nexthour: 8, today: 1
2022.11.14 00:00:48.026 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 459, starttime: 2022-11-14 09:00:00, nexthour: 9, today: 1
2022.11.14 00:00:48.026 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 890, starttime: 2022-11-14 10:00:00, nexthour: 10, today: 1
2022.11.14 00:00:48.026 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 1203, starttime: 2022-11-14 11:00:00, nexthour: 11, today: 1
2022.11.14 00:00:48.026 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 1300, starttime: 2022-11-14 12:00:00, nexthour: 12, today: 1
2022.11.14 00:00:48.027 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 6, starttime: 2022-11-14 13:00:00, nexthour: 13, today: 1
2022.11.14 00:00:48.027 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 852, starttime: 2022-11-14 14:00:00, nexthour: 14, today: 1
2022.11.14 00:00:48.027 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 352, starttime: 2022-11-14 15:00:00, nexthour: 15, today: 1
2022.11.14 00:00:48.027 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 51, starttime: 2022-11-14 16:00:00, nexthour: 16, today: 1
2022.11.14 00:00:48.027 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 169, starttime: 2022-11-15 08:00:00, nexthour: 32, today: 0
2022.11.14 00:00:48.027 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 601, starttime: 2022-11-15 09:00:00, nexthour: 33, today: 0
2022.11.14 00:00:48.027 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 1160, starttime: 2022-11-15 10:00:00, nexthour: 34, today: 0
2022.11.14 00:00:48.027 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 1446, starttime: 2022-11-15 11:00:00, nexthour: 35, today: 0
2022.11.14 00:00:48.027 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 1425, starttime: 2022-11-15 12:00:00, nexthour: 36, today: 0
2022.11.14 00:00:48.028 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 1189, starttime: 2022-11-15 13:00:00, nexthour: 37, today: 0
2022.11.14 00:00:48.028 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 799, starttime: 2022-11-15 14:00:00, nexthour: 38, today: 0
2022.11.14 00:00:48.028 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 312, starttime: 2022-11-15 15:00:00, nexthour: 39, today: 0
2022.11.14 00:00:48.028 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 46, starttime: 2022-11-15 16:00:00, nexthour: 40, today: 0
2022.11.14 00:00:48.028 1: PV_Forecast DEBUG> consumer "01" - surplus expected: 0, starttime: 2022-11-15 23:00:00, nexthour: 47, today: 0
2022.11.14 00:00:48.034 3: PV_Forecast - Consumer "Shelly_Plug_S_2" planned: 2022-11-14 12:00:00 - 2022-11-14 16:00:00
2022.11.14 00:00:48.038 1: PV_Forecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: 260 W, nompower: 1250, surplus: 0 W, planning state: planned: 2022-11-14 12:00:00 - 2022-11-14 16:00:00, start timestamp: 1668423600


Ich stelle mir nun die Frage weshalb er den Zeitraum 12-16:00 Uhr und nicht 9-12 oder ggf. 14:00 Uhr gewählt hat - der Überschuss scheint hier ja größer zu sein?

Bzgl. des Switchings werde ich nachher ebenfalls berichten.

VG,

ambiman

[DS_Starter]

Moin zusammen,

Ggf. wären ein paar mehr Beispiele für Consumer-Konfigurationen in der Hilfe sinnvoll?

Ja, das wäre etwas für das Wiki. Ich werde mal zeitnah eine Seite vorbereiten die dann auf/ausgebaut werden kann.

Ich stelle mir nun die Frage weshalb er den Zeitraum 12-16:00 Uhr und nicht 9-12 oder ggf. 14:00 Uhr gewählt hat - der Überschuss scheint hier ja größer zu sein?

12:00 ist die erste Stunde des Tages in der der erwartete PV Überschuß den erwarteten Energieverbauch des Verbrauchers epiece1: 1250.00 (Wh) überschreitet

=>  surplus expected: 1300, starttime: 2022-11-14 12:00:00, nexthour: 12, today: 1

Das entspricht der Prognose von heute morgen 00:00, d.h. eigentlich der Erwartung vom letzten API Abruf vor Sonnenuntergang gestern. Das kann sich heute anders darstellen oder verschieben ... ist alles dynamisch.
Deswegen tendiere ich dazu die Einplanung von 00:00 wegzunehmen und neu zu positionieren wie ich es schon in einem Post zuvor beschrieben habe.
Ich denke das würde Pluspunkte bringen.

[DS_Starter]

Mal wieder ein allgemeines Statement.
Ich habe festgestellt dass die SolCast API deutlich schlechter als die DWD Prognose funktioniert sobald man lokale Nebelbedingungen hat.
Wir haben gestern und auch heute totale Nebelfelder die wahrscheinlich durch die Flußniederung lokal vorhanden sind.
Die DWD Prognose reduziert sich entsprechend. Bei der SolCast API wird offensichtlich nur die Bewölkung einbezogen (eigentlich wolkenlos). Dementsprechend hoch ist die ... falsche ... Prognose.

Naja .... nichts ist perfekt.    Alles hat seine Vor- und Nachteile.

[DS_Starter]

Ich habe eine Wiki-Seite angelegt:

  https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung

Viel steht noch nicht drin, ist erstmal nur ein Rahmenwerk zum Aufbau und Ausbau.

[ch.eick]

Ich habe eine Wiki-Seite angelegt:

  https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung

Viel steht noch nicht drin, ist erstmal nur ein Rahmenwerk zum Aufbau und Ausbau.

Sollen wir da einen Hinweis zu meiner Prognose mit DbLog und ohne Modul aufnehmen, damit man den Unterschied erkennen kann?