Modul PylonTech

DS_Starter · 23 August 2024, 08:29:50

ZitatSerialNumber antwortet noch, aber bei ManufacturerInfo passiert der Timeout wenn die Adresse 13 oder 14 ist

Danke für die Info. Evtl. ist auch da was mit der Checksum. Ich checke das nochmal nach.

Janvi · 23 August 2024, 08:41:43

Den 5 Sek Abfragezklus habe ich soweit runtergestellt, daß man am Oszi den Trigger schneller einstellen kann und auch früher was sieht. Später reichen natürlich weniger Abfragen. Mein LV-Hub hat sich erstaunlich gehalten. Nach dem Einstecken des CAN Kabels neu gebootet und er hat die beiden Gruppen dann klaglos wieder eingebucht. Letztes Mal ging anstelle des internen Fehlers einfach die Anzahl der gemeldeten Batterien von 32 auf 16 zurück und das ESS lief weiter. Diesmal hat es mit Low Battery abgeschaltet weil neben einem "internen Fehler" auch 0V Spannung gemeldet wurde. Die DC Spannung auf dem Bus hat natürlich weiter angestanden und keine der Batterien ging auf Fehler oder musste neu gebootet werden.

Hier noch mal ein Anhang mit meinem LV_Hub Manual zum Vergleich mit der von @satprofi bei Victron verlinkten Version.
Es ist typisch für die übliche Qualität der Pylontech Dokus: Das Deckblatt mit Dokumentenname und Versionnummer ist vollständig identisch.
Vergleicht man aber die Seiten 7, 8 und 9 so gibt es Unterschiede. Für Kapitel 3.3 hat der Text plötzlich einen anderen Seitenumbruch
Der zum Betrieb des LV Hub alles entscheidende Hinweis, daß 3 Adern bei einem Kabel unterbrochen sein müssen fehlt in einer Version.
Würde kein Mensch merken wenn bei jedem LV Hub so ein Anschlusskabel mitgeliefert würde. Wird es aber leider nicht und der Käufer rätselt dann bis er graue Haare kriegt.

DS_Starter · 23 August 2024, 09:17:17

@Janvi,

an deinem Protokoll ist mir gerade etwas aufgefallen

Zitat2024.08.23 02:44:21 4: pylon - start request cycle to battery number >13< at host:port 10.10.20.142:3195
2024.08.23 02:44:21 4: pylon - Cycle BlockingCall PID "2271631" with timeout "12" started
2024.08.23 02:44:21 4: pylon - retrieve battery info: analogValue
2024.08.23 02:44:21 4: pylon - request command (ASCII): ~200E4642E0020EFD0D
2024.08.23 02:44:21 5: pylon - request command (HEX): 7e3230304534363432453030323045464430440d
2024.08.23 02:44:21 5: pylon - data returned raw: ~200E4600B07E000E0F0CDD0CDE0CDD0CDE0CDF0CDD0CDF0CDD0CDF0CDE0CDF0CDD0CDD0CDF0CDE060B900B8B0B910B900B8F0B8B0000C101FFFF04FFFF001700EDCE0186A0E001
2024.08.23 02:44:21 5: pylon - data returned:
0x00000000 (00000) 7e323030 45343630 30423037 45303030 ~200E4600B07E000
0x00000010 (00016) 45304630 43444430 43444530 43444430 E0F0CDD0CDE0CDD0
0x00000020 (00032) 43444530 43444630 43444430 43444630 CDE0CDF0CDD0CDF0
0x00000030 (00048) 43444430 43444630 43444530 43444630 CDD0CDF0CDE0CDF0
0x00000040 (00064) 43444430 43444430 43444630 43444530 CDD0CDD0CDF0CDE0
0x00000050 (00080) 36304239 30304238 42304239 31304239 60B900B8B0B910B9
0x00000060 (00096) 30304238 46304238 42303030 30433130 00B8F0B8B0000C10
0x00000070 (00112) 31464646 46303446 46464630 30313730 1FFFF04FFFF00170
0x00000080 (00128) 30454443 45303138 36413045 3030310d 0EDCE0186A0E001.

