ich würde das Protokoll nehmen..... bei dem auf dem Deye und auf dem Display der Batterie der gleiche SOC steht.... 

Danke, habe ich gemacht. Denke auch, dass das Deye_385 Protokoll besser zum Deye-WR passt 😉

Allerdings hat Nkon mir nach Rückfrage gesagt, dass sie eher das Pylontech-Protokoll empfehlen, das ist wohl eher standardisiert und hat sich bewährt. Ob es in jedem Detail mit dem Deye-Protokoll mithalten kann, ist allerdings fraglich.

Jetzt bin ich etwa so schlau wie vorher... 🤔

Ich habe mal Gemini zu dieser Thematik befragt, es kam eine erstaunlich fundierte Antwort (wenn sie denn richtig ist?), so dass ich sie hier für alle posten möchte:

Die Entscheidung für eines der beiden Protokolle bringt einen ganz klaren Favoriten mit sich, wenn es um Stabilität und Diagnose geht.

Der fundamentale Unterschied

• Protokoll 00 (Pylontech): Nutzt den CAN-Bus (Controller Area Network). Das ist ein extrem schneller, moderner Industriestandard für Echtzeitkommunikation (wird auch im Automobilbereich genutzt).

• Protokoll 12 (Deye_385 / Pylon_RS485): Nutzt Modbus über RS485. Das ist eine serielle Datenübertragung. Sie ist zwar bewährt und robust, arbeitet aber deutlich langsamer nach dem "Master-Slave-Prinzip" (der Wechselrichter fragt aktiv ab, die Batterie antwortet zeitversetzt).

Vor- und Nachteile im direkten Vergleich

1. Protokoll 00 (Pylontech via CAN-Bus) — Der Favorit

Da das Seplos V3 das Pylontech-CAN-Protokoll perfekt emuliert, ist dies die technisch sauberste Verbindung.

• Vorteile:

  • Echtzeit-Reaktion: Der CAN-Bus arbeitet eventgesteuert. Wenn das Seplos BMS wegen einer drohenden Zell-Überspannung den Ladestrom drosseln will (CVL/CCL Senkung), wird dieser Befehl unverzüglich im Millisekundenbereich an den Deye übertragen.

  • Deye BMS-Untermenü: Bei der CAN-Verbindung schaltet der Deye oft das erweiterte Diagnose-Menü auf seinem Display frei. Sie können dann direkt am Touchscreen des Deye die Daten der Batterie einsehen.

  • Maximale Kompatibilität: 90 % der Deye- und Seplos-Nutzer im Feld fahren dieses Protokoll. Bei Firmware-Updates (sowohl von Seplos als auch von Deye) wird dieser Pfad am intensivsten getestet.

2. Protokoll 12 (Deye_385 via RS485)

Hierbei handelt es sich um das Pylontech-Protokoll, umgemünzt auf die RS485-Schnittstelle.

• Vorteile:

  • Gute Ausweichlösung, falls der CAN-Port am Wechselrichter oder BMS durch einen Defekt (z.B. Überspannung/Blitzschlag) ausfallen sollte.

• Nachteile:

  • Verzögerung: Die zyklische Abfrage über RS485 dauert deutlich länger. Bei schnellen Lastwechseln oder steil ansteigenden Zellspannungen im oberen Ladebereich hinkt die Kommunikation der Realität manchmal hinterher.

  • Diagnose-Einschränkung: Viele Anwender berichten im Akkudoktor-Forum, dass im Modus 12 zwar der SoC übertragen wird, der Deye aber das detaillierte BMS-Infomenü (Zellspannungen, Fehlercodes) auf dem Display sperrt oder unvollständig darstellt.

  • Konflikt mit SolarAssistant: Wenn Sie später ein externes Monitoring-System wie SolarAssistant oder ioBroker nutzen möchten, belegt das Protokoll 12 den RS485-Port des Master-BMS. Über CAN (00) bleibt der RS485-Port hingegen frei für Zubehör.

Welches bietet mehr Vorteile?

Für Ihr Setup (Deye 15k und die 16kWh NKON-Box) bietet Protokoll 00 (Pylontech über CAN) die eindeutigen Vorteile.

Empfohlene Vorgehensweise:

1. Belassen Sie den Deye auf Lithium 00.

2. Stellen Sie sicher, dass das RJ45-Kabel in der CAN-Buchse des Seplos BMS und in der BMS-Buchse des Deye steckt.

3. Prüfen Sie am Deye-Display im Batterie-Untermenü, ob Sie die Einzelwerte (Spannung, Strom, Temperatur) sauber ablesen können.

