Energiemanagement: Photovoltaik, E-Auto und Speicher

[Prof. Dr. Peter Henning]

Meine erste PV-Anlage betreibe ich seit 2007, die wird bis 2027 nicht angerührt.

Jetzt kommen aber hinzu: WallBox, E-Auto sowie zweite PV-Anlage mit Speicher. Wenn ich mir die ganzen halbgaren Apps ansehe, die mit den Komponenten geliefert werden, denke ich mir nur eins: Das geht besser.

Das Ziel dieses Threads ist also, eine weitgehend von der konkreten Hardware unabhängige FHEM-basierte Lösung für das Management und die Visualisierung der Energieflüsse zu produzieren, idealerweise von einer hybriden KI gesteuert. Solche hybriden Systeme aus regelbasierten Anteilen und neuronalen Netzen setze ich in verschiedenen Forschungsprojekten ein, das sollte also kein Problem sein.

Zu loben sind die Vorarbeiten von Christian Eick, der dazu einen langen Thread mit ungeheuer viel Codebeispielen initiiert hat. Dem will ich auch gar keine Konkurrenz machen, aber das Thema doch etwas von der konkreten Hardware lösen.

Erster Schritt also: WallBox. Da habe ich mich nach längerem Hin- und Her für eine go-e Charger Gemini 11 kW entschieden. Eine Übersicht der Systeme die ich näher angeschaut habe, findet man hier: https://wiki.fhem.de/wiki/Wallboxen_%C3%9Cbersicht.
Für den go-e Charger gibt es ein FHEM-Modul GoECharger - das allerdings auf die veraltete API-Version 1 zugreift. Mal sehen, ob ich das bei Gelegenheit gleich noch überarbeite. Derzeit betreibe ich dieses "alte" Modul parallel zur MQTT-Anbindung der WallBox.

LG

pah

[ch.eick]

Hallo pah
durch den Werdgang in meinem Thread habe ich schon lernen müssen, wie schwer es ist einen generischen Ansatz zu finden.
Es fing bereits mit der Namensgebung bei den Devices an, wo ich anfangs den Fehler gemacht hatte z.B. Kostal oder Plenticore mit rein zu nehmen. Es hat sich raus gestellt, da besser einen anderen Namensstandard zu wählen, der nichts mit Hersteller oder der Marketing Gerätebezeichnung zu tun hat.
Auch verfolge ich so gut es eben geht einen Modularen Ansatz und versuche nicht Funktionen zu vermischen.
Leider ist es mir in Zusammenarbeit mit Peter in diesem Leistungsprognose für Wechselrichter Thread dies nicht gelungen. Dort wurde die Leistungsprognose, Darstellung (FHEMWEB) und das Energiemanagement, später sogar noch die Hausspeicher Steuerung in einem Modul vermischt. Das mag für das Programmieren einfacher gewesen zu sein, macht es jedoch nicht einfach es zu adaptieren.

In meinem Fall habe ich nun folgende Aufteilung gefunden:

* Ein Device für die Hardware bzw die Verbindung
  Mein WR hat ModBus (MODBUS) und eine API (HTTPMOD)

* Ein Device für die Steuerung und Darstellung einer Funktionalität
  Da verwende ich DOIF im Perl Modus mit uiTable und widgets
  Beispiel:
     WR_ctl gibt einen Überblick über den kompletten Schwarm
        * Status
        * Prognose Statistik
        * Prognose Aktuelle Werte mit kurzzeit Aussicht
        * Momentan Werte von wichtigen Devices im Schwarm
        * Eventuell wichtige Kommandos als Pull Down für Devices im Schwarm
        * Aktuelle Werte als Tabelle mit Statistiken im Vergleich, wie Tag/Vortag, Monat/Vormonat

     WR_1_Speicher_1_ExternControl ist die Speicher Steuerung (DOIF)
        * In meinem Fall ist der Speicher als Hybrid am WR_1, also kein separates Device
        * Hier werden alle möglichen Konfigurationsparamer in Gruppen angeboten, die mit dem Speicher zu tun haben
        * Es gibt auch einen Gruppe, die z.B. auf EVU_Tibber verweist, um den Speicher nach einem Trigger zu steuern.

     Nach diesem Schema gibt es dann zu jedem Hardware Device ein, den Bedürfnissen des Gerätes, angepasstes DOIF.

     Teilweise verwende ich noch Hilfs-Devices, wie HourCounter

