neue Versionen pymodbus

[Cannon]

Leider wurden wieder grundsätzliche Dinge in pymodbus geändert. Das bedeutet, dass die meisten Plugins mit pymodbus ab Version 3.3.0 nicht mehr laufen werden. Ich hatte ja schon den Workaround von Version 2 auf Version 3 eingebaut. Genau dieser Workaround funktioniert ab 3.3.0 nun nicht mehr, da die elementare Versionsermittlung verändert wurde. Das ist sehr ärgerlich, aber lässt sich nicht ändern.

Was bedeutet das nun konkret?

Sobald jemand ein Plugin einsetzt, welches pymodbus >= 3.3.0 einsetzt müssen die anderen Plugins angepasst werden. Das wird auf jedem Fall bei meinen huawai-sun2000-Plugin der Fall sein.

Die entscheidende Frage die jetzt zu stellen ist, ob wir nicht generell Version 2 auslaufen lassen und dann nur noch die neue Version nutzen? Spätestens mit SmartHomeNG in Version 1.10 ist Python 3.8 sowieso nur noch die kleinste unterstützte Version und die Python-Version war ja bisher der Grund des Workarounds.

Die Plugins wurde ich dann ggf. wieder anpassen.

[Tom Bombadil]

Danke für die Info! Das fängt langsam an, ernsthaft zu nerven.

Gilt das 'geht nicht mehr' auch für die Versionsermittlung mittels Holzhammermethode (try/except), wie ich sie im Trovis-Plugin verwende?

try:   # Modbus rtu/serial, for pymodbus3+ or pymodbus2.x
    from pymodbus.client import ModbusSerialClient
except:
    from pymodbus.client.sync import ModbusSerialClient

try:   # Modbus tcp, for pymodbus3+ or pymodbus2.x
    from pymodbus.client.tcp import ModbusTcpClient
except:
    from pymodbus.client.sync import ModbusTcpClient

Oder nur für die explizite Versionsprüfung, wie sie in diverse andere Plugins nachträglich implementiert wurde?

if pymodbus_baseversion > 2:
    # for newer versions of pymodbus
    from pymodbus.client.tcp import ModbusTcpClient
else:
    # for older versions of pymodbus
    from pymodbus.client.sync import ModbusTcpClient

Was wurde denn konkret geändert? Wenn ich Dich richtig verstanden habe, nur die Abfrage der Version (pymodbus_baseversion = int(version.short().split('.')[0])), aber nicht der Import selbst, oder?

/tom

[Cannon]

Gilt das 'geht nicht' auch für die 'alternative' Versionsermittlung mittels try/except, wie ich sie verwende?

So wie bei dir sollte es eigentlich gehen. Geänderte wurde das Versionsmanagement", wie das konkret umgesetzt wurde weiß ich nicht, aber zumindest existiert diese Versionsdefinition im Code nicht mehr. Aber spätestens wenn du >= Python 2.7 einsetzt, wird die alte Modbus-version sowieso nicht mehr offiziell unterstützt.

Und da stellt sich die Frage, ob dann nicht irgendwann ein harter Wechsel sinnvoll wäre.

Das fängt langsam an, mich ernsthaft zu nerven.

Mich auch, weil man elementare Dinge ändert. Aber ist halt so, wie es ist.

[Tom Bombadil]

Ok, danke.
Ich lass das jetzt erstmal so - falls es knallt: 'Bescheid!'

/tom

Nachtrag: Hier die Änderungen aus #1522.

[bmx]

Es gibt wieder Spaß in diesem Thema. Ich habe heute mal frisch installiert und prompt einen Fehler mit pymodbus 3.8.x bekommen. Es wurde wieder am API geschraubt.
Das betrifft vermutlich folgende Plugins:

(Auszug aus requirements/all.txt):

# plugin 'trovis557x'
pymodbus>=2.2.0

# plugin 'helios_tcp'
pymodbus>=2.3,<3.0;python_version<'3.8'

# plugin 'helios_tcp'
pymodbus>=3.0.2;python_version>="3.8"

# plugin 'pluggit'
# plugin 'modbus_tcp'
# plugin 'kostalmodbus'
# plugin 'ksemmodbus'
# plugin 'sma_mb'
pymodbus>=3.5.2;python_version>='3.8'
​

Der Fehler dazu lautet im Falle des Plugins modbus_tcp

