Einbindung von Modbus TCP

[manhartm]

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:

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:

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.

[manhartm]

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

result = self._Mclient.write_registers(address, registers, unit=slaveUnit)​

Korrekt wäre aber:

result = self._Mclient.write_registers(address, registers, slave=slaveUnit)

Mit dieser unteren Version erscheint die Fehlermeldung nicht mehr.

[beckerth]

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

result = self._Mclient.write_registers(address, registers, unit=slaveUnit)​

Korrekt wäre aber:

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.

[ivande]

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

[Sipple]

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

[ivande]

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.

[Sipple]

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.

[ivande]

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

[Sipple]

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?

[bmx]

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.

[ivande]

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

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.

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.

[Sipple]

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.

[ivande]

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

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)​​

[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

[ivande]

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

Gruß Ivan