* Die Prognose läuft bereits mit einem KI Algorithmus, leider jedoch in Python, da es für den RPI wohl keine lib dafür gibt.
  Um die Mängel des DbLog Models zu umschiffen verwende ich eine MySQL Procedur, die die Daten in eine andere Tabelle überführt.
  Hier habe ich auch eine Art von Hybrid KI, da die KI alleine manchmal sehr euphorisch zu sein scheint. In diesen Grenzfällen
  kappe ich durch einen yield_max, den ich aus der Datenbank ermittle. Wie in der letzten Woche musste ich da bei Schnee gerade
  erst wieder eingreifen.

* Für die Visualisierung verwende ich Grafana, da dort die Funktionalität in den Graphen keine Wünsche offen lässt.
  Auch ein Dashboard lies sich optisch schön umsetzen. Da das mit viel Java läuft kann man auch den Vorteil nutzen, dass
  der Browser auf einer stärkeren Hardware läuft.

* bei den Wallboxen ist ein großes Problem, dass diese sehr unterschiedliche Funktionalitäten bieten und somit einiges erst
  nachprogrammiert werden müsste. Da bin ich mal sehr gespannt auf Deine Umsetzung.


Träume:
Ich habe bereits mal im Thema Nonintrusive Load Monitoring (NILM) gesucht und gelesen, jedoch übersteigt das bei weitem meine Fähigkeiten. Ziel wäre es die Planung der Verbraucher nach dessen Leistungskurve in die Leistungsprognose zu platzieren.
Rein optisch kann ich meine Verbrauchskurven bereits bis ins Detail lesen und die Geräte erkännen. Einige komerzielle Anbieter schaffen die Erkennung wohl bereits zu einem recht guten Prozentsatz automatisch.

Ich hoffe, dass war jetzt nicht nur wirres Zeug und passt hier hin.

VG  Christian

[papa]

Also für die Wallbox würde ich immer ein EVCC dazwischen schalten. Das kann auch super per MQTT angebunden werden.

[Prof. Dr. Peter Henning]

immer ein EVCC dazwischen schalten

Und warum genau bitte?

LG

pah

Edit: In der go-e Charger ist ebenfalls "alles drin"

[ch.eick]

immer ein EVCC dazwischen schalten

Und warum genau bitte?

Für mich wäre das nur ein weiterer Layer, der gepflegt werden muss, aber ich habe ja auch eine openWB, wo bereits alles drin ist.

[papa]

immer ein EVCC dazwischen schalten

Und warum genau bitte?
 der go-e Charger ist ebenfalls "alles drin"

EVCC braucht fast keine Resourcen und hat eine sehr gute, flexible Ladesteuerung inkl. Überschußladen. Unterstützt auch mehrere Fahrzeuge und Ladepunkte. Die wichtigsten Parameter (Lademodus, max. Ladestrom, ZielSoC usw.) lassen sich einfach per MQTT von FHEM aus setzen.

Ich hatte auch mal openWB probiert, aber das lief gar nicht auf dem PiZero. Mit EVCC ist der PiZero ohne Probleme klar gekommen.

[ch.eick]

immer ein EVCC dazwischen schalten

Und warum genau bitte?
 der go-e Charger ist ebenfalls "alles drin"

EVCC braucht fast keine Resourcen und hat eine sehr gute, flexible Ladesteuerung inkl. Überschußladen. Unterstützt auch mehrere Fahrzeuge und Ladepunkte. Die wichtigsten Parameter (Lademodus, max. Ladestrom, ZielSoC usw.) lassen sich einfach per MQTT von FHEM aus setzen.

Ich hatte auch mal openWB probiert, aber das lief gar nicht auf dem PiZero. Mit EVCC ist der PiZero ohne Probleme klar gekommen.

Moin,
okay, ich spreche von einer openWB Hardware Box, es gibt auch nur die Software, die dann fremde Wallboxen steuert.
Die openWB HW hat eine RPI drin und macht alle Anforderungen out of the box.

Ich denke jedoch in diesem Thread soll es nicht um die Wallbox auswahl selber gehen, sondern um das drum herum.

VG  Christian

[Prof. Dr. Peter Henning]

Ich habe in den letzten Tagen erst einmal die Steuerung der WallBox optimiert. Fehlen jetzt nur noch das Auto und die zweite PV-Anlage [Mit-den-Füßen-scharr]

LG

pah

[ch.eick]

Fehlen jetzt nur noch das Auto und die zweite PV-Anlage [Mit-den-Füßen-scharr]

Mitleidigguckweildusolangewartenmusst

[Prof. Dr. Peter Henning]

Na ja, wenigstens ist jetzt die WallBox brauchbar angebunden (und zwar ohne evcc), siehe https://forum.fhem.de/index.php?topic=136856.0

LG

pah