2024.08.23 02:44:21 4: pylon - retrieve battery info: alarmInfo
2024.08.23 02:44:21 4: pylon - request command (ASCII): ~200E4644E0020EFD0B
2024.08.23 02:44:21 5: pylon - request command (HEX): 7e3230304534363434453030323045464430420d
2024.08.23 02:44:21 5: pylon - data returned raw: ~200E46008044000E0F00000000000000000000000000000006000000000000000000000E00000000F089
2024.08.23 02:44:21 5: pylon - data returned:
0x00000000 (00000) 7e323030 45343630 30383034 34303030 ~200E46008044000
0x00000010 (00016) 45304630 30303030 30303030 30303030 E0F0000000000000
0x00000020 (00032) 30303030 30303030 30303030 30303030 0000000000000000
0x00000030 (00048) 30303630 30303030 30303030 30303030 0060000000000000
0x00000040 (00064) 30303030 30303030 45303030 30303030 00000000E0000000
0x00000050 (00080) 30463038 390d 0F089.

2024.08.23 02:44:21 5: pylon - Alarminfo - Status 1 alarm: 00
2024.08.23 02:44:21 5: pylon - Alarminfo - Status 2 Info: 0E
2024.08.23 02:44:21 5: pylon - Alarminfo - Status 3 Info: 00
2024.08.23 02:44:21 5: pylon - Alarminfo - Status 4 alarm: 00
2024.08.23 02:44:21 5: pylon - Alarminfo - Status 5 alarm: 00

2024.08.23 02:44:21 4: pylon - retrieve battery info: chargeManagmentInfo
2024.08.23 02:44:21 4: pylon - request command (ASCII): ~200E4692E0020EFD08
2024.08.23 02:44:21 5: pylon - request command (HEX): 7e3230304534363932453030323045464430380d
2024.08.23 02:44:21 5: pylon - data returned raw: ~200E4600B0140ED002AFC80320FCE0C0F905
2024.08.23 02:44:21 5: pylon - data returned:
0x00000000 (00000) 7e323030 45343630 30423031 34304544 ~200E4600B0140ED
0x00000010 (00016) 30303241 46433830 33323046 43453043 002AFC80320FCE0C
0x00000020 (00032) 30463930 350d 0F905.

2024.08.23 02:44:21 4: pylon - Socket/Connection to the RS485 gateway was closed
2024.08.23 02:44:21 4: pylon - got data from battery number >13< successfully

2024.08.23 02:44:26 4: pylon - start request cycle to battery number >13< at host:port 10.10.20.142:3195
2024.08.23 02:44:26 4: pylon - Cycle BlockingCall PID "2271634" with timeout "12" started
2024.08.23 02:44:26 4: pylon - retrieve battery info: serialNumber
2024.08.23 02:44:26 4: pylon - request command (ASCII): ~200E4693E0020EFD07
2024.08.23 02:44:26 5: pylon - request command (HEX): 7e3230304534363933453030323045464430370d
2024.08.23 02:44:26 5: pylon - data returned raw: ~200E4600C0220E59323230393037433530313033333534F6AB
2024.08.23 02:44:26 5: pylon - data returned:
0x00000000 (00000) 7e323030 45343630 30433032 32304535 ~200E4600C0220E5
0x00000010 (00016) 39333233 32333033 39333033 37343333 9323230393037433
0x00000020 (00032) 35333033 31333033 33333333 35333446 530313033333534F
0x00000030 (00048) 3641420d 6AB.

2024.08.23 02:44:26 4: pylon - retrieve battery info: manufacturerInfo
2024.08.23 02:44:26 4: pylon - request command (ASCII): ~200E46510000FD8F
2024.08.23 02:44:26 5: pylon - request command (HEX): 7e323030453436353130303030464438460d
2024.08.23 02:44:26 3: pylon - Timeout reading data from battery
2024.08.23 02:44:26 4: pylon - Socket/Connection to the RS485 gateway was closed

Die Adressen sind jeweils "13", müsste im zweiten Fall aber wohl "14" sein. Hast du das Device richtig definiert?

EDIT: Vergiß es. Verständnisproblem bei mir. Es ist nur dein 5s Abfrageintervall wie es aussieht.

satprofi · 23 August 2024, 10:18:10

Zitat von: DS_Starter am 23 August 2024, 08:29:50
ZitatSerialNumber antwortet noch, aber bei ManufacturerInfo passiert der Timeout wenn die Adresse 13 oder 14 ist
Danke für die Info. Evtl. ist auch da was mit der Checksum. Ich checke das nochmal nach.

Hallo Kollegen.
Habe gerade nochmals das RS485 Protokoll 3.3 vor mir, und da steht das max. 12 Module pro Gruppe addressierbar sind.
Punkt 2.5.3
Haben wir hier ein Problem?

