FHEM Forum

Hallo.
Vielleicht geht es im anderen Thread unter, hier gibts die akt. Version des Moduls für PylonTech US2000 u. US3000.
Dank an den Modulersteller fürs Grundgerüst.
Ich habe das Modul für die US2000 erweitert um einige Funktionen wie ChargeManagmentInfo, SerialNummer in orig. Bezeichnung, Softwareversion, etc.
Dank auch an User Audi_Coupe_S für die Anpassung der US3000 Serie.

ja, cool. Gibt es einen Grund dafür, dass nur 6 Module unterstützt werden? Möglich wären (mindestens) 8?

Grüße,
Stephan

werden ja 8 unterstützt.musst für jedes neues device anlegen.

Hi, darf ich mal ganz kurz fragen, wo man eine Installationsanleitung für das Modul Pylontech herbekommt? In der CommandRef ist kein Modul vorhanden... Wie kann ich am einfachsten meine Pylonbatterien und evtl auch noch meinen Growatt Wechselrichter in FHEM einbinden?

Danke für Tipps,
Karsten

https://forum.fhem.de/index.php/topic,126361.0/all.html

Hallo,

ich lese zur Zeit die Pylontech via Cerbo GX (Victron) mit MQTT aus.
Es fehlen allerdings die Werte für /History/DischargedEnergy bzw. /History/ChargedEnergy.

So wie ich die Doku und das Modul verstehe gibt es damit diese Werte aber auch nicht oder habe ich etwas übersehen ?

Grüße,
Heiko

Hallo zusammen,

durch meine fortschreitende Victron Energy Installation mit Pylontech US3000C habe ich mich intensiver mit diesem Modul beschäftigt.
Ich war so frei und habe die hervorragende Arbeit der User, die an 70_Pylontech.pm mitgewirkt haben, als Grundlage für ein neues Modul 70_PylonLowVoltage.pm genommen.
Ich habe einen neuen Namen gewählt um 1. das Original nicht zu verändern und 2. können vermutlich (nachweisen kann ich es nicht) nur die Low Voltage Batterietypen von Pylontech ausgelesen werden, da sich die Protokolldoku darauf bezieht. Dieser Umstand sollte sich im Namen wiederfinden.

Was ist in 70_PylonLowVoltage.pm geändert/neu:

- der Typ US3000C und vermutlich auch US5000 werden unterstützt
- programmtechnisch wurde das Modul in ein eigenes Perl Package überführt
- es gibt die Attribute interval und timeout statt Angabe im DEF
- mit dem Attribut interval kann sowohl eine automatisch zyklische Abfrage oder eine Abfrage "On demand" realisiert werden
- mit dem Attribut "gatewayPermLink" kann gewählt werden ob eine permanente Verbindung zum RS485 Gateway verwendet werden soll oder nicht
- das Format der Definition ist geändert "define ... PylonLowVoltage <hostname/ip>:<port> [<bataddress>]"
- das Modul kann mit dem Attribut disable wie in FHEM üblich disabled werden
- der Support von Meta.pm ist eingebaut sowie eine Versionierung
- mit der Getter Drucktaste "get ... data" können die Daten manuell abgerufen werden
- die Validierung empfangener Daten ist der Protokolldoku angepasst
- die chargeManagmentInfo ist erweitert, der Abruf der System Parameter ist eingebaut und Readings eigener Berechnungen wie packImbalance, packState ist eingebaut
- die Logausgaben sind erweitert
- es gibt mehr Readings (siehe Anhang)

Ich hoffe die Erweiterungen treffen auf allgemeine Zustimmung und bereichern unsere Möglichkeiten mit FHEM.
Das Modul kann aus meinem contrib (siehe Fußtext) geladen werden.

Außerdem ziehe ich in Erwägung das Modul nach Überarbeitung/Anpassung der Commandref in das offizielle Repository einzuchecken. Natürlich bleiben die Angaben zum ursprünglichen Autor von 70_Pylontech.pm im Copyright erhalten.
Ich hoffe auf eure Unterstützung; vor allem von satprofi und anderen Users die sich schon lange mit dem Protokoll auseinandergesetzt haben; und euer Interesse. Wer andere Pylontechs wie US5000 u.a. im Einsatz hat kann gern mal den Kompatibilitätscheck wagen. Ich habe nur die US3000C.

LG,
Heiko

Zitat von: DS_Starter am 04 Mai 2023, 16:07:23ich lese zur Zeit die Pylontech via Cerbo GX (Victron) mit MQTT aus.
Es fehlen allerdings die Werte für /History/DischargedEnergy bzw. /History/ChargedEnergy.

Ich habe seit Januar einen Victron MP + Pylontech US5000 + US3000 + RPi mit Venus OS am Start.
Die Batterien sind via CAN Bus Adapter am RPi angebunden und ich lese nicht via MQTT sondern Modbus aus ( da gibt es die beiden fehlenden Werte DischargedEnergy / ChargedEnergy.
Ich würde gerne mal deine Version testen, wie hast du die Pylontechs angebunden da in deinem Sreenshot eine IP steht. ( RS485 Adapter auf LAN ? )

Nabend Wzut,

ja die Kommunikation läuft über einen RS485 to ETH Adapter.
Ich benutze diesen hier: https://www.amazon.de/dp/B07S2K41MS?psc=1&ref=ppx_yo2ov_dt_b_product_details

Bei mir ist der Victron Cerbo GX im Einsatz. Da wüßte ich jetzt auf Anhieb nicht wie ich den per Modbus auslesen sollte. Aber ich habe mir inzwischen eine Datenbanklösung erstellt indem ich die tägliche Lade/Entladeenergie logge. Die Werte kann ich dann nach Belieben aggregieren bzw. auswerten.

Zitat von: DS_Starter am 19 August 2023, 23:06:23Hallo zusammen,

durch meine fortschreitende Victron Energy Installation mit Pylontech US3000C habe ich mich intensiver mit diesem Modul beschäftigt.
Ich war so frei und habe die hervorragende Arbeit der User, die an 70_Pylontech.pm mitgewirkt haben, als Grundlage für ein neues Modul 70_PylonLowVoltage.pm genommen.
Ich habe einen neuen Namen gewählt um 1. das Original nicht zu verändern und 2. können vermutlich (nachweisen kann ich es nicht) nur die Low Voltage Batterietypen von Pylontech ausgelesen werden, da sich die Protokolldoku darauf bezieht. Dieser Umstand sollte sich im Namen wiederfinden.

Was ist in 70_PylonLowVoltage.pm geändert/neu:

- der Typ US3000C und vermutlich auch US5000 werden unterstützt
- programmtechnisch wurde das Modul in ein eigenes Perl Package überführt
- es gibt die Attribute interval und timeout statt Angabe im DEF
- mit dem Attribut interval kann sowohl eine automatisch zyklische Abfrage oder eine Abfrage "On demand" realisiert werden
- mit dem Attribut "gatewayPermLink" kann gewählt werden ob eine permanente Verbindung zum RS485 Gateway verwendet werden soll oder nicht
- das Format der Definition ist geändert "define ... PylonLowVoltage <hostname/ip>:<port> [<bataddress>]"
- das Modul kann mit dem Attribut disable wie in FHEM üblich disabled werden
- der Support von Meta.pm ist eingebaut sowie eine Versionierung
- mit der Getter Drucktaste "get ... data" können die Daten manuell abgerufen werden
- die Validierung empfangener Daten ist der Protokolldoku angepasst
- die chargeManagmentInfo ist erweitert, der Abruf der System Parameter ist eingebaut und Readings eigener Berechnungen wie packImbalance, packState ist eingebaut
- die Logausgaben sind erweitert
- es gibt mehr Readings (siehe Anhang)

Ich hoffe die Erweiterungen treffen auf allgemeine Zustimmung und bereichern unsere Möglichkeiten mit FHEM.
Das Modul kann aus meinem contrib (siehe Fußtext) geladen werden.



LG,
Heiko

cool.
habe gerade das originalmodul um 2 weitere einträge erweitert.
habe jetzt 8 Racks, die ich auslesen müsste.
werde deines mal checken.

Zitat von: DS_Starter am 19 August 2023, 23:06:23Hallo zusammen,

durch meine fortschreitende Victron Energy Installation mit Pylontech US3000C habe ich mich intensiver mit diesem Modul beschäftigt.
Ich war so frei und habe die hervorragende Arbeit der User, die an 70_Pylontech.pm mitgewirkt haben, als Grundlage für ein neues Modul 70_PylonLowVoltage.pm genommen.


LG,
Heiko

Hi.
Welche Kabelbelegung hast du für RS485?

bei mir kommt mit selben Kabel von US2000B auf US2000C "invalid data received ... discarded"

klappt schon. gnd abgeklemmt u. 120ohm widerstand eingesetzt

Nabend satprofi,

Zitathabe gerade das originalmodul um 2 weitere einträge erweitert.

Was hast du denn erweitert?

Zitatbei mir kommt mit selben Kabel von US2000B auf US2000C "invalid data received ... discarded"
klappt schon. gnd abgeklemmt u. 120ohm widerstand eingesetzt

Also ist das Modul sowohl mit US2000B als auch US2000C kompatibel?
Das würde ich in der ComRef ergänzen.

Ja, GND ist bei mir auch nicht angeschlossen, nur data+ und data-.

hallo.
2 stk. US2000C erweitert.
die B erkennt er als C, und die CellTemperatur bei den B pasdt auch nicht, dürfte ein Bit zuviel reinspucken.
weiters dürfte der SOC von den US2000B auch nicht passen. alle akku voll, nur die C zeigen 100% , die B aber 95,55%

vielleicht find ich die fehler.

Modul auf 8 Packs erweitert. Fehler bzgl. bmsTemp noch am eruiren.

Hallo Meister.
Habe jetzt mit BatteryView gegengecheckt, und da muss es einen zusammenhang mit Stringlänge geben.
Ich tippe das der USx000C darauf reagiert:
Answer from US2000 = 128bytes, from US3000 = 140bytes
      # Remain capacity US2000 hex(substr($res,109,4), US3000 hex(substr($res,123,6)
      # Module capacity US2000 hex(substr($res,115,4), US3000 hex(substr($res,129,6)
dadurch verschieben sich beim US2000B+ einige ergebnisse.
Die Daten vom USx000C passen, aber die vom B+ nicht wirklich.
sehe auch das du den SOC berechnest, der wird doch auch ausgelesen. Deine Berechnung sollte eigentlich SOH sein, noch verfügbare Kapa.

ich wollte schon einige werte damit auswerten, aber das modul meldet dann fehler beim reload.
vielleicht kommst du dem etwas näher.

LG Manfred

Hallo Manfred,

ich habe dir die Dokumentation für das verwendete Protokoll angehängt (vllt. kennst du sie schon?).
Es ist die aktuellste mir vorliegende Version.
Vllt. gibt es eine neuere, muss Pylontech mal anschreiben.
Jedenfalls wird US2000B etwas anders behandelt, siehe /get analog value auf Seite 15. Da wäre anzusetzen.
Der Unterschied ob 128 oder 140 Byte von der Bat kommt, ist auch von deren Kapazität abhängig. <=65Ah oder ＞65Ah. Ist auch dort erläutert.

Bin zur Zeit noch mit SolarForevast befasst und schaue mir das hier auch bald mal wieder an.
In der aktuellen Protokollversion V3.3 (ist aber auch schon von 2018) wird kein SOC mehr als Auslesewert dokumentiert. Deswegen berechne ich sie um protokollkonform zu implementieren.

LG,
Heiko

Hallo Heiko.
Ich vermute das der 2000C auch 140Byte sendet, und diese beim Empfang von B genullt sind.Hat dein US3000 nicht 18 Zellen?
Das Dokument kenn ich, hab es studiert. werde mir mit terminal mal genauer ansehen was als antwort von den pylons kommt.

LG

ZitatHat dein US3000 nicht 18 Zellen?

Nein, hat 15 Zellen (US3000C).

Hallo,

Ich lese schon seit Jahren mit Battery View über ein USB Adapter aus.
Wenn ich mir die *.pm ansehe, stoße ich auf:
  define <name> Pylontech <deviceaddress> <host> <port> [<interval> [<timeout>]]";

Muss hier zwingend ein USB zu TCP Adapter verwendet werden?

Danke

Nicht USB, sondern LAN->RS 485 Gateway, z.B. dieses: https://www.amazon.de/dp/B07S2K41MS?psc=1&ref=ppx_yo2ov_dt_b_product_details

Zitat von: DS_Starter am 15 September 2023, 15:59:47Nicht USB, sondern LAN->RS 485 Gateway, z.B. dieses: https://www.amazon.de/dp/B07S2K41MS?psc=1&ref=ppx_yo2ov_dt_b_product_details

Danke, sorry, meinte ich: LAN >RS 485 GW.

Wollte da eigentlich nicht noch so ein Ding dreinhängen, aber es nimmt ja nur <1 Watt hab ich gesehen. OK, wäre eine Notlösung.
Ich habe aber in der Garage wo die Pylontechs stehen, ohnehin einen Raspi mit FHEM am laufen und würde gerne direkt per USB RS485 Adapter drauf gehen, das ich für Battery View verwende.

Gibt es auch irgendwo ein FHEM Modul auf was über USB läuft?

vielleicht hilft dir da weiter

Bin gerade dabei den Code nochmal durchzugehen.
Habe wahrscheinlich einen Fehler bei den Temperaturen gefunden wenn die Batterie mehr als 15 Zellen hat.
Meine US3000C haben 15 Zellen, aber andere Typen könnten vermutlich 16 haben?

Ich habe die V 0.1.6 in mein contrib geladen.
Batterien mit mehr als 15 Zellen werden unterstützt, d.h. insbesondere Zellspannungen und Temperaturen sollten bei den betroffenen Typen korrigiert sein.

LG

Moin,

eine Frage.
Pylontech unterstützt ja soviel ich weiß in einer Gruppe 16 Batterien, 1 Master und max. 15 Slaves.
Im Modul haben können wir bisher bis 6 addressieren, d.h. also Batterie 1 (Master) bis 6 (Slaves).
Ich würde es auch bis ADR 16 ausbauen.
Allerdings kann ich den Erfolg nicht testen, da ich nur 4 Batterien in der Group habe.
Gibt es jemenden der mehr als 4 Batterien in einer Group betreibt und wenn ja wieviele?

Grüße
Heiko

Hallo Heiko.

Ich habe 8 in einer Gruppe. Hoffe du hast dies auch in deiner neuen Version berücksichtigt :-;
Das mit 16 stimmt so? dachte max. 8 pro Gruppe. Adresse btaucht ja nur der Master, Slaves werden autom. adressiert.

Grüsse Manfred

[edit]
sah gerade das du immer noch nur 6 Packs abfr4ägst.
Habe dein Modul auf 8Stk. erweitert.
Klappt weiterhin, nur die US2000B+ passt die Temp. immer noch nicht.

Hallo Manfred,

ZitatIch habe 8 in einer Gruppe. Hoffe du hast dies auch in deiner neuen Version berücksichtigt :-;

Geht eben nur bis 6 zur Zeit (bataddress 1-6 im DEF) in einer Gruppe. Mehrere Gruppen können zur Zeit ja auch nicht angesprochen werden. Kann ich nicht testen.
Aber ich würde es kurzfristig auf 8 Bat erweitern.
Dann kannst du es gerne mal testen, wäre super und würde mir helfen. Geht bei mir halt nicht.

Wenn du mehrere Batterien hast, definierst du entprechend viele Devices.
Hier ein Beispiel für meine 4 Bat:

define Pylon1 PylonLowVoltage 192.168.2.86:9000 1
define Pylon2 PylonLowVoltage 192.168.2.86:9000 2
define Pylon3 PylonLowVoltage 192.168.2.86:9000 3
define Pylon4 PylonLowVoltage 192.168.2.86:9000 4

Jede Instanz spricht die adressierte Batterie an.
Über eine Readingsgroup kann man sich dann eine schöne Übersicht anfertigen (Anhang).

ZitatDas mit 16 stimmt so? dachte max. 8 pro Gruppe. Adresse btaucht ja nur der Master, Slaves werden autom. adressiert.

Ich bin mir unsicher ob es für alle Typen gilt.
In meiner US3000C Doku steht explizit beschrieben, dass man 16 Batterien (1 Master + 15 Slaves) in einer Gruppe verschalten kann.
Pylontech gibt zum Beispiel folgende Möglichkeit an:

Master (1)   - US3000C/US2000C
Slave 2-8    - US3000C/US2000C/US3000/US2000
Slave 9-16   - US3000C/US2000C

Kannst ja mal in die Doku deiner Bat schauen. Wäre interessant.

LG,
Heiko

Ah, hast schon auf 8 erweitert. :)  Super, das übernehme ich dann.

Wegen der Temperaturen könntest du mal verbose 5 einschalten. Im Log erscheint dann zur Analyse der Part "analogValue".

2023.09.20 11:30:32.460 4: Pylone1 - retrieve battery info: analogValue
2023.09.20 11:30:32.460 4: Pylone1 - request command (ASCII): ~20024642E00202FD33
2023.09.20 11:30:32.461 5: Pylone1 - request command (HEX): 7e3230303234363432453030323032464433330d
2023.09.20 11:30:32.478 5: Pylone1 - data returned raw: ~20024600F07A00020F0D270D270D270D270D270D260D260D270D270D270D270D280D280D280D28050BC00BAF0BAE0BAC0BB20044C54BFFFF04FFFF000B00E421012110E2C3
2023.09.20 11:30:32.479 5: Pylone1 - data returned:
0x00000000 (00000)  7e323030 32343630 30463037 41303030  ~20024600F07A000
0x00000010 (00016)  32304630 44323730 44323730 44323730  20F0D270D270D270
0x00000020 (00032)  44323730 44323730 44323630 44323630  D270D270D260D260
0x00000030 (00048)  44323730 44323730 44323730 44323730  D270D270D270D270
0x00000040 (00064)  44323830 44323830 44323830 44323830  D280D280D280D280
0x00000050 (00080)  35304243 30304241 46304241 45304241  50BC00BAF0BAE0BA
0x00000060 (00096)  43304242 32303034 34433534 42464646  C0BB20044C54BFFF
0x00000070 (00112)  46303446 46464630 30304230 30453432  F04FFFF000B00E42
0x00000080 (00128)  31303132 31313045 3243330d           1012110E2C3.

Es müssten die Readings

bmsTemperature
cellTemperature_0104
cellTemperature_0508
cellTemperature_0912
cellTemperature_1316  (bei 16 Zellen, sonst cellTemperature_1315)

erstellt werden.
Kannst deine Readings gerne mal posten.

Edit: Ich habe übrigens Pylon wegen einer neuren RS485 Doku angeschrieben. Sie haben mir geantwortet dass diese Doku nicht der Allgemeinheit zugänglich gemacht wird. :( Vllt. taucht mal etwas neueres im I-Net auf.

@Manfred, ich habe deine Ergänzung auf 8 Bat übernommen und als V0.1.7 in mein contrib geladen.

Weiterhin habe ich in der V noch etwas gefixt, was ich gestern Abend zur späten Stunde vergessen hatte.  ::) Vllt. klappen jetzt auch deine Temps.

Ich habe auch noch das angehängte Dok gefunden. Die Anzahl der möglichen Batterien in einer Gruppe ist wohl tatsächlich vom Typ anhängig, Single string quantity(pcs) -> US2000B Plus = 8.
Ich gehe davon aus, das der Typ des Masters relevant ist.

LG

Noch eine Frage ... welchen Wert hat bei dir das reading numberTempPos?

Zitat von: DS_Starter am 20 September 2023, 13:16:05Noch eine Frage ... welchen Wert hat bei dir das reading numberTempPos?

5

Passt.

Zitat von: DS_Starter am 20 September 2023, 11:33:59Ah, hast schon auf 8 erweitert. :)  Super, das übernehme ich dann.

Wegen der Temperaturen könntest du mal verbose 5 einschalten. Im Log erscheint dann zur Analyse der Part "analogValue".



Es müssten die Readings

bmsTemperature
cellTemperature_0104
cellTemperature_0508
cellTemperature_0912
cellTemperature_1316  (bei 16 Zellen, sonst cellTemperature_1315)

erstellt werden.
Kannst deine Readings gerne mal posten.

Edit: Ich habe übrigens Pylon wegen einer neuren RS485 Doku angeschrieben. Sie haben mir geantwortet dass diese Doku nicht der Allgemeinheit zugänglich gemacht wird. :( Vllt. taucht mal etwas neueres im I-Net auf.

US2000B+

READINGS:
     2023-09-21 17:24:18   Manufacturer    Pylon---------------
     2023-09-21 17:24:18   averageCellVolt 3.321
     2023-09-21 17:24:18   batteryType     US2000C
     2023-09-21 17:24:18   bmsTemperature  29
     2023-09-21 17:24:18   cellTemperature_0104 27
     2023-09-21 17:24:18   cellTemperature_0508 27
     2023-09-21 17:24:18   cellTemperature_0912 27
     2023-09-21 17:24:18   cellTemperature_1315 -100
US2000C

READINGS:
     2023-09-21 17:26:17   Manufacturer    Pylon---------------
     2023-09-21 17:26:17   averageCellVolt 3.316
     2023-09-21 17:26:17   batteryType     US2000C
     2023-09-21 17:26:17   bmsTemperature  28.4
     2023-09-21 17:26:17   cellTemperature_0104 26.7
     2023-09-21 17:26:17   cellTemperature_0508 27
     2023-09-21 17:26:17   cellTemperature_0912 26.6
     2023-09-21 17:26:17   cellTemperature_1315 27.1

Moin,

da fällt mir momentan nichts dazu ein.
Man könnte nochmal manuell die verbose 5 Ausgaben überprüfen von:

2023.09.22 09:11:18.148 4: Pylone1 - retrieve battery info: manufacturerInfo
2023.09.22 09:11:18.149 4: Pylone1 - request command (ASCII): ~20024651E00202FD33
2023.09.22 09:11:18.149 5: Pylone1 - request command (HEX): 7e3230303234363531453030323032464433330d
2023.09.22 09:11:18.161 5: Pylone1 - data returned raw: ~20024600C04055533330303043000000010750796C6F6E2D2D2D2D2D2D2D2D2D2D2D2D2D2D2DEFBC
2023.09.22 09:11:18.162 5: Pylone1 - data returned:
0x00000000 (00000)  7e323030 32343630 30433034 30353535  ~20024600C040555
0x00000010 (00016)  33333333 30333033 30343330 30303030  3333030304300000
0x00000020 (00032)  30303130 37353037 39364336 46364532  0010750796C6F6E2
0x00000030 (00048)  44324432 44324432 44324432 44324432  D2D2D2D2D2D2D2D2
0x00000040 (00064)  44324432 44324432 44324432 44454642  D2D2D2D2D2D2DEFB
0x00000050 (00080)  430d                                 C.

Für den Batterienamen ab Position 13, Länge 20 Zeichen. (hier US3000C -> 55533330303043000000)

Beziehungsweise für die Temperaturen:

2023.09.22 09:11:18.221 4: Pylone1 - retrieve battery info: analogValue
2023.09.22 09:11:18.222 4: Pylone1 - request command (ASCII): ~20024642E00202FD33
2023.09.22 09:11:18.222 5: Pylone1 - request command (HEX): 7e3230303234363432453030323032464433330d
2023.09.22 09:11:18.241 5: Pylone1 - data returned raw: ~20024600F07A00020F0CCE0CCE0CCE0CCE0CCE0CCF0CCF0CCF0CCE0CCE0CCF0CCE0CCE0CCE0CCD050BB30B980B960B950BA5FFF8C015FFFF04FFFF000C007C2C012110E0FE
2023.09.22 09:11:18.242 5: Pylone1 - data returned:
0x00000000 (00000)  7e323030 32343630 30463037 41303030  ~20024600F07A000
0x00000010 (00016)  32304630 43434530 43434530 43434530  20F0CCE0CCE0CCE0
0x00000020 (00032)  43434530 43434530 43434630 43434630  CCE0CCE0CCF0CCF0
0x00000030 (00048)  43434630 43434530 43434530 43434630  CCF0CCE0CCE0CCF0
0x00000040 (00064)  43434530 43434530 43434530 43434430  CCE0CCE0CCE0CCD0
0x00000050 (00080)  35304242 33304239 38304239 36304239  50BB30B980B960B9
0x00000060 (00096)  35304241 35464646 38433031 35464646  50BA5FFF8C015FFF
0x00000070 (00112)  46303446 46464630 30304330 30374332  F04FFFF000C007C2
0x00000080 (00128)  43303132 31313045 3046450d           C012110E0FE.

Die Anzahl der gelieferten Temperaturpositionen ergibt sich ab Position 79 , 2 Zeichen -> 05 -> 5 Positionen.
Ab Postion 81 beginnt die erste Temperaturposition (bmsTemperature) mit Länge 4 die entsprechend der Doku S.15 umzurechnen sind -> 0BB3 -> (2995 - 2731)/10 -> 26,4 °C.
Die nächste Temp begint dann ab Pos. 85 die nach dem gleichen Schema zu berechnen sind.
Die letzte Temperatur (5), deine fehlerhafte Temp, beginnt dann ab Position 97.
Bei mir ist die letzte Temp (cellTemperature_1315) dann entsprechend-> 0BA5 -> (2981 - 2731)/10 -> 25 °C.

Vllt. kannst du damit mal die Antworten deiner US2000B+ analysieren.

Lg
Heiko

Hallo Manfred,

schau mal, hier hat im PV-Forum jemand das gleiche Problem mit US2000B Plus als Slaves und der Temp-Ausgabe 5 mit -100 -> https://www.photovoltaikforum.com/thread/130061-pylontech-us2000b-daten-protokolle-programme/?postID=3240215#post3240215

Leider konnte ich eine Antwort oder Lösung dazu in dem Thread nicht finden.
Hast du in deinem Stapel die aktuellste Batterie als Master eingesetzt?

Hallo Heiko.
Habe jetzt die Daten aufgebröselt. Beim US2000B+ gibts koimischerweise einen unerklärlichen wert, bei Temp N .
Hab dir die Tabellen per PN gesendet.

Gruss Manfred

Die Zeile 20 (M+3) ist eigentlich die Temperatur des BMS, nicht Temp. Zelle 1-4.
Ist aber eigentlich unwichtig. Dadurch verschiebt es sich bloß.
In der Zeile 24 (M+N+2) steht dann die Temp für Zelle 13-15/16.
In meinem Post oben hatte ich einen Beitrag von jemanden mit genau identischen Problem gefunden. Leider ohne Lösung/Reaktion.

In welcher Reihenfolge sind denn deine Batterien (Master->Slaves) gestapelt?

US2000C - US2000B

Zitat von: DS_Starter am 22 September 2023, 15:16:08Die Zeile 20 (M+3) ist eigentlich die Temperatur des BMS, nicht Temp. Zelle 1-4.
Ist aber eigentlich unwichtig. Dadurch verschiebt es sich bloß.
In der Zeile 24 (M+N+2) steht dann die Temp für Zelle 13-15/16.
In meinem Post oben hatte ich einen Beitrag von jemanden mit genau identischen Problem gefunden. Leider ohne Lösung/Reaktion.

In welcher Reihenfolge sind denn deine Batterien (Master->Slaves) gestapelt?

habe die doku als vorlage genommen.

Das passt m.M. auch zu den Empfehlungen von Pylontech.
Möglicherweise ein Thema der Firmware. Aber das würde ich deswegen nicht machen oder nur wenn man genau weiß was man tut. Gibt einige Hinweise im Netz zu diesem Thema.

haben wir was übersehen?

Nicht dass ich wüsste. Ist so implementiert wie dokumentiert. Hmm... wie geschrieben, auch ein anderer User hat dieses Prob mit us2000b plus und dem Temp 5 Wert = -100 (-1000 / 10). Und er hat sicherlich andere Software benutzt.

@Manfred, wenn es dir nicht zuviel ist hätte ich noch den Vorschlag dass du die US2000C mal aus der Kommunikationskette rausnimmst, also die Link-Verbindung trennst, sodass nur noch US2000B aktiv sind.
Dann natürlich die RS485 Verbindung auf die oberste US2000B setzen und den Stapel abfragen.
Möglicherweise stellt sich das Ganze dann anders dar.

nee nee nee, ich lass das system so. rennt ja bestens, diese abfrage ist nur reine spielerei.
vielleicht komm ich ja auf irgendeine Lösung.

Verständlich ;)

Wenn du aber möchtest, könntest du im PV-Forum (mein geposteter Link) nachfragen ob der User dieses Problem bei sich lösen konnte und wenn ja wie. Das könntest du bei deiner Batterie nachprüfen.

Hallo Heiko.
Habe mich jetzt doch gespielt.
Ergebnis:

US2000B+ allein alles sauber !

Screenshot 2023-09-23 at 09-34-54 Home Sweet Home.png

Screenshot 2023-09-23 at 09-34-32 Home Sweet Home.png

Dann US2000C als weitere Pakete dazu, keine Verbindung mehr, weil Die C einen Abschlusswiderstand benötigen, der aber bei den B+ nicht eingesetzt werden darf. Wechselrichter hat aber keine Probleme mit dieser Kombi.

Dann wieder US2000C als Master, und gewohntes Verhalten.
Was mich stört ist, das die US2000B als C ausgeworfen werden, aber allein sehr schön als B+

Aber egal, ich lasse die Kombi so, dein Proggi rennt schön, und vielleicht finde ich eine Lösung

LG Manfred

Moin Manfred,
Super dass du dich getraut hast.  8)
Das Ergebnis habe ich ehrlich erwartet. War/bin mir sicher dass die Implementierung entsprechend der Doku korrekt ist.
Kann eigentlich nur im Zusammenspiel der Bat Typen bzw. der Firmware liegen.

Aber wenn alles läuft, würde ich da auch nichts ändern.
Würde es dir helfen wenn das Modul ein Attr hätte mit dem man manuell den Batterietyp überschreiben kann zur richtigen Darstellung in FHEM?

Hallo.
wie willst das machen? normalerweise genügt es dies nur einmalig abzufragen, weil ändern tut sich das ja nie. dann könnte man ja selbst das reading überschreiben.

Krieg ich schon hin. 🙂 Frage ist ob es hilfreich ist in solchen Spezialfällen.

Hallo Manfred,

bezüglich der Batterietyp-Erkennung hat es mir keine Ruhe gelassen und ich habe nochmal etwas geändert.
Die Version 0.1.8 ist in mein contrib geladen.

Schau mal ob sich damit bei dir etwas ändert.
Wenn nicht, hat diese Version ein Attribut "userBatterytype" eingebaut um den Typ manuell anpassen zu können.
Diese Möglichkeit kann ohnehin nützlich sein um etwas im Typ zu ergänzen.

Grüße,
Heiko

läuft, aber unverändert beim auslesen.

Danke Manfred. Naja einen Versuch war es wert. Dafür gibt es ja jetzt das Attr bei Bedarf.

LG

hallo Heiko.

Es hat sich ein fehler eingeschlichen, Zeile 377
if ($hash->{BATADDRESS} !~ /[123456]/xs) {
      return "Define: bataddress must be a value between 1 and 6";
müsste so lauten

if ($hash->{BATADDRESS} !~ /[12345678]/xs) {
      return "Define: bataddress must be a value between 1 and 8";

Moin Manfred,

aja, danke. Die Änderung ist bei der letzten Erweiterung auf 8 Bat durchgerutscht.
Habe es nachgezogen und wieder ins contrib geladen.

Moin,
ich habe das Modul initial eingecheckt und wird morgen früh im Update enthalten sein.
@Manfred, falls du noch weitere Erkenntnisse erlangst in deiner speziellen Konstellation arbeiten wir sie in das Modul mit ein.

LG,
Heiko

aha, danke.
bin am überlegen, warum die c serie den SOC immer ganze Zahl ausgibt, die B aber mit komma.
hats damit was auf sich, wegen der zelltemperatur?

Moin,

ich kann deinen Gedanken leider nicht folgen.

Zitatbin am überlegen, warum die c serie den SOC immer ganze Zahl ausgibt, die B aber mit komma.

Welches Reading meinst du?

Die Zelltemperatur wird mit der Genauigkeit 1, also eine Stelle hinter dem Komma geliefert.

Der einzige spezifische Hinweis aus der Doku zur US2000B Plus auf S.15:

ZitatFor US2000B/US2000B-Plus, still send user defined items = 2. And use remain capacity 1 and
module total capacity 1.

wird auch im Modul erfüllt, da die "capacity 1" generell für Batterien < 65Ah verwendet wird.

Aber vllt. meinst du etwas anderes.

Zitat von: DS_Starter am 30 September 2023, 13:18:52Moin,

ich kann deinen Gedanken leider nicht folgen.

Zitatbin am überlegen, warum die c serie den SOC immer ganze Zahl ausgibt, die B aber mit komma.

Welches Reading meinst du?

packSOC

ah, ok.
pasckSOC wird nicht geliefert, sondern aus den gelieferten Werten packCapacity und packCapacityRemain berechnet.
Die Werte packCapacity und packCapacityRemain entsprechen den "Remain capacity 1" bzw. "Module total capacity 1" beschrieben auf S.15 des Dok. Bei Batterien > 65Ah ist es dann aber "Remain capacity 2" / "Module total capacity 2".

Die Zweistelligkeit kommt durch die Formatierung -> sprintf "%.2f"

Zitat von: DS_StarterDie Zweistelligkeit kommt durch die Formatierung -> sprintf "%.2f"

is mir schon klar. aber die berechnung ergibt mit C immer volle Zahl, bei B aber mit hundertstel. heist dann, 2 byte müssen immer gleich sein bei C

Hmm, blöderweise gibt es lt. der Doku nur die Unterscheidung gößer bzw. kleiner 65Ah. Mehr ist leider nicht beschrieben.
Und wenn ich es richtig sehe, ist sowohl US2000C als auch US2000B Plus kleiner 65Ah und werden in dem Fall auch gleich behandelt.

Die Kapazitäten für Batterien > 65Ah werden mit 3 Byte beschrieben, darunter mit 2 Byte.
Was mich stutzig macht, ist warum man in der Doku extra darauf hinweist die US2000B/US2000B-Plus mit capacity 1 zu behandeln, was ja eigentlich normal sein sollte wenn die S2000B/US2000B-Plus < 65 Ah haben.

Was denkst du?

Edit: Die Unterscheidung passiert in Zeile 1111 (Var $udi). Du kannst mal schauen ob bei dir für alle Batterien $udi==2 extrahiert wird. Das würde ich erwarten.

Zitat von: DS_Starter am 30 September 2023, 22:03:08Hmm, blöderweise gibt es lt. der Doku nur die Unterscheidung gößer bzw. kleiner 65Ah. Mehr ist leider nicht beschrieben.
Und wenn ich es richtig sehe, ist sowohl US2000C als auch US2000B Plus kleiner 65Ah und werden in dem Fall auch gleich behandelt.

Die Kapazitäten für Batterien > 65Ah werden mit 3 Byte beschrieben, darunter mit 2 Byte.
Was mich stutzig macht, ist warum man in der Doku extra darauf hinweist die US2000B/US2000B-Plus mit capacity 1 zu behandeln, was ja eigentlich normal sein sollte wenn die S2000B/US2000B-Plus < 65 Ah haben.

Was denkst du?

Edit: Die Unterscheidung passiert in Zeile 1111 (Var $udi). Du kannst mal schauen ob bei dir für alle Batterien $udi==2 extrahiert wird. Das würde ich erwarten.

2 wird extrahiert, passt.

Ist es bei dir 4 ?  Und die Doku dürfte fehler haben, denn :

M+7 temp. Cell 13-15
M+8 temp Mosfet (nur US3000B) , also deiner.
M+N+2  Temp. N (?)

in der Auswertung von US3000 aber kein M+7 ! auch kein M+8, der wert steht in M+N+2

Wie sieht dein String eigentlich aus?

Ja bei mir ist $udi=4. Ich habe US3000C, die haben 74Ah.

ZitatM+7 temp. Cell 13-15
M+8 temp Mosfet (nur US3000B) , also deiner.
M+N+2  Temp. N (?)

Dieses Zitat ist aus dem Kapitel "get alarm info" auf S.18.
Wir rufen und extrahieren allerdings mit "get analog value", was auf S.15 beschrieben ist.

Dann sieht es so wie hier und passt auch:
...
M+6   4: Avg. temperature of cell 9~12
M+7   5: Avg. temperature of cell 13~15/16
///
M+N+2 Temperature N
N ist dabei die Anzahl der gelieferten Temperaturen. Sie findet man im Reading numberTempPos (5 bei mir).
Die Länge pro Temperaturwert sind 2 Byte, d.h. 4 ASCII Zeichen. Bei 15 Zellen beginnen die Temp-Werte bei Postion 81 und enden bei Position 100 (inclusive) wenn 5 Werte geliefert werden.
Ab Pos 101 geht es dann weiter mit "Current".

ZitatWie sieht dein String eigentlich aus?

Bin mir nicht sicher, was du mit "String" meinst. Ein verbose 5 Ausgabe von "get analogValue" sieht so aus für die Master-Batterie:

2023.10.01 13:14:36.665 4: Pylon1 - retrieve battery info: analogValue
2023.10.01 13:14:36.666 4: Pylon1 - request command (ASCII): ~20024642E00202FD33
2023.10.01 13:14:36.666 5: Pylon1 - request command (HEX): 7e3230303234363432453030323032464433330d
2023.10.01 13:14:36.684 5: Pylon1 - data returned raw: ~20024600F07A00020F0D260D260D260D260D260D250D250D250D260D260D260D270D270D260D27050BB90BA90BA80BA50BAC003AC53AFFFF04FFFF001000F291012110E2E5
2023.10.01 13:14:36.686 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30463037 41303030  ~20024600F07A000
0x00000010 (00016)  32304630 44323630 44323630 44323630  20F0D260D260D260
0x00000020 (00032)  44323630 44323630 44323530 44323530  D260D260D250D250
0x00000030 (00048)  44323530 44323630 44323630 44323630  D250D260D260D260
0x00000040 (00064)  44323730 44323730 44323630 44323730  D270D270D260D270
0x00000050 (00080)  35304242 39304241 39304241 38304241  50BB90BA90BA80BA
0x00000060 (00096)  35304241 43303033 41433533 41464646  50BAC003AC53AFFF
0x00000070 (00112)  46303446 46464630 30313030 30463239  F04FFFF001000F29
0x00000080 (00128)  31303132 31313045 3245350d           1012110E2E5.


Hallo nochmals.

Mir lässt das keine Ruhe, habe jetzt BatteryView gestartet.
Da werden mir die SOC werte anders angezeigt, die US2000C passen mit der Formel aus dem Script zusammen, aber die US2000+ nicht. Battview zeigt mir 89%, FHEM aber nur 85%.
Irgendwo muss der wurm drinn liegen, spiesst sicvh mit der Anzeige von 13-15/16.

LG

Ich gebe dir Recht. Allerdings fehlt mir die Phantasie wo es haken könnte. Zumal wenn US2000B+ als Master eingesetzt werden es ja stimmt wie du probiert hast.
Nicht zu vergessen ist, dass BatteryView über Console (oder RS232?) angeschlossen wird. Vllt. hat Pylontech auch einen Bug in der eingesetzten Firmware bzgl. RS485, kann man nicht wissen.
Aber einen FW Update wegen dieser Sache riskieren würde ich keinesfalls machen!

Wie sieht es denn eigentlich aus, wenn du das RS485 Gateway nicht an den Master, sondern z.B. die oberste US2000B+ ansteckst? Ändert sich da etwas?
Sollte eigentlich nicht m.M. nach, aber testweise umgesteckt ist es ja schnell.

LG

Edit: Bei mir gerade probiert. Die Kommunikation funktioniert bei mir nur bei Anschluß an den Master.

da muss ich wieder kabel umbauen, die plus arbeiten nur ohne Widerstand und masse.

ich lass es für heute

LG

Noch ein Gedanke ... haben deine beiden US2000B+ die gleiche Firmware? ->
Zitat aus Mamual "For same type of module always use the latest production unit as master".

Ich habe gerade in dem Manual für US2000C nachgelesen, das RS485 Interface der Bat arbeitet ohne Masseanschluß

Ja, die B+ haben alle selbe FW.

Hallo,
habe beschlossen auch den Waveshare RS485 to Ethernet Converter M0
https://www.amazon.de/dp/B07S2K41MS?ref=ppx_yo2ov_dt_b_product_details&th=1
zu verwenden.

Könnte jemand die Verkabelung zur RS485 am US3000C Pylontech Master nennen?
Einige schreiben, dass kein GND zu verwenden ist und ein 120 Ohm R zu verwenden ist..
Ich habe auch keine Pinbelegung von der RS485 der Pylontech.

Danke

Gern.

Ich habe dir das US3000 Handbuch angehängt. Auf Seite 9 siehst du die Achlußbelegung des RS485 Ports.
Du verbindest Pin7 485A mit A+ des Konverters sowie Pin8 485B mit B- des Konverters. GND wird nicht angeschlossen.
120 Ohm sind connected, d.h. Dip-Schalter stehen alle auf off sofern man 115200 Baud benutzt (Standard).
Den Konverter mußt du auch entsprechend einstellen. Baudrate, IP-Adresse, Port im Servermode.
Weiterhin das Datenformat:

Format: start bit 1 bit
 Data bit 8 bit
 Stop bit 1 bit
 Without parity

LG

vielen Dank

Ich habe das Waveshare RS485 to Ethernet nun da und erstmal unter Windows ausgetestet, um eines meiner Modbus RTU Geräte auszulesen.
Das ganze natürlich nativ, da das Modul kein echtes Modbus Protokoll unterstützt.
Hab so ein Modul noch nie in den Händen gehabt und bin ein absoluter dau.

Funktioniert alles, mit diversen Stellschrauben.

Unter Windows muss man einen extra Treiber installieren und eine virtuelle COM Schnittstelle erstellen, die nicht persistent ist. D.h., nach dem reboot dürfte die weg sein, wenn man keinen Service oder ähnliches laufen läßt ..

Frage:
Muss man sich unter fhem (linux) um irgend welche diesbezüglichen Konfigurationen kümmern, wenn man das Modul PylonTech nutzt?

Danke

ZitatMuss man sich unter fhem (linux) um irgend welche diesbezüglichen Konfigurationen kümmern, wenn man das Modul PylonTech nutzt?

Nein. Das Gateway braucht natürlich IP-Adresse, Port usw. die im Define vom Modul PylonTech angegeben werden müssen. Das Datenformat muß auch stimmen wie oben geschrieben (habe die Info jetzt auch in der Hilfe drin).
Das war es schon.

Edit: Die im Gateway eingestellte Baudrate muß natürlich auch mit der Einstellung der Pylontech Batterien übereinstimmen.

danke für die Info.

Unter Windows musste ich noch an den Kommunikationseinstellungen am Waveshare schrauben:

D.h., diese Parameter waren bei meinem Gerät auf AUS und erst nach dem Einschalten ging es, was allerdings
nur try and error war, kurz bevor ich aufgeben wollte.

Buffer Data Before Connected: EIN
UART Set Parameter: EIN

erst dann hat die Kommunikation mit dem Modbusgerät (in meinem Fall eine Hoymiles DTU Pro) funktioniert.
Hierfür benötigt man eigentlich ein Waveshare mit zusätzlicher Modbusfunktionalität, da ich die Modbuskommunikation in C# eh von Hand geschrieben habe, klappte das trotzdem

Hallo.
Das Modul ist jetzt auf 14 Akkus erweitert.
Danke an DS_Starter für die Hilfe.

Vielen Dank an satprofi für die Erweiterung!  :)
Ich mache noch einen 4-Augen Check und stelle die neue V sodann ins Repo.

Grüße,
Heiko

Ich habe heute meine Pylontechs mit dem Modul einbinden wollen, aber so richtig will es nicht.
Ich habe 1x US3000C (Master), 2x USB2000C und US2000 Plus.

DIe Kommunikation steht soweit mit einem USR-TCP232-304, aber ich erhalte immer nur:
insufficient response length 52 of minimum length 82 received
Könnt ihr mir hier weiterhelfen?

Achja, Verbindung geht nur mit 9600bps, bei 115200bps bekomme ich gar keine Verbindung...

Wenn 115200bps nicht funktioniert, kontrolliere bitte ob deine Batterie wo der USR angeschlossen ist auch auf 115200bps eingestellt ist. Die DIP Schalter meiner Batterierien stehen alle auf "OFF".

Das Kabel wird beim Master am RS485 Port angeschlossen. Weiterhin muss das Kabel auch die richtigen PINs belegen. Das habe ich etwas weiter oben beschrieben, ist aber auch im US3000 Handbuch beschrieben.

Bei dem Setup des USR hake die beiden Einstellungen "Link" und "Similar RFC2217" an.
Anbei die Einstellung bei mir.

Im Modul gibt verbose 5 mehr Auskunft:

024.02.17 18:33:00.942 4: Pylon1 - start request cycle to battery number >1< at host:port 192.168.2.86:9000
2024.02.17 18:33:00.943 4: Pylon1 - Cycle started in main process
2024.02.17 18:33:00.947 4: Pylon1 - retrieve battery info: alarmInfo
2024.02.17 18:33:00.948 4: Pylon1 - request command (ASCII): ~20024644E00202FD31
2024.02.17 18:33:00.948 5: Pylon1 - request command (HEX): 7e3230303234363434453030323032464433310d
2024.02.17 18:33:00.966 5: Pylon1 - data returned raw: ~20024600A04200020F000000000000000000000000000000050000000000000000000E00000000F109
2024.02.17 18:33:00.967 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30413034 32303030  ~20024600A042000
0x00000010 (00016)  32304630 30303030 30303030 30303030  20F0000000000000
0x00000020 (00032)  30303030 30303030 30303030 30303030  0000000000000000
0x00000030 (00048)  30303530 30303030 30303030 30303030  0050000000000000
0x00000040 (00064)  30303030 30304530 30303030 30303046  000000E00000000F
0x00000050 (00080)  3130390d                             109.

2024.02.17 18:33:00.967 4: Pylon1 - retrieve battery info: chargeManagmentInfo
2024.02.17 18:33:00.967 4: Pylon1 - request command (ASCII): ~20024692E00202FD2E
2024.02.17 18:33:00.968 5: Pylon1 - request command (HEX): 7e3230303234363932453030323032464432450d
2024.02.17 18:33:01.024 5: Pylon1 - data returned raw: ~20024600B01402D002AFC80172FE8EC0F91C
2024.02.17 18:33:01.024 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30423031 34303244  ~20024600B01402D
0x00000010 (00016)  30303241 46433830 31373246 45384543  002AFC80172FE8EC
0x00000020 (00032)  30463931 430d                        0F91C.

2024.02.17 18:33:01.025 4: Pylon1 - retrieve battery info: analogValue
2024.02.17 18:33:01.025 4: Pylon1 - request command (ASCII): ~20024642E00202FD33
2024.02.17 18:33:01.026 5: Pylon1 - request command (HEX): 7e3230303234363432453030323032464433330d
2024.02.17 18:33:01.043 5: Pylon1 - data returned raw: ~20024600F07A00020F0CE20CE10CE20CE40CE20CE10CE30CE20CE20CE30CE10CE30CE20CE20CE1050B730B5D0B5C0B580B620000C13FFFFF04FFFF000F00454E012110E248
2024.02.17 18:33:01.044 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30463037 41303030  ~20024600F07A000
0x00000010 (00016)  32304630 43453230 43453130 43453230  20F0CE20CE10CE20
0x00000020 (00032)  43453430 43453230 43453130 43453330  CE40CE20CE10CE30
0x00000030 (00048)  43453230 43453230 43453330 43453130  CE20CE20CE30CE10
0x00000040 (00064)  43453330 43453230 43453230 43453130  CE30CE20CE20CE10
0x00000050 (00080)  35304237 33304235 44304235 43304235  50B730B5D0B5C0B5
0x00000060 (00096)  38304236 32303030 30433133 46464646  80B620000C13FFFF
0x00000070 (00112)  46303446 46464630 30304630 30343534  F04FFFF000F00454
0x00000080 (00128)  45303132 31313045 3234380d           E012110E248.

2024.02.17 18:33:01.045 4: Pylon1 - Socket/Connection to the RS485 gateway was closed
2024.02.17 18:33:01.045 4: Pylon1 - got data from battery number >1< successfully
2024.02.17 18:33:01.649 4: Pylon1 - start request cycle to battery number >1< at host:port 192.168.2.86:9000
2024.02.17 18:33:01.650 4: Pylon1 - Cycle started in main process
2024.02.17 18:33:01.657 4: Pylon1 - retrieve battery info: alarmInfo
2024.02.17 18:33:01.657 4: Pylon1 - request command (ASCII): ~20024644E00202FD31
2024.02.17 18:33:01.658 5: Pylon1 - request command (HEX): 7e3230303234363434453030323032464433310d
2024.02.17 18:33:01.675 5: Pylon1 - data returned raw: ~20024600A04200020F000000000000000000000000000000050000000000000000000E00000000F109
2024.02.17 18:33:01.676 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30413034 32303030  ~20024600A042000
0x00000010 (00016)  32304630 30303030 30303030 30303030  20F0000000000000
0x00000020 (00032)  30303030 30303030 30303030 30303030  0000000000000000
0x00000030 (00048)  30303530 30303030 30303030 30303030  0050000000000000
0x00000040 (00064)  30303030 30304530 30303030 30303046  000000E00000000F
0x00000050 (00080)  3130390d                             109.

2024.02.17 18:33:01.676 4: Pylon1 - retrieve battery info: chargeManagmentInfo
2024.02.17 18:33:01.677 4: Pylon1 - request command (ASCII): ~20024692E00202FD2E
2024.02.17 18:33:01.677 5: Pylon1 - request command (HEX): 7e3230303234363932453030323032464432450d
2024.02.17 18:33:01.684 5: Pylon1 - data returned raw: ~20024600B01402D002AFC80172FE8EC0F91C
2024.02.17 18:33:01.684 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30423031 34303244  ~20024600B01402D
0x00000010 (00016)  30303241 46433830 31373246 45384543  002AFC80172FE8EC
0x00000020 (00032)  30463931 430d                        0F91C.

2024.02.17 18:33:01.685 4: Pylon1 - retrieve battery info: analogValue
2024.02.17 18:33:01.685 4: Pylon1 - request command (ASCII): ~20024642E00202FD33
2024.02.17 18:33:01.685 5: Pylon1 - request command (HEX): 7e3230303234363432453030323032464433330d
2024.02.17 18:33:01.703 5: Pylon1 - data returned raw: ~20024600F07A00020F0CE20CE10CE20CE40CE20CE10CE30CE20CE20CE30CE10CE30CE20CE20CE1050B730B5D0B5C0B580B620000C13FFFFF04FFFF000F00454E012110E248
2024.02.17 18:33:01.703 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30463037 41303030  ~20024600F07A000
0x00000010 (00016)  32304630 43453230 43453130 43453230  20F0CE20CE10CE20
0x00000020 (00032)  43453430 43453230 43453130 43453330  CE40CE20CE10CE30
0x00000030 (00048)  43453230 43453230 43453330 43453130  CE20CE20CE30CE10
0x00000040 (00064)  43453330 43453230 43453230 43453130  CE30CE20CE20CE10
0x00000050 (00080)  35304237 33304235 44304235 43304235  50B730B5D0B5C0B5
0x00000060 (00096)  38304236 32303030 30433133 46464646  80B620000C13FFFF
0x00000070 (00112)  46303446 46464630 30304630 30343534  F04FFFF000F00454
0x00000080 (00128)  45303132 31313045 3234380d           E012110E248.

2024.02.17 18:33:01.704 4: Pylon1 - Socket/Connection to the RS485 gateway was closed
2024.02.17 18:33:01.704 4: Pylon1 - got data from battery number >1< successfully

Grüße,
Heiko

Hilf mir mal auf die Sprünge DIP auf OFF heißt alle runter?

Nein, alle oben. Die Schalter stehen auf dem Kopf, sind aber beschriftet. "ON" ist unten.

Ich hatte bis auf Similar RFC2217 alles probiert, aber genau der Haken hat gefehlt. Nun.läuft es  ;)

