Modul PylonTech

[DS_Starter]

Herzlichen Glückwunsch

[Janvi]

Oh nein, leider schnallt der LV-Hub nach rund 10 Minuten daß irgendwas faul ist und geht auf internen Fehler. Als Folge davon werden dem Inverter 0V Batteriespannung gemeldet worauf das ESS abschaltet.

[satprofi]

Ich versteh immer noch nicht wieso du mit waveshare auf gruppe 2 steckst, statt gruppe 1.

[Janvi]

Auf Gruppe 1 ist die B/RS485 Buchse belegt und ich habe noch kein passendes Kabel zum Ausprobieren.
Ausserdem vermute ich, daß an beiden Gruppen die gleichen Probleme auftauchen.
Die RS485 Leitungen sind durchgehend genau die gleichen Leitungen. Wer soll da antworten? Das tut niemand weil es mit den Pin1,2,3 blockiert ist.
Momentan bin ich am Reverse Engineering der Steuerpins 1,2,3. Da sind insgesamt 4 Dioden drin und die machen einzigen Unterschied zwischen A/CAN und B/RS485. Auf den Link0/1 Buchsen gibt es hingegen nur 2 Dioden zusätzlich zum CAN. Vielleicht kann man die Konstruktion doch noch ergründen.

[DS_Starter]

Ich habe das Modul um ein Gruppenmanagement erweitert.
Es kann im Define group=0 (ist eigentlich der Standard 'single group') bis group=7 angegeben werden.
Dazu ist einfach ein Schlüssel hinzugekommen, z.B.:

 

Code Auswählen Erweitern

define Pylone1 PylonLowVoltage 192.168.2.86:9000 1 group=0

Die Version ist eingecheckt, aber liegt auch in meinem contrib zum Download falls ihr schon probieren möchtet. Restart nicht vergessen!

Inzwischen glaube ich tatsächlich dass es eine Beschränkung auf max. 12 Batterien (inkl. Master) in einer Gruppe gibt, so wie es in der Protokolldoku beschrieben ist.
Wenn sich die Erkenntnis erhärtet, muss ich die Adressierung im Modul entsprechend begrenzen und dokumentieren.

LG

[satprofi]

Hallo.
Ich würde Punkt 5 des US5000 Manuals nochmals durchgehen, unabhängig von FHEM.  Wenn du das zum laufen bringst, würd ich dann versuchen über RS485 der 1. Gruppe (Kabel auftrennen) abzufragen. evt. auch mit batteryview schauen ob du alle deine Pylons siehst. Evt. dies ausprobieren

[satprofi]

Ich habe das Modul um ein Gruppenmanagement erweitert.
Es kann im Define group=0 (ist eigentlich der Standard 'single group') bis group=7 angegeben werden.
Dazu ist einfach ein Schlüssel hinzugekommen, z.B.:

 

Code Auswählen Erweitern

define Pylone1 PylonLowVoltage 192.168.2.86:9000 1 group=0

Die Version ist eingecheckt, aber liegt auch in meinem contrib zum Download falls ihr schon probieren möchtet. Restart nicht vergessen!

Inzwischen glaube ich tatsächlich dass es eine Beschränkung auf max. 12 Batterien (inkl. Master) in einer Gruppe gibt, so wie es in der Protokolldoku beschrieben ist.
Wenn sich die Erkenntnis erhärtet, muss ich die Adressierung im Modul entsprechend begrenzen und dokumentieren.

LG

Danke.
Aber lt. Manual dürften 16 in einer Gruppe sein, egal ob US3000 od. US5000. Wichtig ist nur die Schritte mit den Dipschalter unter Punkt 5 einzuhalten, also erst alles auf 0 dann einschalten, warten bis alle eingebunden, dann erst Adressierung, etc.
Leider kann ich nicht testen da US2000B+ einen Hub benötigen, alle C klappen auch ohne Hub.
Manual US3000  
Manual US2000B+
Manual US2000C

[DS_Starter]

Ja dürfen 16 in einer Gruppe sein, nur ist fraglich ob via RS485 auch alle abgefragt werden können. Da habe ich momentan Zweifel weil die Protokolldoku die entsprechende Aussage trifft.
Werden wir sehen denke ich. Deswegen habe ich auch noch nichts beschnitten.

[satprofi]

