zu meiner Anlage:
11,5kW peak in O-S-W Ausrichtung
12kW Deye Hybrid mit modbus Anbindung
32kWh EEL Battery
flexotherm 88/4 Sole Wärmepumpe mit ebus Anbindung
smart meter mit 15min Datenübertragung zum Netzbetreiber
dynamischer Bezugstarif "smartcontrol"
dynamischer Einspeisetarif "smartsunhourly"
Ich habe das EOS im Docker laufen und bastel die "OptimizationParameters" im IObroker blockly zusammen. Über http POST schick ich dem EOS das Objekt und bekomme nach 2-3min die "OptimizeResponse" zurück. Die neue "start_solution" übernehme ich bei der nächsten Anfrage.
Nun ist es so, dass der Akku in der Früh noch gut 80% SOC hat und am Vormittag voll ist. Dann wird der Überschuss zu den denkbar schlechtesten Preisen eingespeist. Ich hab das EOS durch herumschrauben an diversen Parametern nicht dazu gebracht den Akku ins Netz laden zu wollen, wenn der Preis hoch ist. Meist am Abend oder in der Früh würde sich das anbieten, um am nächsten Vormittag genug Platz für Sonnenstrom zu haben.
Hat das schon jemand zusammengebracht oder gibt's Ideen wie man das EOS in diese Richtung erziehen kann?
EDIT:
Der Strompreis setzt sich aus dem Energiepreis der jeweiligen Stunde +21cent zusammen.
Für die Einspeisevergütung habe ich 0,8*Energiepreis der jeweiligen Stunde genommen (enspricht dem Einspeisetarif), somit ist der Preis dynamisch.
Die 2kW peaks sind die Wärmepumpe (wird momentan noch mit eigenem Modell so gesteuert).
Mir scheint das EOS zieht das Einspeisen vom Akku garnicht in Erwägung, sondern nur den direkten PV Überschuss. z.B. Morgen (11.04.2025 zwischen 13:00 und 16:00) bezahle ich fürs Einspeisen. siehe Anhänge:
Beispiel bitte mit Bildern zeigen und genau erklären. Erziehen muss man da nix, dass muss sich aus den Daten mathematisch ergeben. Das klingt eher nach falschen Daten
Danzog4
Hi, @danzog4 gibts bei dir Neuigkeiten?
Hast du EOS zum Laufen bekommen?
Ich habe ein ähnliches Setup
34 kWp PV Anlage
Victron 3phasig
54 kWh Speicher
Wärmepumpe
Direktvermarktung
dynamische Preise beim Strombezug).
Derzeit benutze ich das Victron DESS seit 2 Monaten. Das ist schon gut, macht aber Fehler.
Winterbetrieb (Akku aus dem Netz bei Tiefpreisen laden) habe ich noch nicht durchlebt:-)
Ich suche gerade nach Leuten die schon mehrere Tools ausprobiert haben.
Gruß
Stefan
Hi @stefan123456 , ja bei mir gibts Neuigkeiten.
Ich hab das EOS zwar nicht so zum Laufen gebracht, wie ich es gerne hätte, aber ich hab mein eigenes "EMS" um die Akkuoptimierung erweitert.
Es ist eine regelbasierte Optimierung die nur jetzt gerade unter diesen Bedingungen gut funktioniert. Ich möchte damit einfach nur mal zeigen, wie man einen Akku nutzen kann, um einerseits netzdienlich zu sein und andererseits das meiste aus dynamischen Einspeisetarifen rauszuholen. Schließlich soll der Akku ja auch verwendet werden und nicht nur voll rumstehen
Sobald ich weiß wie man ein ähnliches Verhalten aus dem EOS rausbekommt würde ich umsteigen. Vielleicht kann mir jemand paar Tipps geben? Bis jetzt hab ich beim EOS keine Möglichkeit gesehen den Akku gezielt ins Netz zu entladen.
Mit welche Tool/Sprache/Umgebung programmierst du da gerade?
Mit welchem Tool/Sprache/Umgebung hast du die Diagramme im PDF erstellt?
Hast du schon etwas anderes als EOS ausprobiert?
Danke für DIE wesentliche Info: Das EOS unterstützt derzeit noch keinen Stromhandel = Entladen bei Tiefstpreisen.
Hier mal eine Grafik vom Victron DESS von heute. Ich hoffe man kann die Legende lesen.
Momentan bin ich ziwschen 20 und 21 Uhr, deshalb ist dort noch schrafiert. Das ist der "Plan"
Hier die Prognose für Morgen. Die wurde kurz nach 13 uhr erstellt, als die neuen Strompreise rauskamen. Der Plan wird dann stündlich nachgebessert mit dem Akkustand den er eben hat:
Gelegenltich kommt es zu ungewolltem Strombezug. Dem programmiere ich gerade im Victron-Cerbo (Herzstück bei Victron / die zentrale Steuerung) per Node-red dagegen. Wenn ich Fehler detektiere, schalte ich die Automatik ab. Die Schnittstellen sind allerdings nicht dokumentiert, aber es funktionert halbwegs. Das wird aber spätestens im Winter zu Problemen führen.
Meine Grafiken fallen direkt im Victron Dashboard heraus. Diagramme mit Linien gibts auch, aber die Stunden-basierte Ansicht ist für den Stromhandel viel besser.
Die Strompreise, eine Verbrauchs- und Erzeugungs-Prognose bringt die Victron-KI mit. "Maschine Learning". Da muss man nichts programmieren - das funktioniert direkt out-of-the-box.
Das Laden der Batterie im Winter bei Tiefstpreisen wird ebenfalls unterstütz, da habe ich aber noch keine Erfahrungen.
Minuspunkte:
gelegenltich unnötiger Strombezug (sehr nervig, schaden bei mir zwischen 0,00Eur und 0,50Eur pro Tag)
derzeit keine Unterstützung für variable Netzgebühren (§14A, Modul 3) und auch keine Möglichkeit die Preise reinzuwursteln.
Hi,
bei mir läuft alles als Dockercontainer auf einem Ubuntu mini Recher mit Intel N100.
ich hab den IObroker als Basis
mit dem JavaScript Adapter programmiere ich
die Kommunikation mit Deye läuft über den Modbus Adapter (waveshare an raspberry mit mbusd)
die smartmeter Daten dekodiere ich mit SZreader (IR Lesekopf an raspberry mit nodered & Mqtt)
vom IObroker aus logge ich die wichtigsten Datenpunkte in InfluxDB
mit dem Flot Adapter hol ich die Daten aus der DB und erstelle Diagramme
alternativ auch Grafana aber wenns schnell gehen muss => Flot
Noch hab ich kein anderes EOS ausprobiert, danke für den Input vom Victron DESS. Ich wusste noch nix davon und der Output sieht auf den 1. Blick schon mal ganz gut aus
Ich bin echt gespannt wie sich das EOS Thema allgemein weiter entwickelt. Wir zählen glaube ich zu einem winzigen Prozentsatz, der sich mit diesem Gebiet überhaupt befasst. Bekannte von mir haben erst bei der 2. Jahresabrechnung bemerkt, dass ihre PV Anlage fast 2 Jahre lang nichts geliefert hat, während ich jeder Ws nachlaufe.
Danke, an alle Entwickler vom Akkudoktor EOS. Es wird immer wichtiger Energie sinnvoll und effizient zu nutzen. Ich freue mich schon auf den Umstieg.
Danke für die Infos!
Der Andi-Akkudok hat gerade gestern ein Video bei Youtube veröffentlich, in dem er beiläufig erwähnt, dass er ab nächsten Monat Direktvermarktung macht (Zitat: variablen Preisen einspeist).
Da kann man davon ausgehen das sich demnächst bei diesem Thema ordenlich was bewegt
@Akkudoktor : falls du mitliest kannst du ja gerne kurz einen Kommentar fallen lassen, ob es einen groben Zeitplan für die Funktion "Direktvermarktung" gibt.
Ich werde mit einer Anlage auf EOS umsteigen die nächsten Wochen.
Gruß
Stefan
Moin, also sagen wir mal so: Luox und der vnb kommen nicht in die Pötte. Angeblich diesen Monat. Sobald das losgeht, können wir starten.
Die Arrays für die Einspeisevergütung sind ja schon da, allerdings müsste man noch das "einspeisen" in den Optimierungsalgorithmus einbringen. Das dürfte aber sehr schnell gehen, sobald die endlich soweit sind, werde ich das sofort umsetzen.
Leider kommen dann auch noch die 15min Werte auf uns zu, da müssten wir auch noch schauen wie wir das am intelligentesten integrieren
Jetzt kann man zwar eines dieser Geräte (wie SolarLog oder Meteocontrol) verwenden und das EOS daran anbinden - allerdings sind diese Logger nicht billig, meist mit Lizenzen an die Anlagengröße gekoppelt und an sich nur für die VPN-Anbindung an den Direktvermarkter nötig.
Hintergrund:
Die Deye 12K- und Deye 20K- LV-Hybridgeräte lassen sich mit einem Applikations-Gateway für die SDM630-Zählerdaten recht einfach auf flexible Einspeisung umrüsten.
Habe in ähnlicher Weise bereits ein mit python-can und asyncio implementiertes Gateway zum Multiplexen von BMS-Daten aufgebaut, das selbst auf einem Raspi 2 nur sehr wenig CPU-Leistung benötigt (läuft jetzt seit einigen Wochen ganz gut):
Mit Async-IO sollte das auch gut für die Modbus-Daten funktionieren, wenn ein SDM630 für die Eigenbedarfsregelung verwendet wird, wobei die Zero-Export-Steuerung für die dynamische Einspeisung einfach einen Wirkleistungs-Offset zwischen -12(20) kW ... +12(20) kW bekommt.
Es fehlt per se nur noch die Anbindung an die Direktvermarktungsschnittstelle an das EOS.
Das Git-Repo habe ich so eben gecloned, konnte aber zur Anbindung der Direktvermarktung nichts finden..