Vielen Dank!

Nachdem es mit dem USR-TCP nun läuft wollte ich es gerne mit einem ESP8266 und RS485 Modul auslesen. Dieser scheint jedoch nicht schnell genug zu arbeiten, oder kann es einen anderen Grund geben, wenn zu wenig Daten durchkommen?

2024.02.18 10:12:01 4: Pylon_1 - retrieve battery info: manufacturerInfo
2024.02.18 10:12:01 4: Pylon_1 - request command (ASCII): ~200246510000FDAC
2024.02.18 10:12:01 5: Pylon_1 - request command (HEX): 7e323030323436353130303030464441430d
2024.02.18 10:12:01 4: Pylon_1 - insufficient response length 49 of minimum length 82 received ... discarded
2024.02.18 10:12:01 4: Pylon_1 - Socket/Connection to the RS485 gateway was closed
2024.02.18 10:12:06 4: Pylon_1 - start request cycle to battery number >1< at host:port 192.168.0.102:8123
2024.02.18 10:12:06 4: Pylon_1 - Cycle BlockingCall PID "1093323" with timeout "20" started
2024.02.18 10:12:06 4: Pylon_1 - retrieve battery info: serialNumber
2024.02.18 10:12:06 4: Pylon_1 - request command (ASCII): ~20024693E00202FD2D
2024.02.18 10:12:06 5: Pylon_1 - request command (HEX): 7e3230303234363933453030323032464432440d
2024.02.18 10:12:06 5: Pylon_1 - data returned raw: ~20024600C0220259323231313138433330333430323732F6D6
2024.02.18 10:12:06 5: Pylon_1 - data returned:
0x00000000 (00000)  7e323030 32343630 30433032 32303235  ~20024600C022025
0x00000010 (00016)  39333233 32333133 31333133 38343333  9323231313138433
0x00000020 (00032)  33333033 33333433 30333233 37333246  330333430323732F
0x00000030 (00048)  3644360d                             6D6.

Beim ESP bin ich raus. Aber wenn ich heute Abend dazu komme, könnte ich mit verbose 5 die fehlerhaften Daten ausdrucken lassen wenn "insufficient response length 49 of minimum length 82 received ... discarded" kommt.
Dann kannst du weiter forschen was falsch sein könnte.

Grüße,
Heiko

Morgen früh ist das Feature mit im Update enthalten. Falls du es eilig hast, kannst du dir die neue Version schon jetzt aus meinem contrib (Fußtext) laden. Neustart nicht vergessen.

LG,
Heiko

Vielen Dank nochmal Heiko. Dank deiner Hilfe habe ich den Fehler gefunden.

Falls es jemanden interessiert, die Kommunikation mittels ESPEasy geht nicht per Software Serial, nur Hardware Serial mit RX Receive Timeout (mSec):20 funktioniert.

Aktuell werden alle Akkus als US3000C angezeigt - ist mir aber nicht so wichtig...

Zudem ist mir aber etwas anderes aufgefallen:
Aktuell lese ich die Daten per USB aus der RS232 Schnittstelle aus.
Allerdings weichen die Werte ab?

SOC für
RS485   RS232
44%     44%   US3000C 
46%     46%   US2000C
54%     55%   US2000C
59%     67%   US2000 Plus
59%     67%   US2000 Plus

Kennt jemand das Problem.

Über das RS485 Protokoll muß der SoC aus den gemeldeten Werten Ladungszustand und Nennkapazität berechnet werden. Problem wird sein, dass sich die Batterie als US3000C meldet, die eine größere Kapazität hat.
Möglichweise muß/kann man die US2000 Plus (evtl. auch 2000C) mit einer direkten Adresse versehen per Dip-Schalter versehen. Ich habe hier (https://www.photovoltaikforum.com/thread/151364-unterschied-pylontech-us2000-us2000b-und-us2000b-plus/?postID=2230059#post2230059) eine Info und Doku dazu gefunden.

Bei den US3000C gibt es das nicht.
Hier noch eine Info zum Mixen der Typen: https://community.victronenergy.com/storage/attachments/10425-us2000b-us2000-plus-us3000-difference-and-mixture.pdf

Grüße,
Heiko

Ich habe die älteren 2000 Plus jetzt manuell adressiert, bin echt gespannt, ob das etwas ändert.

Grundsätzlich erkennt das Modul die richtige packCapacity, dürfte doch eigentlich nichts ausmachen, wenn sie als 3000C angezeigt werden.

Stimmt auch wieder.

Im Prinzip kannst du den SoC aus den gemeldeten Readings packCapacity und packCapacityRemain selbst ausrechnen / überprüfen.

Zitat von: DS_Starter am 20 Februar 2024, 22:20:53Stimmt auch wieder.

Im Prinzip kannst du den SoC aus den gemeldeten Readings packCapacity und packCapacityRemain selbst ausrechnen / überprüfen.

Ich habe mir schon ein entsprechendes UserReading angelegt.
Jetzt bei 20% gibt es da keine großen Unterschiede...

Auch der berechnete SoC passt nicht wirklich zu den Daten aus der RS232 Schnittstelle.

Nun die entsprechenden Ausgangswerte werden durch das BMS geliefert. Daran kann man nichts ändern.
Zum SoC bei PylonTech findet man etliches im Photovoltaikforum, z.B.

Zitat....Auch die Schaltung über die Kapazitätswerte der Pylontechs ist nicht makellos. Wie vor mir schon erwähnt, lernt die Batterie ihre Kapazität bei ca 90% und bei 20% nach. Dadurch kommt es an diesen Punkten zu unphysikalisch langen Plateaus der Kapazität trotz realer (Ent)Ladung. Bei längerem Betrieb >20 und <90% wird der Kapazitätswert falsch, weil er auch nur durch Integration der Ströme gebildet werden kann. Besser wie eine spannungsgeführte Logik ist das allemal, aber präzise Vorrausberechnungen, wieviele Ladungen Wäsche noch "in der Batterie" stecken gehen hier in die Binsen. 10% Fehler hab ich schon beobachtet - vmtl. kann es auch deutlich mehr werden.

Quelle: https://www.photovoltaikforum.com/thread/118958-pylontech-us2000b-daten-%C3%BCber-konsole-rs232-auslesen/?postID=1700299#post1700299

Hallo,
ich hatte heute endlich Zeit, den "waveshare rs232 zu ethernet adapter" in fhem einzubinden.

leider bekomme ich keinerlei Kommunikation zum Waveshare Adapter hin.

define Batterien PylonLowVoltage 192.168.0.54:9000
attr Batterien interval 10
attr Batterien room PYLONTECH
attr Batterien timeout 2
attr Batterien verbose 5
#   BATADDRESS 1
#   DEF        192.168.0.54:9000
#   FUUID      65f89f55-f33f-71b5-f281-a1ca0a9e1442740b
#   FVERSION   70_PylonLowVoltage.pm:v0.2.2-s28538/2024-02-20
#   HOST       192.168.0.54
#   NAME       Batterien
#   NR         75
#   OPMODE     Automatic
#   PORT       9000
#   STATE      Timeout reading data from battery
#   TYPE       PylonLowVoltage
#   eventCount 396
#   HELPER:
#     PACKAGE    FHEM::PylonLowVoltage
#     VERSION    0.2.2
#     VERSION_API unused
#     VERSION_CTZ unused
#     VERSION_ErrCodes unused
#     VERSION_SMUtils 1.27.2
#   OLDREADINGS:
#   READINGS:
#     2024-03-18 22:56:00   nextCycletime   22:56:09
#     2024-03-18 22:56:00   state           Timeout reading data from battery
#
setstate Batterien Timeout reading data from battery
setstate Batterien 2024-03-18 22:56:00 nextCycletime 22:56:09
setstate Batterien 2024-03-18 22:56:00 state Timeout reading data from battery



der Waveshare liegt auf .54 (static dhcp reservation) und der fhem server auf .55 (static ip)

Screenshot 2024-03-18 225958.pngScreenshot 2024-03-18 225913.pngScreenshot 2024-03-18 225752.png

Anbei meine Einstellungen auf dem Waveshare.

Hat jemand eine Idee, welche Einstellung falsch ist?

Ein Startbit 1 konnte ich nicht einstellen, da ich die betreffende Einstellung nicht gefunden habe.
Rx Count geht auf dem Waveshare alle 10 Sekunden um 20 Byte hoch, Tx Count bleibt auf 0

Danke vorab ..

   

Ich habe

- UART Set Parameter NICHT gesetzt

Die Baudrate 115200 muß mit dem Setting der Batterien übereinstimmen.

Danke.
Dann probiere ich das morgen mal aus. Die DIP Schalter sind auf default bei mir bei den US3000C.

Letzte Frage für heute:
Wenn das Kabel aus der Pylontech gezogen ist, aber der Waveshare Adapter noch mit dem Ethernet verbunden ist, kommt dann auch:

" Timeout reading data from battery "

?

Ja, weil keine Antwort vom Gateway bzw. der Batterie in der erwarteten Zeit.

UART Set Parameter [ ] habe ich raus genommen. Danach lief die ganze Sache.

Abschlusswidersände habe ich keine werwendet. Leitung ist bei mir momentan nur ein paar cm lang.


Bei der Angelegenheit hatte ich gleich zwei fatale Trugschlüsse:

1. Dass es laut Beshreibung irgendwo noch eine Einstellung für das erwähnte Startbit geben muss:
-Die gibt es beim Wavshare jedenfalls nicht

und der Haupttrugschluss:

2. Dass man die IP vom fhem server hier sehen muss, was natürlich nur der Fall ist, wenn man die connection offen hält.
pic2.png

Man sieht dieses Bild nur leider in 1 von 100 Fällen, da die connection vermutlich sofort wieder geschlossen wird.
(Habe mir den Perl Code nicht angesehen.)

3. bei meinem debian fhem von 2021 musste ich zumindest F5 drücken, bis mal was ankam im Firefox.
Zum Glück habe ich Tx und Rx im Waveshare hochzählen sehen ..

PS:
Man sollte doch mal diese Parameter in den Startthread reinsetzen, da einige den Waveshare aufgrund des günstiges Preises nutzen werden


TAUSEND DANK den Entwicklern ..

Ich habe eine Beispielkonfiguration des Waveshare Converters in die Commandref des Moduls aufgenommen.
Morgen früh ist die neue Version im Update enthalten.

LG

@DS_Starter, ich habe eine US5000 als Master + eine US3000 als Slave und bekomme bei beiden keine Werte.
hier die verbose 5 Logs :
US5000 :
2024.03.31 10:02:44 4: Batterien - start request cycle to battery number >1< at host:port 192.168.0.6:9000
2024.03.31 10:02:44 4: Batterien - Cycle started in main process
2024.03.31 10:02:44 4: Batterien - retrieve battery info: serialNumber
2024.03.31 10:02:44 4: Batterien - request command (ASCII): ~20024693E00202FD2D
2024.03.31 10:02:44 5: Batterien - request command (HEX): 7e3230303234363933453030323032464432440d
2024.03.31 10:02:44 5: Batterien - data returned raw: ~20024600C0220259323230383137433530343430373935F6C4
2024.03.31 10:02:44 5: Batterien - data returned:
0x00000000 (00000)  7e323030 32343630 30433032 32303235  ~20024600C022025
0x00000010 (00016)  39333233 32333033 38333133 37343333  9323230383137433
0x00000020 (00032)  35333033 34333433 30333733 39333546  530343430373935F
0x00000030 (00048)  3643340d                             6C4.

2024.03.31 10:02:44 4: Batterien - retrieve battery info: manufacturerInfo
2024.03.31 10:02:44 4: Batterien - request command (ASCII): ~200246510000FDAC
2024.03.31 10:02:44 5: Batterien - request command (HEX): 7e323030323436353130303030464441430d
2024.03.31 10:02:44 5: Batterien - data returned raw: ~20024600C04055533530303000000000010350796C6F6E2D2D2D2D2D2D2D2D2D2D2D2D2D2D2DEFC5
2024.03.31 10:02:44 5: Batterien - data returned:
0x00000000 (00000)  7e323030 32343630 30433034 30353535  ~20024600C040555
0x00000010 (00016)  33333533 30333033 30303030 30303030  3353030300000000
0x00000020 (00032)  30303130 33353037 39364336 46364532  0010350796C6F6E2
0x00000030 (00048)  44324432 44324432 44324432 44324432  D2D2D2D2D2D2D2D2
0x00000040 (00064)  44324432 44324432 44324432 44454643  D2D2D2D2D2D2DEFC
0x00000050 (00080)  350d                                 5.

2024.03.31 10:02:44 4: Batterien - retrieve battery info: protocolVersion
2024.03.31 10:02:44 4: Batterien - request command (ASCII): ~0002464F0000FD9A
2024.03.31 10:02:44 5: Batterien - request command (HEX): 7e303030323436344630303030464439410d
2024.03.31 10:02:44 5: Batterien - data returned raw: ~200246000000FDB2
2024.03.31 10:02:44 5: Batterien - data returned:
0x00000000 (00000)  7e323030 32343630 30303030 30464442  ~200246000000FDB
0x00000010 (00016)  320d                                 2.

2024.03.31 10:02:44 4: Batterien - retrieve battery info: softwareVersion
2024.03.31 10:02:44 4: Batterien - request command (ASCII): ~20024696E00202FD2A
2024.03.31 10:02:44 5: Batterien - request command (HEX): 7e3230303234363936453030323032464432410d
2024.03.31 10:02:44 5: Batterien - data returned raw: ~20024600400C020103000609FB46
2024.03.31 10:02:44 5: Batterien - data returned:
0x00000000 (00000)  7e323030 32343630 30343030 43303230  ~20024600400C020
0x00000010 (00016)  31303330 30303630 39464234 360d      103000609FB46.

2024.03.31 10:02:44 4: Batterien - retrieve battery info: systemParameters
2024.03.31 10:02:44 4: Batterien - request command (ASCII): ~20024647E00202FD2E
2024.03.31 10:02:44 5: Batterien - request command (HEX): 7e3230303234363437453030323032464432450d
2024.03.31 10:02:44 5: Batterien - data returned raw: ~20024600B032110E420BEA0AF00D030A4703E8D2F0B3B0A7F80D030A47FC18F27E
2024.03.31 10:02:44 5: Batterien - data returned:
0x00000000 (00000)  7e323030 32343630 30423033 32313130  ~20024600B032110
0x00000010 (00016)  45343230 42454130 41463030 44303330  E420BEA0AF00D030
0x00000020 (00032)  41343730 33453844 32463042 33423041  A4703E8D2F0B3B0A
0x00000030 (00048)  37463830 44303330 41343746 43313846  7F80D030A47FC18F
0x00000040 (00064)  3237450d                             27E.

2024.03.31 10:02:44 4: Batterien - retrieve battery info: alarmInfo
2024.03.31 10:02:44 4: Batterien - request command (ASCII): ~20024644E00202FD31
2024.03.31 10:02:44 5: Batterien - request command (HEX): 7e3230303234363434453030323032464433310d
2024.03.31 10:02:44 5: Batterien - data returned raw: ~20024600804400020F00000000000000000000000000000006000000000000000000000E80000000F0A7
2024.03.31 10:02:44 5: Batterien - 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 45383030 30303030  00000000E8000000
0x00000050 (00080)  30463041 370d                        0F0A7.

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

2024.03.31 10:02:44 4: Batterien - retrieve battery info: analogValue
2024.03.31 10:02:44 4: Batterien - request command (ASCII): ~20024642E00202FD33
2024.03.31 10:02:44 5: Batterien - request command (HEX): 7e3230303234363432453030323032464433330d
2024.03.31 10:02:44 5: Batterien - data returned raw: ~20024600B07E00020F0CA20C9E0C9D0CA10CA50CA00CA30CA60C9D0CA30CA70C930CA90CA20CA5060B350B2C0B260B260B240B2F0060BD76FFFF04FFFF0121002D900186A0E178
2024.03.31 10:02:44 5: Batterien - data returned:
0x00000000 (00000)  7e323030 32343630 30423037 45303030  ~20024600B07E000
0x00000010 (00016)  32304630 43413230 43394530 43394430  20F0CA20C9E0C9D0
0x00000020 (00032)  43413130 43413530 43413030 43413330  CA10CA50CA00CA30
0x00000030 (00048)  43413630 43394430 43413330 43413730  CA60C9D0CA30CA70
0x00000040 (00064)  43393330 43413930 43413230 43413530  C930CA90CA20CA50
0x00000050 (00080)  36304233 35304232 43304232 36304232  60B350B2C0B260B2
0x00000060 (00096)  36304232 34304232 46303036 30424437  60B240B2F0060BD7
0x00000070 (00112)  36464646 46303446 46464630 31323130  6FFFF04FFFF01210
0x00000080 (00128)  30324439 30303138 36413045 3137380d  02D900186A0E178.

2024.03.31 10:02:44 4: Batterien - wrong value retrieve analogValue -> user defined items: 255
2024.03.31 10:02:44 4: Batterien - Socket/Connection to the RS485 gateway was closed

US3000 :
2024.03.31 10:04:27 4: Batterien - start request cycle to battery number >2< at host:port 192.168.0.6:9000
2024.03.31 10:04:27 4: Batterien - Cycle started in main process
2024.03.31 10:04:27 4: Batterien - retrieve battery info: serialNumber
2024.03.31 10:04:27 4: Batterien - request command (ASCII): ~20034693E00203FD2B
2024.03.31 10:04:27 5: Batterien - request command (HEX): 7e3230303334363933453030323033464432420d
2024.03.31 10:04:27 5: Batterien - data returned raw: ~20034600C0220348323230383230433330353230353431F6D8
2024.03.31 10:04:27 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30433032 32303334  ~20034600C022034
0x00000010 (00016)  38333233 32333033 38333233 30343333  8323230383230433
0x00000020 (00032)  33333033 35333233 30333533 34333146  330353230353431F
0x00000030 (00048)  3644380d                             6D8.

2024.03.31 10:04:27 4: Batterien - retrieve battery info: manufacturerInfo
2024.03.31 10:04:27 4: Batterien - request command (ASCII): ~200346510000FDAB
2024.03.31 10:04:27 5: Batterien - request command (HEX): 7e323030333436353130303030464441420d
2024.03.31 10:04:27 5: Batterien - data returned raw: ~20034600C04055533530303000000000010350796C6F6E2D2D2D2D2D2D2D2D2D2D2D2D2D2D2DEFC4
2024.03.31 10:04:27 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30433034 30353535  ~20034600C040555
0x00000010 (00016)  33333533 30333033 30303030 30303030  3353030300000000
0x00000020 (00032)  30303130 33353037 39364336 46364532  0010350796C6F6E2
0x00000030 (00048)  44324432 44324432 44324432 44324432  D2D2D2D2D2D2D2D2
0x00000040 (00064)  44324432 44324432 44324432 44454643  D2D2D2D2D2D2DEFC
0x00000050 (00080)  340d                                 4.

2024.03.31 10:04:27 4: Batterien - retrieve battery info: protocolVersion
2024.03.31 10:04:27 4: Batterien - request command (ASCII): ~0003464F0000FD99
2024.03.31 10:04:27 5: Batterien - request command (HEX): 7e303030333436344630303030464439390d
2024.03.31 10:04:27 5: Batterien - data returned raw: ~200346000000FDB1
2024.03.31 10:04:27 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30303030 30464442  ~200346000000FDB
0x00000010 (00016)  310d                                 1.

2024.03.31 10:04:27 4: Batterien - retrieve battery info: softwareVersion
2024.03.31 10:04:27 4: Batterien - request command (ASCII): ~20034696E00203FD28
2024.03.31 10:04:27 5: Batterien - request command (HEX): 7e3230303334363936453030323033464432380d
2024.03.31 10:04:27 5: Batterien - data returned raw: ~20034600400C030104000609FB43
2024.03.31 10:04:27 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30343030 43303330  ~20034600400C030
0x00000010 (00016)  31303430 30303630 39464234 330d      104000609FB43.

2024.03.31 10:04:27 4: Batterien - retrieve battery info: systemParameters
2024.03.31 10:04:27 4: Batterien - request command (ASCII): ~20034647E00203FD2C
2024.03.31 10:04:27 5: Batterien - request command (HEX): 7e3230303334363437453030323033464432430d
2024.03.31 10:04:27 5: Batterien - data returned raw: ~20034600B032110E420BEA0AF00D030A4703E8D2F0B3B0A7F80D030A47FC18F27D
2024.03.31 10:04:27 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30423033 32313130  ~20034600B032110
0x00000010 (00016)  45343230 42454130 41463030 44303330  E420BEA0AF00D030
0x00000020 (00032)  41343730 33453844 32463042 33423041  A4703E8D2F0B3B0A
0x00000030 (00048)  37463830 44303330 41343746 43313846  7F80D030A47FC18F
0x00000040 (00064)  3237440d                             27D.

2024.03.31 10:04:27 4: Batterien - retrieve battery info: alarmInfo
2024.03.31 10:04:27 4: Batterien - request command (ASCII): ~20034644E00203FD2F
2024.03.31 10:04:27 5: Batterien - request command (HEX): 7e3230303334363434453030323033464432460d
2024.03.31 10:04:27 5: Batterien - data returned raw: ~20034600804401030F00000000000000000000000000000006000000000000000000000E80000000F0A4
2024.03.31 10:04:27 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30383034 34303130  ~200346008044010
0x00000010 (00016)  33304630 30303030 30303030 30303030  30F0000000000000
0x00000020 (00032)  30303030 30303030 30303030 30303030  0000000000000000
0x00000030 (00048)  30303630 30303030 30303030 30303030  0060000000000000
0x00000040 (00064)  30303030 30303030 45383030 30303030  00000000E8000000
0x00000050 (00080)  30463041 340d                        0F0A4.

2024.03.31 10:04:27 4: Batterien - retrieve battery info: chargeManagmentInfo
2024.03.31 10:04:27 4: Batterien - request command (ASCII): ~20034692E00203FD2C
2024.03.31 10:04:27 5: Batterien - request command (HEX): 7e3230303334363932453030323033464432430d
2024.03.31 10:04:27 5: Batterien - data returned raw: ~20034600B01403D002AFC80172FE8EC0F91A
2024.03.31 10:04:27 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30423031 34303344  ~20034600B01403D
0x00000010 (00016)  30303241 46433830 31373246 45384543  002AFC80172FE8EC
0x00000020 (00032)  30463931 410d                        0F91A.

2024.03.31 10:04:27 4: Batterien - retrieve battery info: analogValue
2024.03.31 10:04:27 4: Batterien - request command (ASCII): ~20034642E00203FD31
2024.03.31 10:04:27 5: Batterien - request command (HEX): 7e3230303334363432453030323033464433310d
2024.03.31 10:04:27 5: Batterien - data returned raw: ~20034600B07E00030F0CA20CA70CA50CA50CA80CA20CA20C9F0CA00CA50CA50CA60CA20C9F0CA4060B380B240B240B210B230B310029BD93FFFF04FFFF010D0021C9012110E19E
2024.03.31 10:04:27 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30423037 45303030  ~20034600B07E000
0x00000010 (00016)  33304630 43413230 43413730 43413530  30F0CA20CA70CA50
0x00000020 (00032)  43413530 43413830 43413230 43413230  CA50CA80CA20CA20
0x00000030 (00048)  43394630 43413030 43413530 43413530  C9F0CA00CA50CA50
0x00000040 (00064)  43413630 43413230 43394630 43413430  CA60CA20C9F0CA40
0x00000050 (00080)  36304233 38304232 34304232 34304232  60B380B240B240B2
0x00000060 (00096)  31304232 33304233 31303032 39424439  10B230B310029BD9
0x00000070 (00112)  33464646 46303446 46464630 31304430  3FFFF04FFFF010D0
0x00000080 (00128)  30323143 39303132 31313045 3139450d  021C9012110E19E.

2024.03.31 10:04:27 4: Batterien - wrong value retrieve analogValue -> user defined items: 255
2024.03.31 10:04:27 4: Batterien - Socket/Connection to the RS485 gateway was closed
2024.03.31 10:04:29 4: Batterien - start request cycle to battery number >2< at host:port 192.168.0.6:9000
2024.03.31 10:04:29 4: Batterien - Cycle started in main process
2024.03.31 10:04:29 4: Batterien - retrieve battery info: serialNumber
2024.03.31 10:04:29 4: Batterien - request command (ASCII): ~20034693E00203FD2B
2024.03.31 10:04:29 5: Batterien - request command (HEX): 7e3230303334363933453030323033464432420d
2024.03.31 10:04:29 5: Batterien - data returned raw: ~20034600C0220348323230383230433330353230353431F6D8
2024.03.31 10:04:29 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30433032 32303334  ~20034600C022034
0x00000010 (00016)  38333233 32333033 38333233 30343333  8323230383230433
0x00000020 (00032)  33333033 35333233 30333533 34333146  330353230353431F
0x00000030 (00048)  3644380d                             6D8.

2024.03.31 10:04:29 4: Batterien - retrieve battery info: manufacturerInfo
2024.03.31 10:04:29 4: Batterien - request command (ASCII): ~200346510000FDAB
2024.03.31 10:04:29 5: Batterien - request command (HEX): 7e323030333436353130303030464441420d
2024.03.31 10:04:29 5: Batterien - data returned raw: ~20034600C04055533530303000000000010350796C6F6E2D2D2D2D2D2D2D2D2D2D2D2D2D2D2DEFC4
2024.03.31 10:04:29 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30433034 30353535  ~20034600C040555
0x00000010 (00016)  33333533 30333033 30303030 30303030  3353030300000000
0x00000020 (00032)  30303130 33353037 39364336 46364532  0010350796C6F6E2
0x00000030 (00048)  44324432 44324432 44324432 44324432  D2D2D2D2D2D2D2D2
0x00000040 (00064)  44324432 44324432 44324432 44454643  D2D2D2D2D2D2DEFC
0x00000050 (00080)  340d                                 4.

2024.03.31 10:04:29 4: Batterien - retrieve battery info: protocolVersion
2024.03.31 10:04:29 4: Batterien - request command (ASCII): ~0003464F0000FD99
2024.03.31 10:04:29 5: Batterien - request command (HEX): 7e303030333436344630303030464439390d
2024.03.31 10:04:29 5: Batterien - data returned raw: ~200346000000FDB1
2024.03.31 10:04:29 5: Batterien - data returned:
0x00000000 (00000)  7e323030 33343630 30303030 30464442  ~200346000000FDB
0x00000010 (00016)  310d                                 1.


Moin Wzut,

Problem ist:  wrong value retrieve analogValue -> user defined items: 255

Es gibt nur die Werte 2 oder 4:
user defined item=Entscheidungskriterium -> 2: Batterien <= 65Ah, 4: Batterien > 65Ah

Ein anderer Wert kann/darf lt. PylonTech Protokollspezifikation nicht vorkommen.
Bekommst du heraus welche Firmwareversion auf den Batterien ist?
Oder anders gefragt wie alt sind Bats? Vllt. gibt uns das einen Hinweis.

ich habe einfach den error Block auskommentiert, dann gibt es diese Readings :
define Batterien2 PylonLowVoltage 192.168.0.6:9000 2
attr Batterien2 interval 0
attr Batterien2 room Pylontech
#   .FhemMetaInternals 1
#   BATADDRESS 2
#   CFGFN     
#   DEF        192.168.0.6:9000 2
#   FUUID      660920e1-f33f-cb2e-d1ad-9b29df2f0484262f
#   FVERSION   70_PylonLowVoltage.pm:v0.2.4-s28724/2024-03-29
#   HOST       192.168.0.6
#   NAME       Batterien2
#   NR         115
#   OPMODE     Manual
#   PORT       9000
#   STATE      connected
#   TYPE       PylonLowVoltage
#   eventCount 2
#   .attraggr:
#   .attrminint:
#   HELPER:
#     PACKAGE    FHEM::PylonLowVoltage
#     VERSION    0.2.4
#     VERSION_API unused
#     VERSION_CTZ unused
#     VERSION_ErrCodes unused
#     VERSION_SMUtils 1.27.2
#   READINGS:
#     2024-03-31 10:37:53   Manufacturer    Pylon
#     2024-03-31 10:37:54   averageCellVolt 4.354
#     2024-03-31 10:37:53   batteryType     US5000
#     2024-03-31 10:37:54   bmsTemperature  14.4
#     2024-03-31 10:37:54   cellTemperature_0104 12.4
#     2024-03-31 10:37:54   cellTemperature_0508 12.4
#     2024-03-31 10:37:54   cellTemperature_0912 12.1
#     2024-03-31 10:37:54   cellTemperature_1315 12.3
#     2024-03-31 10:37:54   cellVoltage_01  3.194
#     2024-03-31 10:37:54   cellVoltage_02  3.197
#     2024-03-31 10:37:54   cellVoltage_03  3.197
#     2024-03-31 10:37:54   cellVoltage_04  3.196
#     2024-03-31 10:37:54   cellVoltage_05  3.197
#     2024-03-31 10:37:54   cellVoltage_06  3.195
#     2024-03-31 10:37:54   cellVoltage_07  3.195
#     2024-03-31 10:37:54   cellVoltage_08  3.196
#     2024-03-31 10:37:54   cellVoltage_09  3.196
#     2024-03-31 10:37:54   cellVoltage_10  3.197
#     2024-03-31 10:37:54   cellVoltage_11  3.195
#     2024-03-31 10:37:54   cellVoltage_12  3.196
#     2024-03-31 10:37:54   cellVoltage_13  3.196
#     2024-03-31 10:37:54   cellVoltage_14  3.195
#     2024-03-31 10:37:54   cellVoltage_15  3.196
#     2024-03-31 10:37:54   chargeCurrentLimit 37.0
#     2024-03-31 10:37:54   chargeEnable    yes
#     2024-03-31 10:37:54   chargeFullRequest no
#     2024-03-31 10:37:54   chargeImmediatelySOC05 no
#     2024-03-31 10:37:54   chargeImmediatelySOC09 no
#     2024-03-31 10:37:54   chargeVoltageLimit 53.250
#     2024-03-31 10:37:54   dischargeCurrentLimit 37.0
#     2024-03-31 10:37:54   dischargeEnable yes
#     2024-03-31 10:37:54   dischargeVoltageLimit 45.000
#     2024-03-31 10:37:53   moduleSoftwareVersion_mainline V0.6.9
#     2024-03-31 10:37:53   moduleSoftwareVersion_manufacture V1.4
#     2024-03-31 10:37:54   nextCycletime   Manual
#     2024-03-31 10:37:54   numberTempPos   6
#     2024-03-31 10:37:54   packAlarmInfo   failure
#     2024-03-31 10:37:54   packCellcount   15
#     2024-03-31 10:37:54   packCurrent     287.100
#     2024-03-31 10:37:54   packCycles      65535
#     2024-03-31 10:37:54   packImbalance   0.069
#     2024-03-31 10:37:54   packPower       18752.22
#     2024-03-31 10:37:54   packState       charging
#     2024-03-31 10:37:54   packVolt        65.316
#     2024-03-31 10:37:53   paramCellHighVoltLimit 3.650
#     2024-03-31 10:37:53   paramCellLowVoltLimit 3.050
#     2024-03-31 10:37:53   paramCellUnderVoltLimit 2.800
#     2024-03-31 10:37:53   paramChargeCurrentLimit 100.000
#     2024-03-31 10:37:53   paramChargeHighTempLimit 60.0
#     2024-03-31 10:37:53   paramChargeLowTempLimit -10.0
#     2024-03-31 10:37:53   paramDischargeCurrentLimit 99.900
#     2024-03-31 10:37:53   paramDischargeHighTempLimit 60.0
#     2024-03-31 10:37:53   paramDischargeLowTempLimit -10.0
#     2024-03-31 10:37:53   paramModuleHighVoltLimit 54.000
#     2024-03-31 10:37:53   paramModuleLowVoltLimit 46.000
#     2024-03-31 10:37:53   paramModuleUnderVoltLimit 43.000
#     2024-03-31 10:37:53   protocolVersion V2.0
#     2024-03-31 10:37:53   serialNumber    H220820C30520541
#     2024-03-31 10:37:54   state           connected
#


Ja, nur fehlen jetzt die Infos zu packCapacity bzw. packCapacityRemain weil die installierte Batteriekapazität nicht bestimmt wird.
Hast du die neuste Batterie, also die mit der neuesten Firmware als Master eingesetzt?
Das ist wichtig weil Vorgabe von PylonTech bei einem Verbund von Batterien.

EDIT: Ich verbessere/ergänze die obige Aussage:
- besteht der Verbund aus gleichen Typen -> die neueste Bat bzw. mit der höchsten FW als Master einsetzen
- besteht der Verbund aus ungleichen Typen, dann ist die einzuhaltende Reihenfolge im entsprechenden Manual   
  der Batterie beschrieben.

Beide sind ca. 1 Jahr alt. Da ich die 5000er zuerst hatte ist sie auch der Master. Schaue ich mir aber die Readings beider an dann habe ich moduleSoftwareVersion_manufacture V1.3 bei der 5000er und 1.4 bei der 3000er. Also ist die 3000er vermutlich neuer. Ich werde dann am Dienstag mal umstecken.
Erstmal THX und frohe Ostern noch :)

