Heute ist mein zweites CAN Modul angekommen, nachdem ich das erste gleich mal verschmissen hatte. Schnell an den ESP32 angelötet, LAN Kabel braun-weiss/braun dran und fertig. Jetzt hab ich auch ne Pylontech-Batterie ... 😉 Frage dazu: Über Bluetooth kommen ja auch die Cell-Voltages rein. Passiert das bei CAN nicht? Ist das nur in der Pylontech-Emulation so, oder interessiert das per CAN prinzipiell nicht?
Nächste Frage: Mein Ladestand ist sowas von komplett daneben, das begreif ich einfach nicht. Kann ich das irgendwo tunen? Die Batterie hat jetzt schon 20-30 Zyklen durch, da sollte das ja langsam passen? LiFePo4-Zellen haben im Schnitt 3.1V, nachdem das BMS bei 2.8V getrennt hat und das BMS meint der Akku wäre zu 48% geladen. Komplett falsch ...
Jetzt habe ich das CANbus-Modul mit Pylontechemulation für den Victron-Multiplus in Betrieb genommen. Alles läuft gut, er lädt, und dann hört dieses Sch****ding bei 52.6V auf zu laden. Egal was ich im ESS einstelle er geht nicht drüber.
Und nach 6h rumprobieren und hin- und hertesten fällt es mir wie Schuppen von den Augen: Das Pylontech ist ja ein 15s System und kein 16s System wie meines. Daher werden meine 56.8V Ladeentspannung auch nie erreicht.
Jetzt meine Frage: Kann man das irgendwie ändern? Heisst "Pylontech" immer automatisch 52.6V? Kann man das für 16s anpassen?
Das Problem hat Scotty89 schon am 10. Juli gemeldet. Ich verzichte inzwischen auf den CAN-BUS und gebe ein JSON-File als Webserver auf dem ESP32 aus. Auf dem Raspberry läuft dann eine “Batterie” die das JSON File über WLAN ausliest und damit das BMS bekannt macht und den Ladevorgang steuert. Dort manage ich dann auch die Ladeströme und Spannung in Abhängigkeit vom SoC.
ich weiß, dass das Problem bereits mehrfach beschrieben wurde. Also, ich betreibe einen ESP32 mit der aktuellen Version 3.6. Dieser sendet die MQTT Protokolle brav an meinen MQTT Server (Docker auf Unraid) von welchem mein Homeassistant die Werte abruft. Ich hab mir in Homeassistant eine schöne Übersicht gebastelt, worin ich alle relevanten Werte sehen kann. So schön so gut.
Aber, der ESP32 läuft maximal 2 Tage, dann steigt er aus.
Heißt, keine LED auf diesem blinkt mehr. Nur ein Stromlosschalten erweckt ihn wieder zum Leben. Ich habe ihn jetzt per Shelly angeschlossen um nicht immer in den Keller zu müssen oder von Unterwegs neu starten zu können. Wie lange rennt er bei euch? Sollte ich auf ne andere Version downgraden, welche evtl. stabiler läuft?
Das Problem hat Scotty89 schon am 10. Juli gemeldet. Ich verzichte inzwischen auf den CAN-BUS und gebe ein JSON-File als Webserver auf dem ESP32 aus. Auf dem Raspberry läuft dann eine “Batterie” die das JSON File über WLAN ausliest und damit das BMS bekannt macht und den Ladevorgang steuert. Dort manage ich dann auch die Ladeströme und Spannung in Abhängigkeit vom SoC.
Ah danke. Das hatte ich überlesen. Bzw eim ersten Mal Komplettlesen des Threads noch ignoriert, da ich CAN-BUS noch nicht im Visier hatte. Kannst du zu deinem Vorgehen zum Ladevorgang ein wenig präzesieren? Die Daten habe ich über BT alle in HomeAssistant vorliegen, kann sie also auch entsprechend umformen denke ich. Idealerweise würde ich die Ladelogik dem Multiplus gerne vorgeben, also mit wieviel Ampere er bei welchen Zellspannungen ent/laden soll etc. Ist sowas möglich?
Thx. War das jetzt die Antwort auf meinen Beitrag? Ist mir nämlich ein bisschen zu wenig, da ich nicht weiss wie hier was zusammenspielt. Wo läuft da was genau? Ich hab auch keinen Raspberry. Meinst du das System wo venusos drauf läuft? Das ist bei mir ja direkt am Multiplus-GX.
Ok ist jetzt nicht so einfach. Es gibt den Treiber dbus serialbattery ( https://github.com/Louisvdw/dbus-serialbattery ) damit können verschiedene BMS (auch das JK BMS) über den RS485 Anschluss an den Cerbo/Raspberry angebunden werden. Nun gefällt mir der RS485 Anschluss nicht und einige hatten Probleme, allerdings war dies die Grundidee für meinen Treiber. Nun habe ich die Software aus diesem Thread benutzt und kein CAN Bus genommen sondern über den ESP32 ein JSON-File rausgeschrieben. Für mich gehört der ESP32 einfach zur Batterie. Er erweitert einfach die Kommunikationsschnittstellen des BMS. MQTT und JSON. Auf der dem Cerbo/Raspberry läuft jetzt für mich die Steuersoftware (Basis serialbattery). Der „Treiber“ meldet sich als Batterie bei Victron an ( https://github.com/victronenergy/venus/wiki/dbus#battery ) und benutzt als Input das JSON file des ESP32. Aktuell wird dann auf Basis des SoCs der Lade/Entladestrom und die Spannung geregelt. (Den Teil habe ich dir rauskopiert um zu zeigen wie mein Ladestrom gesteuert wird). Allerdings hast du recht, ich will wenn ich mal Zeit habe auch die Zellspannungen berücksichtigen. Bei großen Differenzen könnte man ein langsames, vorsichtiges topbalancing machen, nachdem im Winter es vielleicht nie eine Vollladung gegeben hat. Aber dazu brauch ich mal Zeit. Hier 2 Bilder. Ich habe nur 8s Deswegen auch nur 8 Zellen. Ich hoffe das erklärt nun was ich gemacht habe und wie ich auf den CAN Bus verzichtet habe. Im Prinzip ist es jetzt völlig egal ob hinter dem JSON File ein JK, Daly oder sonst etwas steckt.
Ok ist jetzt nicht so einfach. Es gibt den Treiber dbus serialbattery ( https://github.com/Louisvdw/dbus-serialbattery ) damit können verschiedene BMS (auch das JK BMS) über den RS485 Anschluss an den Cerbo/Raspberry angebunden werden. Nun gefällt mir der RS485 Anschluss nicht und einige hatten Probleme, allerdings war dies die Grundidee für meinen Treiber. Nun habe ich die Software aus diesem Thread benutzt und kein CAN Bus genommen sondern über den ESP32 ein JSON-File rausgeschrieben. Für mich gehört der ESP32 einfach zur Batterie. Er erweitert einfach die Kommunikationsschnittstellen des BMS. MQTT und JSON. Auf der dem Cerbo/Raspberry läuft jetzt für mich die Steuersoftware (Basis serialbattery). Der „Treiber“ meldet sich als Batterie bei Victron an ( https://github.com/victronenergy/venus/wiki/dbus#battery ) und benutzt als Input das JSON file des ESP32. Aktuell wird dann auf Basis des SoCs der Lade/Entladestrom und die Spannung geregelt. (Den Teil habe ich dir rauskopiert um zu zeigen wie mein Ladestrom gesteuert wird). Allerdings hast du recht, ich will wenn ich mal Zeit habe auch die Zellspannungen berücksichtigen. Bei großen Differenzen könnte man ein langsames, vorsichtiges topbalancing machen, nachdem im Winter es vielleicht nie eine Vollladung gegeben hat. Aber dazu brauch ich mal Zeit. Hier 2 Bilder. Ich habe nur 8s Deswegen auch nur 8 Zellen. Ich hoffe das erklärt nun was ich gemacht habe und wie ich auf den CAN Bus verzichtet habe. Im Prinzip ist es jetzt völlig egal ob hinter dem JSON File ein JK, Daly oder sonst etwas steckt.
Das klingt ziemlich genau nach dem was der ein oder andere hier sucht. Könntest du etwas genauer beschreiben wie du das installiert hast und eingerichtet? Dann könnte ich und bestimmt noch einige andere das nachmachen. Der ESP32 erhält ebenfalls via Bluetooth die Daten des BMS oder?
@mascheihei tolle Lösung was du da beschreibst. Aber Ladestrom sinkt doch eh bei vollen Zellen von alleine ab. Außer man hat viele unterschiedliche Zellen (aus China??) im Pack drin. Dann würde ich aber wohl eher einen zusätzlichen Balacher mit möglichst hohem Strom dazu bringen um den Ausgleich schneller zu machen. Übergang vom Winter zum Frühjahr, da sollten die Ströme auch erst mal nicht so stark ansteigen bis das Pack dann mal wieder voll ist. So viel zu meiner Überlegung dazu.
Übergang vom Winter zum Frühjahr, da sollten die Ströme auch erst mal nicht so stark ansteigen bis das Pack dann mal wieder voll ist. So viel zu meiner Überlegung dazu.
Du hast wahrscheinlich recht. Ich habe mir auch dazu noch keine Gedanken gemacht, aber du machst hier einen validen Punkt. Ich weiß sowieso nicht, ob diese Charge Current Control des BMS notwendig ist. Wenn ich das BMS nicht integriere und keine extremen Spannungen vorgebe, sinkt der Strom auch zuverlässig bei der Ladeendspannung ohne Probleme ab. Und mit ordentlichen Zellen passiert auch nichts. Wahrscheinlich macht es bei Entladen mehr Sinn.
Bisher ist quasi nur 1:1 die Lösung aus dbus serialbattery benutzt und die berücksichtigt für den charge current nur den SoC Level. Jetzt ist der SoC Level bei täglichem synchronisieren noch recht zuverlässig, aber über längere Zeit kein wirklicher Maßstab. Deswegen wollte ich eigentlich auch noch berücksichtigen ob eine Zelle wegläuft oder ähnliches. Halte ich zwar bisher noch nicht für so wahrscheinlich, aber es wäre so eine Art Sicherungsmaßnahme. Möchte verhindern, dass das BMS abschaltet. Aber wie gesagt noch keine Gedanken dazu gemacht und bin jetzt erstmal unterwegs und vielleicht bleibt es auch pure Theorie.
Damit das BMS nicht abschaltet, einfach die Werte beim Multiplus/Soyo entsprechend höher wählen wo er abschaltet. Entladestrom zu begrenzen, macht aus meiner Sicht auch wenig Sinn. Da wäre es sicher sinnvoller wenn ab einem bestimmten SOC die max. abgegebene Leistung verringert wird, damit es ggf. länger hält, was aber auch egal ist, alle ist alle ob in 10min oder in 20min. Da aber dann das Netz eh einspringt, egal.
Moin, Das ist ja mal ein ganz tolles Projekt :clap: . Inzwischen läuft es auch bei mir sehr, sehr gut. Ich habe allerdings eine Weile gesucht, welche Stellen im Code geändert werden müssen, um alle Zellenspannungen übermittelt zu bekommen. Bei meinen 48V-LTO-Block sind das 22 Zellen. Es werden aber normal "nur" 16 übertragen. Das reicht ja bei LiFePo's im Normalfall auch aus. Vielleicht ist es keine schlechte Idee die Zellenanzahl mit in den UserConfig-Bereich aufzunehmen. Oder generell auf die maximal mögliche Zellenanzahl eines JKBMS (24) einstellen. Mit freundlichen Grüßen Sascha
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
