Einbindung von Modbus TCP

[ivande]

Ergänzung: wenn in der plugin.yaml das Plugin-Attribut "suspend_item" enthalten ist, kann man dort ein (bool-)Item angeben, und das Item per Hand, per Logik oder eval setzen oder löschen, und das Plugin wird "automatisch" in den suspend- oder resume-Modus gehen. Dann braucht man dafür keine extra Items bzw. zusätzliche Logik erfinden.

irgendwie läuft der suspend modus über das Item nicht, wenn ich "Telegram.TestControlToggle" (bool-Item) Ein- und Ausschalte.
Muss ich dafür noch etwas ins plugin einbauen? Ich hab kein Plugin (-Beispiel) mit suspend_item gefunden.


mit sh.plugins.return_plugin('logoMB').suspend() / resume() kann ich das plugin deaktivieren/aktivieren

etc/plugin.yaml

logoMB:
    plugin_name: priv_modbus_tcp
    instance: logomb
    host: 192.168.0.80
    port: 502
    cycle: 20
    plugin_enabled: true
    suspend_item: Telegram.TestControlToggle
​

priv_modbus_tcp.plugin.yaml

    suspend_item:
        type: str
        default: ''
        description:
            de: 'Item zum Schalten des Suspend-Modus'
            en: 'item for toggling suspend mode'​

[Morg]

Ergänzung: wenn in der plugin.yaml das Plugin-Attribut "suspend_item" enthalten ist, kann man dort ein (bool-)Item angeben, und das Item per Hand, per Logik oder eval setzen oder löschen, und das Plugin wird "automatisch" in den suspend- oder resume-Modus gehen. Dann braucht man dafür keine extra Items bzw. zusätzliche Logik erfinden.

[ivande]

Im Anhang zum testen die Version 1.0.12 mit reduzierten Log-Ausgaben bei fehlerhaften connect. Mit Logger = DEBUG werden alle Fehler geloggt.

Mit suspend() und resume() kann nun das Lesen (poll) und Schreiben (update) angehalten und wieder gestartet werden.
evtl. ins eval eines Items einbauen:

sh.plugins.return_plugin('logoMB').suspend()  # deaktiviert das plugin
sh.plugins.return_plugin('logoMB').resume()​ # reaktivert das plugin
# logoMB mit dem Namen welcher in der plugin.yaml gewählt wurde ersetzten

[Morg]

Ergänzung zum Ab-/Anschalten: das SmartPlugin bringt seit 1.10 (?) einen "suspend"/"resume"-Mechanismus mit. Wenn ein entsprechendes Item definiert wird, kann über das (bool)Item das Plugin aktiviert und deaktiviert werden. Vielleicht schaut ihr mal in den Quelltext vom SmartPlugin (und ggf. im SmartDevicePlugin, wie das da umgesetzt ist).

Es muss natürlich in update_item und ggf. den entsprechenden Gegenstücken der Code so angepasst werden, dass das Senden/Empfangen dann unterbunden wird (und auch das connecten).

Für eine einheitliche Ansteuerung wäre es super, wenn ihr das mit berücksichtigen könntet

[ivande]

die Variante welche im gleichen Zeitintervall die Verbindung versucht aufzubauen, jedoch ab 10. Fehler nur mehr jeden 10 Log ausgibt, und ab den 100.Fehler nur mehr jeden 100.ten Fehler loggt.
Und im log-Level - Debug wird weiterhin "normal" geloggt..

