Ankündigung

Einklappen
Keine Ankündigung bisher.

Einbindung von Modbus TCP

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Sipple
    antwortet
    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:

    Code:
    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?

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Zitat von Sipple Beitrag anzeigen
    Das ist doch schon mal nicht schlecht. Schickst mir die mal?

    Gruß Ivan
    Angehängte Dateien

    Einen Kommentar schreiben:


  • Sipple
    antwortet
    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:

    Code:
    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

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Zitat von Sipple Beitrag anzeigen
    Läßt sich das Logging für das Plugin temporär abschalten?
    ob dies generel über SH steurbar ist wüsste ich jetzt auch nicht.

    im Plugin könnte ich allerdings ab dem 10.Error das loggen unterdrücken - und den Verbindungsversuch gleich oft starten.


    Die Frage ist jetzt: den Verbindungsversuch selber nach mehreren Fehlern reduzieren, oder nur den log ab mehreren Fehlern unterdücken?

    Eine Testversion mit reduzierten Verbindungsversuchen hätte ich schon am laufen (Trigger alle 20sec):

    Code:
    2024-05-05 20:38:37 CEST ERROR    __init__   plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 1  --  (__init__.py:poll_device:231)
    2024-05-05 20:38:57 CEST ERROR    __init__   plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 2  --  (__init__.py:poll_device:231)
    2024-05-05 20:39:18 CEST ERROR    __init__   plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 3  --  (__init__.py:poll_device:231)
    2024-05-05 20:39:35 CEST DEBUG    __init__   plugins.priv_modbus_tcp: poll every 10 cycles, cycles: 1 errors: 3  --  (__init__.py:poll_device_wrapper:205)
    2024-05-05 20:42:43 CEST ERROR    __init__   plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 4  --  (__init__.py:poll_device:231)
    2024-05-05 20:43:00 CEST DEBUG    __init__   plugins.priv_modbus_tcp: poll every 10 cycles, cycles: 11 errors: 4  --  (__init__.py:poll_device_wrapper:205)
    2024-05-05 20:46:08 CEST ERROR    __init__   plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 5  --  (__init__.py:poll_device:231)
    2024-05-05 20:46:26 CEST DEBUG    __init__   plugins.priv_modbus_tcp: poll every 10 cycles, cycles: 21 errors: 5  --  (__init__.py:poll_device_wrapper:205)
    2024-05-05 20:49:34 CEST ERROR    __init__   plugins.priv_modbus_tcp: could not connect to 192.168.0.80:502, connection_attempts: 6  --  (__init__.py:poll_device:231)
    2024-05-05 20:49:51 CEST DEBUG    __init__   plugins.priv_modbus_tcp: poll every 30 cycles, cycles: 31, errors: 6  --  (__init__.py:poll_device_wrapper:210)​​
    Zuletzt geändert von ivande; 05.05.2024, 20:03.

    Einen Kommentar schreiben:


  • Sipple
    antwortet
    Beides gute Ideen.
    Die Start-Stopp Idee würde wohl eher dazu führen, dass keine Fehlereinträge entstehen.
    Die andere Idee reduziert das drastischt, aber ganz weg sind sie nicht. Könnte man aber wohl damit leben.
    Läßt sich das Logging für das Plugin temporär abschalten?
    Ich habe leider immer wieder Verständnisprobleme was das manipulieren des Loggings angeht, drum bekomme ich das nicht hin.
    Zuletzt geändert von Sipple; 05.05.2024, 19:06.

    Einen Kommentar schreiben:


  • ivande
    antwortet
    mein solaredge-WR ist auch in der Nacht per modbus_tcp erreichbar, deswegen hab ich über das Fehler-Loggen bisher gar nicht nachgedacht.

    Zitat von Sipple Beitrag anzeigen
    jede Minute ein Fehlereintrag ins Log geschrieben wird
    evtl. könnte ich nach 3 Kommunikationsfehler nur mehr alle 10 Minuten eine Verbindungsversuch starten, nach 3 weitern Versuchen dann alle 1/2 Stunde oder so ähnlich.

    Zitat von bmx Beitrag anzeigen
    Wenn das Plugin so abgeändert wird das es gestoppt und wieder gestartet werden kann, dann könnte man es mit Sunset abschalten und mit sunrise wieder einschalten.
    das wäre auch eine Option - muss ich mir zuest mal ansehen was sich einfacher einbauen lässt.

    Einen Kommentar schreiben:


  • bmx
    antwortet
    Wenn das Plugin so abgeändert wird das es gestoppt und wieder gestartet werden kann, dann könnte man es mit Sunset abschalten und mit sunrise wieder einschalten.

    Einen Kommentar schreiben:


  • Sipple
    antwortet
    Das war erschreckend einfach.

    SHNG 1.9.5
    pymodbus 3.5.4
    modbus_tcp Plugin 1.0.11 von ivande

    Die Modbus Adressen für den Kaco blueplanet 3.0 NX3 M2 müssen auch nicht korrigiert werden.

    Leider gibt es aber ein - denke ich - fieses Problem: Der WR schaltet z.B. nachts, wenn es keinen PV Ertrag mehr gibt, KOMPLETT ab.
    Ich hatte ja schon ein halbes Dutzend andere Wechselrichter, aber alle anderen haben die Kommunikationseinheit nicht einfach abgeschaltet (Versorgung dann aus dem AC Netz).
    Noch ist es ja hell, aber ich orakel mal, dass heute Abend ab ca. 20 Uhr jede Minute ein Fehlereintrag ins Log geschrieben wird, bis morgen die Sonne aufgeht und der WR wieder hochfährt. Das ist sch....lecht.

    Läßt sich das verhindern? Ich denke nicht, dass das Plugin das abfängt. Hat jemand ne Idee, wie man das behandeln könnte?

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Ich denke das wird ähnlich aufgebaut sein wie beim solaredge-WR. Ein Beispiel dazu findest du in der example.yaml im plugin. Ich habe nur adresse, data-Type und die Berechnung mit dem Skalierungsfaktor Scale factor[_SF] definieren müssen.

    und danke für's Testen vom Plugin.. bitte Melden sollte es Probleme damit geben
    Zuletzt geändert von ivande; 05.05.2024, 11:03.

    Einen Kommentar schreiben:


  • Sipple
    antwortet
    Guten Morgen Ivan

    Danke für das Plugin.
    Das mit Endian.BIG etc. ist klar. Was ich mich frage, ist, woher ich weiß, was ich da im Item nehmen muss. Die Dokumentation der Modbus Schnittstelle für meinen neuen KACO Blueplanet ist da sehr bescheiden. Es gibt auch ein Tool zum Testen der Verbindung zum Wechselrichter, um zu sehen, was für Sunspec Modelle überhaupt vom WR angeboten werden und das funktioniert zumindest schon mal leidlich (das Tool macht einige eklatante Fehler). Aber mehr als die aktuellen Werte und die absoluten Registeradressen bekommt man nicht raus.

    Einen Kommentar schreiben:


  • ivande
    antwortet
    Hallo Martin,

    es sollte ab SHNG1.8 laufen.
    Im Anhang der Ordner mit den Änderungen.

    Ich würde den Ordner als priv_modbus_tcp in den plugins Ordner kopieren, damit bei einem späteren plugins-update der orignal-ordner dann normal überschrieben wird. Dafür auch in etc/plugin.yaml den plugin_name: priv_modbus_tcp anpassen, nach einem eventuellen update der SH-Plugins (oder bei Problemen in diesem Dateien) kannst du dann in der etc/plugin.yaml wieder bequem auf das orgianl plugin switchen - plugin_name: modbus_tcp

    im Pull-Request kann man auch die jeweiligen Änderungen direkt vom Entwickler holen:

    git_pr.png

    Nachtrag:
    mit diesem Update müsste in den Items für modBusByteOrder und modBusWordOrder Endian.BIG oder Endian.LITTLE jeweils in Großbuchstaben geschrieben werden, ansonsten wird SH im Log meckern.
    Angehängte Dateien
    Zuletzt geändert von ivande; 05.05.2024, 06:08.

    Einen Kommentar schreiben:


  • Sipple
    antwortet
    Hi ivande

    Da der Pull Request noch nicht durch ist und die Änderungen somit noch nicht in Develop, kannst du den gesamten Plugin Ordner hier vorübergehend posten?

    Und noch ne Frage zur SHNG Version. Setzt die neuste Plugin Version SHNG 1.10 voraus oder läuft das auch noch auf der 1.9.5?

    Danke schon mal

    Martin

    Einen Kommentar schreiben:


  • ivande
    antwortet
    hab ein paar Verbesserungen (unit -> slave + Big -> BIG) eingebaut und ein Pull Request gemacht...

    Einen Kommentar schreiben:


  • beckerth
    antwortet
    Zitat von manhartm Beitrag anzeigen
    Habe vermutlich den Fehler gefunden. Im Plugin in der Version 1.10 von SmartHomeNG findet sich folgende Zeile für das Schreiben eines HoldingRegisters:

    Code:
    result = self._Mclient.write_registers(address, registers, unit=slaveUnit)​
    Korrekt wäre aber:

    Code:
    result = self._Mclient.write_registers(address, registers, slave=slaveUnit)
    Mit dieser unteren Version erscheint die Fehlermeldung nicht mehr.
    siehe https://knx-user-forum.de/forum/supp...28#post1921828

    Da sind noch ein paar Korrekturen drin. Bei Gelegenheit mache ich mal ein Div gegen den Stand in Github und einen Pull Request. Meine Version läuft bei mir seit einigen Wochen mit wenig Problemen.

    Einen Kommentar schreiben:


  • manhartm
    antwortet
    Habe vermutlich den Fehler gefunden. Im Plugin in der Version 1.10 von SmartHomeNG findet sich folgende Zeile für das Schreiben eines HoldingRegisters:

    Code:
    result = self._Mclient.write_registers(address, registers, unit=slaveUnit)​
    Korrekt wäre aber:

    Code:
    result = self._Mclient.write_registers(address, registers, slave=slaveUnit)
    Mit dieser unteren Version erscheint die Fehlermeldung nicht mehr.

    Einen Kommentar schreiben:

Lädt...
X