Wie in einem vorherigen Post angekündigt hatte ich den Ansatz verfolgt, eine Einspeise- und Laderegulierung in Gänze unabhängig vom Connector-Script (ioBroker) zu realisieren.
Erste Entwicklungsansätze und eine tiefere Recherche in den FHEM Innereien haben mich aber nunmehr zu einer Lösung gebracht, die meine Anforderungen in Gänze erfüllt, stabil läuft
und bis zum jetzigen Zeitpunkt keine Wünsche offen lässt.

Eine Kombination aus beiden Welten: FHEM und ioBroker gestützter EcoFlowkommunikation (MQTT).

Nach dem seitens EcoFlow die „inoffizielle“ Art der Anbindung stark eingeschränkt wurde, war der erste Schritt, hier auf den offiziellen Weg zu switchen.

Ich berichtete.

Im gleichen Moment kam es auch leider dazu, dass das durch die „ConnectorScript“ Community initiierte Verfahren zur dynamischen Einspeisung einiges an Tempo verloren hat und keine vollumgänglichen
Ansätze mehr im Forum verfolgt wurden.

Dies nahm ich dann zun Anlass, die bereits vorhandenen Anpassungen (das Grobgerüst) zur neuen Kommunikationsmethode als Basis herzunehmen und die meinen Anforderungen entsprechende
Funktionalitäten selbst zu entwickeln.

Gesagt getan:

Nun verhält es sich in meinem Setup so, dass die eigentliche Lade- und Einspeiseregulierung auf FHEM Seite initiiert wird.
Sprich: Wann wird Überschuss geladen, wie lange wird geladen, wie wird die ioBroker basierte Regulierung beeinflusst.

Das Ganze baut auf entsprechenden FHEM DOIfs und Notifies auf, welche direkt mit den jeweiligen Objekten in meiner ioBroker Docker Instanz interagieren.
Die reine Kommunikation zum EcoFlow Universum erfolgt dabei auf dem „offiziellen“ MQTT Weg im ioBroker. Ladestände, Spannungen und Ströme werden auf diesem Wege ermittelt und in Echtzeit via FHEM Adapter an die FHEM Instanz übermittelt.

Der Performance tut dieses auf beidenden Seiten (FHEM und ioBroker) keinen Abbruch.

Die Ermittlung des PV Überschusses erfolgt im FHEM und wird über entsprechende Dummies und den Connector dynamisch an die ioBroker Objektstruktur übergeben und vom „RegulierungsScript“ verwurstet.
Die bereits aus den bisherigen Community Scripts vorhandenen Funktionen in Bezug auf Lade-, Entladegerenzen und Einspeiseleistung wurden wieder implementiert. Darüber hinaus werden auch die Ports der DELTAs direkt durch dieses biderektionale Konstrukt bedient. Gemeint sind 12V Ports, USB Ports und AC Ports.

Da die PV Gewinnung in der Zwischenzeit nicht mehr durch BKW Module erfolgt sondern diese einer 5,2 kWp Anlage gewichen sind, kommt auch genug „runter“, um hier dynamisch, in Abhängigkeit vom
Überschuss, laden zu können. Selbst zu den aktuell geringen Sonnenstunden, kann man hier schon ein bisschen was an Akkuladung erreichen.

Die Gesamtlösung unterstützt aktuell folgende Funktionen:

• Einbidung PowerStream (offizieller Weg)
• Einbindung DELTA 2 MAX (offizieller Weg)
• Einbindung DELTA 2 (offizieller Weg)
• Dynamische AC Ladung nach Überschuss (Ermittlung FHEM)
• Überwachung häufiges Ein-/Ausschalten der Überschussladung (Watchdogs)
• Reduzierung der Einspeisung bei geringem Akkustand (lowbatLimit)
• Somit auch kontinuierliche Einspeisung mit festem Wert (wenn gewünscht)
• Start der Einspeisung in Abhängigkeit der Akkuladung und Dämmerungsverhältnisse und Hausbedarf
• FHEM initiertes Ein-/Ausschalten der USB Ports
• FHEM initiertes Ein-/Ausschalten der AC Ports
• FHEM initiertes Ein-/Ausschalten der 12 V DC Ports (beispielsweise zum Crossload)

Crossload?
Unter Crossload verstehe ich das „indirekte“ Laden der Delts2Max über den PV bzw. 12V Port aus der DELTA2. Sinkt der Ladegrenzwert der Delta2Max auf Wert X, wird dynamisch aus der Delta 2 nachgeladen, insofern diese über ausreichend Ladung verfügt.

Warum das Umdenken?

An sich ein ganz einfacher Ansatz. Zum einen stellte sich mir die Frage:“Warum das Rad neu erfinden…?“. Zum anderen, und dieses im Hinblick auf meine Umgebung, die ggf. zu erwartenden Beeinträchtigungen im FHEM Umfeld bei der Performance.
Da ich inzwischen so ziemlich alle „häuslichen Prozesse“ auf die ein oder andere Art und Weise automatisiert und digitalisiert habe und mit der Performance und Zuverlässigkeit sehr zufrieden bin, achte ich sehr genau darauf, dass dieses auch so bleibt.
Vergessen darf man dabei ja schliesslich nie den WAF (wife acceptance factor). 😉

Auch wenn dass Script sehr stark auf meine Bedürfnisse und meine Umgebung vor Ort auslegt ist, spricht nichts dagegen, meine Erkenntnisse und Fortschritte zu teilen.
Wer also Interesse am Script hat, kann mir gerne eine Mail zukommen lassen und ich stelle das Script gerne auf Anfrage bereit.