-
-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seplov V16-10E Multi Pack #116
Comments
To which and how many RS485 ports did you attach the ESP? |
The BMS are cascaded: master pack RS485->pack1->pack2->ESP32 TTL RS485 adaptor So there are four devices on the RS485, three Seplos and the ESP (connected to pack 2). Dip switches according to Seplos documentation: Master: Dip 6 on (master for three packs) protocol version 0x20, 19200 baud |
Could you share your configuration YAML? In worst-case you have two Modbus masters on the same bus at the moment. |
Sure, here we go:
|
I forgot: Thank you for your fast reaction! |
Let's talk german to speed things up. :-) Aktuell hast du zwei Geräte auf dem Bus, welche die Master-Rolle einnehmen. Ich versuche kurz zu beschrieben, wie es normalerweise aussieht und an welcher Stelle dein Setup von diesem Konzept abweicht: Normalerweise hat man einen aktiven Master auf dem Bus. Dieser pollt nacheinander alle Slaves und bittet einen nach dem anderen um eine Meldung. Die Slaves nehmen also eine passive Rolle ein und dürfen nur sprechen, wenn sie kurz vorher aufgefordert wurden. Wenn sich alle Partner an diese Regeln halten sollte es keine Kollisionen auf dem Bus geben. Gesprochen wird immer nur, wenn man gefragt wurde. Stellt man ein Seplos BMS auf die Adresse Du hast nun einen zweiten Master an den Bus gehangen. Dieser quatscht periodisch dazwischen und fordert ebenfalls einzelne Packs auf etwas über sich zu verraten. Kollisionen sind deshalb vorprogrammiert und im schlimmsten Fall verschluckt sich sogar die Seplos Firmware, welche bereits die Master-Rolle einnimmt (ist nur eine These!), weil sie auf eine Frage eine völlig falsche Antwort erhält. Es gibt jetzt zwei Möglichkeiten:
|
OK, verstehe ich und werde die Variante "never" nutzen und eben halt nur lauschen, denn der WR braucht die aggregierten Infos aus dem Gesamtpaket bzw. soll sie bekommen. Mir war nicht klar, daß der ESP sich zum Master aufschwingt und bedanke mich für den Hinweis. Hab ich mir ganz ehrlich auch keine Gedanken drum gemacht, läuft halt. Was mir nur aufgefallen ist: Laut Warnings sendet ein Geräte mit Adresse 0x03 iwas an Daten. Könnte das der Master sein, der ja bei Seplos unter 0x00 nicht erreichbar ist (selbst von deren PC-Software aus nicht) und wären die iwie nutzbar? Das, was mich interessieren würde, wäre der SOC des Master, da die drei Dinger mit ihrem SOC sehr weit driften, die Shunts scheinen nicht besonders akkurat zu sein (oder die AD-Wandler). Volladungen sind mit meiner kleine Anlage nicht sehr häufig, so daß deren "Selbstkalibrierungen" zum Ladeende manchmal zeitlich weit auseinander liegen. Ich greife sporadisch manuell ein um die wieder auf einen realen Wert zu setzen. Nur ist die Menschheit von Natur aus faul, so auch ich, und würde mir den Weg in den Keller für den Blick auf die Anzeige der BMS sparen wollen. Aber ist ein ganz klares nice-to-have! |
Lass uns gerne den Verkehr auf dem Bus genauer unter die Lupe nehmen. Dein kurzer Logauszug oben enthielt nur zwei Frames von Slave https://github.com/syssi/esphome-seplos-bms?tab=readme-ov-file#debugging Kannst du einen weiteren Logauszug zur Verfügung stellen, welcher die Warnung als auch die Debug-Ausgaben enthält? |
Danke für den Hinweis, mit tieferem Hinsehen hätte ich schon im Vorwege sehen können, daß der angemeckerte Datensatz tatsächlich vom Slave 1 kommt. Ein Debug-Log kann ich gerne machen. Nur ist die Frage, macht das Sinn? Der von mir aufgefangene Snippet ist wohl eine Antwort auf eine Anfrage des Masters, Function Code 5A (Byte 3) kann ich in der Doku des Protokolles V 2.0 nicht finden. Hab jetzt grad mal probeweise nur gelauscht, keinerlei verständlicher Verkehr mehr. |
Die Kommunikation gibt es in vielen Ausprägungen, deshalb wäre ein Mitschnitt spannend als Basis für eine Diskussion. :-) Die paar nicht dekodierbaren Frames von Slave Trotzdem finde ich spannend, was das Gerät |
Soderle, aus akademischem Interesse den ESP auf Lauschangriff gestellt, es werden im Sekundentakt vom Slave 1 und Slave 2 wohl cummulierte Daten gesendet, ein Gerät mit Adresse 0x03 taucht dabei nicht auf:
Jetzt stelle ich den ESP mal auf sabbeln und logge das dann wieder mit. ...to be continued... |
Soderle, mit der Doku des Protokolls 2.0 in der Hand, ESP auf sabbeln gesstellt, schön an diesem Snippet zu sehen, der Request an Slave 2 zum Senden der Telemetriedaten (Function Code 42) durch den ESP wird sauber vom Slave 2 beantwortet mit einem Datensatz in der zu erwartenden Länge von 81 Bytes, Function Code 00 für alles iO:
Der Datensatz mit Null Daten scheint mit Function Code 5A die Aufforderung des Master an die Slaves zu sein, cummulierte Daten zu senden, die auch prompt beantwortet wird, ebenfalls mit 5A an entsprechender Stelle. Das bleibt auch so, wenn der ESP dazwischensabbelt. Imho ist damit eigentlich keine Kollision zweier Master zu befürchten, da über die Funktion eindeutig gesagt wird, wer was haben will und es auch mundgerecht geliefert bekommt. Oder? Nur schade, daß vom Master tatsächlich nix aufzutauchen scheintaußer seinen Requests. Die Meldung "0x03" buche ich mal unter geshreddertem Datensatz ab. |
...sollte der Wunsch nach nem längeren Logging bestehen - interessehalber - würde ich den ESP auf einen anderen MQTT Broker hetzen zum Loggen, da ich bei der Menge an Meldungen Störung in meinem Smarthome befürchte. Die Hardware, auf dem das Ding läuft,ist nicht besonders leistungsfähig... |
Mit Kollisionen meine ich "gleichzeitiges Senden". Dieses Risiko besteht unmittelbar, sobald mehr als ein Master auf dem Bus unterwegs ist. Du kannst dir die Kommunikation wie Zeitslots vorstellen. Im ersten Zeitfenster (z.B. 250ms) sendet der Master einen Request. Im naechsten Fenster (250ms) antwortet der Slave. Hoert der Master 250ms lang keine Antwort, dann ist die Frage entweder verloren gegangen oder der adressierte Slave existiert nicht auf dem Bus. In einer anderen Disziplin ist deine Annahme aber richtig: Die Wahrscheinlichkeit, dass der Master eine |
@syssi gibt es irgendwo eine Aufschlüsselung der Daten der intra-pack-Antwortpakete? Ich hatte es damals versucht, aber nicht alle Daten entschlüsseln können.. |
Was diesem Projekt fehlt ist ein Decoder für die
Sehen irgendwelche dieser Werte für die plausibel aus? |
das ist allerdings nicht vollständig.. ich weiß, dass ein Teil der Daten auch alarm-flags enthält. Das kann man aber so schlecht triggern um dann manuell abgleichen zu können. Die Resultate aus meinem Code waren schon viel Raten. Die Doku von Seplos gibt dazu auch nichts her.. |
Mir ist keine offizielle Beschreibung der Frames bekannt. Dein erster Aufschlag sieht aber bereits vielversprechend aus. |
ich hatte schonmal bei Seplos angefragt, aber die haben mir dann ne Pylontech-Protokoll-Doku geschickt, die ich mit ehrlicherweise nicht angesehen habe. Da sie sicher viel davon kopiert haben, findet man dort ggf. etwas. Ich schaue die Tage mal. In jedem Fall enthalten die Intra-Pack-Daten aber weniger Informationen. Zurück zum Thema: Zwei Master auf dem Bus bereiten bei mir auch auf lange Sicht mit 12 Packs bisher keine Probleme. Den Master frage ich zusätzlich mit 9600er Baud über einen Splitter am CAN ab. |
Was in übersetzten Daten identifizieren kann:
|
Ersteinmal bin ich für das Teilen Deiner Erfahrung recht dankbar. Und das Abgreifen des Masters über die 9600 am CAN wäre eigentlich das Datenschnipsel, das mir fehlen würde. Mit Splitter meinst Du sicherlich nen Y-Adapter - laienhaft gefragt? |
siehe den von mir geteilten Link – da hab ich schon recht viel dekodiert, aber eben nicht alles und insb. die Alarm-Daten nicht. |
Korrekt, ein Y-Adapter wie diesen hier |
..bin grad schon imPython versunken... |
es geht auch die Variante, den Master via Bluetooth-Display zu pollen.. |
Ich geh mal die Variante mit 9600 Baud auf dem CAN Anschluss, die Hardware hab ich hier und werde beizeiten berichten.... |
Ich habe einen kleinen Decoder implementiert, der das dekodierte Frame erstmal ins Log schreibt:
Wenn du den
|
Über den Mehrwert muss ich aber noch einmal eine Nacht schlafen. ;-) |
Tolle Arbeit, vor Allem schnell. Für den Mehrwert: wohl eher nicht, weil immernoch der Master fehlt und die schmale Datentiefe wohl nur für die Aufsummierung für den WR Sinn macht. Am CAN Port des Masters kann mit 9600 Baud der Master wohl tatsächlich mit dem Protokoll 2.0 ausgelesen werden, hab das mal q&d ausprobiert. Der ESP32 sollte in der Lage sein, die Daten aller drei ruckelfrei zu verarbeiten, werde wohl morgen oder so das Projektchen mit nem Splitter und einer zweiten RS485 aufpimpen und dann berichten. Ein Dauerlauf muß dann die Stabilität des CAN Bus beweisen, weil mein Solis WR bei Schluckauf auf dem CAN die am Notstrom angeschlossenen Geräte abwirft - was blöde ist. Danke auf jeden Fall für den umfänglichen und schnellen Support, auch an @Privatecoder für den Tipp per Splitter und 9600er Datenrate an den CAN Bus zu gehen. |
Zwischenbericht: |
...und Ernüchterung: CAN und RS485 zusammen über Splitter kommt nix vom Seplos zurück. CAN zum WR funktioniert. |
Ich hatte es bisher so verstanden, dass auf der gleichen Buchse auf unterschiedlichen Pinnen unterschiedliche Signale anliegen. Auf welchen Pinnen liegt das CAN- und auf welchen Pinnen das RS485-Signal? Ich wuerde die zwei relevanten Leitungen zum ESP/RS485-Converter führen und die CAN-Leitungen zum Inverter. Verstehe ich etwas falsch? |
Nö, verstehst wohl nix falsch, hast Recht, wie ein tiefer Blick in die Unterlagen zeigt. CAN liegt auf 4+5, RS485 auf 1/8+2/7. Aber gemeinsam GND auf 3/6. Meine hemdsärmelige Theorie also für die Tonne. |
Mit welches ID arbeitet du am CAN-Bus-Port? Der 0x00? |
Jepp. Wünschte mir nur, mit yaml soweit firm zu sein, daß der u.s. Spaghetticode etwas kompakter daherkommen würde. Falls jemand das nachbauen möchte (könnte auch gerne in die Beispiele einfliessen):
|
Für mich ist das jetzt ersteinmal fertig. |
Weil es doch die eine oder andere Kollision auf dem originären RS485 Port gibt (Master fordert sekündlich die Infos von den Slaves) und die RS485 Schnittstelle von allen dreien komplette Ruhe zeigt bar jeglicher Kommunikation werde ich morgen - oder so - mal ein Kabel basteln, um die drei RS485 Ports, die auf 9600 Baud laufen und parallel zum CAN-Anschluß vorhanden sind, miteinander zum Bus zu kombinieren und entsprechend berichten. |
Das ist ein gutes Experiment! Ich habe auch die Hoffnung, dass du hier auf separaten UARTs unterwegs bist, welcher für Dritte gedacht ist, so dass du die Finger vom Intra-Pack-Bus lassen kannst. |
Hat mir nu ja keine Ruhe gelassen. Der von Dir angestoßene tiefe Blick in die Dokumentation des Boards sowie eine kurze Kontrolle am Board selber hat ergeben, daß der RS485-Teil des CAN Ports auf dem Board schon fertig durchgeschleift ist mit
|
@Wiki591 @syssi ich konnte es noch nicht testen, aber es gibt für die 10E / v2 eine neue Firmware Bei Akku-Doktor las ich zum Vorgägner
Vielleicht kann man damit nun auch am Master ohne Splitter über einen der freien RS485-Ports alle Packs auslesen |
Danke für die Info, nur bei FW Updates folge ich gerne der "Never touch a running system"-Philosophie. Wie oben beschrieben, hab ich mir ein Kabel gecrimpt, mit dem ich den auf den Boards parallel zum CAN durchgeschleiften RS485 Port aller Packs zu einem Bus verbunden habe, zusätzlich am RJ45 ziehe ich die beiden Pins vom CAN aus dem Master raus zum WR - selbstgecrimpter Splitter halt. Funktioniert bis jetzt völlig problemlos und bis jetzt ohne Schluckäufe. Da ich auf dem originären RS485 Port bei meinen ersten Versuchen immer wieder Kollisionen mit der sekündlichen Abfrage des Masters an seine Slaves beobachtet habe, lasse ich den jetzt in Ruhe, da die Kommunikation ja auch zukünftig erforderlich ist. Benötigt wird der separate RS485 (dann mit 19200bd) in meinem Setup nur dann, wenn ich mit dem BMS Monitor von Seplos die Einstellungen runterladen und ggf. ändern möchte - was bei einem Produktiv-System, das seit 1 1/2 Jahren läuft sehr selten ist. Der Batteriemonitor von Seplos gibt mir über den o.g. RS485-Bus (nochmals drei Pins rausgezogen) jetzt auch die Meßwerte aller drei Packs, nur halt das Setup tuts nicht. |
Kannst du nochmal erklären, wie du das jetzt genau verkabelt hast (vielleicht mit Foto)?
Hieraus entnehmen ich: Master CAN-Port mit Y-Kabel (zwei Adern (CAN) an WR und 3x RS485 an ESP). Du hast die Packs unterinenader aber über die RS485 ganz normal verbunden? Danke schon mal |
Am Master hab ich einen dreifachen Splitter gecrimpt, Pin 4&5 -> CAN, Pin 7&8 -> CAN Port Slave 1 Pin 1&2, CAN Port Slave1 Pin 7&8 -> CAN Port Slave 2 Pin 1&2, CAN Port Slave 2 Pin 7&8 -> ESP mit 1xRS485 TTL. Alles läuft an diesem Bus mit 9,6kBd. |
ich danke! |
I am reading pack 1 (adress 0x01) and pack 2 (adress 0x02) from three packs, Seplos BMS V16-10E. The master attached per CAN bus to the inverter is not accessible as known. But anyway, at least I get an idea of the drift of the SOC of the two batteries. Detailed information, i.e. voltages of cells, I am reading with BLE from three attached Neey balancer.
Having a look at the debug protocol I can see, that on the RS485 line a device with adress 0x03 ist sending some unrecognized data. I suppose, this is the master which sends the cummulated/summarized information of the whole packs which are sent to the inverter, too.
The entries look like this:
Is there any way to translate these informations, too? Would be a nice-to-have for i.e. estimating the SOC of the master.
The text was updated successfully, but these errors were encountered: