Modul PylonTech

[DS_Starter]

Habe jetzt mal auf dem vorderen Stack erste Batterie nach dem Master mit verschiedenen einstelligen Adressen probiert. Keine Änderung.
...
Timeout reading data from battery

Der Master macht die Addressierung der Batterien der Reihe nach wie sie unter ihm gestapelt sind. Wenn du das Gateway nicht in den Master steckst, wird die Adressierung nicht funktionieren und die angesprochene Batterie wird nicht antworten = "Timeout reading data from battery".

[satprofi]

Stimmt, dachte adressen vergibt BMS. Man muss die rs485 verbindung trennen zw. Den modulen

[Janvi]

Mit einer einzelnen isolierten US5000 bekomme ich endlich "state connected"
Zumindest weis ich jetzt, daß mein Kabel stimmt und die ETH Kommunikation korrekt eingestellt ist.
Es hat offensichtlich also nur an den Gruppenadressen gelegen, welche ich noch rauskriegen muß.
Am Waveshare sieht man auch an der blauen ACT LED wenn von FHEM alle 30 Sek ein Telegramm rausgeht.
Daran kann man erkennen, ob die ETH Verbindung grundsätzlich korrekt ist um nicht auf der falschen Seite zu suchen.
Man sieht die 3 Request/Response Telegrammpaare Analog, Alarm, Management auch mit dem Oszi auf der RS485 Leitung.
Sowohl Pylon wie auch FHEM trödeln nicht lange mit Pausen bis zum nächsten Telegramm.

Mein Master der ersten Gruppe ist derweil auf Fehler gegangen wie ich das CAN vom Hub abgezogen habe.
Der Hub selbst tut so als ob nix wäre. Das muß ich jetzt erst mal wieder hinkriegen damit der SOC nicht auseinanderläuft.

Code Auswählen Erweitern

2024.08.21 22:32:36 4: pylon - start request cycle to battery number >1< at host:port 10.10.20.142:3195
2024.08.21 22:32:36 4: pylon - Cycle BlockingCall PID "2204544" with timeout "12" started
2024.08.21 22:32:36 4: pylon - retrieve battery info: analogValue
2024.08.21 22:32:36 4: pylon - request command (ASCII): ~20024642E00202FD33
2024.08.21 22:32:36 5: pylon - request command (HEX): 7e3230303234363432453030323032464433330d
2024.08.21 22:32:36 5: pylon - data returned raw: ~20024600B07E00020F0CD60CD60CD60CD60CD60CD70CD60CD60CD60CD50CD60CD70CD80CD60CD5060B810B6E0B6A0B690B680B78FFEAC08CFFFF04FFFF0025010CB90186A0E0C4
2024.08.21 22:32:36 5: pylon - data returned:
0x00000000 (00000)  7e323030 32343630 30423037 45303030  ~20024600B07E000
0x00000010 (00016)  32304630 43443630 43443630 43443630  20F0CD60CD60CD60
0x00000020 (00032)  43443630 43443630 43443730 43443630  CD60CD60CD70CD60
0x00000030 (00048)  43443630 43443630 43443530 43443630  CD60CD60CD50CD60
0x00000040 (00064)  43443730 43443830 43443630 43443530  CD70CD80CD60CD50
0x00000050 (00080)  36304238 31304236 45304236 41304236  60B810B6E0B6A0B6
0x00000060 (00096)  39304236 38304237 38464645 41433038  90B680B78FFEAC08
0x00000070 (00112)  43464646 46303446 46464630 30323530  CFFFF04FFFF00250
0x00000080 (00128)  31304342 39303138 36413045 3043340d  10CB90186A0E0C4.

2024.08.21 22:32:36 4: pylon - retrieve battery info: alarmInfo
2024.08.21 22:32:36 4: pylon - request command (ASCII): ~20024644E00202FD31
2024.08.21 22:32:36 5: pylon - request command (HEX): 7e3230303234363434453030323032464433310d
2024.08.21 22:32:36 5: pylon - data returned raw: ~20024600804400020F00000000000000000000000000000006000000000000000000000E40000000F0AB
2024.08.21 22:32:36 5: pylon - data returned:
0x00000000 (00000)  7e323030 32343630 30383034 34303030  ~200246008044000
0x00000010 (00016)  32304630 30303030 30303030 30303030  20F0000000000000
0x00000020 (00032)  30303030 30303030 30303030 30303030  0000000000000000
0x00000030 (00048)  30303630 30303030 30303030 30303030  0060000000000000
0x00000040 (00064)  30303030 30303030 45343030 30303030  00000000E4000000
0x00000050 (00080)  30463041 420d                        0F0AB.

