Einbindung von Modbus TCP

[ivande]

Durch Zufall gesehen, dass dies generell bei Multiinstanz-Plugins durch ein Suffix passiert:
https://www.smarthomeng.de/user/konf...ance-fahigkeit

genau - wie hierbeschrieben. Bitte um kurzes Feedback ob Multiinstanz funktioniert. Hab die MultiInstanz zwar 1x kurz getestet, aber aktuell nicht in Betrieb.

Gruß Ivan

[zittho]

genau - wie hierbeschrieben. Bitte um kurzes Feedback ob Multiinstanz funktioniert. Hab die MultiInstanz zwar 1x kurz getestet, aber aktuell nicht in Betrieb.

Sieht bisher gut aus bzw. läuft seit gestern ohne Fehlermeldung durch.

Könnte sein, dass bei den items-Definitionen der Instanzname in Kleinschreibung nach dem @ angehängt werden muss, auch wenn dieser in der plugins.yaml groß geschrieben wurde. Das habe ich gestern am späten Abend nicht weiter verfolgt...

[ivande]

die (Groß-) Kleinschreibung vom Instanzname wird dann direkt von SH abhängen.

[Falari]

Hallo, habe das Modbus-Plugin in Betrieb mit einer Wago-Steuerung.
Das Auslesen der Daten funktionierte einwandfrei, Schreiben von Floats war aber nicht möglich, da in den Zeilen 339, 348, 355 & 369 die Variable TypeStr statt dataTypeStr verwendet wurde.
Nach einer schnellen Änderung funktioniert nun auch das Schreiben von Floats einwandfrei.
Int16 und Bools auf Coils funktionieren auch zu schreiben.

Vielen Dank für das klasse Plugin

[ivande]

danke für die Rückmeldung und Fehlersuche,..
Der Fehler ist auch noch unter __read_Registers develop-Version (466, 475, 482,495)
Da werde ich einen Pull-Request vorbereiten müssen.

Freut mich dass das Plugin genutzt wird und auch das Schreiben soweit klappt..

[Onkelandy]

Dann nix wie ran, damit's noch in den kommenden 1.9.3 Release kommt

[Jackhammer]

Hi,

ich versuche das Plugin zum laufen zu bekommen. Das mag mir noch nicht so recht gelingen. Beim ersten Start meldete er
2023-01-19 11:38:18 ERROR lib.plugin Plugin 'modbus' error importing Python package: No module named 'pymodbus.client.sync'
2023-01-19 11:38:18 ERROR lib.plugin Plugin 'modbus' initialization failed, plugin not loaded

Pymodbus ist aber installiert. Ich habe dann in der Init.py die Zeile

from pymodbus.client.sync import ModbusTcpClient in from pymodbus.client import ModbusTcpClient
geändert. Das Plugin startet jetzt. Er meldet aber folgenden Fehler:

something went wrong in the poll_device function: __init__() got multiple values for argument 'unit'

modbus:
    AI1:
        type: num
        name: AI1
        modBusObjectType: InputRegister     #(optional) default: HoldingRegister
        modBusAddress: 30397
        modBusDataType: float32               #(optional) default: uint16
        #modBusUnit: 2                    #(optional) default: slaveUnit aus der Plugin-Konfig​

Jemand eine Idee?

[Tom Bombadil]

Es gab 'breaking changes' beim import (und auch noch einigen anderen Dingen) beim Wechsel von pymodbus V.2 --> V.3. Letzteres wird bei neueren Python-Versionen automatisch installiert - wie Du richtig bemerkt hast, funktioniert der alte import nicht mehr, und Raider heisst jetzt Twix - ähhh .... unit heisst jetzt slave.

Die Pull Requests mit den entsprechenden Anpassungen für etliche shNG Modbus-Plugins sind gestellt, aber von den Maintainern noch nicht in den Develop-Zweig gemerged (oh Herr, was für ein 'Deutsch'). Da hilft nur warten, oder selbst patchen.

/tom

[Sipple]

Danke für den Tipp

Reicht es vorübergehend auf eine 2.x Version von pymodbus zurück zu gehen oder klemmt es dann woanders?

[Tom Bombadil]

Keine Ahnung, ob die 2.x unter den neueren Python-Versionen überhaupt lauffähig ist - hab ich nie ausprobiert ...

Wenn Du den Import schon geändert hast, kannst Du aber problemlos überall 'unit' durch 'slave' ersetzen, dann sollte es gehen (der Rest bleibt). Geht vermutlich schneller als ein ewiges Modul-Version-Gefrickel. Hier ein Beispiel für einen Aufruf, der pymodbus V2 und V3 unterstützt (der erste Zweig ist der 'originale' aus pymodbus2, der zweite die Anpassung für pymodbus3):

if self._pymodbus_major == '2':
    werte = self._modbus.read_holding_registers(_bereich[0], _bereich[1] -_bereich[0]+1, unit = self._modbus_trovis_address)
else:
    werte = self._modbus.read_holding_registers(_bereich[0], _bereich[1] -_bereich[0]+1, slave = self._modbus_trovis_address)

Viel Erfolg!

/tom

[Msinn]

Die Pull Requests mit den entsprechenden Anpassungen für etliche shNG Modbus-Plugins sind gestellt, aber von den Maintainern noch nicht in den Develop-Zweig gemerged

Von den 5 betroffenen Plugins hat es bisher nur zu 3 Plugins Rückmeldungen zu Tests gegeben. Da der PR mehrere Plugins betrifft, wäre es schön, wenn vor dem mergen alle Plugins getestet würden.

[Tom Bombadil]

Von den 5 betroffenen Plugins hat es bisher nur zu 3 Plugins Rückmeldungen zu Tests gegeben.

Ist es nicht Sinn des Develop-Zweigs (also des "Entwicklungs"Zweigs), Plugins zum großflächigen Test freizugeben, also quasi als Beta-Status?

Oder wird vorausgesetzt, dass Tester immer in der Lage sind, Plugins händisch einzuspielen, zu konfigurieren und zu testen (Pullen geht ja nicht, da nicht gemerged)? Aber wozu brauch ich dann noch Develop für die Plugins - wenn das Ding schon erfolgreich getestet wurde, könnte es doch auch gleich in den Master? Denn auf die vorhandenen Releases wirken sich ja nachträgliche Merges nicht aus.

Kann aber auch sein, dass ich da nur wieder mal zu einfach denke oder was nicht verstehe.

Ob übrigens jemals 'offizielle' Test-Rückmeldungen zu Helios und Trovis kommen, weiß ich im übrigen nicht, da es keine offiziellen Tester gibt. In diesem Fall bleibt dann der PR für die nächsten 100 Jahre ungemerged? Zumindest bei mir läuft der PR zu beiden Plugins seit ~2 Monaten unverändert und 'rock stable'.

Ich überlege entsprechend, zukünftige Updates nur noch über mein eigenes Repo zu verteilen (mit entsprechendem Hinweis im shNG-Plugins-Repo). Der zusätzliche PR ist ohnehin nervig und mit Aufwand verbunden.

/tom

[Msinn]

Normalerweise schaut jemand drüber, bevor ein PR gemerged wird. Das "drüber schauen" ist hier nur zu 3/5 erfolgt und ich bin bei PRs immer skeptisch, wenn sie Änderungen an mehr als einem Plugin vornehmen, weil man im Fehlerfall dann auch die Änderungen der andern Plugin mit zurück nimmt. Besonders, wenn (wie bei diesem PR) der PR Autor schreibt, dass auch er den Code nicht getestet hat.

Ob übrigens jemals 'offizielle' Test-Rückmeldungen zu Helios und Trovis kommen

Die Plugins sind von dem PR auch nicht betroffen.

Ich überlege entsprechend, zukünftige Updates nur noch über mein eigenes Repo zu verteilen

