76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

@all,

ich habe in der Zwischenzeit die (lineare) Skalierung der Balkengrafik überarbeitet und die Möglichkeit geschaffen, dass der User für jede vorhandene Ebene der Balkengrafik getrennt die Skalierung zwischen linear (default) und logarithmisch umschalten kann.
Ihr sehr die Darstellungsunterschiede in den Screenshots.

Die Umschaltung erfolgt über das Attr graphicControl->scaleMode:

scaleMode    
        Für jede Ebene der Balkengrafik kann der Skalierungsmodus linear oder logarithmisch festgelegt werden.
        Die logarithmische Einstellung hebt kleine Werte stärker an und komprimiert größere Werte in der Darstellung.
        Die Angabe für eine Ebene besteht aus der Ebenen-Nummer (1..X), einem ':' gefolgt von dem Modus 'lin' oder 'log'.
        Die Strings für jede Ebene werden durch Komma getrennt (siehe Beispiel).
        <Ebene>:lin - lineare Skalierung (default)
        <Ebene>:log - logarithmische Skalierung


Beispiel:  scaleMode=1:log,2:lin

Die V 1.52.14 liegt in meinem contrib.

LG,
Heiko

[bismosa]

Hallo!

Vielen Dank für die ausführliche Antwort!
Das hat mich nun zumindest ein Stück weiter gebracht.

Code Auswählen Erweitern

interruptable=Firmata_Aussensteckdose:SF_Int:1

Das bedeutet, sobald der Regex "1" im Device:Reading Firmata_Aussensteckdose:SF_Int matcht, schaltet die Pumpe ab, egal ob noch Überschuß da ist oder nicht.

So steht es auch in der Commandref:

Verbraucher wird temporär unterbrochen, wenn der Wert des angegebenen Device:Readings auf den Regex matched

Code Auswählen Erweitern

interruptable=1

Verbraucher wird temporär ausgeschaltet falls der PV Überschuß die benötigte Energie unterschreitet

Das sind demnach ja ganz unterschiedliche Funktionen.
Ich habe das nun gesetzt und die Pumpe lief sofort (wie eigentlich erwartet) los.

Dann habe ich das nur aus dem Beispiel im Wiki noch nicht verstanden:

Code Auswählen Erweitern

if ($mrest >= ($mneed - $msum)) {
          readingsSingleUpdate ($dhash, 'SF_Int', 1, 0);                        # Interrupt-Freigabe
      }
      else {
          readingsSingleUpdate ($dhash, 'SF_Int', 0, 0);                        # keine Interrupt-Freigabe
      }
Ich hatte gedacht, das dies dafür da ist, "interruptable=0" zu setzen, das die Pumpe nicht mehr ausgehen darf (damit diese lange genug am Tag läuft...auch bei Schlechtwetter). Aber nach der Beschreibung in der Commandref geht das nicht.?

Ich lasse jetzt mal die Werte $mrest $mneed $msum protokollieren. Vielleicht werde ich dann noch etwas schlauer.

Gruß
Bismosa

[DS_Starter]

Dann habe ich das nur aus dem Beispiel im Wiki noch nicht verstanden:

Ja, das muß ich mir anschauen. Ich denke das passt nicht (mehr) und dort gehört ein anderer Befehl hinein.
Sage auf jeden Fall nochmal Bescheid wenn ich das reviewed habe.

[Wzut]

Im battery_70 steckt ein Hochkomma zuviel, Wuppi wird es bestimmt noch tauschen

[DS_Starter]

Ich habe die V im contrib upgedated -> die logarithmische Darstellung ist nachgebessert.

[DS_Starter]

Ich habe das Fallbeispiel Pumpensteuerung im Wiki überarbeitet.

Das sollte nun passen.

LG,
Heiko

[DS_Starter]

@Parallix,

ich möchte nochmal nachfragen bzgl. dieser Anforderung:

Eins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.

Wenn ich dich richtig verstehe soll das System ermitteln, wieviele (Rest-)Stunden am aktuellen Tag einen PV-Überschuß (in Wh) prognostizieren, der höher ist als eine noch irgendwie anzugebende Minimalleistung, d.h. Minimal-Ladeenergie (Wh) wenn wir die Minimalleistung auf eine Stunde beziehen.

Habe ich das so richtig wiedergegeben?

LG,
Heiko

 

[Max_Meyer]

ch möchte nochmal nachfragen bzgl. dieser Anforderung:

Eins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.

Wenn ich dich richtig verstehe soll das System ermitteln, wieviele (Rest-)Stunden am aktuellen Tag einen PV-Überschuß (in Wh) prognostizieren, der höher ist als eine noch irgendwie anzugebende Minimalleistung, d.h. Minimal-Ladeenergie (Wh) wenn wir die Minimalleistung auf eine Stunde beziehen.