2024.08.21 22:32:36 5: pylon - Alarminfo - Status 1 alarm: 00
2024.08.21 22:32:36 5: pylon - Alarminfo - Status 2 Info: 0E
2024.08.21 22:32:36 5: pylon - Alarminfo - Status 3 Info: 40
2024.08.21 22:32:36 5: pylon - Alarminfo - Status 4 alarm: 00
2024.08.21 22:32:36 5: pylon - Alarminfo - Status 5 alarm: 00

2024.08.21 22:32:36 4: pylon - retrieve battery info: chargeManagmentInfo
2024.08.21 22:32:36 4: pylon - request command (ASCII): ~20024692E00202FD2E
2024.08.21 22:32:36 5: pylon - request command (HEX): 7e3230303234363932453030323032464432450d
2024.08.21 22:32:36 5: pylon - data returned raw: ~20024600B01402D002AFC80320FCE0C0F92B
2024.08.21 22:32:36 5: pylon - data returned:
0x00000000 (00000)  7e323030 32343630 30423031 34303244  ~20024600B01402D
0x00000010 (00016)  30303241 46433830 33323046 43453043  002AFC80320FCE0C
0x00000020 (00032)  30463932 420d                        0F92B.

2024.08.21 22:32:36 4: pylon - Socket/Connection to the RS485 gateway was closed
2024.08.21 22:32:36 4: pylon - got data from battery number >1< successfully

[DS_Starter]

Das Protokoll sieht gut aus. So soll es sein.

[satprofi]

dann musst du nur mehr den code um die gruppe erweitern. wenn ich zeit habe kann ich es mir ja ansehen. heisst gruppe 0 gibts dann nicht, sondern 1-6 wenn im verbund.
habe gelesen, das can u. rs485 gleichzeitig geht, also selbes kabel.

[Janvi]

So einfach scheint das mit der Erweiterung der Gruppe tatsächlich noch nicht zu gehen. Ausgehend von einer funktionierenden Konfiguration waren jetzt aber mehrere erkenntisorientierte Experimente möglich:

1)
Beiliegend sieht man in AnalogReq.bmp  das Anforderungstelegramm am Waveshare RS485 Anschluss ohne das dieses in einer Batterie steckt. Die Dauer eines Bits lässt sich dort mit etwa 8,7 usec ausmessen. Ein Byte mit Start, 8Daten und Stopbit wird demnach in etwa 87 uSec übertragen. In den Quellen des Pylon Moduls sieht man, daß das Telegramm 20 Bytes lang ist. Das dauert dann mindestens 20x87us = 17,4 msec. Die Cursor im Bild stehen bei 17,8 ms was eventuellen kleinen und akzeptablen Pausen zwischen den Bytes zuzüglich Messungenauigkeit geschuldet ist.

Du darfst diesen Dateianhang nicht ansehen.

Die Messung erfolgt zwischen den Anschlüssen A und B, mit dem GND des Oszilloskops auf B. Eine Messung gegen die am Waveshare ebenfalls vorhandenen PE und GND pins hat sich als nicht zielführend erwiesen. Die differentielle Amplitude beträgt etwa 2 Volt. Das liegt sicher über der für RS485 zur Funktion definierten Mindestamplitude von 0,2V. Vor dem Telegramm ist der RS485 Ausgang des Gateways hochohmig und es wird keine Spannung gemessen. Aufgrund der fehlenden Bias Widerstände ist ein Terminierungswiderstand nicht nur zur Terminierung obligatorisch, weil sonst kein Strom fliessen kann. Ich hatte hier 150 Ohm in der Schublade vorrätig. Man sieht einen kleinen Gleichtaktfehler, wo das gesamte Telegramm in der absoluten Höhe ein leichtes Einschwingen zeigt. Dies ist der fehlenden GND Verbindung und den damit ebenfalls fehlenden Bias Widerständen geschuldet. Ein einzelner Bias Widerstand mit der üblichen Größe von 680 Ohm gegenüber PE oder GND hat keinerlei Verbessung gebracht. Neuere RS485 Tranceiver kommen damit aber problemlos klar. Sowohl Waveshare als auch Pylontech verbauen offensichtlich solche Tranceiver denn es hat soweit ja auch zuverlässig funktioniert.