Ja dürfen 16 in einer Gruppe sein, nur ist fraglich ob via RS485 auch alle abgefragt werden können. Da habe ich momentan Zweifel weil die Protokolldoku die entsprechende Aussage trifft.
Werden wir sehen denke ich. Deswegen habe ich auch noch nichts beschnitten.

Vielleicht deshalb , weil User Janvi ja von "Rückseite" abfrägst.

[satprofi]

Auf Gruppe 1 ist die B/RS485 Buchse belegt und ich habe noch kein passendes Kabel zum Ausprobieren.
Ausserdem vermute ich, daß an beiden Gruppen die gleichen Probleme auftauchen.
Die RS485 Leitungen sind durchgehend genau die gleichen Leitungen. Wer soll da antworten? Das tut niemand weil es mit den Pin1,2,3 blockiert ist.
Momentan bin ich am Reverse Engineering der Steuerpins 1,2,3. Da sind insgesamt 4 Dioden drin und die machen einzigen Unterschied zwischen A/CAN und B/RS485. Auf den Link0/1 Buchsen gibt es hingegen nur 2 Dioden zusätzlich zum CAN. Vielleicht kann man die Konstruktion doch noch ergründen.

Hallo.
Gruppe 2 darf dipschalter 2 nicht on stehen, lt. Manual. Hast du so eingezeichnet.

[Janvi]

Zunächst hatte ich die Gruppe N komplett abgetrennt um irgendeine Kommunikation zu bekommen. Das hat also nichts mit der Abfrage von der Rückseite her zu tun.

Die mutmassliche Geschichte von Pylontech ist die: Pylon ist ein Hersteller von Batteriezellen. D.h. sie machen diese selbst und kaufen sie nicht von EVE oder BYD oder sonstwo zu. Um am Markt anzukommen, wollten sie nicht nur Zellen sondern ganze Racks in die Wertschöpfung aufnehmen. Hierzu waren aber andere Kompetenzen erforderlich welche sie nicht hatten. Schliesslich fand sich ein chinesischer Frickler, welcher mit einem uC ein BMS basteln konnte. Der uC hatte zwei serielle und eine CAN Schnittstelle. Über die CAN Schnittstelle wurde der interne Link einer Gruppe realisiert wie der bis heute noch besteht. Über die serielle Schnittstelle wurde die Console und die RS485 zum Anbinden eines WR gemacht. Das waren die Modelle US2000 und US3000. Dummerweise hat bei Pylontech aber noch nie jemand etwas über die Transportschichten des OSI Modells gehört. Das selbstgefrickelte RS485 Protokoll hatte deshalb nicht einmal annähernd die Funktionalitäten von Modbus oder gar Sunspec. Tatsächlich ist die RS485 in der Pylon Ausführung ein Punkt zu Punkt Protokoll. Ein Wechselrichter kommuniziert mit der Masterbatterie welche die Aggregation macht. Der WR kann nicht mit den Slave Batterien kommunizieren, für welche die Adressen im Request Telegramm eigentlich gedacht sind. Die Antwort darauf wird immer von der Master Batterie verschickt. Um dieses Manko zu beheben, wurde ein LV-Hub erfunden. Das RS485 Protokoll beschränkt sich dabei warum auch immer auf 8 Batterien (lt Hub Manual) wobei tatsächlich im Protokoll 12 beschrieben sind und 12,5 tasächlich funktionieren.

Nachdem dieser Ansatz auch mit Hub auf 6x8=40 Batterien als Sackgasse erkannt wurde, kam ein Redesign des BMS. Da hat man dann einen Cortex M4 mit zwei CAN Schnittstellen genommen. Die US2/3000 C oder B+ Modelle waren baugleich mit der US5000 geboren. Die zusätzliche CAN Schnittstelle konnte jetzt alternativ zur Kommunikation mit einer übergeordneten Steuerung (WR oder HUB) genommen werden. Um keine zusätzlichen Buchsen in den bereits gefertigten Frontplatten zu benötigen, wurden die noch freien Pins auf der gleichen Buchse benutzt weil ja sowieso immer nur eine Schnittstellenart benutzt wird. Der Massepin wurde dabei von pin 2 auf pin 6 verlegt um in der Mitte von CAN und RS485 zu liegen und von beiden gleichermassen benutzt werden zu können. Der Pin2 hat eine neue Funktion erhalten damit man irgendwie angeben kann ob RS485 oder CAN benutzt werden soll.

