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.