Ankündigung

Einklappen
Keine Ankündigung bisher.

Einbindung von Modbus TCP

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

    Ich habe gestern mein System auf die Version 1.10 aktualisiert und habe eine Fehlermeldung, wenn ich ein Register in meinem Fronius-Wechselrichter schreiben möchte:

    Code:
    2024-01-29  08:13:34 ERROR    plugins.modbus_tcp  write error: Modbus Error: [Input/Output] No Response received from the remote slave/Unable to decode response HoldingRegister.40360.1 (address.slaveUnit)
    2024-01-29  08:13:57 ERROR    plugins.modbus_tcp  write error: Modbus Error: [Input/Output] No Response received from the remote slave/Unable to decode response HoldingRegister.40360.1 (address.slaveUnit)
    Ich habe dieses Register definiert:

    Code:
    PV_GEN_24:
    
    ​    MinRsvPct:                         # [MinRsvPct] Setpoint for minimum reserve for storage as a percentage of the nominal maximum storage.
            type: num
            modBusAddress: 40360           # 40361 uint16
            modBusUnit: 1
            modBusDataType: 'uint16'
            modBusFactor: '0.01'           # 'eval' nicht verwenden, wenn Register geschrieben wird
            modBusDirection: 'read_write'
            modBusObjectType: 'HoldingRegister'
            visu_acl: rw
    
    ​
    Ich lese den Wert zurück und er wird korrekt verändert.

    Kommentar


      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.

      Kommentar


        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.

        Kommentar


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

          Kommentar


            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

            Kommentar


              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.

              Kommentar


                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.

                Kommentar


                  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.

                  Kommentar


                    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?

                    Kommentar


                      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.

                      Kommentar


                        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.

                        Kommentar


                          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.

                          Kommentar


                            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.

                            Kommentar


                              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

                              Kommentar


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

                                Gruß Ivan
                                Angehängte Dateien

                                Kommentar

                                Lädt...
                                X