Fhem spricht nun Batteriegruppen mit RS485 an, welche nach oben mit CAN angebunden sind. Das funktioniert, aber nur, solange das RS485 Protokoll nicht über die noch zu ergründenden Steuerpins abgestellt werden. Es funktioniert auch nur bis 8 bzw. 12 Batterien in einer Gruppe wie es ursprünglich gedacht war.

Alles nur Vermutungen für diese Geschichte. Wenn man auf der Pylon Webseite aber die neuen Produkte für den Heimspeicher anschaut, passt dies ins Bild. Man möchte hohe Gewinne einfahren indem die Wertschöpfungskette erweitert wird. Der neue Heimspeicher hat einen WR drin. Nur noch AC Ausgang und DC Moduleingänge. Eine rundum sorglos Blackbox für den deutschen Käufer. Der hat sich gefälligst auch nicht dafür zu interessieren wie die Bits in den Protokollen funktionieren.

Edit: Die Geschichte passt auch fasst zu den Typ A und Typ B Kabeln von Victron. Typ B ist für US2000 und US3000 und hat die Masse auf pin 2, Typ A ist für US2000C und US3000C und hat Masse auf pin 6.
Folglich konnten also auch die alten BMS Versionen schon zwei CAN was aber auch welchen Gründen auch immer nicht richtig funktioniert hatte weshalb dazu die 3 Steuerpins eingeführt wurden.
https://www.victronenergy.com/live/battery_compatibility:can-bus_bms-cable#introduction

 

[DS_Starter]

Ich habe mich etwas mit den möglichen Timeouts beschäftigt.
Grundsätzlich haben wir das Thema, dass es im System 1-N PylonLowVoltage Devices gibt. Jedes dieser Devices kommuniziert mit dem gleichen Gateway. Wird eine laufende Kommunikation mit dem Gateway des einen Devices unterbrochen indem ein anderes Devices seine Kommunikation startet, führt das unweigerlich zu entsprechenden Fehlern.
Das Modul fängt diese Fehler ab. Im allgemeinen haben wir eine relativ geringe Anzahl an Batterien und dementsprechende Devices. Wird die Anzahl aber signifikant hoch, kann man das Thema nicht mehr vernachlässigen.

Ich habe eine neue Version erstellt und eingecheckt bzw. auch in mein contrib zum Test gestellt.

In dieser Version habe ich eine Methode eingeführt, die eine Kommunikation zwischen den Devices im System ermöglicht und ein "reingrätschen" in eine laufende Gateway Session verhindert. Zu einem späteren Zeitpunkt könnte ich mir auch die Einführung eines Dispatcher Devices vorstellen, über das ausschließlich die Kommunikation zwischen FHEM und dem Gateway geführt wird. Das wäre dann der beste Weg, braucht aber noch etwas Designarbeit.

Weiterhin gibt es ein Attribut "waitTimeBetweenRS485Cmd". Zur Zeit werden alle RS485 Kommandos nacheinander ohne Pause dazwischen ausgeführt. In einem aktuellen US5000 Bedienungsanleitung (von Effekta) steht auf Seite 36 geschrieben, dass bei Verwendung von RS485 eine Pause >= 1s einzulegen ist. Das trifft auch auf andere Batterien (US3000) zu.
Das verschärft die Timeout Thematik noch mehr und führt im FHEM Kontext auch zu evtl. Blockierungszuständen was natürlich nicht passieren darf.
Deshalb gibt es jetzt das Verfahren, dass man bei einem eingestellten Timeout von >= 1s auch die Wartezeit zwischen Befehlen von nun 0.1s (default) auf bis zu 2 Sekunden erhöhen kann. Je nach Anzahl der Batterien kann es zu Postponed-Situationen kommen, die aber nicht die Funktion behindern und sequentiell abgearbeitet werden.

Zur Verdeutlichung ein Auszug aus dem Event-Monitor:

Code Auswählen Erweitern

