Zweite Begrenzung des Dynamic Power Limiters - Entladung des Akkus während der Ladephase vermeiden

[SummerMeansFun]

Hallo und zunächst herzlichen Dank für die hervorragende Arbeit. Dieses Projekt erfüllt schon jetzt fast alle meine Wünsche.

Ich habe folgendes Setup: 3 Paneele zu 385Wp in Reihe an einem EPever Xtra 4415N. Dieser speist einen Pylontech US5000, an den ein HM-350 angeschlossen ist. Ein Hichi-Lesekopf übermittelt die Strombezugswerte an die DTU, die diesen dynamisch auf 0 bringt. Seit ca. 14 Tagen läuft das mit eingebundenem Pylontech ziemlich reibungslos. Da der EPever allerdings von OpenDTU-OnBattery nicht unterstützt wird, stehen keine Daten vom Laderegler zur Verfügung.

Meine aktuelle Herausforderung:
Auf einen sonnigen Tag folgt ein wolkiger. Der Akku war am Abend voll und die DTU hat den Hoymiles am Morgen noch nicht ausgestellt (da SOC noch > 20%). Über die Paneele kommt wegen der Wolken mal viel (Akku wird geladen), dann aber wieder fast nichts rein. Dann liegt der Strombedarf zeitweise über dem, was die Panele hergeben. In der Folge wechselt der Pylontech ständig von "wird geladen" zu "wird entladen", denn die DTU deckt ja den momentanen Verbrauch ab und lässt den HM sich so viel nehmen, wie dafür nötig ist, solange SOC nicht unter 20% rutscht. Soweit ich informiert bin, wirkt sich dieser ständige Wechsel vom Laden zum Entladen aber äußerst negativ auf die Lebensdauer des Akkus aus.

Mein Wunsch wäre daher eine Möglichkeit, durch eine weitere Begrenzung des dynamisch Limiters den Stromfluss in den Akku (den teilt der Pylontech ja über CAN mit) während der Ladephase (SOC < 85%) in einem positiven Bereich zu halten, z.B. Minimum +1 A und eben nur den "Rest" des vom Laderegler erzeugten Stroms zum Decken des aktuellen Strombedarfs zu nutzen.

Weiterhin könnte man - analog zu Solar-Passthrough - die DTU auch versuchen lassen, ab einem hohen SOC, z.B. > 90%, weiteren möglichen Ladestrom in den Akku zu unterbinden und stattdessen den HM hochzufahren.

Soweit erstmal vielen Dank fürs Lesen und viele Grüße,
Sven

[helgeerbe]

Hallo Sven,

erst mal Danke für dein Feedback. Ich fürchte es wird schwierig, alle möglichen Anwendungsfälle und jede Art von Konfiguration zu berücksichtigen. Ggf. solltest du doch über eine Heimautomatisierung ein eigenes Skript erstellen, dass genau deinen Bedürfnissen entspricht.

Dein letzter Punkt ist in der aktuellen Version schon verfügbar "Battery SOC - Start threshold for full solar passthrough ". Wenn du den Wert auf 90 setzt, und die Batterie 90% überschreitet, wird die Leistung der Panels an den Inverter gegeben. Aber auch hier fehlt dir wieder die Info vom Laderegler, der dir sagt, wie viel Leistung überhaupt von den Pannels kommen.

[uli-bs]

Ich habe hier ein etwas anderes Konzept:
4x 375W Module, davon sind 2 fest mit dem 4 kanaligen "main" WR (Deye 1300, war vorhanden) verbunden
die anderen beiden werden einzeln, durch eine Relaismatrix bedarfsgesteuert, mit dem "main" WR verbunden oder getrennt.
Im "getrennt" Zustand der Paneele wird über die Relais eine Verbindung dieser zu einem EPEVER hergestellt (1 o. 2 parallel), der seinerseits einen LiFePO4 Akku speist und dieser geht dann über einen geregelten HM-600 ins Netz. Der Lastausgang des EPEVER selbst ist unbenutzt.