Danke und ebenso  :)

Ich habe in einem anderen Forum gelsen etwas gefunden -> da hatten User Probleme mit einer Selbstbau Anzeige nachdem sie eine US5000 zusätzlich verbaut hatten. Der eine User hat dann doch entgegen dem Effekta Handbuch seine US2000er zum Master gemacht und das Prob war gelöst.

Aber ein anderer User hat herausgefunden das die US5000 keine 5 Temperatur Werte liefert sondern 6 !!
D.h das Modul liest zwar numberTempPos aus, verwendest den Wert aber weiter nicht ... und der ist bei der US5000 nicht fix 5 sondern 6 :)

Ich habe dann einfach noch einen cellTemperature Block eingefügt und $bpos um weitere 4 Byte erhöht.
Schaut gut aus, d.h der analogValue Fehler ist so erst mal weg.

Hallo Wzut,

ZitatAber ein anderer User hat herausgefunden das die US5000 keine 5 Temperatur Werte liefert sondern 6 !!

was zeigt denn das Reading numberTempPos? 6 für die US5000?

LG

@Wzut,

in meinem contrib liegt eine Version des Modul mit einer variablen Zählerverwerwendung der Temperatur.
Teste sie mal bitte in deiner Umgebung.

Grüße,
Heiko

Zitatwas zeigt denn das Reading numberTempPos? 6 für die US5000?

ja , allerdings auch für die US3000 als zweites Device.
Mit deiner contrib Version schaut das soweit gut aus, bei beiden ist jetzt pacAlarmInfo u.a. von fail auf ok gewechselt.
Was ist mit den vielen mlen Werten, müssen die nicht auch noch angepasst werden ?  [/quote]

Moin Wzut,

zeig mir mal bitte eine Listing der ganzen entstandenen Readings von beiden Devices.
Das sich die US5000 sowohl bei dem Typ als auch der Anzahl der Temp.Werte die US3000 überlagert ist sehr unschön.

ZitatWas ist mit den vielen mlen Werten, müssen die nicht auch noch angepasst werden ?

mlen = erwartete Minimum Length -> sollte passen

Bei meinen US3000C sieht es mit der contrib Version auch gut aus. Da passen auch die Temp.Anzahl:

   READINGS:
     2024-04-02 09:56:25   Manufacturer    Pylon
     2024-04-02 09:56:31   averageCellVolt 3.361
     2024-04-02 09:56:25   batteryType     US3000C
     2024-04-02 09:56:31   bmsTemperature  20.8
     2024-04-02 09:56:31   cellTemperature_0104 18.9
     2024-04-02 09:56:31   cellTemperature_0508 18.7
     2024-04-02 09:56:31   cellTemperature_0912 18.3
     2024-04-02 09:56:31   cellTemperature_1315 19.3
     2024-04-02 09:56:31   cellVoltage_01  3.361
     2024-04-02 09:56:31   cellVoltage_02  3.361
     2024-04-02 09:56:31   cellVoltage_03  3.361
     2024-04-02 09:56:31   cellVoltage_04  3.361
     2024-04-02 09:56:31   cellVoltage_05  3.361
     2024-04-02 09:56:31   cellVoltage_06  3.361
     2024-04-02 09:56:31   cellVoltage_07  3.361
     2024-04-02 09:56:31   cellVoltage_08  3.361
     2024-04-02 09:56:31   cellVoltage_09  3.361
     2024-04-02 09:56:31   cellVoltage_10  3.361
     2024-04-02 09:56:31   cellVoltage_11  3.362
     2024-04-02 09:56:31   cellVoltage_12  3.361
     2024-04-02 09:56:31   cellVoltage_13  3.361
     2024-04-02 09:56:31   cellVoltage_14  3.362
     2024-04-02 09:56:31   cellVoltage_15  3.362
     2024-04-02 09:56:31   chargeCurrentLimit 37.0
     2024-04-02 09:56:31   chargeEnable    yes
     2024-04-02 09:56:31   chargeFullRequest no
     2024-04-02 09:56:31   chargeImmediatelySOC05 no
     2024-04-02 09:56:31   chargeImmediatelySOC09 no
     2024-04-02 09:56:31   chargeVoltageLimit 53.250
     2024-04-02 09:56:31   dischargeCurrentLimit 37.0
     2024-04-02 09:56:31   dischargeEnable yes
     2024-04-02 09:56:31   dischargeVoltageLimit 45.000
     2024-04-02 09:56:25   moduleSoftwareVersion_mainline V0.6.9
     2024-04-02 09:56:25   moduleSoftwareVersion_manufacture V1.8
     2024-04-02 09:56:31   nextCycletime   09:56:37
     2024-04-02 09:56:31   numberTempPos   5
     2024-04-02 09:56:31   packAlarmInfo   ok
     2024-04-02 09:56:31   packCapacity    74.000
     2024-04-02 09:56:31   packCapacityRemain 60.497
     2024-04-02 09:56:31   packCellcount   15
     2024-04-02 09:56:31   packCurrent     2.800
     2024-04-02 09:56:31   packCycles      32
     2024-04-02 09:56:31   packImbalance   0.030
     2024-04-02 09:56:31   packPower       141.17
     2024-04-02 09:56:31   packSOC         81.75
     2024-04-02 09:56:31   packState       charging
     2024-04-02 09:56:31   packVolt        50.418
     2024-04-02 09:56:25   paramCellHighVoltLimit 3.650
     2024-04-02 09:56:25   paramCellLowVoltLimit 3.050
     2024-04-02 09:56:25   paramCellUnderVoltLimit 2.800
     2024-04-02 09:56:25   paramChargeCurrentLimit 90.000
     2024-04-02 09:56:25   paramChargeHighTempLimit 60.0
     2024-04-02 09:56:25   paramChargeLowTempLimit -10.0
     2024-04-02 09:56:25   paramDischargeCurrentLimit 89.900
     2024-04-02 09:56:25   paramDischargeHighTempLimit 60.0
     2024-04-02 09:56:25   paramDischargeLowTempLimit -10.0
     2024-04-02 09:56:25   paramModuleHighVoltLimit 54.000
     2024-04-02 09:56:25   paramModuleLowVoltLimit 46.000
     2024-04-02 09:56:25   paramModuleUnderVoltLimit 43.000
     2024-04-02 09:56:25   protocolVersion V2.0
     2024-04-02 09:56:25   serialNumber    K221206C31740079
     2024-04-02 09:56:31   state           connected


Internals:
   .FhemMetaInternals 1
   BATADDRESS 1
   DEF        192.168.0.6:9000 1
   FUUID      66083c76-f33f-cb2e-c53d-8fe92820d836e3f4
   FVERSION   70_PylonLowVoltage.pm:v1.1.1-s28724/2024-03-29
   HOST       192.168.0.6
   NAME       Bat1
   NR         114
   OPMODE     Manual
   PORT       9000
   STATE      connected
   TYPE       PylonLowVoltage
   eventCount 11
   .attraggr:
   .attrminint:
   HELPER:
     PACKAGE    FHEM::PylonLowVoltage
     VERSION    0.2.4
     VERSION_API unused
     VERSION_CTZ unused
     VERSION_ErrCodes unused
     VERSION_SMUtils 1.27.2
   READINGS:
     2024-04-02 09:56:35   Manufacturer    Pylon
     2024-04-02 09:56:35   averageCellVolt 3.235
     2024-04-02 09:56:35   batteryType     US5000
     2024-04-02 09:56:35   bmsTemperature  13.9
     2024-04-02 09:56:35   cellTemperature_0104 13
     2024-04-02 09:56:35   cellTemperature_0508 12.5
     2024-04-02 09:56:35   cellTemperature_0912 12.5
     2024-04-02 09:56:35   cellTemperature_1315 12.3
     2024-04-02 09:56:35   cellTemperature_add06 13.3
     2024-04-02 09:56:35   cellVoltage_01  3.234
     2024-04-02 09:56:35   cellVoltage_02  3.236
     2024-04-02 09:56:35   cellVoltage_03  3.233
     2024-04-02 09:56:35   cellVoltage_04  3.236
     2024-04-02 09:56:35   cellVoltage_05  3.235
     2024-04-02 09:56:35   cellVoltage_06  3.235
     2024-04-02 09:56:35   cellVoltage_07  3.235
     2024-04-02 09:56:35   cellVoltage_08  3.237
     2024-04-02 09:56:35   cellVoltage_09  3.234
     2024-04-02 09:56:35   cellVoltage_10  3.236
     2024-04-02 09:56:35   cellVoltage_11  3.235
     2024-04-02 09:56:35   cellVoltage_12  3.233
     2024-04-02 09:56:35   cellVoltage_13  3.236
     2024-04-02 09:56:35   cellVoltage_14  3.236
     2024-04-02 09:56:35   cellVoltage_15  3.235
     2024-04-02 09:56:35   chargeCurrentLimit 80.0
     2024-04-02 09:56:35   chargeEnable    yes
     2024-04-02 09:56:35   chargeFullRequest no
     2024-04-02 09:56:35   chargeImmediatelySOC05 no
     2024-04-02 09:56:35   chargeImmediatelySOC09 no
     2024-04-02 09:56:35   chargeVoltageLimit 53.250
     2024-04-02 09:56:35   dischargeCurrentLimit 80.0
     2024-04-02 09:56:35   dischargeEnable yes
     2024-04-02 09:56:35   dischargeVoltageLimit 45.000
     2024-04-02 09:56:35   moduleSoftwareVersion_mainline V0.6.9
     2024-04-02 09:56:35   moduleSoftwareVersion_manufacture V1.3
     2024-04-02 09:56:35   nextCycletime   Manual
     2024-04-02 09:56:35   numberTempPos   6
     2024-04-02 09:56:35   packAlarmInfo   failure
     2024-04-02 09:56:35   packCapacity    100.000
     2024-04-02 09:56:35   packCapacityRemain 11.652
     2024-04-02 09:56:35   packCellcount   15
     2024-04-02 09:56:35   packCurrent     4.400
     2024-04-02 09:56:35   packCycles      290
     2024-04-02 09:56:35   packImbalance   0.124
     2024-04-02 09:56:35   packPower       213.51
     2024-04-02 09:56:35   packSOC         11.65
     2024-04-02 09:56:35   packState       charging
     2024-04-02 09:56:35   packVolt        48.526
     2024-04-02 09:56:35   paramCellHighVoltLimit 3.650
     2024-04-02 09:56:35   paramCellLowVoltLimit 3.050
     2024-04-02 09:56:35   paramCellUnderVoltLimit 2.800
     2024-04-02 09:56:35   paramChargeCurrentLimit 100.000
     2024-04-02 09:56:35   paramChargeHighTempLimit 60.0
     2024-04-02 09:56:35   paramChargeLowTempLimit -10.0
     2024-04-02 09:56:35   paramDischargeCurrentLimit 99.900
     2024-04-02 09:56:35   paramDischargeHighTempLimit 60.0
     2024-04-02 09:56:35   paramDischargeLowTempLimit -10.0
     2024-04-02 09:56:35   paramModuleHighVoltLimit 54.000
     2024-04-02 09:56:35   paramModuleLowVoltLimit 46.000
     2024-04-02 09:56:35   paramModuleUnderVoltLimit 43.000
     2024-04-02 09:56:35   protocolVersion V2.0
     2024-04-02 09:56:35   serialNumber    Y220817C50440795
     2024-04-02 09:56:35   state           connected


Internals:
   .FhemMetaInternals 1
   BATADDRESS 2
   CFGFN     
   DEF        192.168.0.6:9000 2
   FUUID      660920e1-f33f-cb2e-d1ad-9b29df2f0484262f
   FVERSION   70_PylonLowVoltage.pm:v1.1.1-s28724/2024-03-29
   HOST       192.168.0.6
   NAME       Bat2
   NR         115
   OPMODE     Manual
   PORT       9000
   STATE      connected
   TYPE       PylonLowVoltage
   eventCount 5
   .attraggr:
   .attrminint:
   HELPER:
     PACKAGE    FHEM::PylonLowVoltage
     VERSION    0.2.4
     VERSION_API unused
     VERSION_CTZ unused
     VERSION_ErrCodes unused
     VERSION_SMUtils 1.27.2
   READINGS:
     2024-04-02 09:17:52   Manufacturer    Pylon
     2024-04-02 09:17:52   averageCellVolt 3.198
     2024-04-02 09:17:52   batteryType     US5000
     2024-04-02 09:17:52   bmsTemperature  14.2
     2024-04-02 09:17:52   cellTemperature_0104 12.5
     2024-04-02 09:17:52   cellTemperature_0508 12.5
     2024-04-02 09:17:52   cellTemperature_0912 12.3
     2024-04-02 09:17:52   cellTemperature_1315 12.4
     2024-04-02 09:17:52   cellTemperature_add06 13.4
     2024-04-02 09:17:52   cellVoltage_01  3.197
     2024-04-02 09:17:52   cellVoltage_02  3.203
     2024-04-02 09:17:52   cellVoltage_03  3.200
     2024-04-02 09:17:52   cellVoltage_04  3.199
     2024-04-02 09:17:52   cellVoltage_05  3.202
     2024-04-02 09:17:52   cellVoltage_06  3.196
     2024-04-02 09:17:52   cellVoltage_07  3.196
     2024-04-02 09:17:52   cellVoltage_08  3.193
     2024-04-02 09:17:52   cellVoltage_09  3.195
     2024-04-02 09:17:52   cellVoltage_10  3.199
     2024-04-02 09:17:52   cellVoltage_11  3.199
     2024-04-02 09:17:52   cellVoltage_12  3.200
     2024-04-02 09:17:52   cellVoltage_13  3.197
     2024-04-02 09:17:52   cellVoltage_14  3.193
     2024-04-02 09:17:52   cellVoltage_15  3.198
     2024-04-02 09:17:52   chargeCurrentLimit 37.0
     2024-04-02 09:17:52   chargeEnable    yes
     2024-04-02 09:17:52   chargeFullRequest no
     2024-04-02 09:17:52   chargeImmediatelySOC05 no
     2024-04-02 09:17:52   chargeImmediatelySOC09 no
     2024-04-02 09:17:52   chargeVoltageLimit 53.250
     2024-04-02 09:17:52   dischargeCurrentLimit 37.0
     2024-04-02 09:17:52   dischargeEnable yes
     2024-04-02 09:17:52   dischargeVoltageLimit 45.000
     2024-04-02 09:17:52   moduleSoftwareVersion_mainline V0.6.9
     2024-04-02 09:17:52   moduleSoftwareVersion_manufacture V1.4
     2024-04-02 09:17:52   nextCycletime   Manual
     2024-04-02 09:17:52   numberTempPos   6
     2024-04-02 09:17:52   packAlarmInfo   ok
     2024-04-02 09:17:52   packCapacity    74.000
     2024-04-02 09:17:52   packCapacityRemain 7.920
     2024-04-02 09:17:52   packCellcount   15
     2024-04-02 09:17:52   packCurrent     0.000
     2024-04-02 09:17:52   packCycles      270
     2024-04-02 09:17:52   packImbalance   0.313
     2024-04-02 09:17:52   packPower       0.00
     2024-04-02 09:17:52   packSOC         10.70
     2024-04-02 09:17:52   packState       idle
     2024-04-02 09:17:52   packVolt        47.967
     2024-04-02 09:17:52   paramCellHighVoltLimit 3.650
     2024-04-02 09:17:52   paramCellLowVoltLimit 3.050
     2024-04-02 09:17:52   paramCellUnderVoltLimit 2.800
     2024-04-02 09:17:52   paramChargeCurrentLimit 100.000
     2024-04-02 09:17:52   paramChargeHighTempLimit 60.0
     2024-04-02 09:17:52   paramChargeLowTempLimit -10.0
     2024-04-02 09:17:52   paramDischargeCurrentLimit 99.900
     2024-04-02 09:17:52   paramDischargeHighTempLimit 60.0
     2024-04-02 09:17:52   paramDischargeLowTempLimit -10.0
     2024-04-02 09:17:52   paramModuleHighVoltLimit 54.000
     2024-04-02 09:17:52   paramModuleLowVoltLimit 46.000
     2024-04-02 09:17:52   paramModuleUnderVoltLimit 43.000
     2024-04-02 09:17:52   protocolVersion V2.0
     2024-04-02 09:17:52   serialNumber    H220820C30520541
     2024-04-02 09:17:52   state           connected