2024-08-25 11:01:00.852 PylonLowVoltage Pylon7 cycle postponed due to active gateway connection of Pylon3
2024-08-25 11:01:00.852 PylonLowVoltage Pylon7 nextCycletime: 11:01:01
2024-08-25 11:01:00.862 PylonLowVoltage Pylon3 averageCellVolt: 3.369
2024-08-25 11:01:00.862 PylonLowVoltage Pylon3 nextCycletime: 11:01:12
2024-08-25 11:01:00.862 PylonLowVoltage Pylon3 packPower: 424.52
2024-08-25 11:01:00.862 PylonLowVoltage Pylon3 packVolt: 50.538
2024-08-25 11:01:00.862 PylonLowVoltage Pylon3 packCurrent: 8.400
2024-08-25 11:01:00.862 PylonLowVoltage Pylon3 connected
2024-08-25 11:01:01.999 PylonLowVoltage Pylon7 cycle postponed due to active gateway connection of Pylon1
2024-08-25 11:01:01.999 PylonLowVoltage Pylon7 nextCycletime: 11:01:02
2024-08-25 11:01:02.984 PylonLowVoltage Pylon7 nextCycletime: 11:01:03
2024-08-25 11:01:02.984 PylonLowVoltage Pylon7 cycle postponed due to active gateway connection of Pylon1
2024-08-25 11:01:03.989 PylonLowVoltage Pylon7 nextCycletime: 11:01:04
2024-08-25 11:01:03.989 PylonLowVoltage Pylon7 cycle postponed due to active gateway connection of Pylon1
2024-08-25 11:01:04.074 PylonLowVoltage Pylon1 packPower: 313.34
2024-08-25 11:01:04.074 PylonLowVoltage Pylon1 packVolt: 50.538
2024-08-25 11:01:04.074 PylonLowVoltage Pylon1 packCurrent: 6.200
2024-08-25 11:01:04.074 PylonLowVoltage Pylon1 connected
2024-08-25 11:01:04.074 PylonLowVoltage Pylon1 averageCellVolt: 3.369
2024-08-25 11:01:04.074 PylonLowVoltage Pylon1 nextCycletime: 11:01:10
2024-08-25 11:01:04.074 PylonLowVoltage Pylon1 packImbalance: 0.148
2024-08-25 11:01:05.584 PylonLowVoltage Pylon7 averageCellVolt: 3.369
2024-08-25 11:01:05.584 PylonLowVoltage Pylon7 packImbalance: 0.059
2024-08-25 11:01:05.584 PylonLowVoltage Pylon7 nextCycletime: 11:01:16
2024-08-25 11:01:05.584 PylonLowVoltage Pylon7 packVolt: 50.538
2024-08-25 11:01:05.584 PylonLowVoltage Pylon7 packPower: 328.50
2024-08-25 11:01:05.584 PylonLowVoltage Pylon7 connected
 

Bzw. einem verbose 4 Log:

Code Auswählen Erweitern

2024.08.25 11:02:06.449 4: Pylon1 - another Gateway Call from Pylon7 with PID "579554" is already running ... start Update postponed
2024.08.25 11:02:07.450 4: Pylon1 - START request cycle to battery number >1<, group >0< at host:port 192.168.2.86:9000
2024.08.25 11:02:07.456 4: Pylon1 - Cycle BlockingCall PID "579557" started with battery read timeout: >1.5<, blocking timeout >9<
2024.08.25 11:02:07.474 4: Pylon1 - used wait time between RS485 commands: 0.5 seconds
2024.08.25 11:02:07.481 4: Pylon1 - retrieve battery info: analogValue
2024.08.25 11:02:07.481 4: Pylon1 - request command (ASCII): ~20024642E00202FD33
2024.08.25 11:02:07.999 4: Pylon1 - retrieve battery info: alarmInfo
2024.08.25 11:02:07.999 4: Pylon1 - request command (ASCII): ~20024644E00202FD31
2024.08.25 11:02:08.518 4: Pylon1 - retrieve battery info: chargeManagmentInfo
2024.08.25 11:02:08.519 4: Pylon1 - request command (ASCII): ~20024692E00202FD2E


[satprofi]

Danke.
Noch ein vorschlag, man müsste ja nur systemparameter abfragen. SerialNr, Softwarestand, protokoll ist ja nur bei defination wichtig, danach ändert sich das nie mehr.

[DS_Starter]

SerialNr, Softwarestand, protokoll ist ja nur bei defination wichtig, danach ändert sich das nie mehr.

Bedingt.
Wenn der User eine neue Batterie als Master reinschiebt, ändern sich alle Adressen und damit Seriennummern, FW-Stände usw.
Das gleiche passiert wenn die Adresse im Device geändert wird und es gibt mit Sicherheit weitere Situationen wo sich Änderungen ergeben.
Diese statischen Parameter rufe ich z.Zt. nicht öfter als alle 60s ab. Den Zeitraum kann ich auch gerne uf z.B. 5 Minuten ändern. Ganz eliminieren möchte ich den Abruf aus diesen Gründen nicht. 

[Janvi]

