Ich habe einen Deye Sun-12k-sg04lp3 an denen ich 6 Pytes 48100R Akkus betreibe.
4 davon sind Typ B, aber bereits für den 16-Modul-Betrieb ausgelegt dank FW SPBMS16SRPV1.3.35.C16
2 sind Typ C mit FW SPBMS16SRPV1.5.29.C16 (auch für bis zu 16 Module ohne Hub).
Da zu wenig Sonne da war, kann ich nicht sagen, ob es an der FW liegt, aber Fakt ist, dass der Ladevorgang abgebrochen wird, wenn eines der 6 Akkupacks auf 100% SoC geht, die anderen noch bei 90% oder knapp darunter liegen:
Ich vermute einen Bug in der FW von den Akkus oder vom Deye (C059/ 1175), aber leider reagiert der Pytes-Support gar nicht mehr und Deye meint das liegt an den Akkus.
Habt ihr zufällig auch so etwas beobachten können und habt eine Idee wie man das Problem lösen kann?
Habe schon überlegt die CAN-Kommunikation zwischen dem Deye und dem Pytes-Master auszulesen, aber ohne Grundlagen, natürlich nicht so einfach.
Nehme ich den 2. Akku aus der Kommunikation heraus, wird auch wieder munter geladen, bis der nächste auf 100% SoC kommt. Wirkt also ein bisschen so, als würde das Maximum und nicht der Mittelwert an den Deye übermittelt.
5 Batterien auf 90% und eine auf 150% ist sicher auch nicht das, was du möchtest.
Wenn da eine Batterie sagt: ich bin voll, dann sollte die nicht mehr weiter geladen werden. Du musst jetzt herausfinden, warum bei gleicher Spannung die Batterien unterschiedlich voll sind, und was dagegen tun.
Eine Definition, eine Zelle ist in OVP, dann SOC = 100% - mehr geht halt nicht.
Ursache - nicht balanciert.
Dann kommt die Frage zu allen Zellspannungen, im oder kurz vor dem Abschaltaugenblick/Ladevorgang.
Das mit den deblancierten Akku bemerkt man erst, hat man mehrere parallel. Der unbalancierteste ist am schnellsten in OVP = 100% SOC.
Alternativ ist eine oder sind mehrere Zellen defekt, OVP usw.
Interessant ist dann beim Entladen, welcher Akku zuerst in UVP ist, ob dieser durch die gleichen Zellen wie der OVP ausgelöst wird. Dann haben die Zellen Kapazitätsverlust, sonst unbalanciert....
Da würde ich ehrlich gesagt erwarten, dass die betroffenen Module nicht mehr geladen werden, und das hat in der Vergangenheit auch so funktioniert.
Die Spannungen der Module (16S) lagen beim Ladevorgang bei 55 Volt, sind wir da vom kritischen Bereich auch noch entfernt.
Tatsächlich sind mit die Module über den Winter auseinandergelaufen, habe diese auf Empfehlung (Anleitung) von Pytes dann schön einzeln geladen, der Balancer in den Modulen hat sein übriges getan. Abweichung waren am Ende <5mV zischen den 16 Zellen innerhalb eines Moduls.
Der Sprung von 90 auf 100% vom zweiten Akku (Typ C) passiert innerhalb von wenigen Sekunden. Die Spannungen der 6 Module weichen dabei um weniger als +/-20mV voneinander ab:
Also habe ich auch die Vermutung, dass der SoC nicht ganz richtig/ ein ungenauer Schätzwert ist.
Nur wie bringe ich entweder dem Akku bei (bei den Seplos-BMS geht das), dass der SoC zu hoch ist, oder sage dem Deye, dass er trotzdem laden soll..
Also den Pytes-Support nerven bis er damit rausrückt.
Dennoch kann es sein, dass der Pytes (durch die neue FW) das max. (100% SoC) anstelle des Mittelwerts (91% SoC) übermittelt - das würde das Verhalten zumindest erklären.
Hatte am Deye schon einmal ohne CAN-Verbindung versucht auf VBat umzustellen, aber da hatte ich auch komische Effekte (Akku > Grid, PV > Load).
Alternative wäre vielleicht ein “Shunt” mit CAN-Schnittstelle der dann anstelle der Pytes mit dem Deye kommuniziert. Dann wären die 6 Module ein großer Akku (91%SoC).
Aber da kann ich mir (ohne zus. HW) auch das CAN-Protokoll vornehmen.
DU hast es nicht zugelassen das die Battterie alle paar Wochen nicht nur VOLL wird, sondern auch nicht dass die für eine gewisse Zeit lang VOLL bleibt, weil die Zeit braucht es halt das die eingebauten Ballancer ihren Job machen.
Aber die Lösung ist einfach, gehe in das Menue des Deye und schalte die Time of use Tabelle aus, dann klicke noch Bat First anstatt Load first an und schau Dir das Ergebnis nächsten Mittwoch an.
Dann kannst Du auch wieder die Time of use Tabelle einschalten.
warum wird der Akku entladen und in Grid exportiert, obwohl für den Load genug Energie von der PV kommt? Werde den Deye neu starten, hatte versucht den SoC manuell zu setzen, habe es aber nicht hinbekommen.
Habe die CAN-Verbindung gekappt und auf VBat umgestellt. Hier funktioniert das Laden über 91%
Spricht also vieles dafür, dass er an der CAN-Kommunikation seit dem FW-Update hakt.
Jetzt sind sie alle “voll” - das waren jetzt weniger als 5min.
Dass der Akku entladen wird, obwohl ich nun auch die Spannung bis zu der entladen werden darf, höher gesetzt habe, findet auch mit VBat statt. Allerdings habe ich den Deye noch nicht neu gestartet.
Das denken die meisten, dem ist aber nicht so. Zellen welche weniger Kapazität haben werden zwar als erstes leer aber in einem gut ausgeglichenem Akkupack trotzdem gleichzeitig mit den anderen voll. Erreichen sie als erstes die Ladeschlussspannung bzw. die OVP und als erstes die Entladeschlussspanng bzw. UVP, dann hat man man mit großer Wahrscheinlichkeit hohe Übergangswiderstände.
Habe nun einen Werkreset durchgeführt und die Einstellungen neu eingetragen. Dachte zunächst, dass vielleicht durch die neue FW-Version am Deye die CT-Klemmen (oder eine davon) falsch erkannt werden oder negative Werte liefern. Das hat zwar zu komischen Effekten geführt, war aber keine Ursache, außerdem hat ja der Rest funktioniert. Nur das Verhalten, wenn Akku fast voll oder voll ist, ist merkwürdig.
Nach dem Reset sieht es jetzt gut aus, allerdings ist der Load mittlerweile höher als der PV-Ertrag. Ob der Reset war bewirkt hat, sehe ich daher erst morgen.
die Diskussion rund um den SoC ist mir schon geläufig. Und tatsächlich war das eines meiner Probleme, dass die Werte auseinandergelaufen sind.
Allerdings wurden die Module seitdem einzeln geladen und der interne Balancer hat seine Arbeit verrichtet. Und die Spannungen der Module (und auf Zellebene) weichen so minimal ab, dass ich das nicht für die Fehlerursache halte.
An einen Shunt / Victron (?), der das sauber misst und dem Deye dann die Daten liefert, habe ich auch schon gedacht.
Ich gehe nach wie vor davon aus, dass der Pytes-Master via CAN etwas falsches an den Deye liefert.
Da ich nun auf VBat gewechselt habe, hat das Laden funktioniert - ich werte die 6 Pytes per Consolen-Port über einen RasPi in Echtzeit aus.
Das erklärt aber noch nicht den übermäßigen Grid-Export aus den (vollen) Akkus, egal ob per CAN oder VBat. Ich hoffe das Zurücksetzen hat geholfen.
Genau das bezweifle ich, denn das Laden endet, wenn der Deye per CAN mit den Pytes verbunden ist und startet auch wieder, wenn man das Modul mit den SoC=100% herausnimmt.
Im VBat-Mode trat das Problem nicht auf.
Mit socw soll man den SoC an den Pytes einstellen können, aber das ist mir nicht gelungen.
Bei den Seplos (BMS 3.0) kann man den SoC über das DevBMSStudio einfach setzen.
@Vavuum:
Habe gestern eine Einstellung gefunden für den SoC bei den Pytes (socw), und den Wert gesetzt. Auch keinen Fehler erhalten, aber auch keine Veränderung festgestellt.
Aber mit VBat hat es nun wie gewünscht funktioniert.
Kaum waren die Akkus voll, hat er wieder mit rund 1,6kW wieder entladen.
Dann habe ich im SolarAssistant die Einstellung “Start battery discharge voltage” von 52 auf 57V geändert (Time Of Use ist aktiv, sollte also gar nicht relevant sein?).
Im Deye ist das der Wert “Reset” auf Batt set3.
Und nun funktioniert alles (nur mit VBat anstelle mit CAN und Lithium)..
