Modul PylonTech

[DS_Starter]

Hallo zusammen,

ich habe in meiner Pylontech Gruppe 0 eine weitere Batterie hinzugefügt, die nun die Adresse 9 (intern 10 = 0A hex) bekommen hat. Dadurch habe ich festgestellt, dass die Adressen ab 9 nicht funktionierten und konnte den Fehler lokalisieren sowie beheben. Nun klappt es auch mit Addr 9 und höher.

Das Update ist morgen früh wie gewöhnlich über FHEM update verfügbar.

LG,
Heiko

[satprofi]

hallo.
was meinst du mit "ab 9 " funktioniert es nicht? habe selbst 11 units, und alles klappt.

[DS_Starter]

Ich hatte bisher 8 US3000C Batterien, also Adresse 1-8 im DEF des Moduls.
Jetzt kam eine weitere US3000C hinzu, d.h. Adresse 9. Die Adressierung hat nicht mehr funktioniert.
Möglicherweise hängt der Erfolg von der FW des Masters ab. Bei mir ist es die 2.4

Grüße,
Heiko

[satprofi]

aber dein modul konnte doch mind. 14 packs, komisch

[DS_Starter]

Ja, und es war nur eine Kleinigkeit. Die Adresse 10 (0A) wurde in der bisherigen Version als 0a übertragen.
Meine hinzugefügte Batterie als Master eingesetzt hat das nicht akzeptiert und will uppercase Hex, also 0A usw.
Das war alles. Ich tippe auf Firmware Thematik.

[DS_Starter]

Hallo zusammen,

längere Zeit ist hier nichts passiert.
Doch jetzt habe ich ein Update eingecheckt welches morgen früh verfügbar sein sollte.
Es enthält:

16.08.2026 Rev. 31571

- Ersatz der gegenseitigen 'Busy-Loop'- und 'Random-Retry'-Mechanismen durch eine FIFO-Warteschlange pro Gateway (im Bereich Host:Port)
- sofortige Übergabe an das nächste wartende Gerät statt einer zufälligen Verzögerung, deaktivierte/gelöschte Geräte werden übersprungen
- neuer Befehl 'listQueue' zum Abrufen des aktuellen Warteschlangenstatus
- neue Readings cellVoltageMax, cellVoltageMin, cmdChainDuration
- Slider für waitTimeBetweenRS485Cmd angepasst


Wenn man mehrere Batterien und somit mehrere Devices in FHEM definiert hat, gab es bisher einen 'Random-Retry'-Mechanismus um die Kommunikation mit dem Gateway sicherzustellen. Dies hatte unter Umständen einen nicht determinierten Aktualisierungsintervall zu Folge.
Die neue Implementierung der Queue behebt dieses Manko.
Insbesonder das neue Reading cmdChainDuration lässt die Dauer der Kommunikation zur Batterie für einen kompletten Abfragezyklus abschätzen und somit entscheiden ob es Sinn macht timeout<1 Sekunde zu setzen um ohne BlockingCall zu arbeiten.

Bei mir liegt dieser Wert bei 0.049s. Das Attr timeout habe ich nun auf 0.3 für alle PylonLowVoltage-Devices gesetzt.

LG,
Heiko