76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[grappa24]

Die Schnittstelle gibst schon - ich betreibe EVCC seit einiger Zeit mit FHEM-Daten über MQTT (siehe screen) - auch Antworten/Entscheidungen aus EVCC lassen sich auf diese Weise einfach nutzen - selber hab ich (bisher) keinen Mehrwert aus der Verbindung erkennen können - und das auch nicht weiter verwendet - aber Darstellung und Grafik empfinde ich ansprechend. Ich hab das BEV als Verbraucher in SF abgebildet

genau so nutze ich das bisher auch 

[Wolle02]

Die Schnittstelle gibst schon - ich betreibe EVCC seit einiger Zeit mit FHEM-Daten über MQTT (siehe screen) - auch Antworten/Entscheidungen aus EVCC lassen sich auf diese Weise einfach nutzen - selber hab ich (bisher) keinen Mehrwert aus der Verbindung erkennen können - und das auch nicht weiter verwendet - aber Darstellung und Grafik empfinde ich ansprechend. Ich hab das BEV als Verbraucher in SF abgebildet

genau so nutze ich das bisher auch 

Da kann ich mich anschließen; nur dass ich nicht EVCC verwende, sondern openWB. Das System ist bei mir aber ebenfalls per MQTT an Fhem angeschlossen. Leider ist openWB durch die "Verschlimmbesserung" der Softwareversion 2.0 nicht so richtig steuerbar, aber vielleicht tut sich da ja noch was.
Jedenfalls könnte ich versuchen mit diesem System ebenfalls eine (MQTT-) Schnittstelle zu unterstützen.

[DS_Starter]

Guten Morgen,

Die Schnittstelle gibst schon - ich betreibe EVCC seit einiger Zeit mit FHEM-Daten über MQTT (siehe screen) - auch Antworten/Entscheidungen aus EVCC lassen sich auf diese Weise einfach nutzen

An MQTT hatte ich schon nicht mehr gedacht. Aber ja, das hatten wir viel weiter vorn schonmal erwähnt. Für EVCC hatte ich die verfügbaren Daten (Wetter war es?) in SF auf 3 Tage erweitert um sie im EVCC nutzen zu können.
Den BEV als Verbraucher zu integrieren ist eine Variante die mir gefällt und die innerhalb SF auch gut abbildbar / integrierbar ist. Hier würde es sich anbieten consumerXX->type z.B. mit bev zu erweitern und ggf. spezifische Readinginformationen zur Übertragung an einen MQTT Broker bereitzustellen.

Zur Zeit gibt es ja diese spezifischen Readings aus der consumer Steuerung:

consumerXX_currentPower
consumerXX_planned_start
consumerXX_planned_stop
consumerXX  -> Status Info
   
sowie die On/Off Schaltungen.

Für den Typ bev könnten weitere bzw. zusätzliche spezifische Readings bereitgestellt werden die per MQTT gepublished werden könnten.
D.h. wenn dieser Weg auch für euch passend erscheint, wäre die Frage welche weiteren Informationen / Funktionen speziell für bev über die Consumersteuerung bereitgestellt werden sollten und evtl. auch in speziellen Readings consumerXX_blabla hilfreich sein könnten.   

[grappa24]

"Das ist der Weg" (frei nach The Mandalorian) 

[grappa24]

Ich verlinke mal die MQTT API von EVCC: http://docs.evcc.io/docs/integrations/mqtt-api

[Parallix]

...
Den BEV als Verbraucher zu integrieren ist eine Variante die mir gefällt und die innerhalb SF auch gut abbildbar / integrierbar ist. Hier würde es sich anbieten consumerXX->type z.B. mit bev zu erweitern und ggf. spezifische Readinginformationen zur Übertragung an einen MQTT Broker bereitzustellen.

Den Ansatz die BEV als Verbraucher anzusehen, finde auch ich gut. Die besonderen Parameter werde ich am Wochenende zusammenstellen und hier durchgeben. Meinerseits steuere ich meine Wallbox via Modbus und brauche z.B. kein MQTT. Eigentlich sollte es auch völlig ausreichend sein, wenn SF sinnvolle Readings für für den neuen Verbraucher "BEV" zur Verfügung stellt, oder?

