... Danach wird die PV Leistung dann wieder rauf gerampt. So wird halt noch das letzte bisschen Energie in die Batterie rein gequetscht.
... Gibt es keinen Punkt wo der Laderegler sagt, dass die Batterie jetzt einfach voll ist und dann bleibt die Ladeleistung einfach auf 0? Kann man das irgendwie einstellen? Habe ich generell vielleicht die Einstellungen falsch wenn man ein solches Verhalten sieht? Siehe unten noch als Beispiel ein Bild wo man das Verhalten erkennen kann.
Welche Werte hast du denn eingestellt?
Ich kann mir das Verhalten nur so erklären, das die Akku-Spannung ohne Ladestrom abfällt, bis der Regler meint, es geht wieder los.
-> Das ist definitiv der Grund. Finde es nur seltsam dass er dieses Verhalten dann so lange zeigt. Ich glaube dass er dann kurzzeitig immer wartet bis der Cell Balancer die Zellen-Spannungen ausgeglichen hat und versucht dann wieder zu laden. Dann geht die Spannung natürlich schnell wieder bis auf Ladeschlussspannung und der fährt die Ladeleistung bzw. PV-Leistung wieder runter. Je länger er das macht, desto größer werden die Abstände zwischen den "Zacken". Scheint irgendwie schon Logik hinter zu sein, aber optimal wirkt das nicht. Sobald er über die Saturation Charging Voltage (> 55.5V) geht, beginnt das Spiel. Ladeschlussspannung ist ebenfalls fast wie bei dir 57.4V.
Nachtrag: Es könnte auch einfach ein MPPT Tracker Neustart sein, weil zu wenig Leistung umgesetzt wird.
Kannst du mal 2-3 Zacken so herausschneiden, dass man die Skalen besser erkennt - und unnötige Kurven weglassen?
Mein Akku ist nur äußerst selten randvoll, ich habe leider weder Daten (hallo mariadb) noch Erinnerung an das Verhalten bei vollem Akku.
Hier mal 3 Zacken ausgeschnitten inkl. ein bisschen Zeit davor wo er noch "normal" geladen hat.
Scheint irgendwie schon Logik hinter zu sein, aber optimal wirkt das nicht. Sobald er über die Saturation Charging Voltage (> 55.5V) geht, beginnt das Spiel.
Optimal wohl nicht, aber alternativlos, mutmaße ich mal.
Solange die Ladeschlussspannung korrekt eingestellt ist (oder etwas niedriger) ist das schon gut so.
Die Spannung im Akku fällt nun mal ab, wenn er nicht mehr geladen wird.
Hallo @lupenrainer, könntest du mal deine - jetzt stabile? - Umsetzung mit dem Shelly dokumentieren?
Jo gerne. Ist zwar leider noch nicht sauber programmiert und viel zu komplex gemacht aber es funktioniert. Muss es wenn ich Zeit habe mal aufräumen und weniger komplex machen. Sind viele redundante Abfragen drin und auch die Parameter sind teilweise "Magic Numbers" und nicht in Variablen drin. Also bitte nicht auf die Form des Codes im aktuellen Zustand schauen sondern auf die Funktion die dahinter liegt.
2. Das Shelly Gerät / die Shelly Geräte im Python Script anlegen (Beim mir sind es die zwei Shelly Plug S Schaltsteckdosen an denen die Ladegeräte angeklemmt sind:
3. Dann kommt die eigentliche Logik. Für ein Netzteil sieht es wie folgt aus:
Einschalten wenn:
- PV-Überschuss größer ist als das was das Netzteil braucht UND
- aktueller Ladestrom der Batterie gerade kleiner ist als der Maximale Ladestrom + das was das Netzteil brauchen würde (Wie unten z.b. battery_current + 4 A die das 240W Netzteil braucht)
- Die aktuelle Batteriespannung kleiner ist als ein bestimmter Wert der nahe an der Saturation Charging Voltage liegt -> Um dem Laderegler am Ende nicht in die Quere zu kommen
- das Gerät mindestens schon z.B. 10s lang ausgeschaltet war (Um ständiges Ein- und Ausschalten zu vermeiden - Rudimentäre Hysterese)
- Send_power <= 0 (Also Wechselrichter Sollwert = 0) -> Damit die NEtzteile nicht anbleiben wenn der Regler auf 0 Zähler regelt
(Sofort) Ausschalten wenn:
- Zählerleistung größer ist als ein bestimmter Schwellwert ( >0 wäre die logische Wahl aber ich möchte da etwas "Puffer" haben damit er nicht direkt ausschaltet wenn es mal etwas über 0 geht)
- Ladestrom des Ladereglers + Netzteilstrom (fester Wert, wird nicht gemessen) größer ist als der maximal zulässige Ladestrom
- Batteriespannung größer ist als ein bestimmter Wert
- Send_power >= 0 (Also Wechselrichter Sollwert = 0) -> Damit die NEtzteile nicht anbleiben wenn der Regler auf 0 Zähler regelt
4. (Optional): Bei zwei oder mehr Netzteilen kann man dann noch verschiedene Stufen einstellen. Mein Beispiel unten ist für ein Netzteil mit 240W und ein Netzteil mit 600W (Ausgangsleistung)
- Nur Kleines 240W Netzteil einschalten wenn Zählerleistung < -280W
- Nur Großes Netzteil einschalten wenn Zählerleistung < -680W
- Beide Netzteile einschalten wenn Leistung < -960W und kleines Netzteil bereits mindestens 5s an ist (damit das BMS nicht direkt einen großen Strompeak beider Netzteile beim einschalten sieht)
if Relay2_Status == 1:
battery_cur += 10
if ((Ls_read < -280 and Ls_read > -580) or Ls_read < -860) and (battery_cur + 4) < max_bat_charge_cur and bat_cont < 54.5 and send_power <= 0: #Check if overfeed is higher than charger power (with offset) and if actual charging current is below maximum charge current
Relay_Time_Off = time()
if (Relay_Time_Off - Relay_Time_Off_Start) > 10:
if Relay_Status == 0:
device.relay(0, turn=True )
Relay_Status = 1
Relay_Time_Off = 0
Relay_Time_Off_Start = 0
Relay_Time_On = time()
else:
if (Relay_Status == 1 and Ls_read > 30) or (battery_cur + 4) > max_bat_charge_cur or bat_cont > 54.5 or send_power >= 0:
device.relay(0, turn=False )
Relay_Status = 0
if Relay_Time_Off_Start == 0:
Relay_Time_Off_Start = time()
if Relay2_Status == 1:
battery_cur -= 10
if Relay_Status == 1:
battery_cur += 4
if Ls_read < -580 and (battery_cur + 10) < max_bat_charge_cur and bat_cont < 54.5 and send_power <= 0: #Check if overfeed is higher than charger power (with offset) and if actual charging current is below maximum charge current
Relay2_Time_Off = time()
if (Relay2_Time_Off - Relay2_Time_Off_Start) > 10 and (time() - Relay_Time_On) > 5:
if Relay2_Status == 0:
device2.relay(0, turn=True )
Relay2_Status = 1
Relay2_Time_Off = 0
Relay2_Time_Off_Start = 0
Relay_Time_On = 0
else:
if (Relay2_Status == 1 and Ls_read > 130) or (battery_cur + 10) > max_bat_charge_cur or bat_cont > 54.5 or send_power >= 0:
device2.relay(0, turn=False )
Relay2_Status = 0
if Relay2_Time_Off_Start == 0:
Relay2_Time_Off_Start = time()
if Relay2_Status == 1:
battery_cur += 10
if verbose:
print("Battery_Current = ", battery_cur )
print("Relay_Status = ", Relay_Status)
print("Relay2_Status = ", Relay2_Status)
Update: Viele Änderungen da ich es erst heute richtig mit zwei Netzteilen testen konnte. Ganz schön gefrickelt aber das hatte ich ja oben schon erwähnt.
Hier an der "violetten" Kennlinie sieht man wie das Netzteil fröhlich an- und aus geht je nachdem wie viel Überschuss ich gerade habe:
Achso 😀 Sorry. Ich war gerade in der anderen Implementierung unterwegs mit meinen Schaltsteckdosen.
Es geht hier darum auch den Überschuss meiner großen PV-Anlage in die Batterie laden zu können. Dazu habe ich zwei 48V Netzteile von Aliexpress die bei Überschuss über die Shelly Plug S Stecker mit dem Script variabel an- und ausgeschaltet werden. Mit einem regelbaren Netzteil wäre es natürlich noch schöner aber so funktioniert es auch schon echt gut. Aber danke für den Hinweis dass @joehuebner sowas hat.
Mit dem Shelly 3EM kann ich am Wochenende hier rein packen da das Script bei meinem Vater läuft. Ist aber super easy und funktioniert genauso wie bei den Schaltsteckdosen von Shelly über die Rest-Api und kann auch genauso in die Vzlogger.conf eingetragen werden. Nur dass der identifier glaube ich total_power heist und nicht unter ../meter/0 zu finden ist sondern woanders. Aber das schaue ich wie gesagt nach.
In deinem Script musste ich dann auch nur die Zeile wo er nach "1-0:16.7.0" sucht dann durch den identifier ersetzen wie er vom vzlogger für den Shelly 3EM geschrieben wird. (Also "total_power" glaube ich)
beim lesen der Betriebsanleitung für den esmart3 ist mir gerade aufgefallen dass dort eine ausdrückliche Warnung steht dass man den Wechselrichter nicht an den Lastausgang des esmart3 hängen soll sondern direkt an die Batterie.
Weisst du was es damit auf sich hat? Bei dir funktioniert es ja am Lastausgang, frage mich nur was der Hintergrund davon ist und ob man auf irgendwas achten muss.
Grundsätzlich ist das richtig, der WR sollte (hinter einer Sicherung) an einer möglichst kurzen Leitung an der Batterie hängen.
Zum einen, wegen der Verluste, aber eben auch um die Schutzschaltungen des Inverters zu ermöglichen. z.B: Lüfternachlauf bei Überhitzung.
Der Soyosource Netz-WR am Lastausgang ist ein Sonderfall, weil er durch die Wechselstromanbindung eine alternative Energiequelle zusätzlich zum Akku hat.
Kappt der esmart3 den Lastausgang, dann ist das für den Soyo kein Problem, er speist halt nur nicht mehr ein, aber er bleibt operabel.
Mein script hat extra ein Lastbegrenzung für den Batteriestrom, als auch die Leistungsanpassung für sinkende Batteriespannung.
Betreibt man das script mit sinnvollen Werten, wird der esmart niemals(!) den Lastausgang abschalten.
Zufällig habe ich damit zuletzt experimentiert und den Lastabwurf erzwungen, den (die) Soyo hat das nicht gestört.
Fazit: Inselwechselrichter abgesichert (direkt) an die Batterie. Es sei denn, man weiß was man da tut.
Du glaubst gar nicht, wie lange ich das Internet nach dieser Antwort abgesucht habe.. Falls man über Google überhaupt mal was findet, dann nur zu 2-3kW Wandlern mit noch höherem Peak und der Begründung, dass da die Ströme nicht mehr vom LC gehandelt werden können. Kleine 600W Wechselrichter - die bei 48V ja nur ca. 13A ziehen und selbst bei 24V noch vom kleinsten esmart3 ausgelastet werden können, werden nie besprochen. Bei einem 48V-Setup könnte man sogar noch den kleinsten Victron (SmartSolar 100/20) als Laderegler nutzen. Hat das zufällig schonmal jemand probiert?
Die Erklärung mit der Notabschaltung (bei Überhitzung) macht hier natürlich deutlich mehr Sinn. Auch die Unterscheidung von Netz-Wechselrichtern und Insellösungen scheint mir hier absolut notwendig zu sein, um ein (dein) Setup sauber zu argumentieren.
Allgemein kann man daraus doch ableiten, dass man dann jeden Micro-Inverter für ein BKW an den Last-Ausgang eines LCs schalten kann (solange die Spezifikationen eingehalten werden), oder? Das erscheint mir sowieso als einzig wirklich sinnvolle Lösung. Andernfalls müsste ich bei kritischem SOC der Batterie den Inverter mittels zusätzlicher Schaltung von der Batterie trennen. Darüber hinaus wird bei niedriger Grundlast und voller Batterie diese doch auch ständig im obersten Spannungsbereich Be- und entladen. Das sind irgendwann auch viele Zyklen und höher wird der Wirkungsgrad dadurch doch auch nicht. Also warum machen das so wenige? Übersehe ich was?
Diese r Beitrag wurde geändert Vor 1 Jahr von aaron_wnklr
Allgemein kann man daraus doch ableiten, dass man dann jeden Micro-Inverter für ein BKW an den Last-Ausgang eines LCs schalten kann (solange die Spezifikationen eingehalten werden), oder?
Das erscheint mir sowieso als einzig wirklich sinnvolle Lösung. ... Übersehe ich was?
Micro/Modulwechselrichter kommen in meinem Beitrag nicht vor! Das ist eine ganz eigene Gattung.
Man kann sicherlich Last im Rahmen der Spezifikation der Geräte am Laderegler schalten lassen, aber:
Modulwechselrichter sind nicht dafür gemacht, an einem geschalteten Akku zu hängen!
Ich halte es für die schlechteste Lösung, einen Wechselrichter überhaupt "schalten" zu wollen!
In dem zitierten Beitrag sind Maßnahmen skizziert, die genau das verhindern sollen.
Meine hier gezeigte Lösung für eine kleine, günstige PV mit Akku dürfte im Funktionsumfang schon sehr nahe am Optimum sein.
Kernpunkte sind:
Nulleinspeisung
Leistungsanpassung an den Akku
Direktes einspeisen von PV-Leistung (ohne Verwendung vom Akku)
Monitoring
Eine detaillierte Überwachung einer Selbstbau-Anlage ist Pflicht!
Wer nur bei Gelegenheit irgendwelche Displays abliest, hat keine Ahnung was die Anlage macht.
Micro/Modulwechselrichter kommen in meinem Beitrag nicht vor! Das ist eine ganz eigene Gattung.
Man kann sicherlich Last im Rahmen der Spezifikation der Geräte am Laderegler schalten lassen, aber:
Modulwechselrichter sind nicht dafür gemacht, an einem geschalteten Akku zu hängen!
Deswegen wollte ich das Thema gerne noch anreißen, denn (Stand 23.03.23) sind mir keine WR bekannt, die auf 600W Dauerleistung limitiert sind und gleichzeitig keine Modul-WRs sind. Kennst Du einen? Das Problem, solche WRs hinter einem Akku (oder auch am Lastausgang) zu betreiben ist ja meistens der verbaute MPPT.
...mir keine WR bekannt, die auf 600W Dauerleistung limitiert sind und gleichzeitig keine Modul-WRs sind. Kennst Du einen?
Du suchst also einen (nicht Micro-) WR den man beim deutschen VNB vereinfacht anmelden und aber auch regeln kann?
Ich kenne keinen. 😪
Allerdings dürfte der (halbwegs?) regelbare HM-600 nicht so viel Eigenverbrauch im Leerlauf haben, so das man ihn gar nicht hart an- und abschalten müsste. Fragt sich nur wie das mit der Regelung und dem Akku läuft. Dafür gibt es hier im Forum einige Themen!
Allerdings dürfte der (halbwegs?) regelbare HM-600 nicht so viel Eigenverbrauch im Leerlauf haben, so das man ihn gar nicht hart an- und abschalten müsste. Fragt sich nur wie das mit der Regelung und dem Akku läuft. Dafür gibt es hier im Forum einige Themen!
Ich habe gestern tatsächlich eine interessante Konversation hier im Forum gefunden. Man kann den Hoymiles wohl zur Nulleinspeisung nutzen, allerdings ist das nur bei 48V Akkusystemen wirklich brauchbar, weil bei 24V die eingestellte Leistung nicht gehalten wird. Auch muss beim Anschluss des Akkus an die beiden Eingänge des HMs penibel darauf geachtet werden, dass die Leitungswiderstände identisch sind.
Wie gut ist es bei deinem Programm möglich, die Regelung des HM zu implementieren. Wäre dann über openDTU und MQTT (wenn ich nicht komplett auf dem Holzweg bin). Bin zwar mit Wireless nicht ganz happy, aber der HM kann das nicht anders.
Darüber hinaus wäre auch interessant, wie man einen Victron Laderegler integrieren kann. Es gibt einen Fork von openDTU, bei dem die Kommunikationsschnittstelle VE.direct von Victron bereits integriert ist. Alle Informationen werden dann zentral von der openDTU Instanz per MQTT (oder HTTP) bereitgestellt. Wenn man deinen Regelungsalgorithmus damit füttern könnte, wäre das ziemlich gut. Im Prinzip bräuchte man ein weiteres Tool, was die Informationen über MQTT abholt und im bisherigen Format ablegt und eben die Steuerung des HM via MQTT.
Wie gut ist es bei deinem Programm möglich, die Regelung des HM zu implementieren.
Darüber hinaus wäre auch interessant, wie man einen Victron Laderegler integrieren kann.
Mein script ist im kompletten Quellcode veröffentlicht, da kannst du beliebig alles dran ein und umbauen.
Ein paar Seiten weiter vorne ging es schon mal um Victron Regler. Inzwischen weiß ich aber, das mein eSmart3 die vorhandene Anlage gut bewerkstelligt, deshalb werde ich nicht erweitern. (Nachtrag: die Nächste Erweiterung führte zum 2. eSmart3...)
Ich würde die Victron Geräte direkt über eine serielle Verbindung anschließen und auslesen, ganz so wie es mit dem eSmart3 gemacht wird.
Zum HM-x und xDTU etc. kann ich auch nur schreiben: ich würde nur den wirklich wesentlichen Code übernehmen und alles überflüssige weglassen, also wirklich nur die Leistungsvorgaben senden.
MQTT nur zum "schreiben" einsetzen, wenn nötig. Es zeigt sich immer wieder, das schlanker Code ohne viel Überbau stabiler ist.
Wenn mir einer einen HM-x spendet, implementiere ich das gerne. Vermutlich ist eine Parallelschaltung zu den soyosource Invertern aber nicht sinnvoll, müsste man testen.
Der Weg ist: Die relevanten Code-Teil isolieren, testen und integrieren.
Ich würde die Victron Geräte direkt über eine serielle Verbindung anschließen und auslesen, ganz so wie es mit dem eSmart3 gemacht wird.
Würde ich auch so machen. Die Erweiterung von der openDTU von helgeerbe ( https://github.com/helgeerbe/OpenDTU-OnBattery ) vereint den seriellen Anschluss des Victron Ladereglers mit der 2.4GHz Schnittstelle des HMxxx. Theoretisch könnte man sogar den Regelalgorithmus direkt da mit implementieren.
Zum HM-x und xDTU etc. kann ich auch nur schreiben: ich würde nur den wirklich wesentlichen Code übernehmen und alles überflüssige weglassen, also wirklich nur die Leistungsvorgaben senden.
MQTT nur zum "schreiben" einsetzen, wenn nötig. Es zeigt sich immer wieder, das schlanker Code ohne viel Überbau stabiler ist.
Eigentlich wollte ich einen RaspberryPi als Zentrale nehmen, also zum Einlesen der Informationen von der openDTU Instanz (über MQTT) und senden der Zielleistung für den HM (auch MQTT). Mir fehlt das Wissen, wie ich Deinen Algorithmus direkt in das Image von openDTU einpflegen kann. Darüber hinaus wäre ein Raspi auch für die Remote Steuerung nötig, da ich einen VPN Zugang zu dem Netzwerk brauche.
Wenn mir einer einen HM-x spendet, implementiere ich das gerne. Vermutlich ist eine Parallelschaltung zu den soyosource Invertern aber nicht sinnvoll, müsste man testen.
Ich werde mir demnächst einen holen und ein bisschen damit rumspielen. Habe vor, erstmal ohne Speicher eine Nulleinspeisung zu realisieren. Der Zähler in der UVK wird bald eingebaut, sodass ich ja den WR schon entsprechend ansteuern kann. Die überflüssige Energie wird dann zwar nicht gespeichert, aber was solls 😀
Ob es sinnvoll ist, hängt ja von deinen Gegebenheiten ab. Funktionieren sollte es ganz grundsätzlich aber schon.
Den Hoymiles habe ich mal vermessen um die Eignung für ein solches System zu untersuchen. (Batt bzw, Netzteil-> Hoymiles). Bin jetzt nicht mehr allzuweit davon weg das auch komplett in Betrieb zu nehmen.
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
😀 Sorry. Ich war gerade in der anderen Implementierung unterwegs mit meinen Schaltsteckdosen. 