Die Verdrahtung ist auf beiden Seiten A für das nicht invertierte Signal oder Plus und
B für das invertierte Signal oder Minus. Bei ABB Zählern ist das Übrigens genau verdreht und die zählen warum auch immer C,B,A für GND,Plus,Minus wie auch die US5000 die DIP Schalter zur zusätzlichen Verwirrung auf dem Kopf haben und dann die Beschreibung weglassen

Du darfst diesen Dateianhang nicht ansehen.

2)
Auf AnalogResp sieht man das Anforderungstelegramm sowie die Antwort der dazugehörenden Batterie. Die Batterie lässt sich für diese Antwort etwa 280uS Zeit, was völlig ok ist. Man sieht auch hier mit der kleinen Abwärtsbewegung am Anfang des Antworttelegramms das insgesamt eine etwas kleinere Amplitude hat ebenfalls einen kleinen Gleichtaktfehler.

Du darfst diesen Dateianhang nicht ansehen.

3)
In Tel3 sieht man alle 3 Telegramme welche von FHEM angefordert und von der Batterie beantwortet werden. Fhem lässt sich bis zur Anforderung des nächsten Telegramms etwa 3-4 msec Zeit was ebenfalls ok ist. Wie die vertikalen Cursor zeigen, erfolgt die gesamte Übertragung aller Batteriedaten dabei in einer Zeit von weniger als 40ms. Auch bei 16 Batterien einer Gruppe wäre eine Zykluszeit von <1 Sek noch problemlos realisierbar. Am Ende des ersten (und dritten) Antworttelegramms sieht man einen unschönen Überschwinger welcher den fehlenden Bias Widerständen geschuldet ist. Er entsteht, wenn die RS485 Tranceiver nach Beendigung ihrer Übertragung in den hochohmigen Zustand gehen. Auch hierdurch gibt es keine Probleme und bezüglich der Bias Widerstände es gilt das Gleiche wie unter 1)

Du darfst diesen Dateianhang nicht ansehen.

4)
Mit BatView habe ich versucht die aktuelle Adresse einer beliebigen Batterie auszulesen. Ich habe diese Version mal von NKON erhalten und weis nicht, warum hier der SOC nicht angezeigt wird. Bei 100Ah für US5000/50V sind 39,45Ah aber etwa 38% was plausibel ist. Im Device List Window links sieht man unten address: 16. Zum Update der Adressanzeige nach dem Umstecken der seriellen Leitung ist ein Disconnect-Connect Zyklus in BatteryView erforderlich. Damit lässt sich feststellen, daß beide meiner 2 Gruppen a 16 US5000  von 1 (Master mit freier Link Buchse oben) bis 16 (Slave mit freier Link Buchse unten) zählen. Eine Erweiterung der Adressen von 14 auf 16 wäre also sinnvoll und ich könnte das mit einer Gruppe von 16 US5000 testen.

5)
Summa Summarum gilt das Waveshare RS485 to ETH (B) Modul damit als erfolgreich getestet. Es gibt auch auch von dem Modul mit (B) zwei verschiedene Versionen welche sich durch das PoE Feature unterscheiden. Ich habe die Version mit PoE und kann deshalb auf ein extra Netzteil verzichten. Darüber hinaus ist aktives PoE für Pylon Besitzer grundsätzlich zu empfehlen weil es ohne Umwege direkt an das 48V DC Netz angeschlossen werden kann.  Die Waveshare Versionen mit und ohne PoE kann man nur durch die Klemmenbeschriftung NC unter der blauen ACT LED (ohne PoE) oder GND/DEF (mit PoE) unterscheiden. Welche Funktion diese Signale haben und ob sich was mit den Bias Widerständen zu tun haben könnten wird möglicherweise als Geheimnis im Reich der Mitte verleiben.

6)
Es hat sich die momentan bittere Erkenntnis durchgesetzt, daß ein Antworttelegramm auf der RS485 trotz korrekter Adresse eines Masters ausbleibt, sobald dieser am LV Hub oder an einem weiteren Master zum LV Hub eingesteckt ist. Zieht man das Kabel ab, so kommen die Antworttelegramme sofort auch ohne daß die betreffende Master Batterie neu gebootet wurde. Das lässt darauf hoffen, daß mit einem Spezialkabel an dieser Stelle vielleicht noch etwas auszurichten ist. Ansonsten wäre FHEM so nur für Installationen ohne LV-Hub anschaltbar.


 
   




 

[satprofi]

bei rs485 Verbindung beginnt 1. Batterie mit addr 2

[satprofi]

dies kennst du schon, oder?
https://community.victronenergy.com/storage/attachments/24334-lv-hub-communication-hub-product-manual-v22-202103.pdf

[Janvi]

Ja, ich kenne das Manual, habe aber trotzdem Tage gebraucht bis der LV Hub bei mir gelaufen ist. Insbesondere die Bedienreihenfolgen mit 3 mal Piepsen und einschalten und einstecken sind ausserordentlich omninös. Wenn man mehrere Fehler hat so daß man nicht von einer funktionierenden Konfiguration aus experimentieren kann, gibt es kaum eine Chance rauszufinden ob es an der Kabelbelegung oder an einer Fehlbedienung oder an den DIP Switches oder sonst was hängt. Irgendwann hat der LV Hub dann meine 2  Gruppen irgendwie eingebucht. Ich habe den LV-Hub seither nicht mehr angefasst und er hat jetzt glücklicherweise beim rumprobieren auch die 2 Gruppen nicht verloren. Im alten Victron Forum gibt es einen LV-Hub Thread der einige Beiträge von mir enthält und auch einen anderen Benutzer bei dem der LV Hub zuvor schon mit 3 Gruppen funktioniert hat.

Der Screendump von dir gilt wohl nur für RS485. Typisch Pylontech und nutzlos: Should be X000. Man soll jetzt als Anwender annehmen, daß die X nicht links sondern rechts auf DIP SW 1 positioniert ist, daß dies die Baudrate bedeutet, 000 bedeutet die DipSW 2,3,4 oben zu haben und dass dies alles für CAN gar nicht relevant ist. Das sind bereits 5 Annahmen wo man als durchschnittlicher Batteriekäufer eigentlich nicht alleine draufkommt. Ich kann mir auch nicht vorstellen, daß dies irgend ein Chinese erahnen kann. Ebenso selbstredend nutzlos: In Multi Group Mode, Master Battery must have right dip switch address. Dazu muß ein Andwender nun das Manual lesen um zu wissen, daß die DIP Schalter richtig eingestellt sein müssen. Was die richtige Stellung für welchen Anwendungsfall ist, erfährt er hier allerdings nirgends. Pylontech selbst zuckt mit der Schulter und verweist an den Importeuer bzw. Händler. Das war bei mir das zwischenzeitlich insolvente Bosswerk/Greenakku. Der Support dort hatte einen LV-Hub aber noch gar nie gesehen und mich nach 6 Wochen dann darauf aufmerksam gemacht, daß ich mal verschiedene YT Videos dazu anschauen soll wenn ich das nicht zum Laufen kriege.

Eine der großen Schwierigkeiten in den Pylon Beschreibungen ist die gesamte Firmengeschichte zu erkennen. Das LV-Hub Manual erwähnt zum Beispiel gar nirgends die US5000 weil der LV_Hub eben schon älter ist. Wie die Modulentwickler hier ja auch schon gemerkt haben, sind nicht alle Batteriemodelle gleich obwohl sie ähnlich sind.

