DIY Nulleinspeisung mit Hoymiles an Drehstrom

Hallo Zusammen.

Hier mal eine kleine Vorstellung von meinen Projekt. Der aktuelle Stand wurde nicht so geplant, sondern das Projekt ist über die Zeit gewachsen - Der Weg ist das Ziel :wink:

Aktuell habe ich einen 8,5kWh LiFePo4 Akku auf 25,6V Basis, welcher aus mehreren kleineren USV-Akkus besteht. Ist nicht optimal, aber ich kam da günstig ran. Ebenso habe ich für das Projekt tiefentladene Zellen wiederbelebt. Die Erfolgsquote liegt bei ca 30%... Allerdings sollte man das nicht nachmachen :wink:

Geladen werden die Batterien aktuell mit 4x 40A Industriestromversorgungen, welche ich um einen PWM Eingang erweitert habe um die Leistung zu regeln. Ist nicht jedermanns Sache, aber ich bin beruflich Hardware-Entwickler für Industriestromversorgungen, deswegen ist so ein Umbau der Netzteile für mich kein Problem. Diese Stromversorgungen laufen mit Drehstrom, was angesichts der Leistung (max 4kW) auch notwenig ist. Das Laden funktioniert eigentlich prima, da gibts keine Probleme. Übrigens: der Speicher ist ein reiner AC-Speicher, Laderegler gibt es keine.

Bei den Wechselrichtern bin ich noch immer nicht glücklich. Gestartet habe ich hier mit einen Hoymiles 1500, welcher über eine OpenDTU angesteuert wurde. Das hat auch ein paar Monate gut funktioniert, mit der Zeit haben sich aber die internen MPPT's gegenseitig beeinflusst. Das ist auch nicht verwunderlich, wenn man bedenkt, dass hier die Ströme der einzelnen Eingänge ungleich aufteilen, da ja die einenzelnen Eingänge über die Batterie verbunden sind. Dann "zappelt" der Ausgangsstrom etwas. Ich konnte das Fehlerbild leider nicht beheben, warum der HM1500 weichen musste.
Ich bin auf insgesamt 6 Stück HM-400 umgestiegen, welche ja nur einen MPPT besitzen, und daher dieses Problem nicht auftreten kann. Das hat auch funktioniert, bis auf die Tatsache, dass es eben bei der OpenDTU es zu Verzögerungen kommt, da ja pro Wechselrichter ca 1-2 Sekunden vergehen, bis die Werte übernommen werden.
Zu Beginn wurden die Wechselrichter AC-Seitig an der gleichen Phase betrieben, was zwangsläufig auf der DC-Seite zu hohen Pulsströmen im 100Hz Rythmus führt (bei 2400W Einspeiseleistung nicht unerheblich). Um das zu verhindern bin ich auch hier auf Drehstrom umgestiegen und habe die 6 Wechelrichter gleichmässig auf die 3 Phasen aufgeteilt. Tja, und da gibt es ein riesiges Problem, was ich bis jetzt noch nicht lösen konnte:
Für die 0-Einspeisung wird ein Wechselrichter nach dem anderen von 0 auf 300Watt (max 12,5A Eingangsstrom) gefahren, die restlichen Wechselrichter ohne Leistung werden in Standby geschickt. Alle 6 Wechselrichter gleichmässig zu betreiben führt zu mehr Verlusten, weshalb ich diese Methode eigentlich nicht verwenden mag. Aber da würde alles funktionieren. ...
Jedenfalls steigen mir unwillkürlich Wechselrichter aus, wenn nur einer oder zwei mehr Leistung fahren. Beim einphasigen Betreib war das nie ein Problem. Woran könnte das liegen, wenn eine Wechselichter auf einer anderen Phase einspeist, es den im Leerlauf befindelichen Wechselrichter auf einer anderen Phase zum Absturz bringt??
Ich habe AC-Filter probiert, Ferrite eingebaut und und und... Alle sohne Erfolg. Dann war die Überlegung, ob es Rückströme auf der DC-Seite sein könnten, weshalb ich die Wechselrichter mit Dioden entkoppelt habe, so dass der Strom nur rein, aber nicht raus fließen kann. Das hat das Problem zumindest verbessert, aber nicht gelöst.
Vor einigen Tage bin ich günstig zu einen Herf-800 gekommen und habe auch diesen im System integriert. Macht der mehr als 300 Watt zicken die anderen Wechselrichter wieder herum. Im Gegenzug steigt auch der Herf-800 aus, wenn ein Hoymiles auf einer anderen Phase einspeist.
Wenn ich auf jeder Phase jeweils einen Wechselrichter mit der gleichen Leistung betreibe, funktiniert alles. So laufen halt immer 3 Wechelrichter gleichzeitig, was als Mittelweg halbwegs akzeptabel aber nicht ideal ist. Kurz gesagt: wenn Wechselrichter A auf L1 einspeist, bewahrt das auch den Wechselrichter B ebenfalls auf L1 vorm Absturz. Wenn allerdings auf L2 nicht oder nur wenig eingespeist wird, stürzen diese Wechelrichter auf L2 ab. Kann mir das jemand erklären??? Hat jemand die selben Erfahrungen gemacht?