DS_Starter · 23 August 2024, 10:58:16

Vielleicht, vielleicht auch nicht. Das Dokument ist schon von 2018. Ich bin mir sicher dass es Weiterentwicklungen bei Pylon gegeben hat. Aber etwas neueres kenne ich nicht und wollte man mir nicht geben.
Andererseits funktioniert ja die Abfrage der Adresse Batterie "13" bei Janvi prinzipiell wie man anhand seines ersten Calls im Protokoll sieht.
Schwer zu sagen m.M. nach.

satprofi · 23 August 2024, 11:52:45

ja, stimmt. aber welche FW habt ihr drauf?
ich habe hier 2 Kxxxxxxx die mir trotz ,2 led nur 10% ausgeben

DS_Starter · 23 August 2024, 12:19:59

Meine US3000C haben folgende FW-Stände (in der Reihenfolge):

V1.7 (Master)
V1.8
V1.8
V1.7
V1.7
V1.4
V1.4

Janvi · 23 August 2024, 13:06:56

Wie du in meinem BatteryView Screendump siehst, ist es V1.3 bei einer US5000 und bei allen Exemplaren gleich. Es gibt auch eine US5000B mit DC Sicherung (B für Breaker) welche sich sonst nicht unterscheiden dürfte. US5000C gibt es im Gegensatz zu 2/3000C nicht, obwohl dies sogar zeitweise bei Pylontech auftaucht. Die Versionsnummer hat aber glaube ich wenig zu sagen weil Pylontech bei der US5000 und evlt. auch bei der 2/3000 irgendwann den uC auf einen Cortex M4 umgestellt hat. Vielleicht steht das C ja auch für Cortex uC? Das sind deshalb zumindest anders compilierte Quellen und vermutlich zwischenzeitlich auch getrennt gepflegte Versionen soweit FW für den älteren uC überhaupt noch gepflegt wird. Soweit ich mitgekriegt habe, ist das auch einer der Gründe warum Pylontech die Endanwender nicht auf FW Updates loslässt. Man könnte das File für den falschen uC haben. Dann ist die Batterie ein Garantiefall weil der Kunde selbst kein JTAG Kabel hat. Vermutlich ist also nur die Protokollversion ausschlaggebend.

Die Begrenzung auf weniger als 16 ist natürlich ein Rätsel was aber damit zusammenhängen könnte, ob die Master Batterie nach oben über CAN oder RS485 angebunden ist. Im letzteren Fall hätte der Master die Adresse 2 und mit einer 4 bit Adressierung würde das dann nicht bis 16 reichen. Im LV-Hub Manual sind da ja auch Beschreibungen mit maximal 8 pro Gruppe was dann vielleicht mal auf 12 aufgebohrt wurde. Wie bei Microsoft auch als die die PCs von maximal 640kbyte auf 1Mbyte aufgebohrt haben. Mehr braucht ja sowieso niemand.

satprofi · 23 August 2024, 13:35:35

Habs herausgefunden, im neuen manual

2) multi group, group 3, slave 6;
n = 7; m = 3
ADR = 0x07 + 0x10*3 = 0x37; INFO of COMMAND = ADR = 0x37

Also Master auch wieder 2

@ Janvi
Du liest nur aus wenn du den hub trennst, oder? Es könnte sein , das die Adresse auf 12 ,13,usw. angepasst gehört wenn hub verbunden. Aber du hast ja keine möglichkeit mit rs485 kabel, oder?

Janvi · 23 August 2024, 14:51:12

Ja, momentan abgetrennter LV-Hub zum Fhem ausprobieren. Einzelne 16er Gruppe ganz ohne Anbindung der Masterbatterie nach oben oder mit CAN Anbindung zu einem CerboGX. Das ist ja auch ein Spezialkabel Victron Typ-A. Einen RS485 Master (WR) habe ich leider nicht. Ausser dem Waveshare.

Mit angestecktem LV-Hub kommt gar keine Antwort. Gar nirgends gar nie. Aus diesem Grund hats bei mir am Anfang auch so lange gedauert bis irgendwas ging. Vielleicht finden wir da auch noch raus warum.

satprofi · 23 August 2024, 15:26:52

Könntest du über HUB Batterien ansprechen?
Wenn ja, dann definiere testweise nur 12 für erste Master. Natürlich gruppe 1 gejumpert.
Du müsstest das Kabel ja auftrennen für parallel verwendung (CAN u. RS485), oder?