[DS_Starter]

Eigentlich sollte es auch völlig ausreichend sein, wenn SF sinnvolle Readings für für den neuen Verbraucher "BEV" zur Verfügung stellt, oder?

Ja. Wie die weiterverarbeitet werden ist ja aus Sicht SF egal. MQTT ist nur gutes Beispiel auch wegen der verfügbaren API-Infos.

[Wolle02]

Ich habe meine Wallbox schon seit geraumer Zeit als Consumer mit folgenden Parametern eingerichtet:

Code Auswählen Erweitern

openWB_Ladepunkt:Wallbox type=noSchedule power=3000 icon=wallbox swstate=charge_state:true:false pcurr=cp_power:W etotal=cp_imported_overall:Wh exconfc=1

Das funktioniert soweit ganz gut. Aber leider gut in der "get" Richtung. Das setzen von Parametern in der openWB durch SF wird aktuell durch die schlechte Umsetzung in der Software 2.0 derzeit nicht funktionieren, da hier für MQTT die erforderlichen set-Datenpunkte fehlen.

[klaus.schauer]

Seht ihr Notwendigkeiten für weitere Bat-Steuerungsparameter / Prozesse oder sind diese Möglichkeiten mittlerweile als völlig ausreichend einzuschätzen?

Wenn ich mir was wünschen darf, dann ist es eine erweiterte Unterstützung zur Nachladung der Batterie während Niedrigtarifzeiten aus dem Netz. Ziel wäre, ausreichend Energie für die Versorgung der Verbraucher in den folgenden Hochtarifphasen unter Berücksichtigung des anstehenden PV-Ertrages und der Verbrauchsprognose einzuspeichern. Da die Wärmepumpe - sicherlich nicht nur bei mir - in der kalten Jahreszeit der mit Abstand größte Verbraucher ist, wäre eine möglichst exakte Abschätzung des witterungsabhängigen Verbrauchsverlaufs dabei sehr wichtig. Durch eine Aufladung der Heizungs- und Warmwasserpufferspeicher durch  "Nachtstrom" in Perioden mit zu geringem PV-Ertrag könnte man zusätzlich Energiekosten sparen.

Derzeit nutze ich für meine ersten Experimente als Steuergröße Battery_OptimumTargetSoC-XX. Ob man mit diesen berechneten Werten tatsächlich zum Ziel kommt, kann ich noch nicht beurteilen.

M.E. ist eine möglichst treffende Verbrauchsprognose - insbesondere auch für den wankenden Heizbedarf über den Tagesverlauf - eine entscheidende Eingangsgröße zur Berechnung des Nachladebedarfs der Batterie, abgebildet über Battery_OptimumTargetSoC-XX. Soweit ich das sehe, fließen derzeit Witterungsabhängigkeiten, die gebäudespezifisch erforderliche Heizleistung und die Zeitprofile für die Sollinnentemperaturen allenfalls indirekt über die Verbrauchshistorie in die Prognose für den Verbrauchertyp "heater" ein. Mit diesen drei deterministischen Werten hätte man für ein wie immer geartetes Prognoseverfahren gute Eingangsgrößen für die zu erwartende benötigte Heizleistung.

Die Heizleistung selbst lässt sich nach Vorgabe der Außentemperatur und der Sollinnentemperatur mit Hilfe des Verlustkoeffizienten H aus Heizlastberechnung eines Gebäudes (DIN EN 12831) linear ableiten.

Damit wären wir bei meinem konkreten Wunsch nach einem Verbrauchertyp "Gebäudeheizung", bei dem man durch zusätzliche Vorgabe
    - des Verlustkoeffizienten H,
    - eines Korrekturfaktors insbesondere für die Berücksichtigung des COP-Wertes der Wärmepumpe,
    - des Zeitprofils für die Sollinnentemperatur
    - und ggf. der "konstanten" Verbrauchsdaten für die Warmwasserversorgung
die Besonderheiten in die Verbrauchsprognose einfließen lassen könnte.

