JK CAN Protokoll schnell mal ausprobiert:
Du gibt's hier aber schon zu, dass das kein Standard Use Case ist? {green}:laugh:
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 {green}
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 {green}:fighting:
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?
So, ich habe mal das hier esphome-jk-bms/esp32-S3-example-jkpb-rs485_1master_6slaves.yaml at main · txubelaxu/esphome-jk-bms · GitHub
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? {green}:amazed:
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...
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.
1 „Gefällt mir“
@janvi Alles richtig gemacht!
Mit VenusOS kann man echt coole Sachen machen 
1 „Gefällt mir“
Heute habe ich aus einer Parallelschaltung von 32 US5000 Racks mit CAN Bus im laufenden Betrieb einen Slave in der Mitte entnommen. Hierbei macht das originale Pylon CAN Protokoll folgendes:
-
Venus zeigt anstelle 32 Batterien nur noch 31 Stück an. Das ist soweit auch wie erwartet.
-
Bei der Master Batterie der Gruppe mit einem entnommenen Slave geht die rote Error Lampe an. Die Master Batterie schaltet lt. LED der Ladezustandsanzeige seine DFET ab. Die anderen noch verbleibenden Slaves schalten nicht ab. Das müsste zwar nicht sein, wäre aber auch noch ok
-
Weder der Cerbo noch der LV_Hub merken aber von Vorgang 2) irgendwas. Der Hub erkennt weiterhin 2 Gruppen. Venus zeigt weiter laufend aktualisierte Werte an. Das fatale ist aber, daß einer der angezeigten Werte (Zelle mit niedrigster Spannung) von einer Zelle des längst entfernte Racks stammt. Das ist ein fataler Fehler weil dafür entsprechende Folgefehler mit falschen Ladevorgängen passieren können.
Erst wenn man die Master von allen Gruppen und dann den LV Hub neu bootet, passt die Venus Anzeige wieder. Das ist nicht gerade das was man sich als Anwender vom einem hochpreisigen Heimspeicher in sicherheitskritischer Anwendung erhofft. JK bindet die Slaves ja nicht mit einem getrennten CAN sondern mit einem getrennten RS485 an. Das CAN Protokoll kann als Nachbau bei JK aber kaum besser funktionieren wie das Original.
Heute habe ich mir mal das RV-C Protokoll angeschaut. Es steht für Recreation Vehicle CAN. Als Gegenstück zum Yachtbetrieb mit NMEA2000 wurde es für Wohnmobile entworfen.
Es gibt gleich mehrere lukrative Eigenschaften von diesem Protokoll:
-
In neueren Venus Versionen wird dieses Protokoll von Victron bereits eingebaut.
-
Es hat viele Ähnlichkeiten mit NMEA und kann unter Umständen mit diesem sogar auf einem Bus gleichzeitig betrieben werden
Da werde ich mich mal etwas näher damit beschäftigen. Batterien werden ab Seite 473 erklärt.
Das hat nun aber wirklich nichts mehr mit JK BMS zu tun...
Nein, leider kanns JK nicht. Könnte ja aber noch kommen falls die Wohnmobil Szene als neue Kundengruppe anspringt.