2025-01-11 18:57:41 ERROR plugins.modbus_tcp something went wrong in the poll_device function: ModbusClientMixin.read_holding_registers() takes 2 positional arguments but 3 positional arguments (and 1 keyword-only argument) were given
​

[henfri]

Ich verstehe nicht, warum es so schwer ist, die API kompatibel zu halten...

[Cannon]

Es gibt wieder Spaß in diesem Thema. Ich habe heute mal frisch installiert und prompt einen Fehler mit pymodbus 3.8.x bekommen. Es wurde wieder am API geschraubt.
Das betrifft vermutlich folgende Plugins:

Ich hatte kürzlich auch alles frisch installiert, mir aber über pymodbus keine Gedanken gemacht gehabt. Bei mir läuft aktuell 3.6.9. Mit 3.8 war aber zumindest pluggit schon getestet. Ich schaue mir das mal an, was da ggf. geändert wurde.

Ich verstehe nicht, warum es so schwer ist, die API kompatibel zu halten...

Weil offensichtlich das Programmiererteam auf Abwärtskompatibilität keine Rücksicht nimmt, als gäbe es nur die aktuelle Version und nichts davor. Aus den Erfahrungen in den letzten Jahren sind viele Änderungen, die Änderungen am Code bei uns erforderten, sicherlich auch anders umsetzbar gewesen.

[Cannon]

Ich habe mir das mal angeschaut. Also alle Versionen ab 3.8 gehen nicht, vielleicht sogar auch 3.7, was ich nicht getestet habe. Die Versionen 3.6.x laufen aber noch. Da aber die huawei-solar-lib ohnehin pymodbus<3.7,>=3.6.8 braucht, würde ich zumindest für die pluggit das auch so einstellen: pymodbus>=3.5.2,<3.7;python_version>='3.8'. Das wird aber sicherlich alle anderen Plugins, außer evtl. helios_tcp, genauso betreffen. Wie handhaben wir das da?

[Tom Bombadil]

Ich kann nicht mehr aktiv helfen, da ich kein produktives shNG mehr im Einsatz habe, und meine >2 Jahre alte 'eingefrorene' Version (ohne Internetverbindung) nicht anfassen werde, da sie fehlerfrei läuft; und das soll auch so bleiben. Soweit ich das verstehe, sind aber folgende Änderungen notwendig (es ist jeweils count= vor der bereits vorhandenen Anzahl der zu lesenden Register/Coils hinzuzufügen; so wird aus dem Positional Argument ein Keyword Argument):

# Funktionscode 01: Coils (r/w)
Alt: read_coils(1, 1, slave=1)
Neu: read_coils(1, count=1, slave=1)

# Funktionscode 02: Discrete Inputs (r/o)
Alt: read_discrete_inputs(1, 1, slave=1)
Neu: read_discrete_inputs(1, count=1, slave=1)

# Funktionscode 03: Holding Registers (r/w)
Alt: read_holding_registers(1, 1, slave=1)
Neu: read_holding_registers(1, count=1, slave=1)

# Funktionscode 04: Input Registers (r/o)
Alt: read_input_registers(1, 1, slave=1)
Neu: read_input_registers(1, count=1, slave=1)

Hab jetzt nicht geprüft, welche der Funktionscodes von welchem Plugin verwendet werden; aber das Einpflegen sollte nicht allzu viel Aufwand machen.

/tom

[Cannon]

Das Problem tritt schon bei öffnen der Modbus-Schnittstelle auf. Auch da sind die Parameter nicht passend. Deshalb würde ich eher erst einmal die Version begrenzen. Man kann nicht jede Änderung von pymodbus mitmachen. Im Besten Fall bleibt man bei der "alten" Version.

Netter Nebeneffekt:
Zumindest im Pluggit-Plugin wird trotz nicht geöffneter Schnittstelle, dennoch versucht die Werte zu lesen/zu schreiben. Das sollte eigentlich noch abgefangen werden. Vielleicht mache ich das demnächst mal.

Aktuell würde ich erst mal die Abhängigkeiten begrenzen. Es wird allerdings dann ein Problem, wenn einer ein Plugin mit pymodbus >= 3.7 bastelt.

Zum Weg: Aktuell lade ich die Plugins runter, bearbeite die und lade die wieder in github hoch. Gibt es einen leichteren Weg? Die z.B: direkt in der Web-Oberfläche zu bearbeiten und zu speichern? Wie ist da der Beste Ablauf?