Im nächsten Schritt könnte SolarForecast auf Basis einer validen Energiegesamtbilanz und unter Berücksichtigung des Verlauf der variablen Netzentgelte und/oder der EPEX Spot Day-Ahead Tarife unmittelbare Ladeanforderungen auch für Wärmepumpen oder anderer Verbraucher generieren.

Falls dies von allgemeinen Interesse und umsetzbar wäre, könnte ich zumindest als Ideensammlung ein paar Routinen beisteuern, mit denen ich aktuell zur Berechnung von Energiekostenprofilen und  des stündlichen Energiebedarfs für die Gebäudeheizung experimentiere.

[Hadl]

Den Ansatz die BEV als Verbraucher anzusehen, finde auch ich gut

Perspektivisch denke ich sollten wir erwarten das immer mehr Fahrzeuge mit bidirektionalen Laden vorhanden sind.
Damit wäre das Fahrzeug sowohl ein Verbraucher als auch eine Batterie/Generator fürs Hausnetz.

[Max_Meyer]

Im nächsten Schritt könnte SolarForecast auf Basis einer validen Energiegesamtbilanz und unter Berücksichtigung des Verlauf der variablen Netzentgelte und/oder der EPEX Spot Day-Ahead Tarife unmittelbare Ladeanforderungen auch für Wärmepumpen oder anderer Verbraucher generieren.

Falls dies von allgemeinen Interesse und umsetzbar wäre, könnte ich zumindest als Ideensammlung ein paar Routinen beisteuern, mit denen ich aktuell zur Berechnung von Energiekostenprofilen und  des stündlichen Energiebedarfs für die Gebäudeheizung experimentiere.

Hallo Klaus,
den Ansatz finde ich gut - ich bin einen anderen Weg gegangen um da ein bisschen Prognose in die WP-Reglung zu bringen und habe ein separates SF mit nur einem Verbraucher (WP) angelegt - erstmal zum Daten sammeln über den Winter - so sollten sich die Regeln wetter- und leistungsabhängig bilden um zukünftig prognosebasiert agieren zu können - gern könnte ich auch die diesbezüglichen Erkenntnisse - soweit nach der Heizsaison vorhanden - teilen

Gruß Gerd

[klaus.schauer]

Im nächsten Schritt könnte SolarForecast auf Basis einer validen Energiegesamtbilanz und unter Berücksichtigung des Verlauf der variablen Netzentgelte und/oder der EPEX Spot Day-Ahead Tarife unmittelbare Ladeanforderungen auch für Wärmepumpen oder anderer Verbraucher generieren.

Falls dies von allgemeinen Interesse und umsetzbar wäre, könnte ich zumindest als Ideensammlung ein paar Routinen beisteuern, mit denen ich aktuell zur Berechnung von Energiekostenprofilen und  des stündlichen Energiebedarfs für die Gebäudeheizung experimentiere.

den Ansatz finde ich gut - ich bin einen anderen Weg gegangen um da ein bisschen Prognose in die WP-Reglung zu bringen und habe ein separates SF mit nur einem Verbraucher (WP) angelegt - erstmal zum Daten sammeln über den Winter - so sollten sich die Regeln wetter- und leistungsabhängig bilden um zukünftig prognosebasiert agieren zu können - gern könnte ich auch die diesbezüglichen Erkenntnisse - soweit nach der Heizsaison vorhanden - teilen

Da der aktuelle Heizbedarf unmittelbar von der Außentemperatur und der Sollinnentemperatur abhängig ist, sollte man keine zu großen Erwartungen in Vorhersagegenauigkeit für kurze Zeitabschnitte haben, wenn man die aktuell gültigen Rahmenbedingungen nicht berücksichtigt.

[Hadl]

Hallo zusammen,
heute war mal zum Glück wieder ein Tag an dem man die SmartPower Ladestrategie mal wieder sehen konnte.
Man sieht gut wie er durch den barrierSoC unter 40% stärker läd, dann aber gleichmäßig über den Tag weiterläd.

Wenn der Überschuss mal nicht reicht sieht man auch gleich das er dann den OTP höher setzt.