Seite 6/14 zeigt die Verbindung mehrerer Gruppen mit dem LV-Hub unter RS485. Vermutlich ist nur hier der ADDR Dip Switch überhaupt maßgeblich. Die Gruppe kann hier nicht von 1-16 gehen, weil die Master Batterie einer Gruppe gar nicht der RS485 Master ist und diese wie du vermerkt hast bei Adresse 2 startet.

Seite 7/14 zeigt die gleiche Konfiguration mit sternförmig angeordneten RS485 aber die Kommunikation zum WR ist CAN. Vermutlich ist auch hier der ADDR Schalter ausschlaggebend.

Seite 8/14 oder 13/14 zeigt nun eine Konfiguration welche 16er Gruppen über die Master mit CAN verbinden kann. Was der Unterschied zwischen beiden Seiten sein soll, wird das Rätsel des Tages. Dass nun ausgerechnet diese Art der Verbindung die bevorzugte für US5000 sein könnte, liest man ebenso nirgends. Ebensowenig ob vielleicht auch andere Verbindungen mit US5000 gehen und was deren Vor oder Nachteile sind. Man muß  trotz lesen der Beschreibung alles annehmen und mit unendlich vielen Versuchen alles ausprobieren. Der Gipfel auf Seite 8/14 des LV-Hub Manuals ist dann noch, daß für detailierte Informationen auf das LV-Hub Manual verwiesen wird. Sozusagen wird das einstöpseln der passenden Leitungen und Dip Schalter zu einem rekursiv nicht terminierenden Problem. Sonst könnte es ja Jeder wenn es einfacher wäre. 
Man kann nur annehmen, dass US3000, US2000 kein CAN haben oder die CAN FW  zur Aggregation noch fehlerhaft ist, während US2000C, US3000C und US5000 aber mit den CAN Konfigurationen laufen.

Nach dem Auspiepsen der Buchsen auf dem BMS, weis ich ja daß die A/B in der Belegung identisch mit RS485 und CAN gleichzeitig belegt sind. Verbindet man jetzt A  Buchse 1:1 mit der B Buchse der Folgegruppe oder dem LV Hub, so kann die Batterie FW wahlweise über beide Schnittstellen einzeln oder auch gleichzeitig kommunizieren. Ich vermute, daß sie dies nur über CAN macht, die RS485 Seite aber durcheinanderkommt weil mehr als eine Batterie mit dem Waveshare Gateway verbunden ist. Dafür spricht auch, daß das Antwort Telegramm sofort zurückommt wenn man das abgehende Kabel aussteckt. Ohne die Batterie neu zu booten, wird diese vermutlich auch nicht in ihrer Adresse neu enumeriert, so daß es nicht an der falschen Adresse liegt die auch gar nicht am ADDR Adressschalter einzustellen geht. Mit Battery View kann man die Batterieadresse schliesslich auslesen und anzeigen. Aber wir werden sehen und ich werde berichten wenn ich was rausfinde.

Derweil wären die Adressen 15 und 16 aber vermutlich eine naheliegendere und einfacher zu testende Sache.








 


   

[satprofi]

Hallo.
Habe adresse 15 u. 16 für Systemparameter ergänzt, kannst mal checken?

15 => { cmd => "~20104647E00210FD30\x{0d}", mlen => 68 },
16 => { cmd => "~20114647E00211FD2E\x{0d}", mlen => 68 },

Hoffe die Adresse passt, 14 wäre 14 => { cmd => "~200F4647E0020FFD06\x{0d}", mlen => 68 }, + 1 dazu dann bei 15 u. 16.

Die Frage wäre, ob Master in Gruppe 2 auch mit Adresse 2 beginnt, oder jetzt mit 1 . Kannst du das mit BatteryView auslesen?

[edit] @ DS_Starter
habe modul auf 16 Einheiten angepasst , kannst du es checken?

[DS_Starter]

@satprofi, danke für die Erweiterung.
Ich habe es gegengecheckt und zwei/drei Korrekturen in den Checksummen vorgenommen wo du dich nach meiner Berechnung vertan hattest.
Ist eingecheckt und als neue Version morgen früh im Update.

Grüße,
Heiko

[satprofi]

Echt? Trotzdem danke.
Jetzt wär noch interessant mit welcher adresse modul 1 in gruppe 2 angesprochen wird.

[DS_Starter]