Übrigens wird die Nulleinspeisung von IoBrocker im sekundentakt gesteuert. Am Dach befindet sich eine 12kWp Anlage.

Vielleicht hat ja wer eine Idee :wink:

Was heißt WR stürzt ab? Was sagt das WR Log in OpenDTU?

Sehe ich das richtig, Du steuerst die Sollwerte der WR direkt über IoBroker? Berechnungen dort im Script?

Schon mal OpenDTU-OnBattery probiert? Das läuft bei mir recht problemlos, Nulleinspeisung mit 2x HMS-2000-4T an L1 und L2.
Kabellängen zu den DC-Eingängen gleich lang dann gibts auch (fast) keine Differenzen zwischen den 'Strings'. Hängt allerdings an einem 16s Akku!
8s ist nicht empfehlenswert, in dem Leistungsbereich erst recht nicht.

Der Wechselrichter blinkt im 4-Sekunden Rythmus (= Verbindung zur DTU verloren). In der DTU wird allerdings der Wechselrichter als Ausgeschaltet dargestellt. Über die DTU einschalten funktioniert nicht sondern nur neustarten. Darum verstehe ich auch das Blinken nicht, denn zumindest der Neustart über die DTU funktioniert ja.

Ja, ich habe da ein in Iobroker ein Blockly erstellt. Ein Heizstab ist da auch noch im Spiel, weshalb ich mich noch nicht an die Opendtu on Battery rangewagt habe. Ich denke ich bei dieser Version würde mein "Smartmeter" der IoBroker sein.

Kabellängen sind selbstverständlich gleich. Das Problem war, das ein Eingangspaar (1x MPPT auf 2 Strings) den vollen möglichen Strom gezogen hat (23A) während die anderen Beiden nichts gemacht haben. Mittlerweile bin ich schon fast der Meinung, dass es eine Eigenheit vom 1500er ist. Der Herf ist übrignes komplett symetrisch.

Mir ist es durchaus bewusst, dass eine 16s Konfiguration besser wäre. Aber das Projekt ist mit diesen USV-Akkus gewachsen und ein Umstieg von 8s auf 16s würde sehr viel Arbeit für mich bedeuten was für den WAF (Woman aceptance factor) nicht sehr dienich wäre :wink:

Du hast viel beschrieben aber ich denke um das was da passiert zu verstehen braucht es ein Schaltbild des Systems einschließlich der Steuerleitungen.

Ja das funktioniert. Habe noch 4x HM (1x 300, 2x 600 und 1x 1200) an einer zweiten OpenDTU-OnBattery, hängen alle an PV. Die kriegt ihre Regelgröße über MQTT vom IoBroker. Solange der Akku lädt oder der Verbrauch größer als die aktuelle PV Leistung der WR ist laufen die Vollgas indem sie nen aktuellen Netzbezug von Istwert + 2kW vorgegaukelt kriegen. Ist der Akku voll und PV größer Verbrauch dann werden sie mit dem aktuellen Wert vom Zähler versorgt und regeln auf -20W Netzbezug. Das funktioniert auch recht gut, je mehr WR an einer DTU umso langsamer werden allerdings die Aktualisierungs- und Steuerzeiten!
Alle 6 WR im Sekundentakt mit einer DTU steuern kannst Du schon mal komplett vergessen, das kann nicht funktionieren.
Wenn Du nicht groß umbauen kannst oder willst würd ichs als erstes mal mit mehreren DTUs probieren. Ein paar ESP32 und nRF24 kosten ja nicht viel.

Das ist mir bewusst. Das mit den Aktualisierungs- und Steuerzeiten habe ich eh auch oben geschrieben. Mittlerweile betreibe ich dabei eine zweite DTU (ürsprünglich um einen Fehler der ersten auszuschließen). Das verbesserts natürlich.
Aktuell wartet IoBroker bis sich der Vorgabewert bei den Wechselrichter eingestellt hat, erst dann wird der nächste Wert geschickt. Da kommt man dann bei keinen Änderungen auf ca 5s. Das ist akzeptabel.

Ich werde aber deinen Vorschlag beherzigen und noch eine DTU bauen!

Schaltplan muss ich erst pinseln :wink:

Der is recht simpel... Für kleines Geld gibts auch fertige Platinen zum selberbestücken.

Den Schaltplan von der Anlage - Den von der DTU kenn ich schon auswendig :rofl:

Keine Ahnung ob die Info hilft:

In openDTUonBattery hatte ich auch 1-2x das Erlebnis das die Steuerung sich aufgehängt hat. Das passierte super-selten aber hat bei mir zur Situation geführt das der WR eingespeist hat bis das BMS abgeschaltet hat. Den WR konnte man nur durch Neustart (über Funk) zurückholen.

openDTUonBattery hat daraufhin eine Überwachung bekommen die diesen Fehler erkennt und den Neustart des WR automatisch triggered.

Klingt so als ob dein Setup dies provoziert