zwei Batterien an einen ESP32 S3

[Jean-GO]

Hallo, ich habe eine Frage. Ich habe zwei Batterien, und jede von ihnen hat nur einen Anschluss (CAN-Anschluss). Kann ich zwei SN65HVD230-Module anschließen?

Mit einem SN65HVD230-Modul und der Einstellung Battery TX auf GPIO 27 und RX auf GPIO 14 funktioniert die Kommunikation mit einer Batterie einwandfrei. Doch wie kann ich ein weiteres SN65HVD230-Modul an denselben ESP32-S3 anschließen, um die zweite Batterie ebenfalls auszulesen?

Ja, ich könnte zwei ESP32-S3 verwenden und jede Batterie separat auslesen, aber ich möchte dies mit nur einem ESP32-S3 realisieren.

Falls das möglich ist, wie kann ich das umsetzen?
Danke schon mal im Voraus! 😊
Jean

[spcqike]

Das geht mit openDTU bisher nicht.

Du könntest, wenn es sowas gibt, einen esp nehmen um beide Batterien auszulesen und die Daten per MQTT verteilen.

OpenDTU erwartet bisher aber genau eine Batterie.

[Jean-GO]

OK, danke für die schnelle Antwort! Vielleicht gibt es in naher Zukunft eine Lösung, bei der man die Anzahl der angeschlossenen Module (Batterien) einstellen kann. Solange werde ich zwei ESP32 verwenden.

[schlimmchen]

Der ESP32, auch der S3, hat nur einen TWAI, also kann über einen VP230 nur ein CAN-Bus realisiert werden. Das ist eine hardwareseitige Einschränkung. Die Software kann es auch nicht. Und da geht dann nur etwas, wenn wir über zwei gleichartige Batterien sprechen, die man auch gleichzeitig an den gleichen Bus anschließen kann. Bisher ist das nicht auf der Agenda.

[Jean-GO]

Hallo, ja, es sind zwei gleiche Batterien und sind an einem Bus angeschlossen. Siehe Bilder.

[schlimmchen]

Wo CAN Bus?

Welches Protokoll sprechen diese Batterien? Eins das OpenDTU-OnBattery überhaupt unterstützt?

Achso, du hast schon geschrieben, dass du mit einer Batterie bereits sprechen kannst. Okay, dann... wird es and er Software scheitern. Du kannst die Batterien dann, mit geeignetem Kabel oder einer Bastellösung, auf den gleichen CAN-Bus klemmen, das ist ja nur eine Verdrahtungs-Sache. Aber dann musst du den Dingern eine eindeutige Adresse beibringen (falls sie das nicht automatisch machen) und dann wird aber OpenDTU-OnBattery nur die Daten der einen Batterie verarbeiten können.

[Jean-GO]

Mit den Einstellung und Hardware bekomme ich Daten.
Ich Lese die Daten an der RS485 aus.

[Jean-GO]

Es ist diese Platine in der Batterie verbaut
JBD-UP16S015 CON 1.21

https://www.alibaba.com/product-detail/JiaBaiDa-New-UP16S015-Smart-BMS-15s_1600944181176.html

[schlimmchen]

Das sind alles schlüssige und im Grund hilfreiche Infos, aber es bleibt dabei, dass es dann an der Software hängt: OpenDTU-OnBattery versteht es zur Zeit nicht, mit mehr als einem BMS zu sprechen, selbst wenn die am gleichen Bus hängen. CAN oder RS485 wäre hier beides elektrisch kein Problem, aber wie die Adressierung dann aussieht und was dann alles in der Software zu tun ist, ist offen. Stand heute kann OpenDTU-OnBattery das nicht. Daher brauchst du zwei ESP32(-S3). Die für den DPL wichtigen Infos, also Spannug des Gesamt-Akkus (die sind ja parallel geschaltet?), hast du schon, wenn du mit nur einem BMS redest.

[DonJohnLong]

Dazu habe ich auch noch eine frage.

Wenn man zwei Batterien hat (In meinem Fall wären dass dann 2x JK inverter Bms).

Könnte man da nicht die Master Batterie auslesen und die 2. Batterie ls Slave mit dem Master verbinden?

Hat da jemand Erfahrung wie sich das dann verhalten könnte?

Lg

[schlimmchen]

Das ist eine gute Frage. Zwei JK Inverter-BMS kann man ja mit Adressen versehen und an einen gemeinsamen CAN-Bus hängen. Bisher ist die Implementierung der JK Battery Providers aber auf das 4G-GPS Remote module Common protocol V4.2 ausgelegt. Und da weiß ich, dass es keine Adressierbarkeit gibt. Ob die BMS untereinander dennoch Daten austauschen und ob das dann Einfluss auf Daten hat, die per diesem Protokoll gesendet werden, weiß ich nicht. Manche Singe wie Alarme könnte man sinnvoll dareinverwursteln, auch wenn sie von einem anderen BMS erzeugt werden, aber die Spannung aller Zellen über alle BMS wird beispielsweise nicht sichtbar werden, behaupte ich.