2024-05-07  17:20:43 ERROR    plugins.priv_modbus_tcp: read error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received) InputRegister.0.1 (address.slaveUnit) regCount:1
2024-05-07  17:20:46 ERROR    plugins.priv_modbus_tcp: something went wrong in the poll_device function: Modbus Error: [Connection] Failed to connect[ModbusTcpClient 192.168.0.80:502]
2024-05-07  17:21:03 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 1
2024-05-07  17:21:22 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 2
2024-05-07  17:21:44 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 3
2024-05-07  17:22:05 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 4
2024-05-07  17:22:26 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 5
2024-05-07  17:22:46 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 6
2024-05-07  17:23:07 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 7
2024-05-07  17:23:27 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 8
2024-05-07  17:23:48 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 9
2024-05-07  17:24:08 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 10 [Logging suppressed every 10th error]
2024-05-07  17:27:34 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 20 [Logging suppressed every 10th error]
2024-05-07  17:30:59 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 30 [Logging suppressed every 10th error]
2024-05-07  17:34:24 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 40 [Logging suppressed every 10th error]
2024-05-07  17:37:49 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 50 [Logging suppressed every 10th error]
2024-05-07  17:41:15 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 60 [Logging suppressed every 10th error]
2024-05-07  17:44:40 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 70 [Logging suppressed every 10th error]
2024-05-07  17:48:05 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 80 [Logging suppressed every 10th error]
2024-05-07  17:51:31 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 90 [Logging suppressed every 10th error]
2024-05-07  17:54:56 ERROR    plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 100 [Logging suppressed every 100th error]​

[Sipple]

Ich habe jetzt mal aus der all.txt alle pymodbus Referenzen außer der letzten wie oben gezeigt gelöscht, um zu sehen, was passiert.
Die PyPi Check Seite im Admin Interface ging damit sofort wieder und es kommen auch keine neuen Fehler im Log mehr.
Neu gestartet habe ich allerdings noch nicht, weil ich grad noch was anderes teste. Mach ich später mal.

[Msinn]

Ja, die Dateien im requirements Directory werden beim Neustart von SmartHomeNG neu generiert.