Das ist Dein gutes Recht. Allerdings tauchen sie dann auch nicht in der Dokumentation auf und würden aus Sicht des Projekts nicht als supportete Plugins gelistet.

Es geht bei dem PR der offen ist übrigens nicht um einen PR von Dir.

[Tom Bombadil]

Offtopic:

Die Pull Requests mit den entsprechenden Anpassungen für etliche shNG Modbus-Plugins sind gestellt, aber von den Maintainern noch nicht in den Develop-Zweig gemerged (oh Herr, was für ein 'Deutsch'). Da hilft nur warten, oder selbst patchen.

Es geht bei dem PR der offen ist übrigens nicht um einen PR von Dir.

Das ist mir klar, und ich denke, das wissen wir beide.

Es ging um den Fakt, dass (Stand heute) von sechs offenen PR's drei die angesprochenen pymodbus-Anpassungen vornehmen; und zwar für insgesamt sieben (!) verschiedene Plugins. Zwei dieser drei PR's oxydieren da unkommentiert seit Mitte/Ende November rum, und bis jetzt wusste keiner der Autoren, wieso. Andere PR's wurden zwischenzeitlich innerhalb eines Tages quasi durchgewunken (z.B das Tank-Plugin, das offensichtlich auch ungetestet war und wo es sofort nach dem Mergen 'geknallt' hat).

Und ja, einer dieser beiden November-PR's ist von mir (Trovis+Helios RTU), der andere von Cannon (kostalmodbus + ksemmodbus + modbus_tcp + sma_mb - also der mit der Lösung für das hier von Jackhammer angesprochene Problem, der dieses vermutlich nicht hätte, wenn bereits gemerged wäre).

Allerdings tauchen sie dann auch nicht in der Dokumentation auf und würden aus Sicht des Projekts nicht als supportete Plugins gelistet.

Ist Wurst, da der Support ohnehin nicht mehr nur allein auf shNG beschränkt ist. Mittlerweile werden z.B. auf der Projektseite für die Trovis zwölf verschiedene Systemanbindungen von 'Direct KNX' bis hin zu SPS-Systemen gelistet. shNG dient in der Doku als Beispiel, weil es nun mal die erste Anbindung war - läuft aber bei den wenigsten der dort aktiven Mitleser.

Aber selbst in diesem Fall überwiegt für mich der Vorteil, im Fehler- oder Problemfall (wie z.B. der aktuellen pymodbus-Umstellung) über ein eigenes Repo schnell eine Lösung anbieten zu können, statt monatelang auf ein Merge warten zu müssen. Der aktuelle PR vom November bereitet diesen Schritt übrigens bereits vor; während das shNG-Plugin-Repo zukünftig nur noch alle notwendigen Dinge enthält, liefert das lokale Repo deutlich mehr Hintergrundinformationen und Tools.

Nimm das hier geschriebene bitte nicht als 'Universalkritik' - vor Deiner Arbeit, Deiner Geduld und Deinem Pragmatismus habe ich allerhöchsten Respekt. Aber im Fall dieser konkreten Anpassungen ist es einfach 'dumm gelaufen', und in Zukunft möchte ich nicht mehr meine Zeit in den Mehraufwand investieren, um 2 Repos synchron zu halten.

/tom

[Offtopic aus]

Edit: Falsch genannten Namen der Support-Anfrage korrigiert - Jackhammer statt Sipple.

[Cannon]

Reicht es vorübergehend auf eine 2.x Version von pymodbus zurück zu gehen oder klemmt es dann woanders?

pymodbus 3 setzt Python >= 3.8 voraus. Deshalb das ganze hin- und her. Nicht jeder hat Python 3.8 deshalb der Patch. Schau mal im develop branch bei den plugins. Ich weiß nicht genau welches das Problem macht. Ich meine aber, dass ich alle die pymodbus nutzen gefixt habe. Gern auch Feedback, ob die dann funktionieren.