ich sehe gerade beim Dev1 ist packAlarmInfo wieder auf failure und beim Dev2 noch auf ok inzwischen aber auch auf failure. Der Cerbo zeigt z.Z aber keinen Alarm.

Wegen der Alarminfo müssen wir nochmal auf eine verbose 5 schauen.

Bitte sehr :
2024.04.02 10:21:44 4: Bat1 - start request cycle to battery number >1< at host:port 192.168.0.6:9000
2024.04.02 10:21:44 4: Bat1 - Cycle started in main process
2024.04.02 10:21:44 4: Bat1 - retrieve battery info: serialNumber
2024.04.02 10:21:44 4: Bat1 - request command (ASCII): ~20024693E00202FD2D
2024.04.02 10:21:44 5: Bat1 - request command (HEX): 7e3230303234363933453030323032464432440d
2024.04.02 10:21:44 5: Bat1 - data returned raw: ~20024600C0220259323230383137433530343430373935F6C4
2024.04.02 10:21:44 5: Bat1 - data returned:
0x00000000 (00000)  7e323030 32343630 30433032 32303235  ~20024600C022025
0x00000010 (00016)  39333233 32333033 38333133 37343333  9323230383137433
0x00000020 (00032)  35333033 34333433 30333733 39333546  530343430373935F
0x00000030 (00048)  3643340d                             6C4.

2024.04.02 10:21:44 4: Bat1 - retrieve battery info: manufacturerInfo
2024.04.02 10:21:44 4: Bat1 - request command (ASCII): ~200246510000FDAC
2024.04.02 10:21:44 5: Bat1 - request command (HEX): 7e323030323436353130303030464441430d
2024.04.02 10:21:44 5: Bat1 - data returned raw: ~20024600C04055533530303000000000010350796C6F6E2D2D2D2D2D2D2D2D2D2D2D2D2D2D2DEFC5
2024.04.02 10:21:44 5: Bat1 - data returned:
0x00000000 (00000)  7e323030 32343630 30433034 30353535  ~20024600C040555
0x00000010 (00016)  33333533 30333033 30303030 30303030  3353030300000000
0x00000020 (00032)  30303130 33353037 39364336 46364532  0010350796C6F6E2
0x00000030 (00048)  44324432 44324432 44324432 44324432  D2D2D2D2D2D2D2D2
0x00000040 (00064)  44324432 44324432 44324432 44454643  D2D2D2D2D2D2DEFC
0x00000050 (00080)  350d                                 5.

2024.04.02 10:21:44 4: Bat1 - retrieve battery info: protocolVersion
2024.04.02 10:21:44 4: Bat1 - request command (ASCII): ~0002464F0000FD9A
2024.04.02 10:21:44 5: Bat1 - request command (HEX): 7e303030323436344630303030464439410d
2024.04.02 10:21:44 5: Bat1 - data returned raw: ~200246000000FDB2
2024.04.02 10:21:44 5: Bat1 - data returned:
0x00000000 (00000)  7e323030 32343630 30303030 30464442  ~200246000000FDB
0x00000010 (00016)  320d                                 2.

2024.04.02 10:21:44 4: Bat1 - retrieve battery info: softwareVersion
2024.04.02 10:21:44 4: Bat1 - request command (ASCII): ~20024696E00202FD2A
2024.04.02 10:21:44 5: Bat1 - request command (HEX): 7e3230303234363936453030323032464432410d
2024.04.02 10:21:44 5: Bat1 - data returned raw: ~20024600400C020103000609FB46
2024.04.02 10:21:44 5: Bat1 - data returned:
0x00000000 (00000)  7e323030 32343630 30343030 43303230  ~20024600400C020
0x00000010 (00016)  31303330 30303630 39464234 360d      103000609FB46.

2024.04.02 10:21:44 4: Bat1 - retrieve battery info: systemParameters
2024.04.02 10:21:44 4: Bat1 - request command (ASCII): ~20024647E00202FD2E
2024.04.02 10:21:44 5: Bat1 - request command (HEX): 7e3230303234363437453030323032464432450d
2024.04.02 10:21:45 5: Bat1 - data returned raw: ~20024600B032110E420BEA0AF00D030A4703E8D2F0B3B0A7F80D030A47FC18F27E
2024.04.02 10:21:45 5: Bat1 - data returned:
0x00000000 (00000)  7e323030 32343630 30423033 32313130  ~20024600B032110
0x00000010 (00016)  45343230 42454130 41463030 44303330  E420BEA0AF00D030
0x00000020 (00032)  41343730 33453844 32463042 33423041  A4703E8D2F0B3B0A
0x00000030 (00048)  37463830 44303330 41343746 43313846  7F80D030A47FC18F
0x00000040 (00064)  3237450d                             27E.

2024.04.02 10:21:45 4: Bat1 - retrieve battery info: alarmInfo
2024.04.02 10:21:45 4: Bat1 - request command (ASCII): ~20024644E00202FD31
2024.04.02 10:21:45 5: Bat1 - request command (HEX): 7e3230303234363434453030323032464433310d
2024.04.02 10:21:45 5: Bat1 - data returned raw: ~20024600804401020F00000000000000000000000000000006000000000000000000000E40000000F0AA
2024.04.02 10:21:45 5: Bat1 - data returned:
0x00000000 (00000)  7e323030 32343630 30383034 34303130  ~200246008044010
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 410d                        0F0AA.

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

2024.04.02 10:21:45 4: Bat1 - retrieve battery info: analogValue
2024.04.02 10:21:45 4: Bat1 - request command (ASCII): ~20024642E00202FD33
2024.04.02 10:21:45 5: Bat1 - request command (HEX): 7e3230303234363432453030323032464433330d
2024.04.02 10:21:45 5: Bat1 - data returned raw: ~20024600B07E00020F0C960C960C950C960C960C960C960C960C960C960C960C950C970C970C96060B370B2F0B2A0B2A0B280B34FFFABCCAFFFF04FFFF012200314F0186A0E170
2024.04.02 10:21:45 5: Bat1 - data returned:
0x00000000 (00000)  7e323030 32343630 30423037 45303030  ~20024600B07E000
0x00000010 (00016)  32304630 43393630 43393630 43393530  20F0C960C960C950
0x00000020 (00032)  43393630 43393630 43393630 43393630  C960C960C960C960
0x00000030 (00048)  43393630 43393630 43393630 43393630  C960C960C960C960
0x00000040 (00064)  43393530 43393730 43393730 43393630  C950C970C970C960
0x00000050 (00080)  36304233 37304232 46304232 41304232  60B370B2F0B2A0B2
0x00000060 (00096)  41304232 38304233 34464646 41424343  A0B280B34FFFABCC
0x00000070 (00112)  41464646 46303446 46464630 31323230  AFFFF04FFFF01220
0x00000080 (00128)  30333134 46303138 36413045 3137300d  0314F0186A0E170.

2024.04.02 10:21:45 4: Bat1 - Socket/Connection to the RS485 gateway was closed
2024.04.02 10:21:45 4: Bat1 - got data from battery number >1< successfully

Kann es sein as bei alarmInfo auch 6 Temp Werte stecken ?

ZitatM+2 *温度点数量/number of temperature: N

Ja, das ist zu vermuten. Ich überlege nur welche Temp. bei der US5000 die Temp 6 sein soll. Sie hat ja auch nur 15 Zellen. Alternativ würde ich kein Reading für die zusätzliche Temperatur erstellen, sie nur zählen damit dem Protokoll Folge geleistet ist.
Mal sehen ...

Keine Ahnung was die mit Temp Sensor Nr 6 messen - zumal der 6. gelieferte Wert der US3000 besser zur 5000 passt, aber hier wird wohl wie beim batteryType nicht sauber getrennt sondern sich nach dem Master gerichtet.
Bei der Anzahl der Temp Sensoren scheint nicht nur 5 und 6 möglich zu -> die US2000 hat angeblich nur 4 !
Erst mit der US2000C kam Nr 5 (bzw. wohl auch bei den 3000er Varianten).

Hallo Wzut,

in meinem contrib liegt ein Update des Moduls.
Ich habe die Alarminfos komplett überarbeitet und ebenfalls mit einem dynamischen Zellen- und Temperatur Positionszähler ausgestattet. Es gibt jetzt auch viele spezifische Alarmreadings:

   READINGS:
     2024-04-02 17:40:19   AlmCellVoltage_01 00
     2024-04-02 17:40:19   AlmCellVoltage_02 00
     2024-04-02 17:40:19   AlmCellVoltage_03 00
     2024-04-02 17:40:19   AlmCellVoltage_04 00
     2024-04-02 17:40:19   AlmCellVoltage_05 00
     2024-04-02 17:40:19   AlmCellVoltage_06 00
     2024-04-02 17:40:19   AlmCellVoltage_07 00
     2024-04-02 17:40:19   AlmCellVoltage_08 00
     2024-04-02 17:40:19   AlmCellVoltage_09 00
     2024-04-02 17:40:19   AlmCellVoltage_10 00
     2024-04-02 17:40:19   AlmCellVoltage_11 00
     2024-04-02 17:40:19   AlmCellVoltage_12 00
     2024-04-02 17:40:19   AlmCellVoltage_13 00
     2024-04-02 17:40:19   AlmCellVoltage_14 00
     2024-04-02 17:40:19   AlmCellVoltage_15 00
     2024-04-02 17:40:19   AlmChargeCurrent 00
     2024-04-02 17:40:19   AlmDischargeCurrent 00
     2024-04-02 17:40:19   AlmModuleVoltage 00
     2024-04-02 17:40:19   AlmTemperature_01 00
     2024-04-02 17:40:19   AlmTemperature_02 00
     2024-04-02 17:40:19   AlmTemperature_03 00
     2024-04-02 17:40:19   AlmTemperature_04 00
     2024-04-02 17:40:19   AlmTemperature_05 00
     2024-04-02 17:39:56   Manufacturer    Pylon
     2024-04-02 17:40:19   averageCellVolt 3.495
     2024-04-02 17:39:56   batteryType     US3000C
     2024-04-02 17:40:19   bmsTemperature  20.8
     2024-04-02 17:40:19   cellTemperature_0104 18.7
     2024-04-02 17:40:19   cellTemperature_0508 18.6
     2024-04-02 17:40:19   cellTemperature_0912 18.2
     2024-04-02 17:40:19   cellTemperature_1315 19.2
     2024-04-02 17:40:19   cellVoltage_01  3.498
     2024-04-02 17:40:19   cellVoltage_02  3.493
     2024-04-02 17:40:19   cellVoltage_03  3.490
     2024-04-02 17:40:19   cellVoltage_04  3.502
     2024-04-02 17:40:19   cellVoltage_05  3.495
     2024-04-02 17:40:19   cellVoltage_06  3.499
     2024-04-02 17:40:19   cellVoltage_07  3.497
     2024-04-02 17:40:19   cellVoltage_08  3.494
     2024-04-02 17:40:19   cellVoltage_09  3.497
     2024-04-02 17:40:19   cellVoltage_10  3.497
     2024-04-02 17:40:19   cellVoltage_11  3.498
     2024-04-02 17:40:19   cellVoltage_12  3.499
     2024-04-02 17:40:19   cellVoltage_13  3.490
     2024-04-02 17:40:19   cellVoltage_14  3.497
     2024-04-02 17:40:19   cellVoltage_15  3.476
     2024-04-02 17:40:19   chargeCurrentLimit 0.0
     2024-04-02 17:40:19   chargeEnable    no
     2024-04-02 17:40:19   chargeFullRequest no
     2024-04-02 17:40:19   chargeImmediatelySOC05 no
     2024-04-02 17:40:19   chargeImmediatelySOC09 no
     2024-04-02 17:40:19   chargeVoltageLimit 53.250
     2024-04-02 17:40:19   dischargeCurrentLimit 37.0
     2024-04-02 17:40:19   dischargeEnable yes
     2024-04-02 17:40:19   dischargeVoltageLimit 45.000
     2024-04-02 17:39:56   moduleSoftwareVersion_mainline V0.6.9
     2024-04-02 17:39:56   moduleSoftwareVersion_manufacture V1.8
     2024-04-02 17:40:19   nextCycletime   17:40:25
     2024-04-02 17:40:19   numberTempPos   5
     2024-04-02 17:40:19   packAlarmInfo   ok
     2024-04-02 17:40:19   packCapacity    74.000
     2024-04-02 17:40:19   packCapacityRemain 73.778
     2024-04-02 17:40:19   packCellcount   15
     2024-04-02 17:40:19   packCurrent     0.200
     2024-04-02 17:40:19   packCycles      32
     2024-04-02 17:40:19   packImbalance   0.744
     2024-04-02 17:40:19   packPower       10.48
     2024-04-02 17:40:19   packSOC         99.70
     2024-04-02 17:40:19   packState       charging
     2024-04-02 17:40:19   packVolt        52.422
     2024-04-02 17:39:56   paramCellHighVoltLimit 3.650
     2024-04-02 17:39:56   paramCellLowVoltLimit 3.050
     2024-04-02 17:39:56   paramCellUnderVoltLimit 2.800
     2024-04-02 17:39:56   paramChargeCurrentLimit 90.000
     2024-04-02 17:39:56   paramChargeHighTempLimit 60.0
     2024-04-02 17:39:56   paramChargeLowTempLimit -10.0
     2024-04-02 17:39:56   paramDischargeCurrentLimit 89.900
     2024-04-02 17:39:56   paramDischargeHighTempLimit 60.0
     2024-04-02 17:39:56   paramDischargeLowTempLimit -10.0
     2024-04-02 17:39:56   paramModuleHighVoltLimit 54.000
     2024-04-02 17:39:56   paramModuleLowVoltLimit 46.000
     2024-04-02 17:39:56   paramModuleUnderVoltLimit 43.000
     2024-04-02 17:39:56   protocolVersion V2.0
     2024-04-02 17:39:56   serialNumber    K221206C31740079
     2024-04-02 17:40:19   state           connected

Schau mal wie es bei dir damit aussieht.

Sieht für die US5000 soweit gut aus, THX
finde auch schön das du nun in alarm info nicht nur die Nullen zählst :)
 

Moin Wzut,

prima. Dann werde ich die V auch mal einchecken. Wenn ich daran denke schon heute Abend.
Dann kann ich dioe US5000 ja auch in die Referenzliste aufnehmen.  :)

Edit: Kannst du mir nochmal ein List anhängen? Dann sehe ich auch mal wie die Readings jetzt bei der US5000 aussehen.

Grüße,
Heiko

Zitat von: DS_Starter am 03 April 2024, 09:37:39Edit: Kannst du mir nochmal ein List anhängen? Dann sehe ich auch mal wie die Readings jetzt bei der US5000 aussehen.

Nichts leichter als das, ich blicke noch nicht so ganz jede Bedeutung.
   READINGS:
     2024-04-02 10:17:45   Manufacturer    Pylon
     2024-04-03 09:03:19   almCellVoltage_01 00
     2024-04-03 09:03:19   almCellVoltage_02 00
     2024-04-03 09:03:19   almCellVoltage_03 00
     2024-04-03 09:03:19   almCellVoltage_04 00
     2024-04-03 09:03:19   almCellVoltage_05 00
     2024-04-03 09:03:19   almCellVoltage_06 00
     2024-04-03 09:03:19   almCellVoltage_07 00
     2024-04-03 09:03:19   almCellVoltage_08 00
     2024-04-03 09:03:19   almCellVoltage_09 00
     2024-04-03 09:03:19   almCellVoltage_10 00
     2024-04-03 09:03:19   almCellVoltage_11 00
     2024-04-03 09:03:19   almCellVoltage_12 00
     2024-04-03 09:03:19   almCellVoltage_13 00
     2024-04-03 09:03:19   almCellVoltage_14 00
     2024-04-03 09:03:19   almCellVoltage_15 00
     2024-04-03 09:03:19   almChargeCurrent 00
     2024-04-03 09:03:19   almDischargeCurrent 00
     2024-04-03 09:03:19   almModuleVoltage 00
     2024-04-03 09:03:19   almTemperature_01 00
     2024-04-03 09:03:19   almTemperature_02 00
     2024-04-03 09:03:19   almTemperature_03 00
     2024-04-03 09:03:19   almTemperature_04 00
     2024-04-03 09:03:19   almTemperature_05 00
     2024-04-03 09:03:19   almTemperature_06 00
     2024-04-03 09:43:49   averageCellVolt 3.218
     2024-04-02 10:17:45   batteryType     US5000
     2024-04-03 09:29:19   bmsTemperature  15.1
     2024-04-03 09:38:19   cellTemperature_0104 14.7
     2024-04-03 09:37:19   cellTemperature_0508 14.3
     2024-04-03 09:41:19   cellTemperature_0912 14.2
     2024-04-03 09:42:19   cellTemperature_1315 13.8
     2024-04-03 09:34:19   cellTemperature_TempPos_06 14.5
     2024-04-03 08:39:49   cellTemperature_add06 14.7
     2024-04-01 19:13:37   cellTemperature_new 15.3
     2024-04-03 09:43:49   cellVoltage_01  3.217
     2024-04-03 09:43:19   cellVoltage_02  3.217
     2024-04-03 09:43:19   cellVoltage_03  3.214
     2024-04-03 09:43:19   cellVoltage_04  3.219
     2024-04-03 09:43:49   cellVoltage_05  3.221
     2024-04-03 09:43:19   cellVoltage_06  3.218
     2024-04-03 09:43:49   cellVoltage_07  3.217
     2024-04-03 09:43:19   cellVoltage_08  3.225
     2024-04-03 09:43:19   cellVoltage_09  3.213
     2024-04-03 09:43:49   cellVoltage_10  3.220
     2024-04-03 09:43:49   cellVoltage_11  3.223
     2024-04-03 09:43:49   cellVoltage_12  3.207
     2024-04-03 09:43:49   cellVoltage_13  3.223
     2024-04-03 09:43:49   cellVoltage_14  3.220
     2024-04-03 09:43:49   cellVoltage_15  3.220
     2024-04-02 17:28:16   chargeCurrentLimit 80.0
     2024-04-02 10:18:44   chargeEnable    yes
     2024-04-02 10:18:44   chargeFullRequest no
     2024-04-02 10:18:44   chargeImmediatelySOC05 no
     2024-04-02 10:18:44   chargeImmediatelySOC09 no
     2024-04-02 10:18:44   chargeVoltageLimit 53.250
     2024-04-02 10:18:44   dischargeCurrentLimit 80.0
     2024-04-02 10:18:44   dischargeEnable yes
     2024-04-02 10:18:44   dischargeVoltageLimit 45.000
     2024-04-02 10:17:45   moduleSoftwareVersion_mainline V0.6.9
     2024-04-02 10:17:45   moduleSoftwareVersion_manufacture V1.3
     2024-04-03 09:43:49   nextCycletime   09:44:19
     2024-04-02 10:18:44   numberTempPos   6
     2024-04-03 09:03:19   packAlarmInfo   ok
     2024-04-02 10:18:44   packCapacity    100.000
     2024-04-03 09:20:49   packCapacityRemain 9.710
     2024-04-02 10:18:44   packCellcount   15
     2024-04-03 09:43:49   packCurrent     2.900
     2024-04-02 19:51:17   packCycles      291
     2024-04-03 09:43:49   packImbalance   0.559
     2024-04-03 09:43:49   packPower       139.99
     2024-04-03 09:20:49   packSOC         9.71
     2024-04-03 09:10:19   packState       charging
     2024-04-03 09:43:49   packVolt        48.274
     2024-04-02 10:17:45   paramCellHighVoltLimit 3.650
     2024-04-02 10:17:45   paramCellLowVoltLimit 3.050
     2024-04-02 10:17:45   paramCellUnderVoltLimit 2.800
     2024-04-02 10:17:45   paramChargeCurrentLimit 100.000
     2024-04-02 10:17:45   paramChargeHighTempLimit 60.0
     2024-04-02 10:17:45   paramChargeLowTempLimit -10.0
     2024-04-02 10:17:45   paramDischargeCurrentLimit 99.900
     2024-04-02 10:17:45   paramDischargeHighTempLimit 60.0
     2024-04-02 10:17:45   paramDischargeLowTempLimit -10.0
     2024-04-02 10:17:45   paramModuleHighVoltLimit 54.000
     2024-04-02 10:17:45   paramModuleLowVoltLimit 46.000
     2024-04-02 10:17:45   paramModuleUnderVoltLimit 43.000
     2024-04-02 10:17:45   protocolVersion V2.0
     2024-04-02 10:17:45   serialNumber    Y220817C50440795
     2024-04-02 10:18:44   state           connected

   READINGS:
     2024-04-02 10:19:25   Manufacturer    Pylon
     2024-04-03 09:03:30   almCellVoltage_01 00
     2024-04-03 09:03:30   almCellVoltage_02 00
     2024-04-03 09:03:30   almCellVoltage_03 00
     2024-04-03 09:03:30   almCellVoltage_04 00
     2024-04-03 09:03:30   almCellVoltage_05 00
     2024-04-03 09:03:30   almCellVoltage_06 00
     2024-04-03 09:03:30   almCellVoltage_07 00
     2024-04-03 09:03:30   almCellVoltage_08 00
     2024-04-03 09:03:30   almCellVoltage_09 00
     2024-04-03 09:03:30   almCellVoltage_10 00
     2024-04-03 09:03:30   almCellVoltage_11 00
     2024-04-03 09:03:30   almCellVoltage_12 00
     2024-04-03 09:03:30   almCellVoltage_13 00
     2024-04-03 09:03:30   almCellVoltage_14 00
     2024-04-03 09:03:30   almCellVoltage_15 00
     2024-04-03 09:03:30   almChargeCurrent 00
     2024-04-03 09:03:30   almDischargeCurrent 00
     2024-04-03 09:03:30   almModuleVoltage 00
     2024-04-03 09:03:30   almTemperature_01 00
     2024-04-03 09:03:30   almTemperature_02 00
     2024-04-03 09:03:30   almTemperature_03 00
     2024-04-03 09:03:30   almTemperature_04 00
     2024-04-03 09:03:30   almTemperature_05 00
     2024-04-03 09:03:30   almTemperature_06 00
     2024-04-03 09:46:00   averageCellVolt 3.218
     2024-04-02 10:19:25   batteryType     US5000
     2024-04-03 09:23:30   bmsTemperature  15.4
     2024-04-03 09:44:00   cellTemperature_0104 14
     2024-04-03 09:44:00   cellTemperature_0508 14
     2024-04-03 09:41:00   cellTemperature_0912 13.9
     2024-04-03 09:36:00   cellTemperature_1315 14
     2024-04-03 09:39:00   cellTemperature_TempPos_06 14.6
     2024-04-03 09:02:00   cellTemperature_add06 14.7
     2024-04-03 09:47:00   cellVoltage_01  3.217
     2024-04-03 09:46:30   cellVoltage_02  3.221
     2024-04-03 09:46:00   cellVoltage_03  3.220
     2024-04-03 09:46:30   cellVoltage_04  3.219
     2024-04-03 09:46:00   cellVoltage_05  3.221
     2024-04-03 09:46:30   cellVoltage_06  3.216
     2024-04-03 09:46:30   cellVoltage_07  3.216
     2024-04-03 09:47:00   cellVoltage_08  3.214
     2024-04-03 09:47:00   cellVoltage_09  3.215
     2024-04-03 09:46:30   cellVoltage_10  3.219
     2024-04-03 09:46:30   cellVoltage_11  3.219
     2024-04-03 09:47:00   cellVoltage_12  3.220
     2024-04-03 09:46:30   cellVoltage_13  3.217
     2024-04-03 09:47:00   cellVoltage_14  3.214
     2024-04-03 09:46:30   cellVoltage_15  3.218
     2024-04-02 17:21:57   chargeCurrentLimit 37.0
     2024-04-02 10:19:55   chargeEnable    yes
     2024-04-02 10:19:55   chargeFullRequest no
     2024-04-02 10:19:55   chargeImmediatelySOC05 no
     2024-04-02 10:19:55   chargeImmediatelySOC09 no
     2024-04-02 10:19:55   chargeVoltageLimit 53.250
     2024-04-02 10:19:55   dischargeCurrentLimit 37.0
     2024-04-02 10:19:55   dischargeEnable yes
     2024-04-02 10:19:55   dischargeVoltageLimit 45.000
     2024-04-02 10:19:25   moduleSoftwareVersion_mainline V0.6.9
     2024-04-02 10:19:25   moduleSoftwareVersion_manufacture V1.4
     2024-04-03 09:47:00   nextCycletime   09:47:30
     2024-04-02 10:19:55   numberTempPos   6
     2024-04-03 09:00:00   packAlarmInfo   ok
     2024-04-02 10:19:55   packCapacity    74.000
     2024-04-03 09:31:00   packCapacityRemain 8.640
     2024-04-02 10:19:55   packCellcount   15
     2024-04-03 09:47:00   packCurrent     1.000
     2024-04-02 20:50:57   packCycles      271
     2024-04-03 09:47:00   packImbalance   0.218
     2024-04-03 09:47:00   packPower       48.27
     2024-04-03 09:31:00   packSOC         11.68
     2024-04-03 09:16:00   packState       charging
     2024-04-03 09:47:00   packVolt        48.266
     2024-04-02 10:19:25   paramCellHighVoltLimit 3.650
     2024-04-02 10:19:25   paramCellLowVoltLimit 3.050
     2024-04-02 10:19:25   paramCellUnderVoltLimit 2.800
     2024-04-02 10:19:25   paramChargeCurrentLimit 100.000
     2024-04-02 10:19:25   paramChargeHighTempLimit 60.0
     2024-04-02 10:19:25   paramChargeLowTempLimit -10.0
     2024-04-02 10:19:25   paramDischargeCurrentLimit 99.900
     2024-04-02 10:19:25   paramDischargeHighTempLimit 60.0
     2024-04-02 10:19:25   paramDischargeLowTempLimit -10.0
     2024-04-02 10:19:25   paramModuleHighVoltLimit 54.000
     2024-04-02 10:19:25   paramModuleLowVoltLimit 46.000
     2024-04-02 10:19:25   paramModuleUnderVoltLimit 43.000
     2024-04-02 10:19:25   protocolVersion V2.0
     2024-04-02 10:19:25   serialNumber    H220820C30520541
     2024-04-02 10:19:55   state           connected


