Wir wechseln das Forum am 14.11.24 12.11.24 auf die Forensoftware Discourse. Zwischen Montag Abend und Dienstag Nachmittag wird das Forum deaktiviert. Danach sind wir hoffentlich mit neuem Forum inkl. der vorhandenen Beiträge wieder am Start! Hier zum Forenbeitrag! (Datum Falsch, Tage waren richtig 😏)
Die CAN IDs sind aber vor Allem gar nicht für so etwas gedacht.
das kann man nicht unbedingt pauschal so sagen. Bei CANopen z.B. sind die Default COBs immer irgendwas + Node ID. Bei UDSonCAN bsw. sind die COB IDs auch direkt and die ECUs gebunden, eine für Request und eine für Response...
Aber ich stimme @gura zu - das gehört eigentlich nicht hier hin 😉
Die Usabiltiy ist halt dann betroffen wenn man mehrere BMS an einem Bus betreiben möchte. Der zweite Bus zum Anschalten von Slave BMS ist auch weitgehend undokumentiert und konzeptionell begrenzt. Freilich dürfte diese Batteriegröße für die meisten Heimanwender nicht relevant sein. Die Hersteller zeigen aber liebend gerne größere Containerinstallationen. Sowohl Pylon wie auch Pytes umgehen das mit einer eigenen LV-Hub Hardware. Dass das JK BMS daran mit dem nachgebauten Protokoll funktioniert möchte ich bezweifeln. @Eugenius bastelt ja an so einer Kommunikationsbox und wir machen dort weiter. Die Firma JiKong können wir hier in diesem Thread sowieso nicht sanieren und wenn es dann was Neues speziell zum JK Inverter gibt, können wir das Resultat immer noch hier posten.
Solange @eugenius nicht doch noch ein JK CAN Protokoll mit adressierbaren CAN IDs hinkriegt sehe ich nur einen (etwas komplizierten Um-) Weg über RS485 und einen USB Hub zum Betreiben mehrerer Master BMS. Das RS485 Protokoll hat in der Regel auch den Vorteil, daß mehr Infos bezüglich der Einzelzellenwerte verfügbar sind. Über den internen RS485 Bus kann das JK bis zu 15 Slaves an einem Master betreiben. Damit braucht man nur noch einen RS485 zu USB Konverter und belegt nur eine USB Buchse an einem doch relativ billigen USB Hub. USB kann man ja grundsätzlich auf n Anschlüsse kaskadieren.
Zum Glück hat das Venus OS dazu auch noch das geniale dbus Konzept aus freedesktop.org zur Interprozesskommunikation über einen Software Datenbus übernommen. Mit Serialbattery sollte man damit beliebig viele Master Batterien als Device mit Venus verbinden können ohne hierzu selbst eine Hardware löten zu müssen. Die vielen Master Batterien lassen sich dann mit einem Dbus Treiber Aggregate-Batteries zusammenfassen damit Venus über das DVCC die gemeinsame Steuerung übernehmen kann. Damit sollte dann ein von der Leistung her offenes Konzept für mehr als 16 Batterien ohne LV_Hub vorhanden sein. Zumindest wenn das mit den JKBMS so tut wie es die Projekte auf Github versprechen. Meine 3 JKBMS kommen irgendwann nächste Woche und dann kann ich das mit meinem ebenfalls noch rumliegenden Cerbo-GX einmal ausprobieren.
Für normale Inverter Deye & Co ist das natürlich etwas zuviel verlangt und diese wären weiterhin auf ein vernünftiges Protokoll angewiesen was dann auch ganz ohne zusätzliche Hardware RS485 Converter und USB Hub funktionieren könnte. Vermutlich wird es solch Protokoll aber nie geben, weil die anderen WR selbst eben auch nicht wie die Multiplus mit externen MPPTs beliebig parallelschaltbar und erweiterbar sind und damit auch keine größeren Batterien brauchen.
@Janvi, ehrlich gesagt kann ich dir immer noch nicht ganz folgen.
Wenn du nur 3 JK-BMS hast, machst du einen, Master, 2x Slaves und es läuft. Master steuert alle andere. WR Bekommt die benötigte Daten von Master.
Was willst du nun von RS485-USB Konverter? Geht es dir nur um die einzelne Zellen für die "Statistik"?
Um zu verdeutlichen was ich vor habe:
Ich habe ja mein Projekt MITPylon: https://www.akkudoktor.net/forum/open-source-software-projekte/projektvorstellung-mitpylon-man-in-the-pylon/
Da geht es darum, dass ich nur das, was JK über "PYLON" Protokoll sendet auswerte, evtl. modifiziere und weiter an WR sende. Da gibt es leider keine einzelne Zellen. Aber seit kurzen zumindest höchste und niedrigste Zelle Spannung über ALLE Akkupacks (auch Slaves)
Das was ich extra machen wollte: JK-BMS CAN Protokoll decodieren und daraus selbst PYLON Protokoll für WR erzeugen. Vorteil: so hat man Spannungen auch für einzelne Zellen von allen Akkupacks (Auch Slaves). Das hat bei mir sehr niedrige Prio.
Was die anderen schon gemacht haben: RS485 von alten JKs zu PYLON Protokoll um geschlüsselt. Das muss auch mit JK Inverter BMS gehen.
JK Inverter BMS hat seit Kurzem auch PYLON RS485 Protokoll. Da sollen auch einzelne Zellen geben (bin mir nicht sicher), auch dafür gibt es Adapter im Netz.
In allen Fällen:
- Über PYLON Protokoll gehen an den WR keine einzelnen Zell-Spannungen.
- In allen Fällen versuche ich alle Daten die kommen auch an HomeAssistant bzw. MQTT zu senden.
3 Stück sind freilich kein Problem. Das Projekt hat aber Platz für mindestens 40 JK-BMS bzw. mehr als 500kWh. Es gehen aber nur Gruppen von maximal 16 Stück. Deshalb müssen mehrere Master vorhanden sein. Die funktionieren wegen der gleichen CAN Ids aber nicht auf dem CAN Bus sondern immer nur einer. Die 3 JK BMS habe ich nur zum Ausprobieren bestellt weil das die Mindestanzahl ist um zwei Master und einen Slave zu testen. Wenn dann zwei Master gehen nehme ich an daß auch weitere funktionieren.
JK Inverter BMS hat seit Kurzem auch PYLON RS485 Protokoll. Da sollen auch einzelne Zellen geben (bin mir nicht sicher), auch dafür gibt es Adapter im Netz.
Ja, vom Protokoll her geht das prima. Meine original Pylons habe ich auch schon mit FHEM auf der RS485 ausgelesen. Da erhält man alle Daten der Einzelztellen. Leider funktioniert das nur bis 12 Stück in einer Gruppe und nicht bis 16 Stück obwohl diese ansonsten erfolgreich kaskadiert werden. Steht auch so in der Pylon RS485 Protokoll Beschreibung drin. Weil Pylontech hier auch noch weitere undokumentierte Tricksereinen mit zusätzlichen 3 Hardware Leitungen macht, nehme ich an daß die JK RS485 im Pylon Mode auch nicht auf dem Pylon LV-Hub laufen. Werde ich aber ausprobieren.
Was willst du nun von RS485-USB Konverter?
USB ist eine der wenigen billigen Möglichkeiten eine große Anzahl von Ports an den Cerbo zu kriegen. Beliebige Anzahl von CAN Ports gehen im Venus zwar auch, stelle ich mir in der HW aber gegenüber virtuellen Com Ports problematisch vor. Deshalb seriell. Sternförmig muß die Verdrahtung sowieso werden.
In allen Fällen:
- Über PYLON Protokoll gehen an den WR keine einzelnen Zell-Spannungen.
- In allen Fällen versuche ich alle Daten die kommen auch an HomeAssistant bzw. MQTT zu senden.
Das betrifft das Pylon CAN Protokoll aber nicht das RS485
MQTT geht auch über den Cerbo wenn die Daten dortselbst erst mal ankommen
Im Übrigen habe ich zwischenzeitlich ein YT-Video gefunden der genau das was ich vorhabe vorgemacht hat. Allerdings mit JBD-BMS über RS485. Müsste aber mit JK genauso gehen.
Das Projekt hat aber Platz für mindestens 40 JK-BMS bzw. mehr als 500kWh.
Du gibt's hier aber schon zu, dass das kein Standard Use Case ist? 
Aber krasses Projekt. Darf ich fragen was du da treibst?
Dann musst wohl auf 3 Master gehen und die Daten von den 3 Mastern im Cerbo zusammenführen.
So viel Information (jede einzelne Zelle von den 500kWh) würde ich einem ESP32 wahrscheinlich auch nicht zutrauen...
Standard Use Cases sind in der Definition relativ. Nur die VNBs gucken da dumm weil sie das noch nie gesehen haben und die meisten unserer blauen Freunde ihr Guerilla Dasein fristen. Treibe Stromverkauf über PPA, Gewerbenutzung, Büros, Lebensmittelproduktion, Kühlhäuser. 3 Master gibt max. 768 Einzelzellen. Bei der Menge an Rundzellen zuckt da auch kein Batteriebastler mehr zusammen. Warum also nicht mit prismatischen Zellen ? Von der Datenmenge her ist das nicht wirklich viel.
Mit was hast du das JK CAN ausprobiert?
@janvi da ich 2 JK Inverter BMS habe und den Master will ich erst mal nicht stören (da läuft MITPylon) habe ich an den SLAVE in den CAN Port den nächsten ESP32 gesteckt 
Aber so richtig zufrieden bin ich nicht... Morgen, wenn der Akku nicht gebraucht wird, versuche ich dann 2 gleichzeitig auszulesen. Mal schauen ob es mit Zellspannungen über ALLE Batterien klappt... da habe ich langsam meine Zweifel...
Und wenn man schon aufmerksam die Screenshots anschaut: Mir fehlt (auch in der Beschreibung) max. discharge current, OK, damit könnte ich noch leben
Aber die Discharge/Charge allowed sind unbekannt. Nach 2-3 Übersetzungen aus Chinesisch klingt es eher als Steuerparameter aber nicht Info... Nach dem Moto: Nicht das BMS ist soll die Info haben, sondern WR... aber das ist doch Blödsinn. BMS soll doch sagen ob geladen werden darf und WR lädt dann...
Wenn morgen auch mit den Zell-Spannungen nicht klappt, dann muss ich doch noch RS485 in Betracht ziehen 
EDIT: tja... ich sehe doch nur die Zellen von einem BMS... allgemein: über JK-CAN-Protokoll kann man nur ein BMS auslesen, auch wenn mehrere Verbunden sind, dann muss man doch auf RS485 gehen, Schade aber auch irgendwie egal.
@yanvi, kennst du übrigens das hier? Eigentlich das, was du brauchst, oder?
https://github.com/Sleeper85/esphome-jk-bms-can/tree/development
So, ich habe mal das hier https://github.com/txubelaxu/esphome-jk-bms/blob/main/esp32-S3-example-jkpb-rs485_1master_6slaves.yaml
an den internen RS485 Bus angeschlossen (doppelte RS485 Buchse um die JK untereinander zu verbinden). Was soll ich sagen, da gibt es mehr Daten als man haben will.
Wozu brauche ich Balance Wire Resistance? 
Naja, das ging schneller als ich gestern mit CAN Decoding verbracht habe. Danke geht an txublaxu!
Den Autor in Belgien und auch das Projekt und das Vorgängerprojekt kenne ich. Von ihm ist auch die Tabelle mit der herstellerübergreifenden Gegenüberstellung der verschiedenen CAN Telegramme. Im Fall von meinem Cerbo sollte es auch ohne zusätzliche ESP Hardware gehen weil die SW eben direkt auf dem Cerbo läuft. Ist eher was für die Deye Fraktion.
Wie du jetzt auch gesehen hast, sind auf RS485 viel mehr Daten verfügbar als auf CAN. Vielleicht kann man mit "WireResistance" Rückschlüsse auf die Qualität der Verbinder zwischen den Zellen ziehen? Ansonsten beeinträchtigt das vermutlich nur die 1-2Amp beim Balancieren.
@janvi Ich hatte da eine Idee, deswegen wollte ich CAN nutzen, geht nicht so wie ich das wollte, das ist auch ein Erkenntnis.
Nun, in meiner MITPylon Hardware (muss mal doch noch übernehmen) habe ich genau deswegen bis zu 2x RS485 vorgesehen. Dann wird wohl mit RS485 gearbeitet...
Ich nutze RS485 zu USB was auch funktioniert:
Mitsubishi Heavy Set Truhengerät 5,0 kW - SRF50 ZSX-W + SRC50ZSX-W2 R32 Klimaanlage im Flur Erdgeschoss
Mitsubishi Heavy Set Truhengerät 5,0 kW - SRF50 ZSX-W + SRC50ZSX-W2 R32 Klimaanlage im Flur 1. OG
Vaillant aroSTOR VWL BM 270/5 Warmwasserwärmepumpe
12kwp Trina Vertex S+ mit Hoymiles HMS 1600-4T Solar
Multiplus 2 GX 48V 5000 + 16kwh Eve MB31 Akku mit JK PB BMS
Dank USB2 und FTDI haben wir heute brauchbare virtuelle serielle Schnittstellen. Obwohl CAN im Hardwarekonzept sowohl seriell asynchron wie auch USB meilenweit vorraus ist, probiere ich CAN für diesmal erst gar nicht aus. Es wird schon aus der Beschreibung klar daß es unbrauchbar ist.
Im Foto mein RS485 Anschluss für 3 Master JK-BMS. Der Hub ist ein Exsys EX1596 HMVS. Der ist zwar nicht wirklich billig, aber noch immer günstiger als eine eigene Hardware zu entwicklen. Ich habe dieses Modell bestellt, weil man es üher den grünen Anschluss direkt aus dem 48V DC Netz versorgen kann. Man kriegt so alle 24/7 Standby Ströme ins DC Netz und kann die WR bei Bedarf über Nacht nötigenfalls auch in den Standby Modus versetzen.
Bei den Waveshare Wandlern habe ich die FTDI Version zu etwa 12 Euro genommen. Die CH430 Version ist etwa 2 Euro billiger aber Venus scheint von Haus aus hierzu wie auch für Prolific keine passenden Treiber zu haben.