Für die max. Entladung / min. Reserve-Kapazität für ESS gibt es bereits sehr gut funktionierende Controller.
Ich bin heute über eine Studie gestolpert, die, völlig entgegengesetzt der landläufigen Meinung, aussagt, dass man auch einen LFP-Akku nicht auf 100% laden sollte. Zumindest nicht regelmäßig. Ab und an aber schon um die Batterie zu kalibrieren.
Dokumente zur Studie hänge ich noch an.
Aber es gibt hier sicher auch einige Batterie-Experten die etwas dazu sagen können.
Würde denn Interesse an so einem Controller bestehen? Ich würde mich mal damit beschäftigen wollen - am liebsten in Co-Produktion.
So etwas wie: lade/entlade ESS von 20-90%, aber alle X Tage bis auf 100% (Kalibrierung).
Was meint ihr?
Die physikalischen Eigenschaften der Batterie sind natürlich Hersteller-abhängig. Aber grundsätzlich ist die Behandlung der Zellen zumindest ähnlich.
Das Video ist ein bisschen reißerich, aber die Fakten scheinen zu stimmen.
100% SoC: Nach meinem Verständnis muss ein BMS bis 100% Laden um überhaupt alle Zellen ausgleichen und messen zu können. Mein Tesla sagt mir auch, dass ich mindestens 1 x pro Woche auf 100% laden muss.
Schwierig wird es, wenn die 100% über längere Zeit bleiben und keine Entladung stattfindet
0% DoD: Die Tiefentladung verhindert das BMS. Da gehe ich mal fest von aus.
wie du schon schreibst ist das grundsätzliche Verhalten von Batteriezellen zwischen den Herstellern nicht groß unterschiedlich. Diese fühlen sich so zwischen 30% - 80% geladen am wohlsten.
Wie du schon gesagt hast, verhindert das BMS in kommeriziellen Systemen ab der Größe, das es für den Hausgebrauch sinnvoll ist immer selbstständig, das die Zellen in Kritische Zustände kommen, sei es jetzt eine Tiefentladung oder auch eine Überladung oder eine zu hohe Laderate, notfalls durch Abschalten des Speichers.
Allerdings gibt es dabei zwischen den Herstellern doch Unterschiede, indem sie die nutzbare Kapazität begrenzen, sprich die Zelle hat zwar z.B. 50Ah, allerdings lassen sich durch das BMS nur 45Ah nutzen, da die Randbereiche bereits grundsätzlich gesperrt sind. Das ist aber eher bei den höherwertigen Herstellern zu finden, da sich dadurch die Zyklenfestigkeit und kalendarische Lebensdauer erhöhen lässt, gleichzeitig aber das Verkaufsargument Kapazität etwas sinkt.
Für das Balancing muss nicht zwangsläufig ein Zustand von 100% SoC vorherrschen, da gibt es auch Strategien um bei 0% SoC oder bei jeden belieben dazwischen auszugleichen. Tatsächlich habe ich aber auch den Eindruck, das hauptsächlich das Top Level Balancing umgesetzt wird, da es einfach und zuverlässig ist. Wie oft und wie viel gebalanced werden muss ist dagegen von der Qualität der Zellen abhängig.
Von dem her finde ich die Idee mit einem Controller der genau das vorgibt ziemlich gut um einfach die Lebensdauer zu erhöhen. Ich denke aber das er vermutlich nicht zu oft eingesetzt wird, da die meisten wahrscheinlich einen Speicher besitzen, der von der Kapazität gut auf den Anwendungsfall abgestimmt ist und eher selten zusätzliche Kapazitäten vorhanden sind.
Tendenziell würde ich mich da schon gerne mit einbringen, habe aber bisher noch nichts in der Komplexität in OpenEMS programmiert.
Hallo @Josef ,
Danke für den Input. Das mit dem Balancing um die 0% kannte ich noch nicht. Klingt aber alles andere als zweckfrei!
Zu den Batterien die ich bisher zwischen hatte, gab es durch die Bank die Ansage regelmäßig auf 100% zu laden. Bisher Pytes, Pylontech in Verbindung mit Victron, SolarEdge und halt Tesla - alles LFP.
Da ich selbst nicht der große Java-Programmierer vor dem Herrn bin, wäre mir ein Co-Autor mit OpenEMS-Erfahrung recht - aber jemand mit praktischer Expertise beim Thema Batterie-Technik passt doch prima!
Auch wenn die Java-Kenntnisse nicht berühmt sind, hab ich doch mitterweile einigermaßen Einblick in das Thema OpenEMS. Ich verrenne mich oft halt in Strategien, die man sicherlich auch besser lösen könnte. Wennn Du Lust hast, können wir uns da gerne zusammentun. Gerne teile ich auch mein bescheidenes OpenEMS-Wissen. Letzten Endes ziehen wir alle am selben Strang.
Konkret habe ich einen größeren Industriespeicher und meine eigene Heimanlage im Visier. Bei letzterer werde ich kurzfristig auf 30kWh (brutto) aufrüsten - bei den Speicherpreisen…
In der Firma ist Kapazität auch nicht das Riesenthema. Lange Lebensdauer dann doch eher. Ausfallzeiten und die damit verbundenen Lohnkosten sind hingegen durchaus ein Thema.
Netto nutze ich zu Hause von 20-100% - was nach dem aktuellen Kenntnisstand ja nicht optimal für die Lebensdauer ist. Daher auch so ein bisschen die Frage was an dieser Stelle sinnvoll ist und welche Faktoren die Alterung am meisten beeinflussen: Temperatur, übliche Lade-/Entladeströme, min/max SoC, Zyklen, usw.
Da in den Kellern, bzw. Industrieanlagen zumeist zwischen 15 und 35° vorherrschen, wird man das Thema Temperatur wohl außer Acht lassen können.
Als ersten Ansatz würde ich daher beim weiter oben skizzierten bleiben wollen.
sorry für die späte Rückantwort. Für die Anlagen die du beschreibst kann ich mir so einen Controller auch recht gut vorstellen und würde mich da auch an einer Programmierung beteiligen. Ich suche aktuell eh nach einer neuen Funktion die ich aufbauen könnte. Allerdings habe ich da bisher einfach noch deutlich weniger gemacht wie du.
Da hast du ja die wichtigsten schon aufgezählt. Ein niedriger Strom ist da natürlich immer gut, die Temperatur bei deinen 15°C - 35°C eigentlich auch ideal und die SoC könnten man ja dann mit dem Controller begrenzen. Die Zyklenzahl ist ja eigentlich das was dadurch erhöht werden soll wenn die Alterung begrenzt wird.
Aktuell habe ich das Glück einen studentischen Praktikanten hier zu haben, der daran mitarbeiten kann. Wir beschäftigen uns gerade noch mit der Einrichtung und den ersten Schritten im OpenEMS.
Sobald wir was haben, melde ich mich.
Wir haben mal etwas Brain-gestormt:
Eingangs-Parameter (config):
min. -Grenze (ähnlich emergency reserve)
max. -Grenze
Interval (als Einheit wahrscheinlich Tage bis zum nächsten 100% SoC)
Nach Ablauf des Intervals würde die max.-Grenze dann einfach deaktiviert. Jetzt wird es etwas “schwammig”: Im einfachsten Fall würde die Obergrenze für die Beladung wieder aktiviert, wenn das ESS auf 100% war. Sinnvollerweise hält man das ESS dann für mehrere Stunden bei 100%.
Dies ist aber für den Heimanwender unpraktikabel. Der will seinen Speicher ja nutzen und würde sich über einen “defekten” Speicher ärgern.
In einer Industrieanwendung würde ich das allerdings genau so machen.
Man muss jetzt auch so ein bisschen im Hinterkopf haben, dass bei vielen Heim-Speichern die 100% über den Winter wahrscheinlich nie erreicht werden. Insofern wäre die skizzierte Strategie nicht “falscher” als die Realität.
Das Intervall würde ich nicht über ne Zeit sondern lieber über die geladene Energiemenge umsetzen.
Das hätte denn Vorteil, das nur der tatsächliche Einfluss auf die Inkonsistenzen auch als Parameter genutzt wird, die Zeit ist ja erstmal egal wenn der Speicher zwischenzeitlich z.B. nur gering im Einsatz war.
Nach dem Intervall würde ich ähnlich wie du vorgehen und einfach die obere SOC Grenze aufheben bis voll geladen wurde. Dann würde ich aber lieber eine weitere konfigurierbare Zeit warten, bis die Grenze wieder gesetzt wird. Das hätte den Vorteil, das der Speicher sich etwas im Grenzbereich von 100% SoC bewegen könnte.
Dazu als Hintergrund:
Wenn man ein passives Balancing hat, was für die meisten Systeme ja ausreichend ist, wird bei einer Balancingvorgabe durch z.B. verschiedene Spannungen in den Einzelzellen ab einem gewissen Spannungswert einfach ein kleiner Lastwiderstand dazugeschaltet, damit diese Zelle nicht so schnell geladen wird und die anderen aufholen können. Der Speicher als ganzes läd aber weiter. Sobald dann die erste Zelle die Abschaltspannung erreicht hat, wird die Ladung eingestellt und es findet kein Balancing mehr statt, egal ob alle Zellen ausgeglichen sind oder nicht. Entsprechend wäre es dann hilfreich die z.B. in den oberen 5% SoC pendeln zu lassen um ihn vollständig zu balancen. Das tritt vor allem auf, wenn der Speicher schon lange nicht mehr in diesen Zustand gekommen ist (z.B. Lagerung/ Winter oder nur mittlerer Ladezustand).
Danke für die Fakten. Das war mir so nicht klar.
Wahrscheinlich werden wir die Lade-Energie aber selbst berechnen müssen. Nicht jede ESS-Implementierung hat einen “unendlichen” Zähler für ChargeEngery.
Da sieht man mal wieder, dass das alles gar nicht so einfach ist.
Zum Glück gibt es im OpenEMS für ESS einen Scheduler über den man Prioritäten festlegen kann. Z.B. Peakshaving nicht betreiben zu können weil der Speicher gerade mit Balancing beschäftigt ist, wäre ein NoGo.
Ich denke auch mal, dass Transparenz hier nicht unwichtig ist. Speziell UI-Programmierung fällt mir allerdings schwer.
Ja genau, der minimale Vorteil den man damit hat das die Kapazität einfach länger erhalten bleibt, rechtfertigt auf keinen Fall ein notwendiges Peakshaving zu unterlassen.
Wie kann ich mich denn dann am besten mit einbringen? Ich betreibs halt aktuell etwas als Hobby, da ich mich in meiner MA viel mit OpenEMS beschäftigt hab und es aktuell einfach als sinnvollen Zeitvertreib seh bis ich ne Arbeitsstelle bekomme.
Ich hoffe, dass wir heute das Grundgerüst fertig kriegen, dann werde ich das mal mit meinem Kollegen besprechen. Denke, wir geben Dir einfach Schreib-Zugriff auf den Fork.
Melde mich
EDIT: Wir haben einen Branch vom OpenEMS develop erzeugt:
feature/chargeDischargeLimiter
Für GitHub bin ich definitiv zu doof, aber Du müsstest auf diesem Branch auch arbeiten können, da public.
…ist alles schon ein bisschen her. Ich vermute, Du brauchst zusätzliche Rechte, um an einem branch mitarbeiten zu können. Was wir aber machen können: ich erstelle einen neuen fork und richte entsprechende Zugänge ein.
Hoffe, ich komme morgen dazu. In meinem aktuellen fork ist noch nichts dazu.
Wir sind aber, rein von der Logik, schon recht weit. Das Thema UI haben wir aber noch nicht angepackt.
Ich habe nun eine neue Organisation erstellt um einen weiteren Fork von OpenEMS ziehen zu können.
Einladungen an Dich und meinen Kollegen sind raus. Ich versuche heute noch die bisherige Entwicklung zu pushen.
Die Logik des Controllers ist schon ziemlich weit fortgeschritten. Bei der Umsetzung in´s UI ist mir aufgefallen:
Ui, das wird kompliziert…
Wenn ich mir den EmergencyReserve-Controller als Vorlage anschaue stelle ich fest, dass dieser mit ziemlich vielen Stellen im Code verwoben ist. U.a. werden Controller dieser Art auch im TimeOfUse-Controller abgefragt. Also müsste mein Controller dort ebenfalls eingebunden werden.
Da stellt sich die Frage, ob die ganze Geschichte nicht eine Todgeburt wird und ob überhaupt eine Chance besteht, dass der spätere PullRequest angenommen wird. @stefan.feilmeier : Vielleicht könntest Du dazu ein kurzes Statement posten?
Gruß,
klinki
PS: “Todgeburt” ist relativ: Einsetzen werde ich den Controller so oder so (müssen). Ich fände es halt gut, wenn alle etwas davon hätten und die Entwicklung nicht nur in meinem Fork “vor sich hin schimmelt”. Die Sammlung an wartenden PRs macht es immer aufwändiger up-to-date zu bleiben
Ich bin mittlerweile recht weit. Auch beim Thema UI. @josef: Hast Du Möglichkeiten das Ganze mal zu testen?
Wie weit gehen Deine Programmierkenntnisse? Es fehlt noch “schick” im UI, JUniTests, der Java-Code ist vielleicht auch noch verbesserungswürdig (Struktur, Kommentare, usw.).
ich bin die letzten Tage nicht wirklich dazu gekommen etwas zu programmieren. Soweit ich das auf die schnelle gesehen hab, bist du da ja schon richtig weit.
Das ganze mal zu testen kann ich gerne übernehmen. Denke aber das ich vermutlich bis zum Wochenende brauche um dir ne Rückmeldung geben zu können. Parallel würde ich mich dann vielleicht zuerst mal mit um die UI kümmern.