Janvi · 23 August 2024, 16:41:20

Zitat von: satprofi am 23 August 2024, 15:26:52Könntest du über HUB Batterien ansprechen?

Bislang funktioniert mit Hub ja gar nichts auf der RS485.
Auf den 8 Buchsen des Hubs selbst habe ich noch nicht probiert.
Die sternförmige Verbindung des Hubs mit den Batterien über RS485 habe ich auch noch nicht probiert.
Du meinst ich soll anstelle 2 Gruppe a 16 Stück doch 3 Gruppen mit 12 + 12 + 8 Stück einbuchen?

Das aufgetrennte Kabel kann ich gegen später mal probieren wenn ich das ESS dazu ausschalten kann.
Beiliegend habe ich zur weiteren Verwirrung mal ein Schaltbild meines momentanen Aufbaus gemacht.

satprofi · 23 August 2024, 20:07:12

Hallo.
Deine Verdrahtung passt ja fast mit LV Manual, wobei du aber bei master 1 falsch gejumpert hast. Auch rs485 dürfte nicht passen, da du ja dazwischen erst abfrägst.
Ich würde rs485 beim Hub-in abfragen, also kabel zw. Master 1 und Hub auftrennen und dort rs485 zu waveshare oder evt. am port 0 zu can-in.

Noch was, lt. Manual sollte kabel zu can-in voll beschalten sein, erst zu ext. Rechner 1,2,3 offen. Wenn ich es richtig interpretiere

DS_Starter · 23 August 2024, 21:53:07

Morgen früh gibt es ein weiteres Update.
In Vorbereitung der Gruppenintegration ist der Aufbau der Kommandos vereinfacht, insbesondere wird die Checksumme durch das Modul automatisch berechnet sowie Kommando-Präfix und Suffix im Code hinzugefügt. Diese Änderungen merkt man als User nicht, sind aber für die weitere Entwicklung wichtig/hilfreich.

@satprofi, der Aufbau der statischen Kommandohashes ist vereinfacht / reduziert.

EDIT: Wer will ... die V liegt auch in meinem contrib zum sofortigen Download

Janvi · 23 August 2024, 22:54:37

Von mir gibt es heute schon ein kleines Update mit einem kleinen Erfolg.

1) Den Dip Schalter am Master 1 habe ich umgezeichnet wie er tatsächlich steht. Ich bewzeifle aber daß dies ein relevanter CAN Terminierungswiderstand ist wie es im Manual steht. An anderen Stellen wie etwa dem LV-Hub Manual ist dieser Schalter als Teil der RS485 Adresse beschrieben. Vermutlich ist er im CAN Betrieb Dont-Care.

2) Die letzte Version des Verdrahtungsplans hatte einen Fehler mit verdrehten Farben am Waveshare Gateway. Im Zeichnungskopf wurde dazu die Verwendung des Farbschemas EIA568-B vermerkt. Das ist zwar normalerweise eher in USA und Asien als in Europa gebräuchlich. Käufliche Patchkabel kommen aber meist aus China benutzen dann üblicherweise diese Farben.

3) Der LV-Hub läuft jetzt zusammen mit FHEM. Zwischen Master Gruppe N und Master Gruppe 1 habe ich dazu ein schaltbares Experimentierkabel gebastelt. Es scheint so, also ob Pylontech so etwas wie einen Enable Eingang auf den Pins 1,2 und 3 hat, über welche der Nachbar die RS485 Kommunikation des Vorgängers abstellen kann. Für die Lieferung eines Antworttelegramms auf die Anfrage von Fhem ist nicht das Auftrennen der RS485 Adern sondern vor allem der als Control eingezeichneten Adern auf den Pins 1,2 und 3 zuständig. Da bin ich rein zufällig drübergestolpert. Diese Stelle hat mich am Anfang maßgeblich blockiert. Sie funktioniert jetzt plötzlich. Ich werde morgen noch mal probieren, welche der einzelnen Adern für die Funktion förderlich bzw. hinderlich sind. Rein empirisch ohne das dann verstehen zu müssen.

4) Das Problem mit den Adressen 13 und 14 bleibt leider weiterhin. Immerhin kann ich jetzt schon 12 meiner 32 Batterien im Betrieb ansehen. Sobald klar ist, welche Adern für die Funktion der Verbindung maßgebend sind, werde ich ein weiteres unterbrochenes Kabel löten und die gleichen Versuche zwsichen Gruppe 1 und LV-Hub machen.