wenn denn das tatsächlich so wäre, gebe ich dir Recht. Nur leider sind die Dinger noch nicht so lange am Markt, dass die Theorie bewiesen wäre.
Und wenn "voll" warum sie so hoch in der Spannung halten? Ich seh den Benefit nicht so ganz.
Aber das ist wahrscheinlich mal wieder eine Geschmacksfrage ohne Richtig/Falsch. Ich versuche jetzt erstmal den Mist zum (dauerhaften) Laufen zu bringen.
Ich denke das liegt an dem aktiven Float Timer.
Wenn der aktiviert wird nach der neuen Logik, dann wird die Spannung auf 16 x RFV
(Requested Float Voltage) für die Dauer des Timers gesetzt .
Steht dieser als Bsp. bei 5 Std., bleibt die Spannung auch so lange bei 16 x RFV. Ich denke das du 3.35 V als RFV eingestellt hast, das entspricht ja 53.60 V.
Argument war, man will ja nicht den Akku ständig im kurzen Wechsel erneut auf Absorption / Bulk Spannung laden .
Leute ich hab gerade 2h verbracht meinen pc mit der 2.8.0 software mit meinen (seit 8 monaten laufenden) jk bms zu verbinden, und hab es nicht hinbekommen. Ich meine damit den Modus zum Firmware upgraden.
ich bin noch auf 15.24 und hätte gern die aktuelle draufgespielt, und ich krieg keine Verbindung zustande (nur parallel, aber das hilft ja nix zum updaten). Is ja auch nicht so als hätte ich noch nie geupdated.
Einen der RS485-2 Ports mit den beiliegenden (hab 2 probiert) USB auf RJ45-Adapterkabel verbinden, und in der software korrekten COM port auswählen und auf verbinden drücken oder? Mach ich irgendwas falsch?
hast du auch mal den anderen RS485 Port probiert? Bei mir gehts nur an einem der beiden. Warum auch immer. Sicher den richtigen COM x gewählt?
beides ja. Muss man einen der UART-Modi in der Handy-app speziell einstellen? ich kann mich nicht erinnern dass das das letzte mal so aufwändig war
Hast du den Akku auf Adresse 0001 und ohne Slave Akku angeschlossen?
Port RS485_2 verwenden, es geht aber auch mit dem RS232 Port in der Mitte.
Verbindung funktioniert auch ohne Adresse 0001
Lässt sich nur nicht updaten…
Ich hab 2 bms, das erste hat einen hardwarefehler (der ganz rechte address pin 8 ist immer aktiv) , das zweite bms funktioniert normal und ist deswegen auch immer das master im normalbetrieb.
Ich habe aber trotz all dem beide früher geschafft zu updaten.
Ich hab beide rs485 ports probiert. Ich hab ein EEL Gehäuse falls das relevant ist. Den 232 zu benutzen muss ich mir mal anschaun, danke für den tipp. Restliche Kabel abgesteckt sind sie immer gewesen beim update versuch. Hab sogar die handy app gekillt weil ich dachte die spielt rein. Ich hab mir ja auch nurtons video dazu angesehen
Normaler Prozess wäre:
Einen der RS485 Ports mit dem RS485-USB Kabel verbinden.
In der Applikation den richtigen COM-Port und die ID (ID muss ungleich 0 sein zum Firmware oder Fireware upgrade 
) auswählen.
Bei mir klappt das nur, wenn im Daisy-Chain-Betrieb kein weiteres BMS mit dran hängt.
Danke fürs klarstellen, so hatte ich es auch in Erinnerung. Ich tüftel mal weiter, melde mich.
Hat einer von euch eine Ahnung, was das BMS nach Ende RCV und Umschalten nach RFV bei gleichzeitigem Soc Reset auf 100 via CAN an die Anlage sendet?
Meine Studer-Anlage schaltet in dem Moment ab, wartet 20 Sekunden und schaltet wieder an. Dann läuft sie weiter, als wäre nichts gewesen.
Es gibt keine Warning-Anzeige irgendwelcher Art in der PC-Software und auch kein OVP oder ähnliches, was das Verhalten erklären würde. Pylontech-Protokoll.
Blöde Frage: Welchen Port nutzt ihr denn für die CAN Kommunikation?
Gemäß Anleitung ist der Port ganz links CAN, daneben RS485-1, mittig RS 232 und rechts 2x RS485-2.
Bei mir (mit Deye 12k) funktioniert die CAN Kommuikation aber nur, wenn ich den 2. Port von links (RS485-1 gemäß JK Doku) nutze.
Wenn ich im JK "Discharge" deaktiviere (finde ich im Winter eigentlich eine elegante Lösung, um über mehrere Tage den Akku doch mal voll zu bekommen), meldet JK an den Deye "Force Charge" was zum Laden des Akkus aus dem Netz führt. Gerade noch mal mit der neuen 15.38 und sowhl Deye als auch Pylontech CAN Protokoll getestet. Ziemlich blöd...
TOU auf 100 am Deye würde da auch gehen
Der 2. Port bei mir, also wie bei dir.
Ja ein echt blöder Fehler, das darf nicht sein. Ich werde das heute Abend bei mir testen. Ich hatte mit V15.34 dieses Problem nicht mehr, auch nicht mit dem Deye Protokoll. Vorher habe ich immer das Pylontec Protokoll benutzt da dort der "Request Force Charge" Fehler nicht auftrat. Unabhängig ob man Discharge/Charge Switch gesetzt hat.
Leider habe ich beim Update auf V15.38 vergessen auf diesen Fehler hin zu prüfen.
Bei meinem SunSynk WR, ein Deye OEM, kann ich die Stromstärke beim Laden aus dem Netz auf 0 Ampere stellen. Da gibt es eine Checkbox "Grid charge" und wenn die gesetzt ist kann ich in einem Eingabefeld den Strom auf 0 setzen. Das habe ich gemacht und dann lädt der SunSynk niemals aus dem Grid, auch nicht beim Request Force Charge.
Ok, nochmal ran an den Mist und erneut alles überprüfen ;(
Gute Idee, da muss ich nur mal die ganzen Zeiträume auf einen reduzieren.
Gerade auch so bei Andy in einem Video gesehen. Scheinbar ist die Doku falsch.
Woher hattest du die 15.34? Bei Andy gibts nur 30,33 und 35-38.
Danke, gerade probiert, gibt es bei Deye auch. Hilft aber nicht, er lädt bei Force Charge trotzdem aus dem Netz. 
Ok, habs soeben überprüft. Und ja V15.38 sendet an den WR ein "Request Force Charge " wenn man den Discharge SSchalter OFF stellt.
Nun, laut Release Logs von JK
V15.38 Upgrade logs
V15.26 Upgrade logs
Mit V15.26 haben sie den Request Force Charge Fehler aus dem Deye Protokoll gefixt. Ich habe auf Grund dieses Fehelr immer das Pylontec Protokoll benutzt.
Mit V15.38 haben sie nun das Pylontec Protokoll gefixt. Was nichts anderes heist das nun das Pylontec Protokoll jetzt auch den "Request Force Charge" Fehler drinnen hat.
Keine Ahnung ob ich als Ingenieur überpingelig bin aber das was JK Entwickler da machen ist absoluter rotz.
Ich downgrade jetzt auf V35.17, da das Release Log für V15.38 nur diesen Pylontec-Kapputt-Mach-Fix enthält.
Mal schauen ob das dann geht.
V15.37 gleiches Problem, egal ob Pylontec oder Deye Protokoll. Bei mir kommt der "Request Force Charge " Fehler aber nur dann wenn beide Akkus den Discharge Schalter OFF haben. Nur dann.
Bei mir kam mit 15.35 mit nur einem Akku und Pylontech Protokoll auch schon das Force Charge.
Muss man scheinbar mit leben... ToU auf 100% stellen klappt zumindest als Workaround.
Hm. Mit einem Akku kommt bei mir der Fehler dann auch sofort.
Ich hatte nicht V15.34 sondern V15.30 drauf gehabt, sorry da hatte ich mich geirrt. Hatte am Anfang mal V15.24 drauf, muß ich wohl damit verwechselt haben.
Allerdings, habe ich den Strom bei Laden aus dem Netz auf 0 stehen. Und beim "Request Force Charge" lädt der WR dann nicht aus dem Netz.
Also zuerst Haken bei Grid Charge und Strom 0A rein und Ok Button, nochmal Screen öffnen und Haken bei Grid Charge wieder raus und Ok Button drücken.
Dann lädt er bei mir definitiv nicht mehr aus dem Netz. Ich habe es getestet mit 10A statt 0A und dann lädt der Deye/SunSynk auch mit 10A den Akku aus dem Netz. Dieser Wert wird also nicht ignoriert bei mir.
Ich bin mir sehr sicher das ich das mit dem Request Force Charge in den Griff bekommen hatte, warum das jetzt wieder nicht geht weiß ich auch nicht.
Bin jetzt wieder auf V15.38 und hatte soeben die Versionen 30,32,36,37,38 getestet. Bei allen das gleiche Fehlerbild.
Versionen V15 die ich habe sind 10 ,11, 17, 24, 30, 32, 33, 35, 36, 37, 38
Ich möchte nicht auf alle Features der neusten Versionen verzichten und wieder auf V15.24 downgraden. So wie du, lebe ich erstmal damit.
In welcher Situation stellt man den Discharge Schalter auf Off?