[wvhn]

Zum Weg: Aktuell lade ich die Plugins runter, bearbeite die und lade die wieder in github hoch. Gibt es einen leichteren Weg? Die z.B: direkt in der Web-Oberfläche zu bearbeiten und zu speichern? Wie ist da der Beste Ablauf?

Wenn Du die Änderungen in der Weboberfläche machst und keine Schreibrechte im Repo hast, wird die Änderung beim commit automatisch in einen neuen branch in Dein eigenes Repo übernommen und ein PR erstellt. Das ist für kleine Änderungen einfach zu handhaben.

Bei größeren Änderungen habe ich gute Erfahrungen damit gemacht, einen Fork im eigenen Repo anzulegen und den mit Github Desktop (gibt's für Windows und Mac) auf den Rechner zu clonen. Dann kannst Du die Dateien lokal bearbeiten und anschließend in Github Desktop wieder committten.

Gruß
Wolfram

[ivande]

modbus_tcp
es scheint als ob das Ergänzen von count= ausreicht.., ich habe damit 3.8.3 und 3.6.3. kurz getestet

        if objectType == 'Coil':
            result = self._Mclient.read_coils(address, count=registerCount, slave=slaveUnit)
        elif objectType == 'DiscreteInput':
            result = self._Mclient.read_discrete_inputs(address, count=registerCount, slave=slaveUnit)
        elif objectType == 'InputRegister':
            result = self._Mclient.read_input_registers(address, count=registerCount, slave=slaveUnit)
        elif objectType == 'HoldingRegister':
            result = self._Mclient.read_holding_registers(address, count=registerCount, slave=slaveUnit)
        else:
            self.logger.error(f"{AttrObjectType} not supported: {objectType}")
            return None​

es bahnt sich jedoch ein weiteres Problem an:

deprecate    ln:292 BinaryPayloadDecoder is deprecated and will be removed in v3.9.0 !
Please use "client.convert_from_registers()" or "client.convert_to_registers"
See documentation: "https://pymodbus.readthedocs.io/en/latest/source/client.html#pymodbus.client.mixin.ModbusClientMixin.convert_from_registers"​

[Cannon]

es bahnt sich jedoch ein weiteres Problem an:

Verrückt! Vielleicht doch erst mal die requirements anpassen?

Wie gesagt die huawei-solar-lib wird mit der neuen Version auch nicht mehr funktionieren. Allerdings gibt es das Problem, wenn die lib angepasst wird, dann wird die neue Version notwendig sein und dann funktioniert entweder nur die huawei-solar-lib oder die Plugins von SmartHomeNG.

Mir geht das ständige Gebastel, ohne Mehrwert, auf den Nerv.

[Tom Bombadil]

Das Problem tritt schon bei öffnen der Modbus-Schnittstelle auf. Auch da sind die Parameter nicht passend.

Wie gesagt die huawei-solar-lib wird mit der neuen Version auch nicht mehr funktionieren. Allerdings gibt es das Problem, wenn die lib angepasst wird, dann wird die neue Version notwendig sein und dann funktioniert entweder nur die huawei-solar-lib oder die Plugins von SmartHomeNG.

Es gibt wohl einige Gleichrichter mit herstellerseitiger Busadresse 0. Dies ist aber eine Broadcast-Adresse (genau wie die 255). In pymodbus 3.8 wurde entsprechend (korrekterweise) das default von 0 auf 1 abgeändert, wenn beim Verbindungsaufbau keine Busadresse explizit spezifiziert wurde.

Wenn also ein Plugin beim Verbindungsaufbau keine (Ziel-)Adresse angibt (was sowieso unsauber ist), kann das nun entsprechend zu Problemen führen.

Weitere Umstellungen beim Verbindungsaufbau sind mir nicht bekannt.

/tom

[SKraft]

Hallo Zusammen,

ich versuche verzweifelt das modbus_tcp zum schreiben zu bringen.
Lesen geht ohne Probleme, aber schreiben keine Chance.

Habe modbus_tcp v1.0.13 mit pymodbus 3.6.4 am laufen

Da ich mit einem modbus Tool auf dem Handy ohne Probleme auf meine Wallbox schreiben konnte,
denke ich das es einen Zusammenhang mit denn hier beschrieben Problemen gibt.

Oder gibt es vielleicht noch andere Lösungsansätze?

Danke für eure Unterstützung