Einbindung von Modbus TCP

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

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]

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.

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

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

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

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]

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]

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]

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

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

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

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

[beckerth]

Da ich selbst das Plugin "modbus_tcp" nicht nutze kann ich das Problem nicht nachvollziehen. Wenn es aber am pymodbus liegen sollte, dann würde ich die erst einmal die letzte 3.5er Version mal probieren. Das wäre dann die 3.5.4. Es wäre ja gut, wenn alles was pymodbus nutzt auch erst einmal auf eine Version lauffähig wäre.

Also ich habe mal eine neue virtuelle Maschine mit SmarthomeNG zum Testen installiert. Angehängt eine korrigierte Version des Plugins (Als .zip weil 21 kB das Limit von 19,5kB für Dateianhänge überschreiten 🙃). Folgende Änderungen:

• Vorschlag mit pyModbus==3.5.4 zu arbeiten (Änderung nicht enthalten, Anpassung in requirements.txt nötig)
• Itemdefinitionen mit Endian.Big und Endian.Little werden vom Plugin in Endian.BIG/LITTLE umgesetzt. Falls nicht erwünscht müsste die valid_list in der Plugin.yaml angepasst werden, soweit ich es verstehe? Hab bissl gebraucht um es zu schnallen - ShNG hat mir immer z.B. Endian.BIG durch Endian.Big überschrieben, so wie in der plugin.yaml definiert. Wenn Großbuchstaben verwendet werden sollen müssten die User die Item Definitionen anpassen da in alten Versionen nur der erste Buchstabe groß war. Man könnte auch im Plugin abfangen beides zu akzeptieren...
• In einer konsequtiven if/elif/else Abfrage der modbus_write Funktion hat ein "el" vor dem elif gefehlt - daher konnte float32 nicht geschrieben werden. (Ca. Zeile 358)
• dataDirection == 'write' hinzugefügt

Könntest du es Dir mal anschauen/diffen und ggf. deinen Pull Request updaten? Ich habe jetzt kurz mit einer Minimalversion getestet, werde meine Produktivumgebung aber die Tage umstellen auf das angehängte Plugin um zu sehen wie es dann läuft.

[beckerth]

Deine Solaredge Fehler kann ich bestätigen:

2023-12-09 03:56:57 ERROR plugins.modbus_tcp se_inverter@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.20.68:1502): Connection unexpectedly closed 0.000308990478515625 seconds into read of 8 bytes without response from slave before it closed connection
2023-12-09 17:52:57 ERROR plugins.modbus_tcp se_inverter@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.20.68:1502): Connection unexpectedly closed 2.3365020751953125e-05 seconds into read of 8 bytes without response from slave before it closed connection
​

Ich bin auf dem aktuellen develop branch unterwegs. Ich vermute das der Solaredge Wechselrichter nur eine modbus Verbindung zur Zeit erlaubt und die interne Verbindung zum zugehörigen Zähler dann schlicht gewinnt.

Hallo zusammen,

ich hatte eine ganze Weile den Modbus Plugin mit zwei Geräten recht stabil am laufen. Bis vor einiger Zeit lief das alles recht problemlos. Jetzt ist mir aufgefallen, dass ich immer wieder folgende Fehlermeldungen bekomme. Unterschiedlich für meine beiden Geräte, eine Paradigma Heizung und ein Solaredge Wechselrichter:
Code:

2023-12-09 13:12:18 ERROR plugins.modbus_tcp paradigma@: read error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received) InputRegister.40.1 (address.slaveUnit) regCount:1 2023-12-09 13:17:14 ERROR plugins.modbus_tcp solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.007294893264770508 seconds into read of 8 bytes without response from unit before it closed connection 2023-12-09 13:27:15 ERROR plugins.modbus_tcp solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.01136159896850586 seconds into read of 8 bytes without response from unit before it closed connection 2023-12-09 13:37:17 ERROR plugins.modbus_tcp solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.0036919116973876953 seconds into read of 8 bytes without response from unit before it closed connection 2023-12-09 13:37:20 ERROR plugins.modbus_tcp paradigma@: read error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received) InputRegister.7.1 (address.slaveUnit) regCount:1 2023-12-09 13:47:18 ERROR plugins.modbus_tcp solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.005329132080078125 seconds into read of 8 bytes without response from unit before it closed connection 2023-12-09 13:57:19 ERROR plugins.modbus_tcp solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.001871347427368164 seconds into read of 8 bytes without response from unit before it closed connection 2023-12-09 14:07:20 ERROR plugins.modbus_tcp solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.019519329071044922 seconds into read of 8 bytes without response from unit before it closed connection
In regelmäßigen Abständen klappt die Abfrage nicht. Aktuell habe 300s cycle Time eingestellt, d.h., beim Solaredge klappt jede zweite Abfrage nicht, bei der Paradigma in unregelmäßigen Abständen. Wenn ich die cycle Time ändere, verändern sich die Abstände der Fehler, sie bleiben aber nicht aus.

Wie gesagt, früher lief das besser. Ich muss aber gestehen, ich weiß nicht, was ich geändert haben könnte, was den Fehler verursacht.

Hat jemand von euch eine Idee??

Die gelegentlichen Fehler kommen bei mir jetzt auch mit ShNG Version 1.9.2 und der letzten develop Version vom Plugin.

2024-01-01  10:07:33 ERROR    pymodbus.client.tcp Connection to (192.168.177.46, 1502) failed: timed out
2024-01-01  10:07:33 ERROR    plugins.modbus_tcp  kostal_wr2@: could not connect to 192.168.177.46:1502
2024-01-01  10:07:33 ERROR    plugins.modbus_tcp  kostal_wr2@: not connected to 192.168.177.46:1502
...
2024-01-01  12:25:10 ERROR    plugins.modbus_tcp  modbus_ernergy_meters@: read error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received) InputRegister.342.1 (address.slaveUnit) regCount:2
2024-01-01  12:25:13 ERROR    pymodbus.client.tcp Connection to (192.168.177.50, 1502) failed: timed out
2024-01-01  12:25:13 ERROR    plugins.modbus_tcp  modbus_ernergy_meters@: something went wrong in the poll_device function: Modbus Error: [Connection] Failed to connect[ModbusTcpClient(192.168.177.50:1502)]
2024-01-01  12:25:16 ERROR    plugins.modbus_tcp  modbus_ernergy_meters@: read error: Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response InputRegister.0.1 (address.slaveUnit) regCount:2
2024-01-01  12:29:35 NOTICE   modules.admin.api_logs  - log_name=smarthome-warnings, logs[log_name]=[['smarthome-warnings.log', 638.2]]​​

Für mich auffällig: Parallel laufen die Kostalmodbus und KSEMmodbus Plugins (auch mit 5s Cycle time) und da kommen keine Fehler(Vielleicht werden diese auch nur nicht ausgegeben, muss ich mir anschauen).
Außerdem kommen die Fehler immer nur bei einem von zwei Wechselrichtern und von der Modbus RTU/TCP Bridge.