Wie man eine dynamische Einspeisekontrolle via dem EcoFlow Script von Waly realisieren kann hatte ich schon entsprechend veröffentlicht.
Wie wäre es nun, die dynamische Hausnetzeinspeisung und Kontrolle der PowerStream direkt aus FHEM heraus bereitzustellen ohne eine ioBroker Instanz einzusetzen?
Die Grundidee
Das EcoFlow Script für den ioBroker stellt eine absolut geniale Möglichkeit zu dynamischen Einspeisung des PowerStreams dar. Ich selbst habe diese aktuell in Betrieb und bin auch nach wie vor
hoch begeistert. Es wäre aber eine tolle Sache, wenn ich mir den eigens dazu bereitgestellten Docker Container für den ioBroker sparen könnte und direkt aus FHEM heraus im ersten
Schritt die dynamische Einspeisung (Haushaltsstrombedarf) regulieren könnte.
Auf die Idee bin ich durch den hervorragenden Artikel von Jürgen gekommen. In “Jürgen Technik Welt” beschreibt dieser den offiziellen Weg der EcoFlow MQTT Anbindung- auch wenn die bereits hier im Blog
veröffentlichte Variante über den etwas komplizierteren “inoffiziellen” Weg ebenso funktioniert. Habe das gleich mal zu direkten Einbindung der PowerStream umgesetzt und kann sagen – passt.
Funktioniert wie es soll. Super!
Zur Umsetzung der dynamischen Einspeisung habe ich nun folgende Überlegungen angestellt, aber auch schon die ersten Schritte unternommen.
Das Script zur EcoFLow “Kontrolle” wird in einem gesonderten Script untergebracht (analog zum 99_myUtils Script). Innerhalb dieses Scriptfiles befindet sich die eigentliche “EcoControl”
Sub Routine. Der Aufruf der Subroutine kann durch ein FHEM getriggertes AT oder aber auch ein Notify erfolgen. Ein Notify kann beispielsweise immer dann getriggert werden, wenn sich
am bereits in FHEM eingebundenen PowerMeter (Stromzähler) eine Veränderung ergibt. In der ersten Phase meiner Umsetzung habe ich mich für das AT entschieden, welches alle x Sekunden das Script ausführt.
Das Script selbst basiert, wie sollte es bei FHEM auch anders sein, auf reinem Perl Code.
Das Script ist abschliessend dann natürlich so aufgebaut, dass dieses universell einsetzbar ist. Über entsprechende Initialierungsvariablen werden dann “nur noch” die Variablen mit den entsprechenden Daten und Devices der eigenen FHEM Umgebung gefüttert.
Aktueller Stand
Derzeit wird noch keine tatsächliche Regulierung durchgeführt. Nach erfolgter Einbindung des EcoFLow Universums in meine FHEM Instanz, werden aktuell die entsprechenden Werte gelesen, notwendige Berechnungen ausgeführt und
die ermittelten bzw. berechneten Werte in ein EcoControl – Dummy Device geschrieben. Diese dienen dann in der ersten Phase der Prüfung und dem Entwicklungsprozess als solchem.
Wie Jürgen auch in seinem Blog Beitrag angibt, werden vom EcoFlow MQTT Device eine Ganze Latte an Readings und Parametern übermittelt. Diese gilt es erstmal zu verinnerlichen. Am besten kann man die Auswirkungen in direkter Verbindung mit der EcoFlow App überprüfen und schauen, wie sich welche Parametrisierungen in der APP in den MQTT Readings auswirken.
In einer weiteren Phase wird das EcoControl Dummy Device im Rahmen der Scriptausführung automatisch erstellt, falls dieses noch nicht vorhanden ist. Selbiges gilt für die eigentliche EcoFlow MQTT Einbindung, welche aktuell noch als vorbereitende Maßnahme manuell erfolgen muss/musste. Wie gesagt bietet hier der Blog von Jürgen eine Klasse Unterstützung.
Das Dummy Device und dessen Werte
FeedInFrom Bat = Einspeiseleistung vom Akku ins Hausnetz
FeedInFromPV = Einspeiseleistung der PowerStream PV ins Hausnetz
FeedInPower = Gesamteinspeiseleistung des PowerStream in Hausnetz (PS PV und Akku)
LoadPower = Ladeleistung des PowerStream (Überschuss der in den Akku geht). Hier werden “nur” die am PowerStream angebundenen PV Module / Eingänge berücksichtigt
NetRequest = Aus dem öffentlichen Netz angeforderte/bezogene Leistung aus dem Powermeter
RealPV = Gesamt PV Leistung der PowerStream PV und ggf. vorhandener weiterer Pv Module / BKWs
RealPower = Aktueller/Tatsächlicher Energiebedarf des Hauses (Summe aus RealPV,NetRequest und FeedInFromBat)
state = Status des MQTT Clients
Wie geht es weiter?
Grundsätzlich habe ich mein “Projektchen” in 4 Phasen unterteilt, wobei sich die Phase 4 erst noch zeigen wird.
Phase 1: Wie hie rbeschrieben. In erster Linie werden die Grundvoraussetzung geschaffen und die ermittelten Werte eruiert und geprüft
Phase 2: produktiver Test der dynamischen Einspeisung
Phase 3: Codeoptimierungen und Dynamisierung. Dazu gehört auch die Integration ggf. bereits vorhandener Überschussladelogiken via AC.
Phase 4: Modulisierung des EcoControl Scripts
In den kommenden Tagen und Wochen wird fleissig weiterentwickelt. Werde, wenn es neue Erkenntnisse und/oder Meilensteine zu verkünden gibt, erneut berichten.
Dynamische Einspeisung – Warum überhaupt?
Sicher bietet die EcoFlow PowerStream Lösung von Haus aus eine Task gesteuerte Möglichkeit der Hausnetzeinspeisung. Allerdings ist diese konstant und birgt die Gefahr, dass man im Fall der Fälle Akkuleistung kostenlos ins öffentliche Netz des Versorgers einspeist.
Eine dynamische Einspeisung verhindert dieses, da die der aktuelle Bedarf im Hausnetz in Echtzeit ermittelt wird und die entsprechenden Werte in der PowerStream automatisch angepasst werden – dynamisch eben :-). Und vor allem das Ganze ohne den Einsatz der EcoFlow Plugs, da sich direkt auf die Werte des Powermeters bezogen wird-