aber noch etwas pure Neugier : alarm info , Seite 17 der RS485 Effekta Doku :

ZitatNo Content Note
1 电芯节数/number of cell: M 1
2 Cell 1 voltage 1

Wie kommt von von da auf den Offset von 17 der im Modul benutzt wird ?

Die Readings     
     cellTemperature_add06
     cellTemperature_new

Kannst du löschen. Für diese unbestimmten "Zusatztemperaturen" erstelle ich cellTemperature_TempPos_X.

Die Response besteht zunächst aus 7 Byte Headerinfos -> 14 Positionen.
Dann folgt INFO = DATAFLAG + WARNSTATE (Data Format INFO) -> 2Byte -> 4 Positionen.

D.h. in Summe 18 Positionen. Da wir bei 0 anfangen, beginnt der Datencontent bei 17.
Nur oberflächlich und verkürzt dargestellt. Die Datenformate sind nicht fix und im Dokument ganz vorn beschrieben.

Du hast "RS485 Effekta Doku" geschrieben. Ich habe das Dok glaube ich woanders her. Kannst einen Link posten? Ich möchte vergleichen ob ich das gleiche Dok habe/benutze.

THX, aber das ist deine V3.3 aus Antwort #15.
Effekta vs. Pylontech Dreher, sorry mein Fehler :(

Ich habe die Alarmreadings noch richtig codiert, d.h. je nach Zustand bekommen diese Readings einen der Werte:

normal
below lower limit
above higher limit
other error
Das Update ist eingecheckt und morgen früh in der Auslieferung.

Hallo zusammen,

habe auch 4 US3000C in Betrieb, bekomme aber mit dem Waveshare keine Daten in FHEM ( aktuelles System) im Log kommt folgender Fehler

2024.04.04 17:11:36 4: Batt - start request cycle to battery number >1< at host:port 192.168.178.184:9800
2024.04.04 17:11:36 4: Batt - Cycle started in main process
2024.04.04 17:11:36 4: Batt - retrieve battery info: serialNumber
2024.04.04 17:11:36 4: Batt - request command (ASCII): ~20024693E00202FD2D
2024.04.04 17:11:36 5: Batt - request command (HEX): 7e3230303234363933453030323032464432440d
2024.04.04 17:11:36 4: Batt - invalid data received ... discarded
2024.04.04 17:11:36 5: Batt - faulty data is printed out now:
2024.04.04 17:11:36 5: Batt - data returned raw: 6~20024600C0220259323231313134433330323632363635F6D1
2024.04.04 17:11:36 5: Batt - data returned:
0x00000000 (00000)  367e3230 30323436 30304330 32323032  6~20024600C02202
0x00000010 (00016)  35393332 33323331 33313331 33343433  5932323131313443
0x00000020 (00032)  33333330 33323336 33323336 33363335  3330323632363635
0x00000030 (00048)  46364431 0d                          F6D1.

2024.04.04 17:11:36 4: Batt - Socket/Connection to the RS485 gateway was closed
2024.04.04 17:11:38 4: Batt - start request cycle to battery number >1< at host:port 192.168.178.184:9800
2024.04.04 17:11:38 4: Batt - Cycle started in main process
2024.04.04 17:11:38 4: Batt - retrieve battery info: serialNumber
2024.04.04 17:11:38 4: Batt - request command (ASCII): ~20024693E00202FD2D
2024.04.04 17:11:38 5: Batt - request command (HEX): 7e3230303234363933453030323032464432440d
2024.04.04 17:11:38 4: Batt - invalid data received ... discarded
2024.04.04 17:11:38 5: Batt - faulty data is printed out now:
2024.04.04 17:11:38 5: Batt - data returned raw: 6~20024600C0220259323231313134433330323632363635F6D1
2024.04.04 17:11:38 5: Batt - data returned:
0x00000000 (00000)  367e3230 30323436 30304330 32323032  6~20024600C02202
0x00000010 (00016)  35393332 33323331 33313331 33343433  5932323131313443
0x00000020 (00032)  33333330 33323336 33323336 33363335  3330323632363635
0x00000030 (00048)  46364431 0d                          F6D1.

2024.04.04 17:11:38 4: Batt - Socket/Connection to the RS485 gateway was closed
im Waveshere werden aber Daten empfangen, hat jemand eine Idee ?2024-04-04 17_19_21-RS485 TO ETH.png

In der Hilfe zum Modul habe ich die Einstellungen des Waveshare aufgeschrieben.
Ist es so gesetzt? Stimmt die Geschwindigkeit zwischen Waveshare und dem Battriemaster Setting überein?
Ist das verwendete Kabel richtig angeschlossen (RS485 Buchse am Master verwenden)?

bin alle Punkte mehrmals durchgegangen, konnte aber keinen Fehler finden.
die DIP Schalter sind alle auf OFF de Baudrate ist auf 115200 eingestellt und auch am Master eingesteckt.
Bin mittlerweile auch etwas Ratlos :( 

Und das Kabel zur Batterie?
Irgendwo weiter vorn hatte ich die Belegung geschrieben. GND nicht anschließen.

-> Habe es gefunden: im Post #70

7 auf Klemme A, 8 auf Klemme B. Ground nicht angeschlossen
Internals:
   .FhemMetaInternals 1
   BATADDRESS 1
   CFGFN     
   DEF        192.168.178.184:9800
   FUUID      660ec1a0-f33f-976c-c317-5e0047479e6d51c4
   FVERSION   70_PylonLowVoltage.pm:v0.2.5-s28745/2024-04-03
   HOST       192.168.178.184
   NAME       Batt
   NR         1336
   OPMODE     Automatic
   PORT       9800
   STATE      invalid data received ... discarded
   TYPE       PylonLowVoltage
   eventCount 138
   .attraggr:
   .attrminint:
   HELPER:
     PACKAGE    FHEM::PylonLowVoltage
     VERSION    0.2.5
     VERSION_API unused
     VERSION_CTZ unused
     VERSION_ErrCodes unused
     VERSION_SMUtils 1.27.2
   READINGS:
     2024-04-04 17:40:08   nextCycletime   17:40:38
     2024-04-04 17:40:08   state           invalid data received ... discarded
   hmccu:
Attributes:
   room       Solar
   verbose    5

Ist eigenartig, ich habe mal mit der Antwort meiner US3000C (6 Stck) verglichen:

Richtig:
0x00000000 (00000)  7e323030 32343630 30433032 32303234  ~20024600C022024
0x00000010 (00016)  42333233 32333133 32333033 36343333  B323231323036433
0x00000020 (00032)  33333133 37333433 30333033 37333946  331373430303739F
0x00000030 (00048)  3643360d                             6C6.


Falsch:
0x00000000 (00000)  367e3230 30323436 30304330 32323032  6~20024600C02202
0x00000010 (00016)  35393332 33323331 33313331 33343433  5932323131313443
0x00000020 (00032)  33333330 33323336 33323336 33363335  3330323632363635
0x00000030 (00048)  46364431 0d                          F6D1

Die Zeichenfolge zu Beginn deiner Antwort vom Gateway ist falsch. Es muß mit "7e" beginnen, Tilde.
Da fällt mit auch gerade nicht viel ein dazu.
Ist dein FHEM ein Linux?

Ach ja, Linux ist es. Gerade gelesen.

Mach mal ein paar Screenshots deiner Gateway Einrichtung/dem Setup.

anbei

wenn ich über Console auf die Batterie gehe habe ich diese Infos
info

@

Device address      : 1

Manufacturer        : Pylon

Device name         : US3000C

Board version       : V10R04

Board               : NF4.E2

Main Soft version   : B69.13.2.0

Soft  version       : V1.8

Boot  version       : V1.0

Comm version        : V2.0

Release Date        : 22-10-19

Barcode             : Y221114C30262665



Specification       : 48V/74AH

Cell Number         : 15

Max Dischg Curr     : -90000mA

Max Charge Curr     : 90000mA

EPONPort rate       : 1200

Console Port rate   : 115200

Command completed successfully

$$

pylon>

Also ich kann da auch nichts falsches sehen und mit meinem Setup verglichen.
Hast du spaßeshalber mal eine andere IP und Port ausprobiert?

alles schon durch, IP manuell vergeben dann auch mit DHCP verschiedene Ports usw...

Auch mal ohne das gesetzte "Buffer data before connection ..." probiert?
Möglicherweise hilft auch eine Reduktion der Verbindungsbaudrate?

Weiterhin wäre es einen Versuch wert das Attr timeout auf einen Wert > 1 zu setzen.

leider nicht Zielführend, werde mein Glück morgen nochmals versuchen.

Hallo zusammen,

bei mir hat es nun auch geklappt, musste einen 100ohm ( hatte keine 120ohm) Wiederstand zwischen A und B klemmen.
Jetzt kommen die Daten nur so rein  ;D Internals:
   .FhemMetaInternals 1
   BATADDRESS 1
   DEF        192.168.178.155:9600
   FUUID      661271d4-f33f-976c-aba4-14d8f5993c01bc12
   FVERSION   70_PylonLowVoltage.pm:v0.2.5-s28745/2024-04-03
   HOST       192.168.178.155
   NAME       Pylon
   NR         956
   OPMODE     Automatic
   PORT       9600
   STATE      connected
   TYPE       PylonLowVoltage
   eventCount 201
   .attraggr:
   .attrminint:
   HELPER:
     PACKAGE    FHEM::PylonLowVoltage
     VERSION    0.2.5
     VERSION_API unused
     VERSION_CTZ unused
     VERSION_ErrCodes unused
     VERSION_SMUtils 1.27.2
   OLDREADINGS:
   READINGS:
     2024-04-07 13:36:21   Manufacturer    Pylon
     2024-04-07 13:36:21   almCellVoltage_01 normal
     2024-04-07 13:36:21   almCellVoltage_02 normal
     2024-04-07 13:36:21   almCellVoltage_03 normal
     2024-04-07 13:36:21   almCellVoltage_04 normal
     2024-04-07 13:36:21   almCellVoltage_05 normal
     2024-04-07 13:36:21   almCellVoltage_06 normal
     2024-04-07 13:36:21   almCellVoltage_07 normal
     2024-04-07 13:36:21   almCellVoltage_08 normal
     2024-04-07 13:36:21   almCellVoltage_09 normal
     2024-04-07 13:36:21   almCellVoltage_10 normal
     2024-04-07 13:36:21   almCellVoltage_11 normal
     2024-04-07 13:36:21   almCellVoltage_12 normal
     2024-04-07 13:36:21   almCellVoltage_13 normal
     2024-04-07 13:36:21   almCellVoltage_14 normal
     2024-04-07 13:36:21   almCellVoltage_15 normal
     2024-04-07 13:36:21   almChargeCurrent normal
     2024-04-07 13:36:21   almDischargeCurrent normal
     2024-04-07 13:36:21   almModuleVoltage normal
     2024-04-07 13:36:21   almTemperature_01 normal
     2024-04-07 13:36:21   almTemperature_02 normal
     2024-04-07 13:36:21   almTemperature_03 normal
     2024-04-07 13:36:21   almTemperature_04 normal
     2024-04-07 13:36:21   almTemperature_05 normal
     2024-04-07 13:36:21   averageCellVolt 3.338
     2024-04-07 13:36:21   batteryType     US3000C
     2024-04-07 13:36:21   bmsTemperature  24.1
     2024-04-07 13:36:21   cellTemperature_0104 22.1
     2024-04-07 13:36:21   cellTemperature_0508 22.1
     2024-04-07 13:36:21   cellTemperature_0912 22
     2024-04-07 13:36:21   cellTemperature_1315 23
     2024-04-07 13:36:21   cellVoltage_01  3.339
     2024-04-07 13:36:21   cellVoltage_02  3.338
     2024-04-07 13:36:21   cellVoltage_03  3.339
     2024-04-07 13:36:21   cellVoltage_04  3.338
     2024-04-07 13:36:21   cellVoltage_05  3.339
     2024-04-07 13:36:21   cellVoltage_06  3.338
     2024-04-07 13:36:21   cellVoltage_07  3.338
     2024-04-07 13:36:21   cellVoltage_08  3.338
     2024-04-07 13:36:21   cellVoltage_09  3.338
     2024-04-07 13:36:21   cellVoltage_10  3.338
     2024-04-07 13:36:21   cellVoltage_11  3.338
     2024-04-07 13:36:21   cellVoltage_12  3.339
     2024-04-07 13:36:21   cellVoltage_13  3.339
     2024-04-07 13:36:21   cellVoltage_14  3.339
     2024-04-07 13:36:21   cellVoltage_15  3.339
     2024-04-07 13:36:21   chargeCurrentLimit 37.0
     2024-04-07 13:36:21   chargeEnable    yes
     2024-04-07 13:36:21   chargeFullRequest no
     2024-04-07 13:36:21   chargeImmediatelySOC05 no
     2024-04-07 13:36:21   chargeImmediatelySOC09 no
     2024-04-07 13:36:21   chargeVoltageLimit 53.250
     2024-04-07 13:36:21   dischargeCurrentLimit 37.0
     2024-04-07 13:36:21   dischargeEnable yes
     2024-04-07 13:36:21   dischargeVoltageLimit 45.000
     2024-04-07 13:36:21   moduleSoftwareVersion_mainline V0.6.9
     2024-04-07 13:36:21   moduleSoftwareVersion_manufacture V1.8
     2024-04-07 13:36:21   nextCycletime   13:36:51
     2024-04-07 13:36:21   numberTempPos   5
     2024-04-07 13:36:21   packAlarmInfo   ok
     2024-04-07 13:36:21   packCapacity    74.000
     2024-04-07 13:36:21   packCapacityRemain 37.740
     2024-04-07 13:36:21   packCellcount   15
     2024-04-07 13:36:21   packCurrent     8.100
     2024-04-07 13:36:21   packCycles      1
     2024-04-07 13:36:21   packImbalance   0.030
     2024-04-07 13:36:21   packPower       405.62
     2024-04-07 13:36:21   packSOC         51.00
     2024-04-07 13:36:21   packState       charging
     2024-04-07 13:36:21   packVolt        50.077
     2024-04-07 13:36:21   paramCellHighVoltLimit 3.650
     2024-04-07 13:36:21   paramCellLowVoltLimit 3.050
     2024-04-07 13:36:21   paramCellUnderVoltLimit 2.800
     2024-04-07 13:36:21   paramChargeCurrentLimit 90.000
     2024-04-07 13:36:21   paramChargeHighTempLimit 60.0
     2024-04-07 13:36:21   paramChargeLowTempLimit -10.0
     2024-04-07 13:36:21   paramDischargeCurrentLimit 89.900
     2024-04-07 13:36:21   paramDischargeHighTempLimit 60.0
     2024-04-07 13:36:21   paramDischargeLowTempLimit -10.0
     2024-04-07 13:36:21   paramModuleHighVoltLimit 54.000
     2024-04-07 13:36:21   paramModuleLowVoltLimit 46.000
     2024-04-07 13:36:21   paramModuleUnderVoltLimit 43.000
     2024-04-07 13:36:21   protocolVersion V2.0
     2024-04-07 13:36:21   serialNumber    K221125C30051671
     2024-04-07 13:36:21   state           connected
   hmccu:
Attributes:
   room       Solar
   timeout    0.5
   verbose    5

Als blutiger FHEM Anfänger probier ich gerade PylonLowVoltage zum laufen zu kriegen. Als Gateway habe ich ein Waveshare in der Version als Hutschienenmodul. Die http Oberfläche ist erreichbar, aber die Einstellmöglichkeiten etwas anders als im FHEM Help. Ich weis nun nicht, ob der timeout auf Ebene der TCP Verbindung (anderer Port probieren?) oder wegen fehlenden seriellen Daten ist. Wenn ich die serielle GND Leitung abtrenne, geht die blaue ACT LED aus. Die 115k sollten passen und an der blauen LED sollte man ja die Telegramme sehen? Die 10.10.20.158 ist die IP des Zielrechners wo FHEM drauf läuft. Kann die Einstellungen mal jemand mit seiner funktionierenden Installation vergleichen?




define pylon PylonLowVoltage 10.10.20.142:4196 1
attr pylon room pylon
#   BATADDRESS 1
#   CFGFN     
#   DEF        10.10.20.142:4196 1
#   FUUID      66b8fdb5-f33f-b913-d2ea-01f88590d5a64951
#   FVERSION   70_PylonLowVoltage.pm:v0.2.6-s28908/2024-05-25
#   HOST       10.10.20.142
#   NAME       pylon
#   NR         42
#   OPMODE     Automatic
#   PORT       4196
#   STATE      Timeout in communication to RS485 gateway
#   TYPE       PylonLowVoltage
#   eventCount 212
#   HELPER:
#     PACKAGE    FHEM::PylonLowVoltage
#     VERSION    0.2.6
#     VERSION_API unused
#     VERSION_CTZ unused
#     VERSION_ErrCodes unused
#     VERSION_SMUtils 1.27.2
#   READINGS:
#     2024-08-11 21:52:19   nextCycletime   21:52:49
#     2024-08-11 21:52:19   state           Timeout in communication to RS485 gateway
#
setstate pylon Timeout in communication to RS485 gateway
setstate pylon 2024-08-11 21:52:19 nextCycletime 21:52:49
setstate pylon 2024-08-11 21:52:19 state Timeout in communication to RS485 gateway



Frage zur verdrahtung, pin 7 u. pin 8 von pylontech klemmen am waveshare? Wenn ja, dreh die mal aus oder nutze einen widerstand zw. den adern. jumper auf pylontech auch alle off?

Habe mit 120 Ohm am Waveshare terminiert, kein GND verbunden und A / B zum Test auch schon mal getauscht. 
Dip Schalter sind alle oben, am Master ist der zweite von rechts aber unten (CAN Terminierung aus).

Es könnte ja sein, daß das Gateway gar keine seriellen Daten sieht was ja dann gar nichts mit FHEM zu tun hat. Vieleicht sollte ich mal versuchen am Gateway anstelle FHEM ein normales Terminal anzuschliessen? Oder sieht man da in ASCII gar nichts weil man keine Anfrage schicken kann?

Eine andere Unsicherheit: Die Anlage hat zwei mal 16 US5000 auf einem LV-Hub der für beide Gruppen als Aggregator arbeitet. Soweit ich sehe, gibt es am LV-Hub selbst gar keinen freien RS485 Port. Die erste Gruppe hat dabei sowieso beide Buchsen belegt (CAN + RS485), nur bei der zweiten (=letzten) Gruppe ist am Master die untere RS485 frei. Auf dem Venus-OS (Victronenergy) werden aber Werte per CAN von einzelnen Racks mit Gruppennummer+Racknummer korrekt angezeigt. Beiliegend mal meine verwendete Verschaltung aus dem LV Hub Manual.

Hmmm, du verwendest ja den HUB. Versuch mal ohne HUB das erste Pack per RS485 auszulesen.

DS_Starter schrieb:
Edit: Ich habe übrigens Pylon wegen einer neuren RS485 Doku angeschrieben. Sie haben mir geantwortet dass diese Doku nicht der Allgemeinheit zugänglich gemacht wird. :( Vllt. taucht mal etwas neueres im I-Net auf.

Pylontech hat zum Erreichen der KfW Förderfähigkeit unter Punkt 4 eine Erklärung in deutscher Sprache abgegeben, daß die Schnittstellenprotokolle zur Erzielung einer Kompabilität mit anderen Herstellern offengelegt sind. Das ist jetzt zwar nicht besonders nützlich, aber zu den "anderen Herstellern" gehört eindeutig auch FHEM als FOSS.

Na vielleicht hilft das wenn ich Pylontech nochmal anschreibe mit diesem Blatt im Anhang ;-)

Hast du in deinem Waveshare eine EInstellung "Similar RCF2217"? Ich glaube es war wichtig diesen Flag zu setzen.
Übrigens unterstützt das Modul zur Zeit nur eine Gruppe von Batterien. Siehe Hilfe. Ich kann bei Bedarf versuchen eine Gruppenfähigkeit herzustellen. Da es bislang e´keinen Bedarf und keinen Tester dafür gab, ist das nicht impementiert.

Um herauszufinden ob überhaupt Daten kommen, hilft verbose 5. Im Normalfall kommen dann diese Ausschriften:

2024.08.13 21:47:40.849 4: Pylon1 - start request cycle to battery number >1< at host:port 192.168.2.86:9000
2024.08.13 21:47:40.850 4: Pylon1 - Cycle started in main process
2024.08.13 21:47:40.856 4: Pylon1 - retrieve battery info: analogValue
2024.08.13 21:47:40.857 4: Pylon1 - request command (ASCII): ~20024642E00202FD33
2024.08.13 21:47:40.857 5: Pylon1 - request command (HEX): 7e3230303234363432453030323032464433330d
2024.08.13 21:47:40.874 5: Pylon1 - data returned raw: ~20024600F07A00020F0CF80CF80CF80CF80CF80CF70CF80CF80CF80CF80CF80CF80CF80CF90CF8050BC10BAA0BAA0BA70BB8FFF0C288FFFF04FFFF000F010C8F012110E15C
2024.08.13 21:47:40.875 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30463037 41303030  ~20024600F07A000
0x00000010 (00016)  32304630 43463830 43463830 43463830  20F0CF80CF80CF80
0x00000020 (00032)  43463830 43463830 43463730 43463830  CF80CF80CF70CF80
0x00000030 (00048)  43463830 43463830 43463830 43463830  CF80CF80CF80CF80
0x00000040 (00064)  43463830 43463830 43463930 43463830  CF80CF80CF90CF80
0x00000050 (00080)  35304243 31304241 41304241 41304241  50BC10BAA0BAA0BA
0x00000060 (00096)  37304242 38464646 30433238 38464646  70BB8FFF0C288FFF
0x00000070 (00112)  46303446 46464630 30304630 31304338  F04FFFF000F010C8
0x00000080 (00128)  46303132 31313045 3135430d           F012110E15C.

2024.08.13 21:47:40.875 4: Pylon1 - retrieve battery info: alarmInfo
2024.08.13 21:47:40.875 4: Pylon1 - request command (ASCII): ~20024644E00202FD31
2024.08.13 21:47:40.876 5: Pylon1 - request command (HEX): 7e3230303234363434453030323032464433310d
2024.08.13 21:47:40.888 5: Pylon1 - data returned raw: ~20024600A04200020F000000000000000000000000000000050000000000000000000E40000000F105
2024.08.13 21:47:40.888 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30413034 32303030  ~20024600A042000
0x00000010 (00016)  32304630 30303030 30303030 30303030  20F0000000000000
0x00000020 (00032)  30303030 30303030 30303030 30303030  0000000000000000
0x00000030 (00048)  30303530 30303030 30303030 30303030  0050000000000000
0x00000040 (00064)  30303030 30304534 30303030 30303046  000000E40000000F
0x00000050 (00080)  3130350d                             105.

2024.08.13 21:47:40.889 5: Pylon1 - Alarminfo - Status 1 alarm: 00
2024.08.13 21:47:40.889 5: Pylon1 - Alarminfo - Status 2 Info: 0E
2024.08.13 21:47:40.889 5: Pylon1 - Alarminfo - Status 3 Info: 40
2024.08.13 21:47:40.890 5: Pylon1 - Alarminfo - Status 4 alarm: 00
2024.08.13 21:47:40.890 5: Pylon1 - Alarminfo - Status 5 alarm: 00

2024.08.13 21:47:40.890 4: Pylon1 - retrieve battery info: chargeManagmentInfo
2024.08.13 21:47:40.890 4: Pylon1 - request command (ASCII): ~20024692E00202FD2E
2024.08.13 21:47:40.891 5: Pylon1 - request command (HEX): 7e3230303234363932453030323032464432450d
2024.08.13 21:47:40.899 5: Pylon1 - data returned raw: ~20024600B01402D002AFC80094FE8EC0F919
2024.08.13 21:47:40.900 5: Pylon1 - data returned:
0x00000000 (00000)  7e323030 32343630 30423031 34303244  ~20024600B01402D
0x00000010 (00016)  30303241 46433830 30393446 45384543  002AFC80094FE8EC
0x00000020 (00032)  30463931 390d                        0F919.

2024.08.13 21:47:40.900 4: Pylon1 - Socket/Connection to the RS485 gateway was closed
2024.08.13 21:47:40.900 4: Pylon1 - got data from battery number >1< successfully
Grüße,
Heiko

Ich habe mal eben in meiner Doku (US3500C) zum Thema Multi-Gruppen Mode nachgeschaut.
Dort steht unter Kapitel

Zitat4.8 Multi-Gruppen-Modus
Über RS485. Wird noch nicht unterstützt. Maximal 16 in 1 Gruppe.
Durch CAN:
....

Liest sich für mich so dass in diesem Mode RS485 keine Unterstützung findet. Macht auch Sinn wenn kein entsprechender Port am Hub verfügbar ist.

lt. Manual muss es aber gehen, denn ein Inverter ja infos über rs485 bekommt. Ausgang aber nur frei wenn kein CAN verwendet.
evt. kann man das Modul auf rs232 umschreiben.

Zitat von: DS_Starter am 13 August 2024, 21:49:56Hast du in deinem Waveshare eine EInstellung "Similar RCF2217"? Ich glaube es war wichtig diesen Flag zu setzen.

Mein Waveshare hat komischerweise eine völlig andere http Oberfläche wie hier abgebildet. Screendump siehe hier 6 Posts weiter vorne.
Das mit dem RFC2217 habe ich gelesen. Allerdings kann ich die Einstellung bei mir nicht finden. Ich habe abgebildetes Waveshare Gateway in der Hutschienenausführung.
Es wird über PoE mit Strom versorgt. Das RJ45 Kabel ist mit Pin 7 (ws/bn) auf RS485B und pin 8 (bn) auf RS458A. PE/GND sind nicht verbunden. Terminierung 150 Ohm, Leiungslänge 3m.

Um die Unsicherheiten mit dem LV Hub zu umgehen, möchte ich ungern meine beiden Gruppen auflösen. Das war eine ziemliche Kugelfuhr diese am LV Hub einzubuchen. Diesen ziemlich diffus beschriebenen Vorgang möchte ich zuvor erst noch mal besser verstehen um ihn dann systematisch üben zu können.

Ich kann allerdings ein einem der beiden Gruppen die letzte (16.) Batterie abtrennen und neu booten. FHEM sollte ja dann mit einer einzigen Batterie kommunizieren ohne daß diese eine zusätzlich CAN (oder RS485) Datenverbindung zu einem WR hat?

Noch was: Der Dip Schalter für die RS485 Baudrate ist im US5000 Manual in in der hier geposteten Protokollbeschreibung gegensätzlich beschrieben.
Manual:          Oben = 115200   Unten 9600
RS485 Protokollbeschreibung:    Oben = 9600   Unten 115200

Der verdreht platzierte DIP Schalter ist problematisch. Die Beschreibungen dazu aber eine dreiste Frechheit. Muß man zum Umschalten der Baudrate neu booten?

Bild 7503 zeigt den Master der zweiten (letzen) Gruppe.  Das weise Kabel links geht zur nächsten Gruppe (sonst WR). Das schwarze Kabel ist die Konsole für BatView und das Kabel bei B/RS485 geht zum Waveshare Gateway. 

Meine Mutmaßungen zum Verständnis der Pylontech Schnittstellen

Mein US5000 BMS ist mit einem Nation N32G455-VB Mikrocontroller aufgebaut. Das ist ein chinesischer Cortex M4 im QFP100 Gehäuse welcher 2 CAN Schnittstellen anbietet. Um ohne Spezialkabel einen linearen CAN Bus mit zwei Nachbarn verdrahten zu können, ist jede der CAN Schnittstellen auf zwei  RJ45 Buchsen aufgelegt. Diese können von je einem CAN Nachbarn  belegt werden.

Die erste CAN Schnittselle sind die beiden Link Ports zur internen Kommunikation. Die Buchsen LINK0 und LINK1 sind an den CAN Pins 4,5,6 durchverbunden. Der GND pin 6 ist jedoch unterschiedlich mit den Pins 7 oder 8 gebrückt. Vermutlich sind die Pins 7+8 Pullup Eingänge um bereits beim Booten ohne Kommunikation feststellen zu können,  ob ein Vorgänger/Nachfolger gesteckt ist.

Die zweite CAN Schnittstelle liegt auf den RJ45 Buchsen, welche auf der Batterie Frontplatte mit A/CAN und B/RS485  beschriftet sind. Die Pinbelegung der RJ45 Buchsen ist so gewählt, daß in den 8 pins das CAN und das RS485 Halbduplex Signal gleichzeitig aufgelegt werden kann. Ein Versuch mit Durchgangspiepser bestätigt, daß alle Pins der beiden Buchsen A und B 1:1 durchverbunden sind. Sie beinhalten sowohl die gleiche CAN wie auch die gleiche RS485 Schnittstelle wie auch irgendwas auf den pins 1,2,3.
Versuche ausstehend: Kabel an beiden Buchsen A / B sollten beliebig vertauschbar sein. RS485 sollte auch mit einem Spezial Y Kabel genutzt werden können wenn beide CAN belegt sind.

Als Folge ergibt sich hiervon:

1) Pylontech passt sowohl über CAN wie auch RS485 an entsprechende Wechselrichter
2) Bei WR Anschluss über CAN ist gleichzeitig FHEM über RS485 möglich
3) Bei WR Anschluss über RS485 ist kein FHEM Anschluss möglich weil das halbduplex Signal sonst mit dem WR kollidiert
4) Ebenso wie die WR über CAN oder RS485 angeschlossen werden können, ist auch der Anschluss über CAN oder RS485 an einen LV-Hub möglich.
5) Die LV-Hub Anschlussvariante über RS485 erfolgt in sternförmiger Verdrahtung von jedem Master einer Gruppe zum LV-Hub. Warum eine Gruppe hier nur 8 Batterien haben darf ist unklar.

6) Die LV-Hub Anschlussvariante über CAN fasst die Batteriegruppen in einem linearen CAN Bus zusammen. Durch die doppelte RJ 45 Buchsenbelegung auf B/RS485 ist es möglich, den A/CAN Anschuss des vorhergehenden Masters mit der B/RS485 Buchse des nachfolgenden Masters zu verbinden.

7) Der GND Pin der RJ45 Buchse ist der CAN Schnittstelle zugeordnet. Er darf deshalb nicht mit dem PE eines RS485 Gateways verbunden werden. Entstehen durch lange RS485 Leitungen Gleichtaktprobleme, so sollte der B Anschluss am Gateway über 680 Ohm mit PE verbunden werden.

8) Die Dip Schalter sind im US5000 User Manual und im Schnittstellenprotokoll unterschiedlich  beschrieben. Vermutlich ist die Beschreibung im User Manual falscher als die Protokollbeschreibung. Der verdrehte Einbau des Schalters auf der Frontplatte ist problematisch, die Beschreibungen dazu aber eine dreiste Frechheit.

8a) Der Dip Schalter 1 ist zweifelsfrei für die Baudrate der RS485 Schnittstelle zuständig.
Manual:             Oben = 115200   Unten 9600
RS485 Protokollbeschreibung:    Oben = 9600      Unten 115200



b) Beim DIP Schalter 2 ist noch nicht mal die Funktion klar.
US5000 (nicht 2/3000) Manual:   Can Terminierung (ein R lässt sich aber nicht auspiepsen)
RS485 Protokollbeschreibung:    Dip 2,3,4 ist 7 bit Gruppenadresse m=1-7 für den Master

Aus 8b) ergibt sich eine Batterieadresse m:n in einem LV Hub System. In jede Gruppe m passen 16 Batterien welche allerdings nicht 0 bis 15 sondern 1 bis 16 zählen.

Gruppenadresse m=0 ist einem System mit nur einer Gruppe vorbehalten.
Gruppenadresse m von 1 bis 7 ermöglichen maximal 6 Gruppen a 16 Batterien = 96 Batterien mit einem einzigen LV Hub.

Die LV Hubs haben ebenfalls einen 3 bit Adressschalter. Hier sind aber nur die Adressen 1-5 zur Nutzung beschrieben. Damit würden sich maximal 5x96=480 Batterien oder 0,24GWh mit einem zweistufigen LV-Hub bzw. 6 LV-Hubs ergeben.

Gleich noch ein Post und vielleicht ein Stück schlauer warum es bei mir nicht funktioniert:
Es gibt von Waveshare offensichtlich zwei verschiedene RS485->ETH Gateways die einen ziemlich unterschiedlichen Funktionsumfang in der FW haben.

1) RS485 TO ETH
https://www.waveshare.com/w/upload/6/6d/RS485-TO-ETH-user-manual-en.pdf

2) RS485 TO ETH (B)
https://www.waveshare.com/w/upload/8/86/RS485-TO-ETH-B-user-manual-en-v1.1.pdf

Das 2te ist die Hutschienenversion welche ich habe. Es sind aber ziemliche Unterschiede in den Protokollen. 2) scheint neuer zu sein, aber 1) kann auch was mit AT Kommandos was 2) definitiv nicht kann. Möglicherweise ist es mit dem RFC 2217 auch so? Das kommt aus alter Zeit wo AT Kommandos und Einwahlverbindungen über Hayes üblich waren. Da brauch nicht mehr suchen warum FHEM bei mir keine Verbindung hin kriegt sondern muß ein anderes Gateway bestellen?

Ich kann bei mir mal RFC 2217 ausschalten und das Ergebnis mitteilen. Aber erst morgen, habe heute keine Zeit dazu. Vllt. kann satprofi den Check auch mal machen.

LG

Weiter vorne in diesem Thread ist ein Post daß es ohne RFC2217 nicht funktioniert. Wie ich verstanden habe, ist RFC2217  dafür gut, daß über Eth die Einstellungen für Baudrate u.a. gemacht werden können was normal nicht über die seriellen Daten geht. Andererseits ist es vorteilhaft, wenn man dazu keinen Treiber für virtuelle COM Ports braucht.

Offensichtlich gibt es von Waveshare aber noch mehr RS485 auf ETH Konverter welche wiederum andere Funktionsumfänge haben. Hier eine Version die neben Modbus auch MQTT kann.
https://www.waveshare.com/wiki/RS232/485_TO_WIFI_ETH_(B)

Was soll "verbose 5" sein ? Eine ASCII Eingabe auf der RS485 welche dann wie oben antwortet?
Dazu müsste ich dann einen virtuell seriellen Port aufmachen und ein Terminal laufen lassen?
Oder geht das auch mit telnet?

Ich habe soeben das RS485 Gateway OHNE den Haken bei RFC2217 betrieben und ausprobiert. Läuft bei mir genauso einwandfrei wie mit RFC2217.

ZitatWas soll "verbose 5" sein ?

verbose 5 bedeutet, du solltest im Modul das Attribut verbose auf 5 setzen. Das ist die höchste Stufe für Ausgaben im Log und protokolliert so ziemlich alles was in der Kommunikation abläuft.

LG

Danke - verbose 5 ist ein Parameter bzw. Attribut für das Modul PylonTech (Sorry FHEM ist für mich  völlig neu). Beiliegend ein Screendump von meinen Modul Einstellungen und was im Logfile angezeigt wird.
Es sieht so aus als ob es schon auf der TCP/IP Ebene keinen Kontakt gibt?
Ist die Batterie Nr. 1 genau die Batterie Adresse wo auch das RS485 Gateway stecken muß ?
Falls ja, könnte man diese auch mit BatteryView in Erfahrung bringen?
Noch was zum Vergleichen: Der DIP Switch 1 steht oben und das sind 115kBaud

2024.08.18 20:51:54 4: pylon - start request cycle to battery number >1< at host:port 10.10.20.142:4001
2024.08.18 20:51:54 4: pylon - Cycle started in main process
2024.08.18 20:51:54 4: pylon - retrieve battery info: serialNumber
2024.08.18 20:51:54 4: pylon - request command (ASCII): ~20024693E00202FD2D
2024.08.18 20:51:54 5: pylon - request command (HEX): 7e3230303234363933453030323032464432440d
2024.08.18 20:51:55 3: pylon - Timeout in communication to RS485 gateway
2024.08.18 20:51:55 4: pylon - Socket/Connection to the RS485 gateway was closed

ZitatEs sieht so aus als ob es schon auf der TCP/IP Ebene keinen Kontakt gibt?

Ja, sehe ich auch so.

ZitatIst die Batterie Nr. 1 genau die Batterie Adresse wo auch das RS485 Gateway stecken muß ?

Ja, es ist im Stapel die oberste Batterie (wo der Link-Port frei ist) zumindest wenn ohne Gruppen gearbeitet wird.

Mir ist aufgefallen dass du den Port 4001 angegeben hast, aber in einem Bild weiter vorn ist der Port 4196 zu sehen?
Du kannst testweise auch das timeout Attribut weiter hoch setzen, glaube aber nicht das es daran liegt.

Grüße,
Heiko

Noch etwas ist mir aufgefallen. Die Adresse 10.10.20.158 ist als DNS-Server angegeben. Ich denke hier müßte 10.10.20.250 stehen, das Gateway ist i.A. auch der DNS-Server.
Ist der Waveshare eigentlich per ping vom FHEM-Rechner aus erreichbar? Dein IP-Adressbereich ist ziemlich umgewöhnlich, ist der korrekt?

Zitat von: DS_Starter am 18 August 2024, 22:38:02

ZitatEs sieht so aus als ob es schon auf der TCP/IP Ebene keinen Kontakt gibt?

Ja, sehe ich auch so.

ZitatIst die Batterie Nr. 1 genau die Batterie Adresse wo auch das RS485 Gateway stecken muß ?

Ja, es ist im Stapel die oberste Batterie (wo der Link-Port frei ist) zumindest wenn ohne Gruppen gearbeitet wird.

Mir ist aufgefallen dass du den Port 4001 angegeben hast, aber in einem Bild weiter vorn ist der Port 4196 zu sehen?
Du kannst testweise auch das timeout Attribut weiter hoch setzen, glaube aber nicht das es daran liegt.

Grüße,
Heiko

Seine erste def war
10.10.20.142:4196 1

Habe den Port mal zum Teste auf beiden Seiten von 4196 auf 4001 geändert. Trotzdem kein Erfolg.
 
Eigentlich sollte der Master (wo oben der Link Port frei ist) die Nr. 0 sein ?

Wenn bei mehreren Batterien in einer Gruppe die Adresse die Batterieadresse am Modul geändert wird, dann antwortet die Batterie mit der passenden Adresse (sofern sie physikalisch vorhanden ist) doch auch, wenn das Gateway auf einer anderen Batterie der gleichen Gruppe eingesteckt ist?

In Zeile 198 der Quellen liest man aber als Kommentare korrekt wie die  Gruppennummer funktioniert,
ohne daß eine solche Adresse akzeptiert werden würde. Ist das ein Feature für Version 2 ?

# ADR: n=Batterienummer (2-x), m=Group Nr. (0-8), ADR = 0x0n + (0x10 * m) -> f. Batterie 1 = 0x02 + (0x10 * 0) = 0x02

Ich verstehe auch noch nicht, woher aktuell die Beschränkung auf 14 Batterien 1 Master +13 Slaves kommt,
wo doch in einer Gruppe 16 Stück (mit 15 Link Kabel) akzeptiert werden.

Wenn ich eine Batterie ausbaue und ohne ohne weitere Verbindung einschalte (alle Dip SW oben), funktioniert dann die Kommunikation mit Fhem?

Eigentlich sollte der Master (wo oben der Link Port frei ist) die Nr. 0 sein ?
Lt. Pylon Doku beginnt die Adressierung des Master sogar mit "2".

(n)     Position
 2    Master battery
 3      Slave 1
 4      Slave 2
 5      Slave 3
...    ........
Damit es für den User nicht unlogisch wird, beginnen wir mit "1" und kodieren intern entsprechend.

ZitatWenn bei mehreren Batterien in einer Gruppe die Adresse die Batterieadresse am Modul geändert wird, dann antwortet die Batterie mit der passenden Adresse (sofern sie physikalisch vorhanden ist) doch auch, wenn das Gateway auf einer anderen Batterie der gleichen Gruppe eingesteckt ist?

Nein. Nach meinen Erfahrungen kommt es dann zum Timeout. Man muss das Gateway mit dem Master verbinden.

ZitatIn Zeile 198 der Quellen liest man aber als Kommentare korrekt wie die  Gruppennummer funktioniert,
ohne daß eine solche Adresse akzeptiert werden würde. Ist das ein Feature für Version 2 ?

? Wie gesagt Gruppen sind noch nicht implementiert da es bis jetzt an der Notwendigkeit und entspr. Tester gemangelt hat.

ZitatIch verstehe auch noch nicht, woher aktuell die Beschränkung auf 14 Batterien 1 Master +13 Slaves kommt,
wo doch in einer Gruppe 16 Stück (mit 15 Link Kabel) akzeptiert werden.

Ich habe einfach noch nicht die ganzen Kommandokodierungen für Batterien größer 14 implementiert. Mehr kann ich jederzeit hinzufügen wenn es Bedarf UND entsprechend Tester für die Implementierung gibt.
Die max. Akzeptanz ist übrigens vom Batterietyp abhängig. Andere Batterietypen akzeptieren ggf. weniger.

ZitatWenn ich eine Batterie ausbaue und ohne ohne weitere Verbindung einschalte (alle Dip SW oben), funktioniert dann die Kommunikation mit Fhem?

Das wird so sein wenn das Gateway richtig eingestellt ist und ordnungsgemäß arbeitet.

Hast du den Ping des Gateeway vom FHEM Rechner aus probiert?

Danke mal für die klaren Antworten.
Es fehlt zur Sicherheit noch eine: DipSwitch 1 oben = 115 kBaud auf RS485?

Den Ping hatte ich bislang nicht probiert, weil die http Oberfläche des Gateways nicht nur auf den gleichen Rechner sondern auch auf dem gleichen Browser wie FHEM bedienbar ist.
Habe ich jetzt aber nachgeholt: Der Ping ist 0,55mSec.

Am Testen solls nicht liegen. Ich habe 32 Stück US5000 in 2 Gruppen am LV-Hub. Außerdem eine lose BMS Platine mit vergeigter Firmware im Controller.
Solange die Wege hier im Forum so kurz sind, sollten wir auch dahinter kommen woran es liegen könnte.
Ich werde als nächstes mal probieren, das Gateway mit einem Treiber für virtuelle COM Schnittstelle einzurichten um zu sehen ob sich mit einem Terminal anstelle FHEM was tut.
Dann eine der Batterien vom Stack abgtrennen und neben dem FHEM Rechner einfach mal einzeln aufstellen. Das erhöht die Probiergeschwindigkeit wenn ich dazu nicht jedesmal in ein anderes Gebäude gehen muß.

> Noch etwas ist mir aufgefallen. Die Adresse 10.10.20.158 ist als DNS-Server angegeben.
> Ich denke hier müßte 10.10.20.250 stehen, das Gateway ist i.A. auch der DNS-Server.

10.10.20.158 ist der Rechner auf welchem momentan FHEM läuft.
10.10.20.250 ist mein Mikrotik Router im Netz wo das DHCP und den Internetzugang routet. 
Das 10.10.20.xxx Netz ist absichtlich und funktioniert ansonsten auch.
Ich habe hier auch zwei weitere baugleiche Waveshare RS485 Gateways als transparentes Pärchen laufen, weil mein Stromzähler in der Trafostation in einem anderen Gebäude ist.
In diesem Fall muss unter Destination IP/DNS die IP der Gegenstelle stehen damit sich das Gateway Pärchen findet.

Funktionieren die US5000 überhaupt mit FHEM modul? Schon mal mit batteryview eingeloggt?

ZitatFunktionieren die US5000 überhaupt mit FHEM modul?

Ja, wurde schon erfolgreich eingesetzt. Erfolgreiche Tests/Einsätze nehme ich in die Online-Hilfe als Referenz auf.

ZitatIn diesem Fall muss unter Destination IP/DNS die IP der Gegenstelle stehen damit sich das Gateway Pärchen findet.

Hmmm, ich habe die DNS Konfiguration mit den "Pärchen" zwar noch nicht verstanden, aber wenn du dir sicher bist dann ist es ja gut.

Es ist einfach die Destination IP des Waveshare TCP Clients der zum Waveshare TCP Server passt.
Auf beiden Seiten ist RS485, dazwischen TCP/IP über Glasfaser oder beliebige Physik.

Für FHEM nehme ich an, daß Waveshare auf TCP Server stehen muß.
Wegen dem habe ich da probiert die IP des Sytems von FHEM als Destination einzutragen.
Das braucht man aber vermutlich nicht, weil FHEM ja weis, auf welcher IP das Gateway ist,
wo die Daten abzuholen sind. Geht aber auch mit meiner Router Adresse 10.10.20.250 nicht und der Eintrag ist vermutlich Dont-Care.
Mit DNS Domain Name System hat das dann vermutlich nichts zu tun was vielleicht für irgendwelche anderen Gateway Modis relevant ist.

Zitat von: Janvi am 19 August 2024, 19:31:01Danke mal für die klaren Antworten.
Es fehlt zur Sicherheit noch eine: DipSwitch 1 oben = 115 kBaud auf RS485?


Dann eine der Batterien vom Stack abgtrennen und neben dem FHEM Rechner einfach mal einzeln aufstellen. Das erhöht die Probiergeschwindigkeit wenn ich dazu nicht jedesmal in ein anderes Gebäude gehen muß.

versuche doch mal , den Waveshare an einem Pack mit freiem RS485 Port anzuschliessen, und dann die adresse nur durchzutesten. Wenn am 2. Pack, dann versuch adresse 2 zu definieren, vielleicht bekommst dann verbindung.


noch was, habe gerade im iobroker forum gelesen das man vircom benötigt, da im webif nicht alles einstellbar ist.

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

Aber: Das Modul bringt noch eine andere Fehlermeldung. Das sind:

Timeout reading data from battery
No connection to RS485 gateway established wenn die Ports auf beiden Seiten verschieden eingestellt sind.