[Snoopy-HSS]

Ich habe mit mit einem ESP32 ein "zwischen BMS" erstellt um an die OpenDTU 6 Batterien anschliessen zu können.
1x TWAI um mit der OpenDTU zu sprechen und ein BMS zu simulieren und 6x MCP2515 um mit den Batterien über die 2 SPI Schnittstellen und je 3 MCP2515 zu sprechen.

Und es muss ein S3 sein, die "normalen" ESP32 haben keine 2 freien SPI...

Oder man nimmt den C6, der kann 2 twai und 2 SPI mit je 5 Slaves, also 11 Batterien, der unterstützt aber arduino Framework nicht so gerne...

Geht einwandfrei, braucht aber tiefere Kenntnisse...

[schlimmchen]

Wenn du diesen Aufwand betreibst, was nachvollziehbar ist, dann hättest du dir aber auch die Mühe (oder meiner Einschätzung ahc: Erleichterung) machen können, alle sechs an einen Bus zu hängen mit nur einem MCP2515, um dann die Daten im deinem Zwischen-BMS zu aggregieren. Ich verstehe den Sinn hinter den 6 Stück MCP2515 nicht... Sind diese 6 BMS nicht addressierbar und dadurch unterscheidbar? Wenn sie CAN sprechen, hätte ich das erwartet.

[Snoopy-HSS]

leider nicht einzeln addressbar, hatten wir schon mal in einer anderen Diskusion.
Oder Firmware für jedes einzelne Pack umschreiben, was die Austauschbarkeit schwierig macht...

Sieht für 12 Batterien so aus...
Incl. Directanschluss für Victron Multiplus.

[schlimmchen]

leider nicht einzeln addressbar

Na das ist ja Mist.

hatten wir schon mal in einer anderen Diskusion

Sorry, erinnere mich nicht mehr dran 😉

Oder Firmware für jedes einzelne Pack umschreiben

Ne, das ist natürlich auch Mist.

Sieht für 12 Batterien so aus...

Sehr spannend! Ich nörgel trotzdem: Mit ein paar Zeilen Code hätte man doch sicherlich noch die Chip-Select Pins multiplexen können, sodass nur ein ESP32 nötig gewesen wäre?

Spucken die BMS Nachrichten spontan/asynchron aus? Dann ist es natürlich sportlich, die rechtzeitig einzusammeln.

Reichen die IRQs an einem ESP32?

Sehr spannend. Aber wie gesagt ziemlich lame von den Packs, dass sie CAN sprechen, aber von Adressierung nichts wissen wollen...

[Snoopy-HSS]

Ja, man muss nehmen, was da ist.
Die spucken alle 10ms die werte aus. Sporadisch je nach "Boot"-Zeit des BMS.
Ich lese die MCP2515 ohne IRQ, da der Verlust von ein paar Werten vernachlässigbar ist.
Aber IRQ Pins wären dank S3 ja noch genügend frei.
Die Paketanzahl ist ja recht begrenzt, da nur 1 Gerät je CAN Channel.
Nach etwas optimieren, kam es auch zu keinen Buffer Overflow mehr bei den CAN Controllern. 5 Nachrichten speichern die ja auch ab...
Bei einer Ausgaberate von 500ms kommen ja 50 Werte bis die OpenDTU Nachricht erhält. Da fällt einer weniger nicht auf...
Auf CS Multiplexen hatte ich keine Lust, hätte ja nur einen ESP32 sparen können, nicht aber die MCP und die CAN Transceiver. Dafür hätte es aber IO extender gebraucht...
Platine wäre aufgrund der Stecker etc. auch nicht wesentlich kleiner geworden.
Und ob die CPU von einem ESP dann 12 Batterien + Umrechnung und Ausgabe auf dem TWAI geschafft hätte?!

[Snoopy-HSS]

die beiden ESP haben die gleiche Firmware und werden über Weboberfläche als Master oder Slave konfiguriert

[Snoopy-HSS]

Oder du hängst beide Batterien parallel und liest nur eine per CAN aus. die andere kann ja was Spannung und SoC angeht nicht abwandern. Bestenfalls die Temperatur wäre interessant von beiden Batterien...

[schlimmchen]

Die Spannung kann bei Parallelschaltung an den Packs nicht driften, korrekt. Aber der SoC sehr wohl. Auch die Verteilungs der Spannungen auf die einzelnen Zellen kann stark abweichen und interessant sein, um vorzeitige Ausfälle zu erkennen. Auch wie sich der Strom durch die einzelnen Packs aufteilt, kann aufschlussreich sein.

[Snoopy-HSS]

Ja, da hast du recht.
Aber wie viel % das bei baugleichen, gleich alten Packs passiert?!

[schlimmchen]

Sicherlich vernachlässigbar, bis die Zellen plötzlich stark unterschiedlich altern.