Einbindung von Modbus TCP

[ivande]

War da weiter oben nicht die Rede von einem bool Item?

in der plugin.yaml wird der Item-Pfad zum boolschen-Item übergeben - der Item pfad ist str

[Sipple]

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

War da weiter oben nicht die Rede von einem bool Item?

[Morg]

Oha... Okay, mein Fehler. In der parse_item musst du entweder "vorneweg" noch super().parse_item(item) aufrufen oder den folgenden Code einfügen: (besser mit super() direkt aus SmartPlugin einbinden, dann bekämst du auch Updates mit

        # check for suspend item
        if item.property.path == self._suspend_item_path:
            self.logger.debug(f'suspend item {item.property.path} registered')
            self._suspend_item = item
            self.add_item(item, updating=True)
            return self.update_item
​

Außerdem in update_item:

            # check for suspend item
            if item is self._suspend_item:
                if caller != self.get_shortname():
                    self.logger.debug(f'Suspend item changed to {item()}')
                    self.set_suspend(by=f'suspend item {item.property.path}')
                return
​

Ich hoffe, dann passt es sorry für die Verwirrung, hab da schon ein paar Tage nicht mehr reingeschaut

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