Einbindung von Modbus TCP

[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]

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]

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]

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

[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]

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

[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?

[Onkelandy]

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

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

[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]

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

[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]

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]

Jetzt würde ich gerne ein weiteres Gerät abfragen und offenbar kann man mehrere Instanzen in der plugins.yaml definieren. Mir ist jedoch nicht klar geworden, wie ich in den einzelnen Item-Definitionen dann die zugehörige Instanz anspreche. Bräuchte man nicht ein Parameter wie, modBusInstance=...?

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

[zittho]

Hallo zusammen, und vielen Dank für die Bereitstellung des Plugins, ivande. Ich nutze dieses Plugin bereits seit Monaten problemlos für die Abfrage eines Victron Geräts.

Jetzt würde ich gerne ein weiteres Gerät abfragen und offenbar kann man mehrere Instanzen in der plugins.yaml definieren. Mir ist jedoch nicht klar geworden, wie ich in den einzelnen Item-Definitionen dann die zugehörige Instanz anspreche. Bräuchte man nicht ein Parameter wie, modBusInstance=...?

    Battery_Voltage:
        name: Batterie Spannung
        type: num
        modBusInstance: Victron # So was bräuchte man vermutlich?
        modBusUnit: 100
        modBusAddress: 840
        modBusDataType: uint16
        modBusFactor: 0.1
        database: True
        cache: True​

Danke und Gruß, zittho