Generell ist der Verlauf über den Tag eher leicht steigend. Es sieht mir so aus als ob wir keinen Margin mehr haben bei großem Ratio.
Erst bei Ratio 100%-120% gegen Abend zieht er dann die Ladeleistung kräftig an.
Du darfst diesen Dateianhang nicht ansehen.
Kann es sein das wir den normalen Margin bei ausreichend Überschuss verloren haben? In der Fortschreibung erwartet er gerade nichtmal das wir den Akku bis zum Ende des Überschusses voll bekommen werden. (7588Wh / 7680 Wh im Akku)

Code Auswählen Erweitern

2025.11.14 10:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.11.14 10:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, E requirement incl. efficiency: 4952 Wh -> target likely achievable? yes
2025.11.14 10:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - Ratio of remaining surplus 14228 Wh / energy requirement to achieve the load target: 287.30 %
2025.11.14 10:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 14/10 - hod:11/00, lr/lc:1/1, SocS/E:3372/4094 Wh, SurpH/D:2752/14228 Wh, OTP:831/723 W
2025.11.14 10:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 14/11 - hod:12/01, lr/lc:1/1, SocS/E:4094/4817 Wh, SurpH/D:2751/11476 Wh, OTP:831/723 W
2025.11.14 10:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 14/12 - hod:13/02, lr/lc:1/1, SocS/E:4817/5540 Wh, SurpH/D:3468/8725 Wh, OTP:831/723 W
2025.11.14 10:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 14/13 - hod:14/03, lr/lc:1/1, SocS/E:5540/6262 Wh, SurpH/D:2825/5257 Wh, OTP:830/722 W
2025.11.14 10:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 14/14 - hod:15/04, lr/lc:1/1, SocS/E:6262/6984 Wh, SurpH/D:1738/2432 Wh, OTP:830/722 W
2025.11.14 10:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 14/15 - hod:16/05, lr/lc:1/1, SocS/E:6984/7588 Wh, SurpH/D:694/694 Wh, OTP:3000/694 W
Wenn ich nachrechne müsste ich nen OTP von 852W haben.
(4952 - 694) / 5 = 852
Er hat aber "OTP:831/723 W". Dadurch muss er dann gegen Abend hochziehen, und bei fehlenden Überschuss zieht er noch weiter hoch.
Eigentlich hätte ich Abends eher 20% Margin-Luft erwartet.

Können wir die fehlende Leistung angleichen und auch im Überschuss-Fall den Margin draufrechnen?

Viele Grüße

Hadl

[DS_Starter]

@Hadl,

Kann es sein das wir den normalen Margin bei ausreichend Überschuss verloren haben?

Ja, haben wir. Gerade gecheckt:

Code Auswählen Erweitern

elsif ($ratio >= 100 + $otpMargin)             {$pow = $limpower}
müsste aber sein:

Code Auswählen Erweitern

elsif ($ratio >= 100 + $otpMargin)             {$pow = $limpower + $limpower * $otpMargin / 100}
Ändere ich.

[Parallix]

Hier eine Beschreibung eines typischen Szenarios: ...

Was ich nicht erwähnt hatte: Im Gegensatz zu der üblichen Ladung von Hausspeichern (Überschussladung mit beliebiger Leistung) muss ein BEV o.B.d.A. mit einer Mindestleistung (typ.: Anzahl der Phasen * 6A A * 230 V) geladen werden. Die Ladung kann auch zwischenzeitlich pausieren, sollte hierzu aber nicht abgeschaltet werden, da es hierdurch zu unnötigen Schaltvorgängen (Schütze) kommt. Aufgrund dieser Mindestleistung wird es insb. im Winter Situationen geben, in denen sinnvollerweise eine Ladung direkt aus dem Netz erfolgen sollte, damit es nicht zu stärker verlustbehafteten Umladevorgängen (Netz -> Hausspeicher -> BEV) kommt. Spätestens an dieser Stelle gibt es eine große Gemeinsamkeit mit dem Ansinnen von @Klaus.Schauer.

@Hadl: Aus meiner Sicht ist es nicht wirtschaftlich, eine teure BEV bidirektional einzubinden und darüber hinaus auch noch nicht in der Breite möglich.