Ich habe einen Deye 12K LV mit 2 JK BMS mit 304 und 314Ah Eve Zellen. Anbindung per CAN.
Seit 3 Tagen habe ich ein merkwürdiges Verhalten. RCV steht auf 3,45V = 55,2V. Der Deye zeigt als RCV auch korrekt 55,2V an. Die Akkus werden aber nur bis 55,13/14V geladen (Anzeige in beiden BMS + Deye, entspricht auch den Werten per Multimeter).
Dann zeigt der Deye im LI-BMS Menü immer noch RCV 55,2V und die korrekte Akkuspannung von 55,13/14V an. Im Batt Menü zeigt er aber nur 55,09V an. Das passt auch, denn der Deye zeigt immer etwas geringere Spannung an.
Wenn ich den Deye testweise von "Lithium" auf "Batt V" umstelle und als Ladespannung 55,3V eintrage zeigen das Batt Menü 55,19V und die JK BMS 55,24V an.
Das Verhalten ist also gleich, in beiden Fällen regelt der Deye die Ladespannung 0,11V niedriger als angefordert. Warum auch immer...
Hat jemand eine Idee? Ich könnte natürlich die JK BMS höher kalibrieren, sodass sie bei 55,13V 55,2V anzeigen, aber so richtig toll finde ich die Lösung nicht.
Bei meinem 12k Deye ist es eher umgekehrt, RCV steht auf 3,44V und der lädt bis 3,47...
Von deinem Problem habe ich auch schon gehört, aber leider ohne Lösung.
Lade beide Akkus voll. Wenn fertig lese am Deye die Akku Spannung ab. Nicht die im LiBMS Menu steht sondern die vom Deye gemessene. Addiere darauf ca. 120mV. Benutze diese virtuelle Spannung um in beiden JK-BMS die Spannung zu kalibrieren. Findest du auf der Settings-Page der Bluetooth Software.
Ich hatte das gleiche Problem und das man dieses Problem bekommt ist absehbar. Die Logik des JK-BMS für den 100%-SOC-Reset ist dämlich.
Der 100%-SOC ist wichtig da nur dann das BMS in der SOC Berechnung nicht driftet, sondern sich jedesmal neu kalibriert.
Das ist ja das komische. Die Spannungswerte sind ok. die BMS zeigen 55,13V an und der Deye im LIBMS Menü auch. Die vom Deye gemessene Spannung ist 55,09V. Er hebt sie aber, warum auch immer, nicht auf die angeforderten 55,2V an.
Warum ist es absehbar, dass man dieses Problem bekommt? Das lief jetzt gut 1/2 Jahr problemlos.
wenn nun Akku Spannung >= 100%-SOC Spannung ist dann setze SOC auf 100%
Nun folgende logische Probleme damit:
100% SOC Spannung muß immer <= RCV Spannung sein, logisch. Daraus folgt das Bedingung 3. überflüssig ist. Denn wenn RCV Spannung am Akku dann ist es schon 100% SOC Spannung. Und warum möchte man 100% SOC Spannung dann kleiner als RCV Spannung einstellen? Ergo: Bedingung 3. ist überflüssig
unnötige Abhängigkeit der 100%-SOC Spannung von RCV Spannung. Wenn man die 1. Regel weg ließe dann wäre es korrekt. Denn nun ist RCV unabhängig von 100%-SOC Spannung. Man kann nun damit beliebige Logiken abbilden. Zb. RCV Spannung größer als 100%-SOC Spannung und damit die Problematik mit dem Deye sauber abbilden. Dh. wenn 100%-SOC Spannung erreicht oder überschrietten wurde dann warte Timer ab. Sollte 100%-SOC Spannung wieder unterschritten werden dann setze Timer zurück. Wenn Timer abgelaufen ist und 100% SOC Soannung die ganze Zeit überschritten/erreicht wurde dann setze auf 100% SOC. Das wäre die korrekte Logik.
nun haben Deye User ein Problem, das sie nur mit üblen Tricks lösen können. Das Problem ist das Deye es einen Scheiß interessiert was das BMS als Spannung an ihn sendet. Deye misst selber an seinen Akkuklemmen und ignoriert somit den Fakt das von diesen Klemmen ein Kabel zum Akku geht. Und dieses hat nunmal einen Spannungsabfall. Wenn auch nur 100mV+ aber dieser kleine Drop bewirkt das die Logik vom JK-BMS eben nicht mehr fiunktioniert. JK und Andy von OffGrid Garage argumentieren nun so: Deye ist Schuld da der nicht die Spannung benutzt die das BMS ihm meldet. Auf den ersten Blick könnte man meinen, Recht haben sie. Aber das ist ebenfalls eine fehlerhafte Argumentation. Deye kann sich nicht auf die Qualität der chinesischen BMS'e verlasen. Das hat China-Deye mal mit gedacht und meiner Meinung nach korrekt gehandelt.
In Kurz:
RCV ist Request Charge Voltage und nichts mehr
100%SOC Spannung und Timer sind alleinig zu betrachten ohne Zusammenhang mit RCV
Timer wird solange zurückgesetzt wie Akkuspannung < 100% SOC Spannung
wenn Timer abgelaufen ist dann 100% Reset durchführen und auf Float-Mode umschalten wenn dieser aktiviert wurde
So wäre die korrekte Logik. Mit dieser kann man RCV = 100%SOC Spannung einstelen und hätte das jetzige Verhalten des JK-BMS für unsere Victron Jünger oder Wechselrichter die die vom BMS gemeldete Spannung auch berücksichtigen. Oder man setzt RCV um 120mV größer damit der Spannungsabfall der Kabel berücksichtigt wird und hätte so WR wie den Deye ebefalls sauber berücksichtigt. Ohne das man nun die komplette Spannungsmessung des BMS "fehl-kalibrieren" muß.
Schon als Andy in seinem YT Video die Logik erklärte wusste ich das das mit dem Deye Probleme machen wird. Denn schon zu diesem Zeitpunkt hatte ich bei meinem System die Differenzen in den Spannung des Deyes gemessen.
PS: Rechtschreibfehler gehören Dir, kein Bock das jetzt alles zu fixen, sorry
Ich glaube eher, dass hier ein Problem vorliegt, es hat doch vorher funktioniert, warum jetzt auf einmal nicht mehr?
Ich habe die Spannungen alle abgeglichen, Messgerät, Deye und das JK BMS zeigen gleiche Werte an.
Mein Deye verhält sich genau anders rum, ich hab meine RCV Spannung im BMS auf 3,420V eingestellt (im Winter etwas höher) und mein Deye lädt bis 3,44V warum auch immer??? Aber so haben es meines Wissens fast alle 12k Deye.
Hier ist es genau umgekehrt, der Deye gibt zu wenig raus. Ich würde es auf jeden Fall bei Deye melden.
ps. Ich bin mit der JK Reset Logik komplett zufrieden, läuft jetzt seit mehreren Wochen stabil. (FW 15.38/ im Deye 1140)
weil vor V13.38 die 100%-SOC Logik eine andere war. Und mit den älteren Versionen lief es bei mir ja auch gut. Allerdings wurde in v13.38 nicht nur die Reset-Logik geändert sondern auch die Berechnung des SOC selbst angeblich verbessert. Und darauf wollte ich nicht verzichten.
Im Grunde ist mir das auch egal. 120mV/16 = 7,5mV pro Zelle höhere Spannung gemessen als tatsächlich anliegt. Wäre es andersherum, also ich müsste so kalibrieren das das BMS eine geringere Spannung annimmt als tatsächlich anliegt, würde es mich deutlich mehr stören. So werden die Akkus nur geschont.
edit: Und ich habe das auch überprüft indem ich ein Downgrade meiner beiden Akkus durchgeführt habe. Danach lief alles wieder. Ergo: nur die Firmware des BMS wurde geändert und macht den Unterschied aus. Es liegt also an der JK-BMS Firmware.
Ich würde mir eher Sorgen machen warum dein Deye die korrekte Spannung an seinen Klemmen misst die das BMS an seinen Akkuklemmen ebenfalls misst. Hast du Supraleiter als Akkukabel die ohne Verluste arbeiten ?
Ich messe bei mir einen Spannungsabfall von Deye Akkuklemmen zu Akku-Akkuklemmen und die Spannung die ich im Deye Menu (nicht LiBMS Menu) sehe messe ich auch an seinen Klemmen. Ebenso messe ich am Akku die Spannung die das BMS im LiBMS Menu dem Deye meldet. (ok jetzt nicht mehr da ich ja +120mV fehl-kalibrieren musste).
Ich sehe hier den Zusammenhang mit der JK Änderung nicht. Davon abgesehen lief es bei mir auch mit der neuen Version gut, bis vor ein paar Tagen.
Nein, Bedingung 3 ist nicht überflüssig. Denn wenn in der Zwischenzeit der Akku etwas entladen wurde, kann die Spannung nach Ablauf des RCV Timers durchaus niedriger sein. Das habe ich hier im Januar/Februar beobachtet.
Das stimmt, dann wäre man flexibler. Allerdings wäre das ganze auch noch komplexer und warum sollte man den RCV Wert unnötig höher setzen? Ein sinnvoller Use Case fällt mir da nicht ein. Ich denke in den meisten Fällen ist der 100% SoC Wert minimal unter RCV konfiguriert.
100mV Spannungsabfall fände ich schon bedenklich viel. Sind bei mir <10mV zwischen Deye Akkuklemmen und den Akkus. Allerdings auch nicht unter Vollast gemessen. Wobei bei erreichen der RCV ja auch kaum noch Strom fließt.
Aus meiner Sicht ist das Problem, dass man den Deye nicht kalibrieren kann. Somit bleibt nur das BMS entsprechend anzupassen.
Aber nochmal: Das ist in meinem Fall überhaupt nicht das Problem. Der Deye misst immer ~40mV weniger, sodass die erreichte RCV bis vor ein paar Tagen 55,24 V war. Er regelt jetzt nur zu niedrig.
Gestern den Deye für 1/2h stromlos gemacht, bis auch der Ring am On Knopf erloschen ist. Hat leider nichts gebracht. Ich habe keine Ahnung, woran das liegt.
Ich habe jetzt eben das JK 70mV hoch kalibriert (55,13 -> 55,20). Finde ich aber keine sonderlich tolle Lösung. Da will man alles ganz genau messen und einstellen und pfuscht dann so...
So schlimm finde ich es nicht, Hauptsache es funktioniert.
Es gibt eh keine Alternative für den Preis.
JK etwas hoch Kalibrieren, dann den RCV Wert etwas absenken, dann passt es.
"Schlimm" für meinen Kopf.
Praktisch hast du recht, ist nicht so dramatisch. RCV lasse ich erstmal. 70mV auf die 16 Zellen sind ja nur ~4,4mV.
Aber jetzt zum Sommer setze ich RCV komplett etwas runter, da werden die Akkus eh nicht leer. Aktuell ist 3,45V, evtl. gehe ich auf 3,42 oder so.
Jep, hab auch diese Woche gemacht. RCV 3,42V und RFV 3,34V
Deye mach noch ca. 0,02V drauf dann bin ich auch bei 3,44V Darunter ist es kacke weil Balancieren fast unmöglich. Lieber die Balancierzeit auf 30min setzen und dann die Float Spannung auf 12 Stunden und richtig tief.
Ich weiß was du meinst, aber das ist so eine Sache mit der Genauigkeit.
Hab heute alle meine Messgeräte geprüft und musste feststellen, dass alle ihre Toleranzen haben, ich kann die zwar alle Kalibrieren, aber nach was gehe ich, was ist meine richtige Referenz?
Hatte sogar 2 Messgeräte dabei die gleiche Spannung wie Deye angezeigt haben
Ich hab genau das gleiche Problem, das ich die RCV Spannung nicht erreichen.
Hier mal ein Bild.
Ich habe aus Zwei jk BMS und und ca. 3 einfach Leitungslänge 70mm2 und noch eine 250a Adler Sicherung dazwischen.
Wenn ich vom Urlaub zurück bin werde ich mal an den Anschluss die
Spannung Messen.
Ja, symptomatisch betrachtet von Deye verursacht. Aber betrachtet man den Entscheidungsbaum den Deye hat dann wiederum kann ich Deye verstehen. Denn was sind die Fakten:
Deye unterstützt den AGM Modus, messen muß Deye als in jedem Fall
Deye möchte intelligente BMS'e unterstützen, vor 5-8 Jahren.
diese BMSe sind durch die Bank weg damals alle nur als extrem schlecht zu bezeichnen
sich auf diese BMSe zu verlassen wäre grob fahrlässig
Deye geht keine Risiken ein und misst lieber selber
denn der Imageschaden/die Gewinnverluste wären gigantisch wenn damals Deye es anders entscheiden hätte und kein BMS verlässlich funktioniert.
Und selbst heute noch enthalten gute BMSe grobe logische Fehler, eben wie das JK-BMS
falsche 100% SOC Logik
schlechte Berechnung des SOC ansich, der dumme Benutzer möchte sich nur auf den SOC verlassen, so ist nunmal die Forderung der Kunden.
getürkte und nervige Passwortabfragen. Denn jeder kann mit bischen BT-Software das BMS per BT aus der Ferne steuern, da das BMS das Passwort sendet.
deaktiviert man die MOSFETs für das Entladen dann wird ein "Request Force Charge" gesendet obwohl der Akku voll ist. Also keine Überprüfung des Akkustandes oder Spannung und dumpfes unlogisches Senden das der Akku aus den Netz geladen werden muß.
ist einer der MOSFETs für Charge/Discharge deaktiviert kann der Akku denoch ent/geladen werden. Nur bei Deaktivierung beider MOSFETs ist der Akku getrennt. Das ist auch technisch logisch wenn man die Schaltung der MOSFETs betrachtet, geht physikalisch garnicht anders. Das heist im Umkehrschluß, diese Schalter in der BT App anzuzeigen ist schon dumm und zeigt das die Entwickler der Software keine Ahnung haben was die Technik macht.
die Bedienlogik ist absolut nicht stringent. Man macht von der Reihenfolge der Eingabemaske es abhängig wie Parameter auf ihre Gültigkeit überprüft werden (Sanitychecks sagt der SW-Entwickler dazu). Das hat logisch nichts mit dem GUI zu tun sondern ist in der Grundfunktion des BMS zu verankern. Das gehört noch nicht mal in das GUI der App sondern in die Firmware des BMS. Denn dort sitzt und bastelt der Entwickler dran rum der wirklich Ahnung hat. Nicht der GUI Designer hat diese. So kann das Management des JK-BMS die Entwicklung des GUIs außer Haus geben und hat denoch ein sicheres Produkt. Da dies aber so nicht ist heist dies zwangsläufig: das Management von JK hat auch keine Ahnung wie man die Entwicklung von SW- und HW managed. Ich bin HW- und SW- Entwickler und Projektleiter ähnlicher Produkte.
wenn in einer Eingabemaske man einen Fließkommawert ändert, also zb. die Zahl 52.8 auf 52.6 ändern möchte dann löscht man Zeichen für Zeichen von Hinten nach vorne. Also man erwartet nach dem ersten Löschen "52." in der Eingabe. Löscht man aber beim JK-BMS die "8" von "52.8" dann steht dort eben nicht "52." sondern "52". das Komma ist ebenfalls gelöscht worden. Du sagst jetzt: hey PV-Soko du bist aber pingelig. Nein bin ich nicht. Denn die Frage lautet: warum ist dieses Verhalten so? Und das erkläre ich dir. Jedesmal wenn der Benutzer diese Werte ändert hat der GUI Entwickler diesen Eingabewert umgewandelt in eine echte Zahl und diese wandelt er zurück in einen Anzeigestring und schreibt sie in das GUI. Dadurch wird das Komma autom. gelöscht. Das ist sehr schlechter Programmierstil und impliziert viele Nachfolgefehler. Und ich weiß das weil ich mindestens schon 4 Lehrlinge hatte die exakt die gleichen Fehler gemacht haben. Richtig ist es die Eingabemaske von der Übernahme der Eingabedaten zu trennen. Das macht man indem man die RETURN/ENTER/Eingabetaste abfragt, der Benutzer drückt diese wenn er fertig ist oder bei Verlassen der Maske wenn Änderungen gemacht wurden. So ist es richtig,
Und ich könnte diese Liste noch weiter führen. Die Software von JK, die als sehr gut gilt, ist es nach meinen Kriterien längst noch nicht. Es ist aber eben das "beste" am Markt.
In meinem konkreten Fall ist das Problem jetzt ja, dass Deye selbst nach der eigenen Messung zu niedrige Spannung liefert. Aktuell ist RFV mit 54,4V angefordert, im Deye Batterie Menü selbst werden nur 54,29V angezeigt. Also einiges zu wenig. Gemessen sind es 54,28V, also ist der Deye Wert gar nicht mal so schlecht.
Wie du schreibst, bei allen Optimierungsmöglichkeiten gibt es eben nichts am Markt, was Preis/Leistung besser ist. Von daher müssen wir wohl zufrieden sein.