Bei max. Sonne und etwas Vorlauf (für den Akku), komme ich so auf max. ca.1200W vom Deye + 480W vom HM (z.B. für Waschmaschine o.ä.) und im Min bei max Sonne ca 590W aus 2 Modulen ins Netz und ca. 500W (20A) Input für den Akku.
Der HM versucht dabei immer die Differenz bis zum eingestellten Limit auszugleichen, wobei vorrangig 2-4 Panel am Deye hängen.

[madmartin]

... EPever Xtra 4415N...

Das gute Stück verfügt laut Info auf dem einen Shop wo ich den gefunden habe über eine "RS485-Schnittstelle mit MODBUS-Industriestandard"

Wie wäre es diese hier als addon zu programmieren?

... wechselt der Pylontech ständig von "wird geladen" zu "wird entladen" ... wirkt sich dieser ständige Wechsel vom Laden zum Entladen aber äußerst negativ auf die Lebensdauer des Akkus aus.

Wer sagt das? Und vor allem: liegt hier möglicherweise eine Verwechslung der Akkutechnologie vor?
Soweit ich weiß trifft das auf NiCD, NiMH und alle Blei-Akkus zu, bei den Blei-Akkus variiert es je nach Unter-Typ (AGM, flüssige Säure etc). Und nicht für Lithium-basierte Zellen.
Bei Lithium-basierten Zellen kommt es vor allem darauf an den Ladezustand in der "Komfort-Zone" 20-80% Ladezustand zu halten sowie den recht engen Temperaturbereich von ~5 - 40 Grad Celsius.

[uli-bs]

EPEVER...
ich lese das Ding mit ESP-easy und einem RS485 Konverter aus und gebe die Daten per MQTT weiter an die HA
ein weiters Projekt dazu gibt es unter https://github.com/KlausLi/Esp-Epever-Controller damit ließen sich die relevanten Daten auch per HTTP Request parsen.

[SummerMeansFun]

Zunächst herzlichen Dank für die rege Teilnahme an der Diskussion.

@helgeerbe Ich kann gut verstehen, dass Du hier nicht alle Eventualitäten abdecken kannst und willst. Da würde man mit dem ESP32 auch schnell an die Grenze des Machbaren kommen. Ich probiere auch mit Heimautomatisierung herum, (OpenHab, HomeAssistant), tu mich als Fast-DAU damit aber schwer und war von deiner Lösung, das alles in einem ESP zu vereinen begeistert - insbesondere, da mein Wlan zickig ist und einzelne Geräte dann manchmal nicht erreichbar sind.

@madmartin

... EPever Xtra 4415N...
Wie wäre es diese hier als addon zu programmieren?

Das wäre natürlich ein Traum, dann wäre die gesamte Berechnungslogik schon vorhanden - ich kann es aber nicht und hab mich erst gar nicht getraut, danach zu fragen.

Wer sagt das? Und vor allem: liegt hier möglicherweise eine Verwechslung der Akkutechnologie vor?

Ich bin auch da kein Experte. Ich beziehe mich auf eine Kritik von "Der Kanal" in einem kürzlich veröffentlichten YT-Video zum "Zendure Solar-Flow", dessen Regelung den Akku in vollem Zustand auch ständig von laden zu entladen wechseln lässt. Auch da kommt LiFePo4 zum Einsatz und der Typ scheint m.E. vom Fach zu sein.

@uli-bs Ich kenne zumindest das Projekt von KlausLi und habe die Hardware dafür auch schon herumliegen, um das aufzubauen. Es bliebe aber immer noch das Problem, die Daten hier zu integrieren und den HM entsprechend zu regeln.

Alternativ müsste die Regelung über Openhab/HA stattfinden mit dem Risiko, dass einzelne Komponenten dann mal nicht erreichbar sind und das Ganze aus dem Ruder läuft. Genau das wollte ich eigentlich vermeiden, denn dieses Projekt ist eigentlich die optimale Stand-Alone-Lösung.

[madmartin]

Habe zum Thema Modbus noch diesen PR tbnobody#582 entdeckt. Ich schätze die Chancen für einen Merge bei tbnobody eher gering ein, so chaotisch wie der PullRequest aussieht, aber vielleicht ist es inhaltlich ein Anfang falls sich jemand mit Modbus beschäftigen möchte.