Habe ich das so richtig wiedergegeben?

Hallo allerseits,
ich frage mich ob eine einseitige Fokussierung ausschließlich auf netzdienliche Batterieladung im letzten drittel des Tages so sinnvoll ist.
Da ist zum einen die 'Energie-Konkurrenz' zwischen Batterie(n) und 'Großverbrauchern z.B. WP, Heizstab, E-Car, WA, GSP, Poolheizung etc. besonders in der Übergangszeit(Herbst, Winter, Frühjahr) wo gerade genug Energie vom Dach zur Verfügung steht um den Bedarf weitestgehend zu decken. Und die Batterie ist ein 'gutmütiger' Consumer - d.h. die nimmt die PV-Energie ab wenigen Watt Überschuss und gewährleistet so eine max. Ausbeute während z.B. meine WP mind. 650 W braucht um anzulaufen und bei PV-Überschuss den Puffer wärmer zu machen als er lt. Heizkurve sein müsst - ein Heizstab braucht 1500W, E-Car alt ab 1500W neu (ISO 15118) 600W etc.
Auf der anderen Seite sollte jede Batterie (Theorie (Studie) durfte ich gerade lernen) nur möglichst kurz im Ladezustand 100% verharren. Ansonsten altert eine (LFP-) Batterie überdurchschnittlich schnell. Zumindest ist dies neben Umgebungstemperatur und (Ent-) Ladestrom ein sehr entscheidender Einfluss. Mit Ladezuständen um die 80% passiert das nicht (siehe Handy). BMS hält auch eine definierte Ladung vor um Überladung und Tiefenentladung zu vermeiden.
Die Frage aus meiner Sicht ist, auf was optimiert werden soll - max. Energieausbeute vs. max. Batteriegesundheit.
Vielleicht ist es sinnvoll die Bat (erstmal nur im Sommer) bis auf 80% laden? Verbraucher priorisieren? so dass sie hintereinander einschalten solange PV Überschuss vorhanden ist und dann auch wieder ausschalten wenn weg? Aber wie kann man das planen? Es ist sicher möglich für Verbraucher ein Profil zu ermitteln - beim Heizstab z.B. der braucht (bei mir 200l WW-Boiler) ca. 0,5 kWh pro 1K Temperaturerhöhung - die Krux ist wenn der Heizstab ausschaltet weil z.B. 75°C erreicht sind (lt. Sensor Heizstab) ist das im oberen Bereich des Boilers noch nicht der Fall - also geht das Ding mit bis zu 4500 W 'unkontrolliert' wieder an sobald die Konvektion gewirkt hat  - schreib das nur um die kleinen Klippen zu skizzieren die da so umhergeistern - denn heute stört das nicht, jede Lücke wird von der Batterie genutzt - die saugt die Energie weg wenn verfügbar.
Ich möchte diesen Post bitte nur als Diskussionsanstoß verstanden wissen - bin mir nicht sicher was da richtig wäre - gerne antworten
Gruß Gerd

[DS_Starter]

Hallo Gerd,

meine Anlage fahre ich zur Zeit so, dass sie nur ca 2/3 der möglichen Einspeiseleistung einspeisen soll (plantControl->feedinPowerLimit).
Dadurch wird die Batterie in den Zeiten ohne "Ladefreigabe" bzw. "nur Laden wenn Einspeiselimit überschritten" bereits mit wenig Leistung (der evtl. Überschußleistung) geladen und der SoC steigt so langsam an. Mit der Ladefreigabe, die sich nach dem SoC in Beziehung zum erwarteten Restüberschuß des Tages sowie Verbrauchsprognose richtet, wird die Batterie dann mit voller Überschußleistung voll geladen.

So werden die 100% zur Zeit erst recht spät am Tag erreicht und gehen nach kurzer Zeit wieder in den Entladungsmodus.
Im Herbst/Winter wird die "Ladefreigabe" früher oder ohnehin für den ganzen Tag erteilt. Dadurch ist die Batterie eher voll (wenn möglich), aber die Energieausbeute und Einspeisung ohnhin gering(er).

Die Verbraucher kann man priorisiert im Modul planen lassen, indem man über die Schlüssel notbefore in Verbindung mit mintime und den weiteren Möglichkeiten eine Abfolge aufbaut. Man kann auch eine automatische Chain aufbauen, indem über eine kleine Logik in ctrlUserExitFn der Status  planningstate='finished' eines Consumers ausgewertet wird um danach den nächsten zu starten. Es gibt viele Möglichkeiten.

LG,
Heiko