Das könnte eigentlich ein Hinweis sein, daß ein Problem auf der RS485 Seite vorliegt.
Wie war das mit der Baudrate 115k und Dipschalter oben?

Vircom habe ich schon zum Aufsezten benutzt. Es hat noch ein paar weitere Einstellungen wo ich annehme, daß diese nicht relevant sind?
Beiliegend meine Einstellungen in Vircom. 
10.10.20.145 und 153 sind das transparente Client/Server Pärchen welches noch im Netz ist.
Die Device Settings sind für das Pylon Modul aufgeklappt. Hier sieht man auch, daß die NetMask, Gateway und Dest.IP/Domain(DNS) ausgegraut sind,
sobald der Work Mode TCP Server ist. Das ist ein weiterer Hinweis, daß diese Einstellungen in der http Oberfläche in dem Fall dont care sind.
Im Advanced Tab sind Multi-Host Einstellungen aber ich wäre schon froh wenn es mit einem einzigen Host funktioniert.

Als nächstes steht der Ausbau einer einzelnen Batterie an. Das mach ich aber erst wenn ich einen Helfer mit Abitur für die 40kg Gewicht habe.
 

Die dip schalter sollten alle off sein, bei einigen baureihen verkehrt eingebaut, wegen "oben".

ZitatHabe 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".

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

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.

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

Das Protokoll sieht gut aus. So soll es sein.

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.

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.

AnalogReq.bmp

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

AnalogResp.bmp

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.

Tel3.bmp

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)

bat16.PNG

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.


 
   




 

bei rs485 Verbindung beginnt 1. Batterie mit addr 2

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

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.








 


   

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?

@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

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

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

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:



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






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.

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.

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.

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

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?

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.

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

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

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.

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?

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.

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?

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.
 

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

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

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.

Herzlichen Glückwunsch :)

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.

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

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.

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

 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

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  (http://www.multisibcontrol.net/)ausprobieren

Zitat von: DS_Starter am 24 August 2024, 10:41:09Ich 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  (https://lichtex.de/mediafiles/Dokumente/PylonTech/Lithium%20Speichersystem%20US2000C_US3000C%20/US3000C_Bedienungsanleitung_DE_V1.3.pdf) 
 Manual US2000B+ (https://midsummerwholesale.co.uk/pdfs/pylon-us2000b-plus-v2-manual.pdf)
Manual US2000C (https://atersa.shop/app/uploads/2021/03/US2000C-Product-Manual-V1.0-20CPSV0901-.pdf?srsltid=AfmBOoqjKIBITdbn_LmbFc0IESm5gi6yBQNOLoVuB4HBh9Is1feUau4o)

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.

Zitat von: DS_Starter am 24 August 2024, 11:03:14Ja 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.

Zitat von: Janvi am 24 August 2024, 10:30:54Auf 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.

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 (https://de.wikipedia.org/wiki/OSI-Modell) 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

 

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:

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:

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


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.

ZitatSerialNr, 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. 

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.

Zitata- Fhem kann die Daten irgendwo an einem CAN Gateway abgreifen.

An der Stelle bin ich raus.

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

Damit wären wir weiter im Spiel.

Auch nach Stunden bucht der LV-Hub noch einen der beiden Gruppen unerwartet aus wenn Fhem mitläuft bzw. ein Steuerpin unterbrochen ist. Wurde diesmal sogar an den Leds richtig angezeigt. Macht also auch keinerlei Sinn und ich habe wieder zurückgesteckt. Etwa die gleiche Beobachtung wie schon gestern nur etwas später. Möglicherweise werden zusätzlich zu CAN gelegentlich noch irgenwelche Steuerdaten über RS485 zwischen den Mastern übermittelt, was dann ein Schwebungsproblem mit Fhem ergibt bei welchem es dann irgendwann kracht. Schade, aber Pylons kommen eben aus China und da wird sich nix tun. Nach Zurückstecken des 1:1 Kabels hat es 3x gepiepst und der Hub hat selbstständig wieder auf 2 Gruppen umgeschaltet und weitergemacht.

Bleibt zu hoffen, daß die Pylons bei der Zellchemie nicht genauso gemurkst haben. So ganz wohl ist mir natürlich mir nicht solche Teile ins Zimmer zu stellen. Mein Kapazitätstest heute nacht war leicht über der erwarteten Berechnung. Alternativen (mit JK-BMS) gibt es wohl auch kaum da Pylon eine der am besten funktionierenden Batterien ist. JK-BMS kann das Pylon Protokoll emulieren, macht dabei aber auch Fehler wie Andy von der Off Grid Garage in einem seiner jüngsten Videos festgestellt hat (https://www.youtube.com/watch?v=yAVGzT3Do-4).

Hast du mal das neue Attr waitTimeBetweenRS485Cmd ausprobiert und auf >1s gestellt? Möglicherweise ist diese Pausezeit wichtig da sie explizit beim Multigruppenbetrieb erwähnt ist wie ich gelesen habe.

Nein, ich habe deine neue Version noch nicht installiert. Ich weis auch nicht, wie der Multigruppenbetrieb auf RS485 funktionieren soll. Wenn der Hub als RS485 an den Master angebunden ist, kann nicht gleichzeitig auch noch ein Gateway die Request Telegramme losschicken. Beide Instanzen sind in keiner Weise synchronisiert. Solange die Inhalte der Request Telegramme gleich sind, merkt die Master Batterie nicht von wem die kommen. Aber es ist auch bei längeren Wartenzeiten zwischen den Telegrammen immer nur eine Frage der Zeit bis es kracht. Das liegt daran, daß das Protokoll ein Punkt zu Punkt Protokoll ist wo es keinen zweiten Master geben kann.

Man kann im RS485 Hub Betrieb also nur hören und sieht dann auch die Request Telegramme vom Hub inklusiv der darauf folgenden Antwort von der Batterie. Wenn der Hub aber nicht alles abfrägt - Pech für Fhem. Oder man schaut auf die typsichen Pausen zwischen den Abfragen des Hubs ob man zu einem unverdächtigen Zeitpunkt  zusätzlich eine eigene einschieben kann. Sauber ist das aber in keiner Weise und eine langsamere Abfrage macht nur die Wahrscheinlichkeit geringer bis es zu einer Kollision kommt.

Frage, du benötigst den hub wegen can verbindung zum cerbo, oder?
Sonst könntest du mal nur rs485 ohne lv hub zu testen.

Ja, aber ich glaube der Cerbo kann auch RS485. Nennt sich dort VE Bus. Hat ein eigenes Protokoll und ist zur
Verbindung der Multiplus untereinander bereits belegt. Darf man wohl auch nichts anderes dran machen.
Würde aber auch nichts helfen, ausser daß ich einen nutzlosen Hub übrig habe.
Denn auch dann wären zwei Instanzen welche eine Batterie auf der gleichen RS485 abfragen möchten.
Es geht bei euch nur deshalb, weil es zum Cerbo per CAN geht und Pylon die RS485 ausserdem nebenbei bedient.
Sobald ein Hub dabei ist, geht das nicht mehr, weil die RS485 mutmaßlich noch zu irgendwas zwischen den Gruppen missbraucht wird.
Wenn man das per Leitungsunterbrechnung unterbindet, geht es eine Zeit lang bis der Hub merkt daß was faul ist.
Entweder geht er dann ganz auf Fehler oder er bucht einen der beiden Gruppen aus. Nützt also nicht wirklich was.

Nachfrage zu den 3 adern auf 0, hast du die auf ground gelegt oder nur getrennt? Was ich aus regelungstechnik kenne , ist 0 immer ground. Offen ist immer unbestimmter zustand.

Ich könnte mir vorstellen, dass in solchen Fällen ein RS485 Splitter/Verteiler wie einer von denen (https://ewimar.de/category/dystrybutory-rs485) helfen könnte um die Informationen der Batterie einmal zum LV-Hub und auch zum RS485 Gateway zu verteilen, bzw. andersherum die Befehle von beiden Quellen zur Batterie zu übertragen.
Aber nur Theorie ...

Die Leitungen habe ich nur getrennt. Die Dioden gehen ja auch auf GND oder den ehemaligen GND. Vermutlich gibt es zu den Einängen irgendwo einen Pullup. Am Hub schreibt Pylon ja selbst vor, daß die pins 1-3 nicht verbunden sein dürfen. Als Nächstes wäre mal dran nachzugucken was sich auf den Signalen tatsächlich tut oder ob sie die ganze Zeit nur einen Pegel haben.  Eigentlich lohnt es aber nicht sowas verstehen zu wollen weil es klar ist, daß es kein sauberes Design ist. 

Die von @DS_Starter verlinkten Splitter sind HW Splitter für differentielle Signale. Die machen einen Sinn, wenn sich bei einem Bussystem mit mehreren Teilnehmern kein linearer Bus aufbauen lässt sondern eine Abzweigung benötigt wird. Die Abzweigung würde auf dem Signal Reflexionen erzeugen. Um die mit einem getrennten Widerstand terminieren zu können, nimmt man einen Splitter der mit einem Treiberbaustein elektrisch so tut, als ob die Leitung an der gesplitteten Stelle anfängt.

Auf der Protokollebene hilft das aber überhaupt nicht. Da geht es um Kollisionsvermeidung damit nicht 2 Teilnehmer gleichzeitig senden. Falls doch, muß dies erkannt und zur Korrektur wiederholt werden. Fehlerkorrektur ist schon an einer Punkt zu Punkt Verbindung nicht ganz trivial. Zum Beispiel das Protokoll von  Siemens RK3964 (https://de.wikipedia.org/wiki/3964R) ist schon uralt und macht das ausserordentlich robust. Punkt zu Multipunkt, also ein Master mit mehreren Slaves ist etwas anspruchsvoller. Trotzdem gibt es genug freie Protokolle die das machen und an denen man sich orientieren kann bevor man meint etwas Eigenes erfinden zu müssen. Modbus RTP ist das bekannteste. CAN bietet gegenüber RS485 dann noch an wesentlichen Punkten eine Hardwareunterstützung welche die SW deutlich vereinfacht. Das sind HW Vergleicher welche auf die 11 oder 28 bit Identifier reagieren. Ein Teilnehmer kriegt dann nur noch die Telegramme mit, welche für ihn bestimmt sind. Auf RS485 müsste man hingegen alle eingehenden Telegramme auswerten und nachschauen ob der Inhalt die eigene Adresse betrifft. Es gibt auch Broadcasts welche alle Teilnehmer am Bus lesen können. Die Empfangsquittierungen gehen mit dem Acknowledge Slot per Hardware, so daß der Master automatisch mitkriegt, wenn der angesprochene Slave vom Bus entfernt wurde. Multimaster mit entsprechenden Verriegelungen und selbstadressierende Teilnehmer welche man nicht konfigurieren muß, Sicherheitsfeatures beim Ausfall eines Teilnehmers wurde alles schon mehrfach erfunden. Allerdings sind die Beschreibungen meist unter Verschluss. Für CanOpen muß man Mitglied beim CiA (Can in Automation) sein. Die NMEA2000 (https://de.wikipedia.org/wiki/NMEA_2000) arbeitet mit den 29bit CAN Identifiern, ist im Bootsbereich für Kompass, Radar usw. weit verbreitet. Auch bei Victron gibts einen Treiber dafür. Die Spec dafür kostet zum Download aber schlappe 500 USD. Eine Zertifizierung von einem Produkt kostet dann noch extra bis man den Namen des Protokolls draufschreiben darf. Das alles nur um eine Kompabilität zu haben um jedem Käufer den Tausch mit einem Mitbewerber Produkt problemlos zu ermöglichen. Deshalb hält sich die Motivation für ein vernünftiges Protokoll bei vielen Herstellern in Grenzen.

Das mit der waitTimeBetweenRS485Cmd werde ich mal nachlesen und ausprobieren. Kann sein, daß sie damit etwas getrickst haben um Kollisionen zwischen zwei anfragenden Instanzen zu umgehen. Der Master wartet ob er in der Zeit jemand anderes hört. Falls ja, weis er daß er anschliessend diese Zeit hat um einen eigenen Request zu machen.






 

Hallo.
Habe heute Modul upgedated, und jetzt keine Verbindung mehr zu Battery höher 8 . Was muss man jetzt neu definieren? group=0 hab ich dazu

LG

Hi,

nichts. Es gibt in der Logik keine Einschränkungen außer bei der Definition.
Hoffe ich habe mich bei der Gruppenkalkulation mit Bat > 8 nicht vertan.
Verbose 5 des Devices mal checken.

LG

Hallo, ich wollte mal fragen ob ich das Modul auch über einen rs485 to Usb Adapter ansprechen kann oder ob ich zwingen einen wafeshare Adapter benötige?

Ich habe für einen sdm630 das modbus modul am laufen und dachte ich kann das alles zusammen auf diesem Wege einfangen.

Hallo, ein Wafeshare muss es nicht sein, aber ein TCP/IP zu RS485 Adapter. D.h. USB Adapter gehen leider nicht.

Schade, ich habe einen USB Adapter im Betrieb an dem ich meinen Deye Wechselrichter auslese, wäre ja schön gewesen dort noch den Akku gleich mit anzuschließen.

Zitat von: Wzut am 20 August 2023, 18:57:16

Zitat von: DS_Starter am 04 Mai 2023, 16:07:23ich lese zur Zeit die Pylontech via Cerbo GX (Victron) mit MQTT aus.
Es fehlen allerdings die Werte für /History/DischargedEnergy bzw. /History/ChargedEnergy.

Ich habe seit Januar einen Victron MP + Pylontech US5000 + US3000 + RPi mit Venus OS am Start.
Die Batterien sind via CAN Bus Adapter am RPi angebunden und ich lese nicht via MQTT sondern Modbus aus ( da gibt es die beiden fehlenden Werte DischargedEnergy / ChargedEnergy.
Ich würde gerne mal deine Version testen, wie hast du die Pylontechs angebunden da in deinem Sreenshot eine IP steht. ( RS485 Adapter auf LAN ? )

Hallo WZut,
ich lese meinen Cerbo GX auch über Modbus, allerdings mit Loxone. Laut Victron sollte DischargedEnergy im Input Register Addr 301 und ChargedEnergy auf Addr 302 liegen. Da kommt aber bei mir nix, auch im ModbusDoctor nicht. Hast Du vielleicht andere Register gefunden, wo was drinsteht?

Gruß Roland

ich lese folgende 5 Register vom Device 239 (Multiplus) :
attr Multiplus obj-h74-reading AC-In1_to_AC-out
attr Multiplus obj-h76-reading AC-In1_to_battery
attr Multiplus obj-h86-reading Battery_to_AC-In1
attr Multiplus obj-h90-reading Battery_to_AC-out
attr Multiplus obj-h92-reading AC-out_to_batteryVon welcher Device iD liest du ? Ich finde das von Victron saublöd gemacht mit denen vielen Ids in einem Gerät. Bei mir hat der MP2 die ID 239 und die Pylontechs 225.

Bei mir sind Geräte-IDs:
- 40: com.victronenergy.grid und .pvinverter
- 225: .battery
- 227: .veBus
- 100: .hub4 und .system

Charged und Discharged sollten unter Battery auf 301 und 302 stehen, sind aber leer bzw. 0. Der MultiPlus hat bei mir keine eigene Modbus Geräte-ID. Muß man auf dem MP Modbus erst aktivieren? Ich dachte, der Cerbo kriegt vom MP alles über vebus,

Gruß Roland

Der MP steckt wohl hinter ID 227 vebus. Momentan lese ich folgende Register:
(Title und ModbusAddress)
<?xml version="1.0" encoding="utf-8"?>
<Modbus Title="Venus GX vebus" Comment="" HintText="" Channel="246">
<Info templateType="7" minVersion="14051207"/>
<ModbusCmd Title="Battery voltage" Comment="" HintText="" ModbusAddress="26" ModbusCmd="4" ModbusPollingCycle="5" Unit="&lt;v.2&gt; V" Analog="true" Sensor="true" SourceValHigh="10" DestValHigh="0.1"/>
<ModbusCmd Title="Input power 1" Comment="" HintText="" ModbusAddress="12" ModbusCmd="4" ModbusDataType="1" ModbusPollingCycle="5" Unit="&lt;v&gt; W" Analog="true" Sensor="true" SourceValHigh="10" DestValHigh="100"/>
<ModbusCmd Title="Input power 2" Comment="" HintText="" ModbusAddress="13" ModbusCmd="4" ModbusDataType="1" ModbusPollingCycle="5" Unit="&lt;v&gt; W" Analog="true" Sensor="true" SourceValHigh="10" DestValHigh="100"/>
<ModbusCmd Title="Input power 3" Comment="" HintText="" ModbusAddress="14" ModbusCmd="4" ModbusDataType="1" ModbusPollingCycle="5" Unit="&lt;v&gt; W" Analog="true" Sensor="true" SourceValHigh="10" DestValHigh="100"/>
<ModbusCmd Title="Output power 1" Comment="" HintText="" ModbusAddress="23" ModbusCmd="4" ModbusDataType="1" ModbusPollingCycle="5" Unit="&lt;v&gt;W" Analog="true" Sensor="true" SourceValHigh="10" DestValHigh="100"/>
<ModbusCmd Title="Output power 2" Comment="" HintText="" ModbusAddress="24" ModbusCmd="4" ModbusDataType="1" ModbusPollingCycle="5" Unit="&lt;v&gt;W" Analog="true" Sensor="true" SourceValHigh="10" DestValHigh="100"/>
<ModbusCmd Title="Output power 3" Comment="" HintText="" ModbusAddress="25" ModbusCmd="4" ModbusDataType="1" ModbusPollingCycle="5" Unit="&lt;v&gt;W" Analog="true" Sensor="true" SourceValHigh="10" DestValHigh="100"/>
<ModbusCmd Title="Battery current" Comment="" HintText="" ModbusAddress="27" ModbusCmd="4" ModbusDataType="1" ModbusPollingCycle="5" Unit="&lt;v.1&gt;A" Analog="true" Sensor="true" SourceValHigh="10" DestValHigh="1"/>
<ModbusCmd Title="VE.Bus state of charge" Comment="" HintText="" ModbusAddress="30" ModbusCmd="4" ModbusPollingCycle="5" Unit="&lt;v.1&gt;%" Analog="true" Sensor="true" SourceValHigh="10" DestValHigh="1"/>
<ModbusCmd Title="Switch Position" Comment="" HintText="" ModbusAddress="33" ModbusCmd="4" ModbusPollingCycle="5" Unit="&lt;v&gt;" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS power setpoint phase 1" Comment="" HintText="" ModbusAddress="37" ModbusCmd="4" ModbusDataType="1" ModbusPollingCycle="5" Unit="&lt;v&gt;W" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS disable charge flag phase" Comment="" HintText="" ModbusAddress="38" ModbusCmd="4" ModbusPollingCycle="5" Unit="&lt;v&gt;" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS disable feedback flag phase" Comment="" HintText="" ModbusAddress="39" ModbusCmd="4" ModbusPollingCycle="5" Unit="&lt;v&gt;" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS power setpoint phase 2" Comment="" HintText="" ModbusAddress="40" ModbusCmd="4" ModbusDataType="33" ModbusPollingCycle="5" Unit="&lt;v&gt;W" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS power setpoint phase 3" Comment="" HintText="" ModbusAddress="41" ModbusCmd="4" ModbusDataType="1" ModbusPollingCycle="5" Unit="&lt;v&gt;W" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="Disable PV inverter" Comment="" HintText="" ModbusAddress="56" ModbusCmd="4" ModbusPollingCycle="5" Unit="&lt;v&gt;" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="VE.Bus BMS allows battery to be charged" Comment="" HintText="" ModbusAddress="57" ModbusCmd="4" ModbusPollingCycle="5" Unit="&lt;v&gt;" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="VE.Bus BMS allows battery to be discharged" Comment="" HintText="" ModbusAddress="58" ModbusCmd="4" ModbusPollingCycle="5" Unit="&lt;v&gt;" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="VE.Bus Reset" Comment="" HintText="" ModbusAddress="62" ModbusCmd="4" ModbusPollingCycle="5" Unit="&lt;v&gt;" Analog="true" Sensor="true" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="Maximum overvoltage feed-in power L3" Comment="" HintText="" ModbusAddress="68" ModbusCmd="6" Unit="&lt;v&gt;W" Analog="true" Sensor="false" SourceValHigh="1000" DestValHigh="10"/>
<ModbusCmd Title="Maximum overvoltage feed-in power L2" Comment="" HintText="" ModbusAddress="67" ModbusCmd="6" Unit="&lt;v&gt;W" Analog="true" Sensor="false" SourceValHigh="1000" DestValHigh="10"/>
<ModbusCmd Title="Maximum overvoltage feed-in power L1" Comment="" HintText="" ModbusAddress="66" ModbusCmd="6" Unit="&lt;v&gt;W" Analog="true" Sensor="false" SourceValHigh="1000" DestValHigh="10"/>
<ModbusCmd Title="Fee DC overvoltage into grid" Comment="" HintText="" ModbusAddress="65" ModbusCmd="6" Unit="&lt;v&gt;" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="VE.Bus Reset" Comment="" HintText="" ModbusAddress="62" ModbusCmd="6" Unit="&lt;v&gt;" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="Disable PV inverter" Comment="" HintText="" ModbusAddress="56" ModbusCmd="6" Unit="&lt;v&gt;" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS power setpoint phase 3" Comment="" HintText="" ModbusAddress="41" ModbusCmd="6" ModbusDataType="1" Unit="&lt;v&gt;W" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS power setpoint phase 2" Comment="" HintText="" ModbusAddress="40" ModbusCmd="6" ModbusDataType="1" Unit="&lt;v&gt;W" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS power setpoint phase 1" Comment="" HintText="" ModbusAddress="37" ModbusCmd="6" ModbusDataType="1" Unit="&lt;v&gt;W" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS power setpoint phase" Comment="" HintText="" ModbusAddress="39" ModbusCmd="6" Unit="&lt;v&gt;" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="ESS disable charge flag phase" Comment="" HintText="" ModbusAddress="38" ModbusCmd="6" Unit="&lt;v&gt;" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="Switch Posistion" Comment="" HintText="" ModbusAddress="33" ModbusCmd="6" Unit="&lt;v&gt;" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
<ModbusCmd Title="VE.Bus state of charge" Comment="" HintText="" ModbusAddress="30" ModbusCmd="6" Unit="&lt;v&gt;%" Analog="true" Sensor="false" SourceValHigh="100" DestValHigh="100"/>
</Modbus>

.vebus ist bei mir halt 239
von .battery 225 lese ich 6 Register wobei nur 259, 261, 262 und 266 sinnvolle Werte enthalten.
301 & 302 liefern auch bei mir immer nur 0

Zitat von: Wzut am 27 November 2024, 12:11:24301 & 302 liefern auch bei mir immer nur 0

Bei mir auch. Das liegt wohl daran, dass die Pylontechs eben die Werte des Pylontech-BMS nicht an den Multiplus senden.

Es gibt einen workaround battery-energy-meter für pylontech. Das Vorgehen ist auf github beschrieben. Man muss eine battery-energy-meter.py auf dem Cerbo einspielen und dann laufen lassen. Nicht trivial und man muss sich vorher superuser Berechtigungen auf dem Victron einrichten!

Ich behelfe mir mittlerweile mit den AcIn1ToInverter und InverterToAcIn1 die ich aus dem Modbus bekomme.
Dazu ein device statistics angelegt und ich habe alle Werte mit Stunden, Tages, Monats und Jahresbasis.

Wenn man sich ansehen will, welche Werte von den einzelnen Geräten an Fhem übertragbar sind, empfehle ich den MQQT Explorer. Dort kann ich nicht nur die Bezeichnungen sehen, sondern auch die aktuellen Werte. Somit lassen sich auch die Readings umbauen zu writings (publish) und die victron steuern.

Hallo.
Frage zum Modul, klappt damit US5000 auch?
lG

ZitatFrage zum Modul, klappt damit US5000 auch?

Ich selbst habe keine US5000, aber es wurde der erfolgreiche Einsatz mit US5000 berichtet, weswegen ich in der Hilfe zum Modul die Info aufgenommen habe:

Modul zur Einbindung von Niedervolt-Batterien mit Batteriemanagmentsystem (BMS) des Herstellers Pylontech über RS485 via RS485/Ethernet-Gateway. Die Kommunikation zum RS485-Gateway erfolgt ausschließlich über eine Ethernet-Verbindung.
Das Modul wurde bisher erfolgreich mit Pylontech Batterien folgender Typen eingesetzt:

    US2000
    US2000B Plus
    US2000C
    US2000 Plus
    US3000
    US3000C
    US5000

Weiterin sind im Code die Eigenheiten von Batterien dieser Leistungsklasse eingebaut, die in der mir vorliegenden Protokollspezifikation beschrieben sind (ist aber schon älter).
Sollte also funktionieren.

LG,
Heiko