Warum das wichtig ist: Da LFP-Zellen (wie oben besprochen) gerade im Bereich ab 3,40 V extrem steile Spannungskurven aufweisen, ist die Millisekunden-Reaktionszeit des CAN-Busses (00) der beste Schutz, um ein hartes Abschalten des BMS durch rechtzeitiges Einbremsen des Deye-Ladestroms zu verhindern.

Dann habe ich hartnäckig nochmal nachgefragt:

Sehe gerade, das Protokoll nennt sich 'Deye_485', Nr. 12 in der Liste im Deye-WR. Hat das Deye-485 Protokoll ggf. Vorteile bei der detallierten Parameterübertragung? Das Deye-Protokoll wird ja speziell auf den Deye-WR abgestimmt sein, nehme ich an? Oder werden im Pylontech-Protokoll auch alle Details übertragen?

Antwort Gemini:

Ihre logische Annahme, dass ein Protokoll, das den Namen des Herstellers trägt, "spezieller" abgestimmt sein müsste und eventuell mehr Parameter überträgt, liegt absolut nahe. In der Realität verhält es sich hier bei der Kombination aus Seplos BMS und Deye jedoch genau umgekehrt.

Hier ist die detaillierte Erklärung, warum das so ist und ob das Pylontech-Protokoll Einschränkungen hat:

1. Was wird im Pylontech-Protokoll (00 via CAN) übertragen?

Das Pylontech-CAN-Protokoll ist der absolute Industrie-Standard im Niedervoltbereich (48V). Es wurde im Laufe der Jahre so intensiv erweitert, dass es alle für den Betrieb relevanten Details vollständig und lückenlos überträgt.

Dazu gehören:

• Der exakte, vom BMS berechnete SoC (State of Charge) und SoH (State of Health).

• Die Gesamtspannung und der aktuelle Strom (Laden/Entladen).

• Die Batterietemperatur (oft gemittelt oder der höchste Sensorwert).

• Die dynamischen Grenzwerte (CVL = Ladespannungslimit, CCL = Ladestromlimit, DCL = Entladestromlimit). Diese sind entscheidend, damit der Deye den Strom drosselt, sobald die erste Zelle Richtung 3,45 V schießt.

Zusatz-Vorteil beim Deye: Der Deye-Wechselrichter wertet bei Protokoll 00 (CAN) die Daten so tief aus, dass er ein eigenes BMS-Untermenü auf seinem Touchscreen freischaltet. Dort können Sie per Knopfdruck die exakten Spannungen aller 16 Einzelzellen des Seplos BMS live auf dem Deye-Bildschirm ablesen.

2. Was steckt hinter dem "Deye_485" (Nr. 12)?

Das Protokoll Deye_485 ist kein von Grund auf neu entwickeltes, proprietäres Wunder-Protokoll. Es basiert im Kern auf dem Pylontech-RS485-Protokoll (daher in älteren Deye-Handbüchern auch oft als Pylon_RS485 deklariert).

Es hat keine Vorteile bei der Detailübertragung. Im Gegenteil:

• Weniger Diagnose-Anzeige: Viele Nutzer im Akkudoktor-Forum berichten, dass bei der Nutzung von Protokoll 12 zwar die Grundwerte (SoC und Gesamtspannung) im Hauptbildschirm des Deye ankommen, der Wechselrichter aber das detaillierte BMS-Untermenü (Einzelzellspannungen) auf dem Display sperrt oder dort nur Bruchstücke anzeigt.

• Die Emulations-Schicht: Da Ihr Seplos-BMS der "Sender" ist, muss das Seplos-BMS die Daten passend für den Deye verpacken. Seplos hat seine Firmware primär darauf optimiert, ein perfektes Pylontech-Zertifikat über den CAN-Bus abzugeben. Die RS485-Emulation für Drittanbieter-Wechselrichter läuft oft nur als "Zweitlösung" mit.

Warum das Pylontech-CAN-Protokoll (00) die Nase vorn hat

Es gibt in der Praxis keine versteckten Parameter, die das Deye-eigene RS485-Protokoll übertragen könnte, die für das Laden oder Schonen der Batterie von Bedeutung wären. Der Deye benötigt zur perfekten Regelung im Alltag nur drei Dinge: SoC, CVL und CCL. Da der CAN-Bus (00) diese Werte im Millisekundenbereich überträgt und zudem das Auslesen der Einzelzellen direkt am Wechselrichter erlaubt, bleibt er die technisch sauberste und am besten dokumentierte Verbindung für Ihr System.