• die Datei all.txt dient dabei nur der allgemeinen Übersicht über alle Requirements (und mögliche Konflikte)
• die Datei base.txt wird beim bei Neuinstallationen genutzt, um die grundlegenden Packages zu installieren, damit der SmartHomeNG Core vollständig initialisiert werden kann. Das ist die Liste der Packages, die beim ersten Start von SpartHomeNG installiert werden. (Da sollten eigentlich keine Plugin Requirements drin sein, muss ich mir mal ansehen.
• die Datei conf_all.txt enthält die Requirements für alle in der aktuellen Installation konfigurierten Plugins (auch wenn sie mit

  plugin_enabled: false

  disabled sind. Das ist die Liste der Packages, die beim Start installiert werden.

[Sipple]

Ja, meine Installation läuft mit 3.11.
Das seltsame ist, dass das seit letzten Sommer läuft und nie ein Problem war. Den Cherrypy Fehler hatte ich definitiv nie.
Bis ich Ivan's Develop Version des modbus_tcp Plugins verwendet habe. Dabei noch nicht mal bei der vorletzten Version, sondern erst seit Sonntag Abend, als ich die neuste Variante hergenommen habe, die das Problem entschärft, dass der KACO Wechselrichter nachts nicht mehr erreichbar ist.

Es scheint auch keine ernsteren Probleme zu geben, alles läuft wie gehabt. Wenn es nur um einen Logeintrag geht, kann ich damit leben. Sobald meine aktuelle Änderungsphase abgeschlossen ist, fass ich das Admininterface eh nur selten an und komme hoffentlich endlich dazu, mal meinen Backup-Raspi zu reanimieren und dann 1.10 zu installieren.

Zum Verständnis: Wenn ich aus der all.txt die Requirements, die ich nicht brauche, lösche, würde SHNG die bei einem Neustart wieder rein schreiben und somit käme der Fehler wieder?

Und danke für deine wie immer schnelle und kompetente Hilfe.

Gruß, Martin

[Msinn]

Ich kann das Problem auf die Schnelle nicht nachvollziehen (SmartHomeNG v1.10 unter Python 3.10).

Allerdings ist mir beim genaueren Blick auf die Log Einträge die Du gepostet hast aufgefallen, dass Du Python 3.11 nutzt. SmartHomeNG unterstützt jedoch nur Python Versionen bis incl. 3.9.

Der cherrypy Error hat seinen Ursprung im Aufruf der Systemeigenschaften/PyPI Check in der Admin GUI.

[Msinn]

Soweit ich das im Moment sehe, sind 2 Hunde begraben. Der zweite Hund ist, dass Cherrypy beim Auftreten des Fehlers auf die Bretter geht. Den Fehler muss ich beheben.

Die eigentliche Ursache steht unscheinbar in einem Log Eintrag. Das Konsolidieren scheitert daran, dass verschiedene Plugins unterschiedliche minimale Versionen von pymodbus erfordern. Das sollte bei Dir eigentlich keine Rolle spielen, da in der conf_all.txt nur ein Eintrag zu pymodbus steht. In der all.txt sind allerdings mehrere Einträge, mit den besagten Unterschieden.

[Msinn]

Welche Python Version nutzt Du?

[Sipple]

Nachtrag:

Ich habe mal im Ordner \SmartHomeNG\requirements die vier Textdateien durchsucht und folgende Bezüge auf pymodbus gefunden:

In conf_all.txt

# configured plugin 'priv_modbus_tcp'
pymodbus>=3.5.2;python_version>='3.8'

In base.txt

# configured plugin 'priv_modbus_tcp'
pymodbus>=3.5.2;python_version>='3.8'

In all.txt

# plugin 'trovis557x'
pymodbus>=2.2.0

# plugin 'ksemmodbus'
# plugin 'kostalmodbus'
# plugin 'helios_tcp'
# plugin 'sma_mb'
# plugin 'pluggit'
pymodbus>=2.3,<3.0;python_version<'3.8'

# plugin 'ksemmodbus'
# plugin 'kostalmodbus'
# plugin 'helios_tcp'
# plugin 'sma_mb'
# plugin 'pluggit'
pymodbus>=3.0.2;python_version>="3.8"

# plugin 'priv_modbus_tcp'
# configured plugin 'priv_modbus_tcp'
pymodbus>=3.5.2;python_version>='3.8'​

Liegt da der Hund begraben? Wenn ja, weiß ich nicht, warum.

[Sipple]

Guten Morgen ivande

Ich habe die Version verwendet und das funktioniert nicht schlecht. Sprich, die Log Einträge werden deutlich reduziert. Kann man mit leben.
Allerdings bekomme ich nun folgende Fehlermeldung im Log, die mit pymodbus zusammen hängen:

2024-05-07  07:50:15 WARNING  lib.shpypi           - pymodbus: MULTIPLE requirements [{'min': '2.2.0'}, {'min': '3.0.2'}, {'min': '3.5.2'}]
2024-05-07  07:50:15 ERROR    cherrypy.error.139668107957136 [07/May/2024:07:50:15] HTTP
> Traceback (most recent call last):
>   File "/home/smarthome/.local/lib/python3.11/site-packages/cherrypy/_cprequest.py", line 638, in respond
>     self._do_respond(path_info)
>   File "/home/smarthome/.local/lib/python3.11/site-packages/cherrypy/_cprequest.py", line 697, in _do_respond
>     response.body = self.handler()
>                     ^^^^^^^^^^^^^^
>   File "/home/smarthome/.local/lib/python3.11/site-packages/cherrypy/lib/encoding.py", line 223, in __call__
>     self.body = self.oldhandler(*args, **kwargs)
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/home/smarthome/.local/lib/python3.11/site-packages/cherrypy/_cpdispatch.py", line 54, in __call__
>     return self.callable(*self.args, **self.kwargs)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/smarthome/modules/admin/systemdata.py", line 190, in pypi_json
>     package_list = self.shpypi.get_packagelist()
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/smarthome/lib/shpypi.py", line 670, in get_packagelist
>     package['vers_req_min'] = required_packages[pkg_name].get('min', '*')
>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> AttributeError: 'list' object has no attribute 'get'
2024-05-07  07:50:19 WARNING  lib.shpypi           - pymodbus: MULTIPLE requirements [{'min': '2.2.0'}, {'min': '3.0.2'}, {'min': '3.5.2'}]
2024-05-07  07:50:19 ERROR    cherrypy.error.139668107957136 [07/May/2024:07:50:19] HTTP
> Traceback (most recent call last):
>   File "/home/smarthome/.local/lib/python3.11/site-packages/cherrypy/_cprequest.py", line 638, in respond
>     self._do_respond(path_info)
>   File "/home/smarthome/.local/lib/python3.11/site-packages/cherrypy/_cprequest.py", line 697, in _do_respond
>     response.body = self.handler()
>                     ^^^^^^^^^^^^^^
>   File "/home/smarthome/.local/lib/python3.11/site-packages/cherrypy/lib/encoding.py", line 223, in __call__
>     self.body = self.oldhandler(*args, **kwargs)
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/home/smarthome/.local/lib/python3.11/site-packages/cherrypy/_cpdispatch.py", line 54, in __call__
>     return self.callable(*self.args, **self.kwargs)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/smarthome/modules/admin/systemdata.py", line 190, in pypi_json
>     package_list = self.shpypi.get_packagelist()
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/smarthome/lib/shpypi.py", line 670, in get_packagelist
>     package['vers_req_min'] = required_packages[pkg_name].get('min', '*')
>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> AttributeError: 'list' object has no attribute 'get'

Irgendwie und irgendwo beißen sich die Requirements, aber ich verstehe nicht ganz wie das zustande kommt.
Den Logeintrag bekomme ich nun jedesmal, wenn ich das Admin-Interface aufmache.
Außerdem jeweils einmal mehr, wenn ich die Systemeigenschaften->PyPi Check aufrufen will, was nicht mehr funktioniert. Dort steht nun endlos "Loading".
Ist für mich plausibel, dass das passiert, wenn es einen groben Fehler bei den Requirements gibt, aber ich weiß nicht, wie ich das weg bekomme.
Das Plugin läuft. Andere Modbus Plugins verwende ich nicht.
SHNG ist immer noch 1.9.5
pymodbus ist 3.5.4
In requirements.txt des Plugins steht pymodbus>=3.5.2;python_version>='3.8'
Sieht für mich normal aus.

Jemand eine Idee wie ich das bereinigen kann?

[ivande]

Das ist doch schon mal nicht schlecht. Schickst mir die mal?

Gruß Ivan

[Sipple]

Zuerst dachte ich gerade, dass die Kommunikationseinheit doch aktiv bleibt, wenn man sie regelmäßig anspricht, weil die Verbindung noch über eine halbe Stunde nach Sonnenuntergang funktioniert hat.
Jetzt allerdings, wie vermutet:

2024-05-05  21:11:58 ERROR    plugins.priv_modbus_tcp read error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received) HoldingRegister.40229.3 (address.slaveUnit) regCount:1
2024-05-05  21:12:01 ERROR    pymodbus.logging    Connection to (192.168.178.157, 502) failed: timed out
2024-05-05  21:12:01 ERROR    plugins.priv_modbus_tcp something went wrong in the poll_device function: Modbus Error: [Connection] Failed to connect[ModbusTcpClient(192.168.178.157:502)]
2024-05-05  21:12:59 ERROR    pymodbus.logging    Connection to (192.168.178.157, 502) failed: timed out
2024-05-05  21:12:59 ERROR    plugins.priv_modbus_tcp could not connect to 192.168.178.157:502
2024-05-05  21:13:59 ERROR    pymodbus.logging    Connection to (192.168.178.157, 502) failed: timed out
2024-05-05  21:13:59 ERROR    plugins.priv_modbus_tcp could not connect to 192.168.178.157:502
2024-05-05  21:15:00 ERROR    pymodbus.logging    Connection to (192.168.178.157, 502) failed: timed out
2024-05-05  21:15:00 ERROR    plugins.priv_modbus_tcp could not connect to 192.168.178.157:502
2024-05-05  21:16:01 ERROR    pymodbus.logging    Connection to (192.168.178.157, 502) failed: timed out
2024-05-05  21:16:01 ERROR    plugins.priv_modbus_tcp could not connect to 192.168.178.157:502

ivande
Das ist doch schon mal nicht schlecht. Schickst mir die mal?

Gruß, Martin