👍🏻
BMS: JK_PB2A16S15P FW 14.20
Akku: LiFePo4 16 x 200Ah 48V
Laderegler: Victron 150/60
Inverter: Victron MultiPuls 2 48/3000/32
Solarmodule: 4 x Q.PEAK DUO-G8 355; 3 x 380W JA SOLAR; 3 x DHM-60L9(BW)-380W
Strings: 3s3p
Moin,
ab der neuen Venus OS beta (3.00~20) verden jetzt mehrere unterschiedliche Can-Protokolle angeboten.
Könnte die mal jemand freundlicher Weise testen.
Gruß,
luphi
Hallo zusammen, ich bin Martin. Ich habe heute mein JK BMS bekommen und im Keller hängt ein Multiplus GX an der Wand. Auch ich möchte beide zur Kommunikation bringen. Die verbindung hätte ich gerne potentialfrei - daher bietet sich das CAN Netz an. Ich bin eher Techniker denn Programmierer daher fange ich erst mal technisch an. Weis jemand wie das CAN funktioniert? ist das ein Ring oder ein Bus System ? Wieviele Pole. Mein JK BMS hat zwei verschiedene Buchsen. Die Buchsen CAN/RS485 und GPS sind unterschiedlich. Die CAN Buchse scheint noch kleiner und mit Halteklammer zu sein. Wie sind bitte die Typenbezeichnungen von JST? Ich möchte erst mal die nötige Hardware kaufen (konfektionierte Stecker) . Auf Victron Seite sei das der JST PH 2.0-4 Pin. Kann bitte jemand einen link geben zu dem Git des BCS? Solaranzeige auf einem RPI habe ich auch am laufen. Wobei mir dieses USB Stecker umgewandel nicht gefällt . Ideal finde ich einen RS485 Host oder eben einen CAN-Host und daran klinken sich die ID´s ein. So - funktioniert das wohl in der Industrie und so ist das wohl auch gedacht. Danke für das gemeinsame Forum
Hallo dv2000,
CAN ist ein serieller differentieller Feldbus bestehend aus zwei, am besten verdrillten, Adern CAN_H und CAN_L.
CAN ist ein relativ störsicher, da er differentielle Spannungspegel hat. Selbst beim Ausfall einer Ader kann theoretisch noch gegen Masse ausgewertet werden.
Störsicher hat aber nichts mit potentialfrei zu tun, das kommt auch den Aufbau und die Beschaltung an. CAN ist nur ein Bus und hat daher nichts mit potentialfrei zu tun. Prinzipiell lässt sich jedes Signal potentialfrei übertragen.
Zur Topologie: Der CAN-Bus wird im normal Linienförmig aufgebaut und hat am Anfang und Ende einen Abschlusswiderstand um Reflektionen zu vermeiden.
Auch ein Ring ist ein Bus! Es ist kein entweder Ring oder Bus. Ein Bus wird meistens dann zum Ring gemacht, wenn es um Redundanz geht. Dies wird z.B. beim Profinet so gemacht, aber auch bei vielen anderen Bussystemen.
Ich weiß jetzt nich was du alles zum CAN-Bus wissen willst. Das könnte ein Roman werde;-)
Der Link zum BSC auf github steht in meiner Signatur.
Ein möglicher Aufbau wäre:
JK-BMS --RS485--> BSC --CAN--> Wechselrichter
An den BSC kannst du drei serielle (RS485) BMSen anschließen.
Hallo,
ich habe mein JK-BMS bekommen - in der "mit CAN" Version.
Ich kann den CAN Port nicht zum leben erwecken. Kann einer bestätigen das er überhaupt funktioniert?
Loggen jeglicher Kommunikation mit esphome hat nicht funktioniert.
Ich bin da jetzt mit dem Oszilloskop dran. Da kommt überhaupt nix.
Laut eigestelltem JK Protokoll (250kbit oder 512 kbit) sollte ja mal was kommen.
Hat einer eine Idee?
MfG
Hallo,
ich kann bestätigen das die CAN-Bus Schnittstellen grundsätzlich funktionieren. Ich gebe euch jedoch gleich den guten Rat: vergesst den Gedanken ein BMS per Can Bus direkt mit einem Victron Gerät zu verbinden.
Warum?
Die meisten China BMSse haben nur einen rudimentär implementiertes CAN Bus Protokoll. Ich habe das ausgiebig getestet. Die Daten die per CAN bereit gestellt werden sind vom Umfang auch geringer als welche per RS 485 bzw. UART. Victron kann auch nur ein Haupt BMS verwalten. Das heißt wenn man mehr als ein BMS anschließen möchte wird ein Aggregator benötigt, welcher alle BMSse zu einer Gesamt-Batterie zur Verfügung stellt.
Es gibt einige Lösungen die hier im Thred bereits genannt wurden, die alle immer die Daten per Seriellem Protokoll vereinen und dann auch unter anderem auch per möglichem CAN an Victron zur Verfügung stellen. Wenn Ihr eine fertige Lösung wollt müsst Ihr euch REC BMS, 123 BMS oder Boostech BMS ansehen.
Jetzt zur Begründung warum das so ist:
Die China BMS ermöglichen bis Dato keinen echten Broadcast. Deswegen kann auch am CÁN Port nichts gemessen werden. Wenn Du allerdings einen CAN BUS zum BMS mittels Adapter vom Computer aufbaust kannst Du das testen.
Das BMS antwortet auf die Identifier ID ohne Daten mit der ID mit Daten. z.B. JK 0x05F4 --> 0x05F4 48 06 2F 01 3F
Mehr nicht. Außerdem kann aufgrund der nicht implementierten Slave ID auch nicht mehr als 1 BMS am BUS verwendet werden, da alle Slaves gleich antworten würden. Es macht also keinen Sinn einen Treiber für CAN im Venus OS zu schreiben der diese Kommunikation ermöglicht.
Falls Du allerdings nur 1 BMS anschießen möchtest kannst du das per CAN mit dbusSerialBattery bereits jetzt mit DALY oder JK machen.
Gruß
Daniel
hallo Daniel,
für einen Neuling weißt du aber viel, hört sich erst mal plausibel an was du erzählst, obwohl, gib mal mehr Infos zu deinem background und deinem Wissen zu bms, Akku, Victron usw.
Hallo,
nun ja ich bin Neuling hier im Forum, das stimmt. Auf dem Gebiet der Elektrotechnik allerdings nicht. Ich bin Elektromaschinenbauer und beschäftige mich schon lange mit dem Thema PV, Speicher usw. Ich bin heute im Bereich Steuer- und Automatisierungstechnik tätig.
Meine Antwort oben war auch ein wenig zusammengefasst, da ich nicht so gerne Romane schreibe. Im Grunde bin ich oft geschockt was für Sachen im Bereich BMS und Akku gerade von Leien zusammengebaut wird. Da von sehr vielen DIY Projekten eine erhebliche Brandlast ausgeht. z.B. durch die Verwendung von nicht isolierten Schnittstellenadaptern. Deswegen habe ich ich mich entschieden hier mal anzumelden.
Außerdem kann aufgrund der nicht implementierten Slave ID auch nicht mehr als 1 BMS am BUS verwendet werden, da alle Slaves gleich antworten würden.
Wie oder warum funktioniert denn das Can Protokoll dann bei Victron mit Pylontech? Zumindest tut es das bis zu 16 Batterien bzw. BMS-en OHNE daß an diesen auch nur irgend eine CAN Adresse eingestellt werden müsste. Man muß nur sagen, welches der "Master" ist. CAN - technisch sollte aber eigentlich Victron der Master sein. Ich habe mir noch nicht die Mühe gemacht auf dem Bus mit zu Tracen.
Außerdem ist es mir völlig unklar, weshalb auch Pylontech bei mehr als 16 CAN Busteilnehmern dann auch noch einen LV-Hub benötigt. Jeder normale CAN Identifier hat ja wenigstens 12 bit. Der Vorteil von CAN HW ist ja gerade, daß die ID in der HW dekodiert werden kann und nicht der gesamte Busverkehr eine Rechenlast zum Ausfiltern erzeugt. Die mit 500kbit zur Verfügung stehende Bandbreite sollte auch nicht das Problem sein. Es scheint mir daher, daß es auch bei dem als einer der am besten bewährten Kompabilitäten von Victron-Pylontech doch noch erhebliche Mängel im Konzept gibt. Andere BMSen verschlimmbessern das dann noch indem sie es nur unvollständig nachbilden.
Diverse Pylon Anleitungen mit Einschaltreihenfolgen und Piepsen und Einstecken usw. zur Detektierung von mehr als 16 Batterien sind ja auch haarsträubend. Ein vernünftiges Protokoll-Design scheint ebenso Mangelware wie irgendein halbwegs brauchbares Open Source BMS zu sein. Dabei gäbe es mit Kicad, GCC, Git & Co heute alle Voraussetzungen die Manpower von hunderten Batteriefricklern zu bündeln anstelle auf irgendwelche undokumentierten JK oder Seplos zu setzen.
Na dann viel spass hier,
Ach, ja, bitte unbedingt im Vorstellungsforum ein "Hallo Welt", am besten mit Vorstellung deiner Anlage.
Im Grunde bin ich oft geschockt was für Sachen im Bereich BMS und Akku gerade von Leien zusammengebaut wird. Da von sehr vielen DIY Projekten eine erhebliche Brandlast ausgeht. z.B. durch die Verwendung von nicht isolierten Schnittstellenadaptern. Deswegen habe ich ich mich entschieden hier mal anzumelden.
Du hast Dir die Frage im Grunde selbst beantwortet. Der Pylontech Master kommuniziert mit Victron per CAN und übermittelt die Daten des Batterie Arrays. Der Master ist Aggregator und stellt diesen Victron als eine große Batterie dar. Ab 16 Batterien in einem Array brauchst Du dann einen LV-Hub. Der LV-Hub ist dann wieder ein Aggregator und stellt Victron wiederum eine große Batterie dar.
Es kommuniziert immer nur der Master per CAN mit Victron.
Das selbe kannst Du auch mit Seplos machen. Seplos spricht Pylontech Protokoll. Die einzelnen BMS untereinander sprechen über RS 485. Verbindung per CAN zu Victron.
Ich kann Dir zustimmen das es derzeit meiner Meinung nach noch keine super perfekte Lösung gibt. Das liegt aber auch daran, das dieses Ganze Thema noch sehr jung ist. Es bleibt abzuwarten das sich in der Zukunft ein "Standard" ausbildet. Die Hersteller haben daran meist gar kein Interesse daran und verkaufen lieber eigene geschossene Systeme. Wenn dann bilden sich Standards aus einer Marktlage oder vom Gesetzgeber bzw. Normungungen. Victron hat einen genialen Schachzug begangen das Venus OS teilweise zu öffnen und public zu machen. Wenn das nicht wäre, hätten wir sehr viele Möglichkeiten in diesem System garnicht.
Der CAN-Bus ist beispielsweise schon relativ alt. Es gibt diverse Standards, jedoch nicht einen solchen, das jegliche Geräte einfach mal eben so miteinander verbunden werden können.
In unserem Falle ist es grundsätzlich immer so, das entweder das Batteriemangement selbst die Aggregation durchführt und diese Daten dann an das übergeordnete System übergibt, oder jedes BMS einzeln seine Daten übermittelt und dann im Übergeordneten System die Aggregation stattfindet. Das sind grundsätzliche Entscheidungen.
Der CAN-Bus ermöglicht das. Es sind entweder 11-bit oder 29-bit Identifier. Damit kann natürlich jedem BMS eine eindeutige Identifizierung gegeben werden. Diese würden dann abgefragt und Aggregiert.
Ich habe mal einen Versuch mit JBD gestartet und ein spezielles Bus Protokoll mit einem Entwickler von JBD entwickelt welches in der Firmware des BMSes steckte. Basierend auf dem von Luis van der Walt geschrieben Treibers DbusSerialBattery. Den habe ich soweit angepasst und die Daten per DBus im Venus OS zur Verfügung gestellt. Das hat auch grundsätzlich funktioniert. Ich habe auch den CRC16 Checksummen-Check mit implementiert. Jedoch habe ich letztendlich aufgegeben. Zum einen legen die Chinesen nichts gänzlich offen und die Kommunikation mit den schlauen Köpfen ist schwierig, da diese meist kein Englisch sprechen.
Ab einer Anzahl von 6 Teilnehmern am Bus kam es zu Kommunikationsproblemen. Im CAN-Bus ist klar geregelt was passiert wenn 2 oder mehr Teilnehmer gleichzeitig antworten. Der Teilnehmer mit dem niedrigeren Identifier erhält Vorrang und der oder die höherwertigen müssen ihre Antwort erneut senden. Dabei kam es zu Problemen die im BMS lagen. Es war mir dann zu mühsam und zu zeitaufwendig da weiter zu machen. Vor allem weil ich auf die Chinesen angewiesen war. Ich will garnicht nachrechnen wie viele Stunden ich da investiert habe.
Danke, so wird das etwas klarer. Man könnte sich ja vielleicht an Can-Open orientieren oder auch nur ein kleines Subset davon für die Batterie welches sich dann als quasi Standard durchsetzt. Einfach ein paar wenige Objektnummer für SDO/PDO. Muß ja nicht mal im elitären CiA Verein registriert sein. Die Chinesen bauen das dann schon alleine nach. Aber immerhin verdient sich beim Verkauf einer LV-Hub Hardware wohl mehr als an der Batterie selbst. Da von den Akkufricklern praktisch kaum einer dabei ist welcher mehr als ein BMS hat, ist ein vernünftiges Protokoll bei den Herstellern bislang halt auch kein Thema. Komischerweise kriegt Varta hier bei mir vor der Haustüre aber auch nichts brauchbares gebacken. Die wollen wohl nur Komplettlösungen in Schränken mit WR als Black Box verkaufen und kommen damit zu Recht nirgends am Markt an.