Nachdem ich mir den Sonntag mit den Pylons verdorben habe, beiliegend ein Schaltbild der A/CAN B/RS485 Belegung welche insgesamt 5 Dioden auf 3 Steuerleitungen enthält. Diese haben offensichtlich eine Funktion welche Pylontech selbst nicht so genau weis, weshalb die Nachträge im LV-Hub Manual zum Auftrennen der pins 1-3 erforderlich waren.

Es gibt folgende Erkentisse:

1) Stack N arbeitet in vorliegender Konfiguration mit CAN und RS485 gleichzeitig, wenn pin 2 (or) an der Verbindung zwischen Master N und Master 1 aufgetrennt ist. Beim Auftrennen aller Steuerpins 1-3 steigt der Hub irgendwann aus.

Unabhängig davon, daß über den Link-Can bis zu 16 Racks verbunden werden können, sind die RS485 Telegramme bei US5000 und US2/3000C auf die Adressen 1-12 und bei US2/3000 ohne C auf 1-8 begrenzt. Dies entspricht auch der RS485 Protokollbeschreibung.

Unabhängig vom DIP Schalter meldet auch BatteryView immer die Batterieadressen 1 bis 16 ohne Gruppenadresse. Es ist derzeit nicht bekannt, ob das Nibble für die Gruppenadresse dabei eventuell ausgeblendet wird oder ob sich die Gruppenadresse nur beim RS485 Modus des Hubs ändert.

2) Stack 1 arbeitet in vorliegender Konfigruation mit CAN und RS485 gleichzeitig, wenn Pin 1 (ws/or) aufgetrennt wird. Die über RS485 erhaltenen Daten stammen dabei aber von Stack N. Nach einiger Zeit werden darüber hinaus vom Hub 16 Batterien ausgebucht, während die LEDs am Hub weiterhin 2 angeschlossene Stacks anzeigen. Welcher der beiden 16er Gruppen noch weiter nach oben gemeldet wird, ist momentan unbekannt.

Beim Wiederherstellen der Verbindung von Pin1 zwischen den beiden Stacks schaltet die Anzeige des Hubs sofort von 2 auf nur noch einen erkannten Stack um. Das ist ein klarer Fehler im Protokollentwurf welche fehlerhafte physikalische Verbindungen erkennen und korrigieren können muß.  Interessant ist dabei, daß die RS485 auf Gruppe N plötzlich trotz allen 3 geschlossenen Pins antworten kann. Vermutlich glaubt Stack N jetzt nicht mehr an einem Hub sondern an einem WR angeschlossen zu sein.

Zur Wiedereinbuchung von beiden Stacks muß die Verbindung zwischen Master Stack N und Master Stack 1 austgesteckt werden und bei beiden Geräten ein Reset gemacht werden. Ausserdem müssen recht undurchsichtigen Schritte 1 bis 7 vom Hub Manual Seite 8/14 eingehalten werden.  Diese beinhalten unter Anderem ein Abwerten von 3xPiepsen, dann Umstellen von DIP Schaltern nachdem bzw. während der Master 1 eingeschaltet ist und dann erst einstecken des an Pin1-3 aufgetrennten Kabels zum Hub.

Beide Gruppen werden aber nur dann erfolgreich am Hub wieder eingebucht, wenn die Verbindung zwischen den Mastern 1:1 inklusive RS485 ist. Ist die RS485 für das Gateway aufgetrennt, so so gehen entweder Hub oder Master 1 auf Fehler. Das ist ein Zeichen dafür, daß  über die RS485 zusätzliche nicht dokumentierte Daten zum Einbuchen am Hub ausgetauscht werden.


 3) Summa Summarum ist ein vernünftiger Betrieb der RS485 am Hub mit CAN Modus nicht möglich bzw. liefert auch mit Trickserei nur einen kleinen Teil der vorhandenen Daten.

Andererseits ist FHEM eine der wenigen Möglichkeiten Geräte herstellerübergreifend zu visualisieren. Es gibt daher 2 mittelfristige Möglichkeiten damit weiterzukommen:

a- Fhem kann die Daten irgendwo an einem CAN Gateway abgreifen. Die dort zur Verrfügung stehenden Daten sind aber weit weniger als auf RS485

b- Obwohl für die 2/3000C Modelle angegeben ist, daß man bei RS485 keinen Hub braucht, könnte ich mit meine US5000 versuchen, die in 12er Gruppen aufzuteilen und am Hub den RS485 Modus zu fahren.