Jetzt wär noch interessant mit welcher adresse modul 1 in gruppe 2 angesprochen wird.

Ja, das muß ich mir noch anschauen. Ist aber heute zu spät dafür geworden.

Gleich im ersten Block war z.B. ein Fehler drin:

 15 => { cmd => "~20104693E00210FD2E\x{0d}", mlen => 52 },
 16 => { cmd => "~20114693E00211FD2D\x{0d}", mlen => 52 },

geändert in

 15 => { cmd => "~20104693E00210FD2F\x{0d}", mlen => 52 },
 16 => { cmd => "~20114693E00211FD2D\x{0d}", mlen => 52 },

War noch 1 oder zwei Stellen. Kann ich halt nicht testen, habe nicht so viele Batterien.

[Janvi]

Danke für die rasche Änderung. Im Vorfeld habe ich erst mal probiert, die bisherige Version vollständig mit allen Adressen zu testen. Dazu habe ich meine hintere Gruppe am CAN ausgesteckt um ein Telegramm zu erhalten. Das hatte ich gestern schon mal gemacht ohne daß groß was passiert ist. Diesmal hat es aber den kompletten LV-Hub zerlegt. Er steht jetzt auf "Internal Error", hat dies nach oben weitergemeldet und das  ESS ist auf Netzbezug gegangen. Andererseits ist es aber auch beruhigend, daß das Teil überhaupt einen Kommunikationsausfall bemerkt und darauf in einen sicheren Zustand wechselt. Aber ich muß ich jetzt schauen wie ich das mit 3 mal Piepsen usw. wieder hinkriege. Wenigstens weis ich daß die Kabel stimmen weil es so schon mal funktioniert hat. Die Pylons haben von Protokollen, Sicherungsschicht, Wiederholstrategien einfach Null Ahnung und der gesamte Datenaustausch ist irgendwie hingebastelt. Bei CAN könnte man CANOpen nehmen, bei RS485 Modbus RTU und jeder WR Hersteller wüsste was er zu tun hat. Aber CiA möchte natürlich Gebühren für die Mitgliedschaft um die Specs downloaden zu können welche nicht nur in China niemand zahlen will. Wenn dann irgendwelche Pylon spezifischen SDO oder PDO Nummern dabei rauskommen ist das trotzdem ok. Der grobe Rahmen arbeitet dann zuverlässig und für Kompabilität sind die einzelnen Hersteller oder Teilnehmer zuständig. Wahrscheinlich weis Pylontech ganz gut, daß ihr selbstgestricktes Protokoll an vielen Stellen nicht ordentlich arbeitet und rückt deshalb die Spezifikation dazu nicht wirklich raus um Nachfragen zu vermeiden.  Überhaupt würde man bei  bei CAN mit 11 bit Hardware Identifier niemals einen LV-Hub brauchen und auch mit RS485  wären 128 Batterien ohne Hub möglich wenn nur das Protokoll was taugen würde.

Das ist aber eine andere Sache. Beim durchprobieren der US5000 Adressen mit der bestehenden in Fhem eingebauten Version hat von 1 bis einschliesslich 12 alles wie erwartet funktioniert. Adressen und die gemeldeten Seriennummern stimmen mit den Aufklebern an der Frontplatte und mit den von BatteryView gemeldeten Daten überein. Das Gateway war immer an der Master Batterie auf B/RS485 eingesteckt.

Bei der Adresse 13 und 14 gibt es dann regelmässig einen Timeout. Nachfolgend ist ein Log wo man sieht, daß AnalogValue, AlarmInfo, ChargeManagementInfo zunächst noch erfolgreich gelesen werden. Gelegentlich wird dann ein anderer Abfragezyklus eingeschoben, welcher SerialNumber und ManufacturerInfo abfrägt. SerialNumber antwortet noch, aber bei ManufacturerInfo passiert der Timeout wenn die Adresse 13 oder 14 ist:

Code Auswählen Erweitern



2024.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






[satprofi]

Jetzt wo du es erwähnst, auch ich habe manchmal bei modul 11 u. 12 leere abfragen, sah ich schon öfters durch zufall. Ich frage sogar nur alle 60sec. ab.