Modbus adapter

[bkuerby]

Im TCP-Modus habe ich den Adapter auch im Einsatz. Ich habe damit zwei Stromzähler angebunden. Das funktioniert auch einwandfrei. Die Kommunikation mit der Heizung über die serielle Schnittstelle macht Probleme

[darkbrain85]

@bkuerby:

Im TCP-Modus habe ich den Adapter auch im Einsatz. Ich habe damit zwei Stromzähler angebunden. Das funktioniert auch einwandfrei. Die Kommunikation mit der Heizung über die serielle Schnittstelle macht Probleme `

Irgendwas ist da nicht wie es soll beim Zugriff auf die Serielle Schnittstelle… Ich überlege schon ob ich ein Modbus TCP Gateway aufsetze und es damit nochmal probiere. Aber dann habe ich wieder ein System mehr zu "versorgen"...

[eLichte]

Hi,
ich habe jetzt auch den Modbus Adapter mit RS485 als Master im Einsatz.
Auch bei mir verabschiedet er sich regelmäßig mit timeout Fehlern.

Wenn er läuft sieht der log so aus:

modbus.0	2019-02-26 09:25:49.868	debug	Poll holdingRegs DevID(2) address 2051 - 12 bytes
modbus.0	2019-02-26 09:25:49.803	debug	Poll holdingRegs DevID(2) address 2003 - 27 bytes
modbus.0	2019-02-26 09:25:49.758	debug	Poll holdingRegs DevID(2) address 1000 - 1 bytes
modbus.0	2019-02-26 09:25:49.693	debug	Poll inputRegs DevID(2) address 2102 - 23 bytes
modbus.0	2019-02-26 09:25:49.601	debug	Poll inputRegs DevID(2) address 2006 - 53 bytes
modbus.0	2019-02-26 09:25:49.597	debug	Poll device 2

Jetzt hätte ich dazu ein paar Fragen:

1. Kann man die Zeit zwischen den Requests irgendwo einstellen. Also z.b. die Zeit zwischen Poll Input-Adress 2006 und Input-Adress 2102. Mein Client will eine definierte Wartezeit zwischen seiner Antwort und einer neuen Anfrage. Evtl. ist das auch der Grund für die Timeouts, wenn der Master manchmal zu schnell ist.

2. Eigentlich will ich die Holding Register nur schreiben.
   Dazu erschließt sich mir die Einstellungen Poll, WP und CW im Reiter "Holding Register" nicht. Ich dachte wenn ich Poll abwähle liest der Adapter die Register nicht mehr. Allerdings wird damit im iobroker das ganze Objekt gelöscht.
   Was ist der Unterschied von WP (schreibe bei Änderung?) zu CW (schreibe zyklsich?)? Es wird irgendwie immer bei Änderung geschrieben. Auch hier könnte ein Timing Problem auftreten.

Vielen Dank schon mal im vorraus für die Antworten.

[eLichte]

Der Verdacht zu Punkt 1 hat sich bestätigt. Der Master schickt zu schnell wieder eine Querry message an den Slave nach dessen Antwort. Wenn ich nur 5 zusammenhängende Register abfrage läuft die Kommunikation ohne Probleme.

modbus.0	2019-02-28 11:32:51.341	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:51.341	debug	Poll device 2
modbus.0	2019-02-28 11:32:41.290	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:41.290	debug	Poll device 2

Auszug aus dem Handbuch einer Daikin Klimaanlage:

(T1-T2-T3-T4) ist wie folgt definiert: 5ms bei 9600bps und 2,5ms bei 19200bps

Ich werde dazu einen Issue im Github erstellen. Evlt kann da jemand eine Verzögerungszeit einbauen. Meine Porgrammierkenntnisse reichen dafür leider nicht.

[darkbrain85]

Das kann tatsächlich ein Grund sein!
Bei meinem Modbus Stromzähler kann ich dazu nichts finden. Aber eine Danfoss Steuerung die mir die selben Probleme macht, hat im Handbuch etwas von "relaxed timing" stehen. Allerdings ohne weitere Angaben wie das timing sein muss.
Eventuell ist das aber ein Hinweis in die Richtige Richtung!
Wie ich sehe hat Bluefox das ganze auf Github ja schon mit einem Label versehen.

[wendy2702]

@eLichte sagte in Modbus:

Der Verdacht zu Punkt 1 hat sich bestätigt. Der Master schickt zu schnell wieder eine Querry message an den Slave nach dessen Antwort. Wenn ich nur 5 zusammenhängende Register abfrage läuft die Kommunikation ohne Probleme.

modbus.0	2019-02-28 11:32:51.341	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:51.341	debug	Poll device 2
modbus.0	2019-02-28 11:32:41.290	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:41.290	debug	Poll device 2

Auszug aus dem Handbuch einer Daikin Klimaanlage:

(T1-T2-T3-T4) ist wie folgt definiert: 5ms bei 9600bps und 2,5ms bei 19200bps

Ich werde dazu einen Issue im Github erstellen. Evlt kann da jemand eine Verzögerungszeit einbauen. Meine Porgrammierkenntnisse reichen dafür leider nicht.

Ich hatte ein ähnliches Problem mit einem Stromzähler.

Habe dann mal zum testen „alle“ lesbaren Register im Adapter eingetragen und seitdem läuft er.

[darkbrain85]

Interessanter Ansatz... Ich teste das mal hier mit meinem Zähler.
Da ist es noch überschaubar. Bei größeren Sachen wie meiner Danfoss Steuerung ist das aber quasi unmöglich. Die hat verdammt viele Register...

[KanteTaete]

Hallo zusammen,

ich habe Probleme mit dem Modbus Adapter, wenn ich mehr als einen Slave per Serial RTU abfragen möchte. Solange ich nur einen Slave abfrage (egal welchen der 3 möglichen), funktioniert das Ganze problemlos.

Meine Konfiguration:

• Raspi2 mit laufendem ioBroker
• USB-RS485-Adapter zum Zugriff auf den Bus
• Stromzähler, Typ ABB B23 (baugleich, auf Modbus-Adressen 1-3).

Bei der Konfiguration des Adapters habe ich folgendes eingestellt:

Bei den Holding Registern werden diverse (50-60) Register vom Slave 3 gepollt.
Die Abfrage dieser Register funktioniert problemlos, der "connection" Status bleibt immer auf true.
Die Polltime beträgt ca. 1,8s.

Sobald ich aber die Abfrage eines einzelnen Registers für Slave 1 oder 2 hinzufüge (ein Register vom Slave 3 verdoppelt auf den anderen Slave - die Slaves sind ja baugleich), erhalte ich timeouts.
Außerdem wechselt der "connection" Status häufig (vermutlich beim Timeout) auf "false", die Polltime wird mit ca. 120ms angegeben.

Hier die Logmeldungen:

modbus.0	2019-04-30 11:58:10.577	info	Disconnected from slave
modbus.0	2019-04-30 11:58:09.580	warn	Poll error count: 1 code: {"err":"timeout"}
modbus.0	2019-04-30 11:58:09.579	error	Request timed out.
modbus.0	2019-04-30 11:58:09.571	warn	Error: undefined
modbus.0	2019-04-30 11:57:47.923	info	List of port: [{"comName":"/dev/ttyAMA0"},{"manufacturer":"1a86","pnpId":"usb-1a86_USB2.0-Serial-if00-port0","vendorId":"1a86","productId":"7523","comName":"/dev/ttyUSB0"}]
modbus.0	2019-04-30 11:57:47.426	info	Connected to slave
modbus.0	2019-04-30 11:57:43.801	info	starting. Version 2.0.9 in /opt/iobroker/node_modules/iobroker.modbus, node: v8.16.0
host.myhost	2019-04-30 11:57:40.981	info	instance system.adapter.modbus.0 started with pid 16951

Kann es sein, dass der Adapter mit mehreren Slaves nicht zurecht kommt?
Müsste bei der Abfrage der beiden Slaves ggf. eine Wartezeit dazwischen eingebaut / diese vergrößert werden?

Kennt jemand das Problem bzw. hat jemand die Abfrage mehrerer baugleicher Slaves fehlerfrei am Laufen?

[Stefan_io]

@KanteTaete das gleiche Problem habe ich auch, einen Slave kann ich einlesen, füge ich einen weiteren hinzu gibt es Timeout.

hier meine Forumeintrag https://forum.iobroker.net/topic/22126/adapter-modbus-mehrere-geräte-ids-timeout-beim-auslesen-von-mehr-als-einen-teilnehmern

[eLichte]

@eLichte said in Modbus:

Der Verdacht zu Punkt 1 hat sich bestätigt. Der Master schickt zu schnell wieder eine Querry message an den Slave nach dessen Antwort. Wenn ich nur 5 zusammenhängende Register abfrage läuft die Kommunikation ohne Probleme.

modbus.0	2019-02-28 11:32:51.341	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:51.341	debug	Poll device 2
modbus.0	2019-02-28 11:32:41.290	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:41.290	debug	Poll device 2

Auszug aus dem Handbuch einer Daikin Klimaanlage:

(T1-T2-T3-T4) ist wie folgt definiert: 5ms bei 9600bps und 2,5ms bei 19200bps

Ich werde dazu einen Issue im Github erstellen. Evlt kann da jemand eine Verzögerungszeit einbauen. Meine Porgrammierkenntnisse reichen dafür leider nicht.

Ich habe im Github einen Fork gezogen und quick&dirty mit meinen bescheidenen Programmierkenntnissen eine sleep-Funktion eingebaut. Wollte nur mal testen ob das tatsächlich was bringt. Das log sieht jetzt so aus:

modbus.0	2019-05-10 10:26:07.043	debug	Poll holdingRegs DevID(2) address 2051 - 12 bytes
modbus.0	2019-05-10 10:26:06.836	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.835	debug	Poll holdingRegs DevID(2) address 2003 - 27 bytes
modbus.0	2019-05-10 10:26:06.692	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.692	debug	Poll holdingRegs DevID(2) address 1000 - 1 bytes
modbus.0	2019-05-10 10:26:06.517	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.516	debug	Poll inputRegs DevID(2) address 3634 - 8 bytes
modbus.0	2019-05-10 10:26:06.324	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.324	debug	Poll inputRegs DevID(2) address 3602 - 18 bytes
modbus.0	2019-05-10 10:26:06.119	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.118	debug	Poll inputRegs DevID(2) address 2102 - 23 bytes
modbus.0	2019-05-10 10:26:05.844	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:05.844	debug	Poll inputRegs DevID(2) address 2006 - 53 bytes
modbus.0	2019-05-10 10:26:05.700	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:05.700	debug	Poll inputRegs DevID(2) address 0 - 1 bytes
modbus.0	2019-05-10 10:26:05.699	debug	Poll device 2

So läuft die Kommunikation seid ein paar Wochen ohne Fehler. Es ist also tatsächlich so, dass der Server für manche Clients zu schnell ist.

[darkbrain85]

Das scheint tatsächlich die Lösung zu sein!
Mein Stromzähler lässt sich nun auch auslesen. Ich hatte zwischenzeitlich ein Gateway (mbusd) dazwischen um diesen "bug" in iobroker zu umgehen. Dort kann man exakt diese Zeit auch konfigurieren. Das hilft natürlich nicht bei TCP Verbindungen.

Möglicherweise ist eine Konfiguration aber auch nicht notwendig. Ich glaube das die Wartezeit von 100ms grundsätzlich funktionieren wird.

Irgendwie will nur ein Host in meiner Multihost Umgebung die neue Version nicht nutzen. Dort wird noch wie vor nicht gewartet. Keine Ahnung warum. Upload habe ich bereits gemacht...

Willst Du das auf Github auch mal für Bluefox als PR bereitstellen? Dann kann er es ja leicht hinzufügen oder es notfalls noch verbessern.

Edit: Zu früh gefreut... Ich habe jetzt doch nach einiger Zeit wieder Verbindungsabbrüche. Schade. Mit dem Gateway hat es völlig schmerzfrei funktioniert.

Edit: Ich habe nun selbst auch einen Fork gemacht und Deine Änderungen gemerged. Ich habe nun allerdings 500ms eingestellt, da dies beim Gateway auch so war. Test läuft, ich bin gespannt...

[darkbrain85]

Nachdem 500ms auch keine Veränderung gebracht haben, bin ich nun wieder zu meiner Gateway Lösung gewechselt. Das bringt mir jedenfalls bei den seriellen Schnittstellen eine störungsfreie Kommunikation. Für Modbus TCP habe ich noch keine Lösung.

Fakt ist aber, dass der Adapter nicht sauber funktioniert. Jedenfalls nicht mit jedem Gerät!

[hacki11]

https://github.com/hacki11/ioBroker.valloxmv

[Telefisch]

Hallo...
nach langer Zeit habe ich heute mal den Modbus-Adapter upgedatet.
Von 1.1.1 auf 3.0.0
Seitdem läuft Modbus TCP nicht mehr.
Adapter ist zwar grün, schmeiß aber die Meldung list of port undefined und meine SPS reagiert nicht mehr.
Ist das Problem lösbar oder muss ich auf den alten Adapter zurück?

[peterfido]

Hallo,
ich "kämpfe" auch schon ein paar Tage mit dem Modbus. Hier soll ein DHV 4013 Stromzähler abgefragt werden. Der erste USB-Adapter ging wegen ständiger Fehler zurück an Amazon. Der zweite lief so halbwegs. Der dritte läuft "zu Fuß" per Terminal und seriell per Node-Red. Mit dem Modbus- Adapter vom iobroker leider ständig Timeouts. 5 Register klappen, ab dem 6. hagelt es Fehler.

Danach fängt sich der Port nicht mehr. Ich musste dann erst per USB-reset den USB - Seriell Adapter zurücksetzen. Das geht per Script, ist aber wohl nicht die feine englische Art.

Unter Node-Red bekomme ich jetzt die gewünschten Werte übertragen. Dem Modbus-Adapter vom iobroker könnte eine Option, welche die Pause zwischen den Abfragen einstellbar macht, nicht schaden.

[Farmer-cb]

Hallo
kämpfe gerade mit den Diskreten Eingängen
möchte meine Ladestation (PhönixContact EM-CP-PP-ETH) per modbus-TCP abfragen
Diskrete-Ausgänge Holding-Registers / Eingangsregister Abfragen funktionieren einwandfrei.
Sobald ich bei Diskrete Eingänge etwas einstelle, bleibt der Adapter bei Gelb stehen
Fehlermeldung:

modbus.0	2019-08-04 16:36:10.914	warn	Poll error count: 5 code: {"errorCode":130,"exceptionCode":2,"message":"ILLEGAL DATA ADDRESS"}
modbus.0	2019-08-04 16:36:09.910	warn	Poll error count: 4 code: {"errorCode":130,"exceptionCode":2,"message":"ILLEGAL DATA ADDRESS"}
modbus.0	2019-08-04 16:36:08.905	warn	Poll error count: 3 code: {"errorCode":130,"exceptionCode":2,"message":"ILLEGAL DATA ADDRESS"}
modbus.0	2019-08-04 16:36:07.901	warn	Poll error count: 2 code: {"errorCode":130,"exceptionCode":2,"message":"ILLEGAL DATA ADDRESS"}
modbus.0	2019-08-04 16:36:06.897	warn	Poll error count: 1 code: {"errorCode":130,"exceptionCode":2,"message":"ILLEGAL DATA ADDRESS"}

muss ich das noch irgendwo etwas einstellen????


per qModMaster funktioniert die Abfrage

[Dolomiti]

Das deutet auf ein Adressproblem hin. Unter www.simplymodbus.ca findet sich folgender Hinweis:

The data address received in the query is not an allowable address for the slave. More specifically, the combination of reference number and transfer length is invalid. For a controller with 100 registers, a request with offset 96 and length 4 would succeed, a request with offset 96 and length 5 will generate exception 02.

Du versuchst anscheinend auf eine "verbotene" Adresse zuzugreifen.
Hast du schon mal einen Mitschnitt mit Wireshark gemacht. Damit kann man recht gut sehen was ioBroker fragt und der Slave antwortet. Du kannst den Mitschnitt auch gerne hier posten und ich versuche zu helfen.

Gruß
Dolomiti

[Farmer-cb]

@Dolomiti
wie kann es sein, wenn im qModMaster genau diese Adressen funktionieren.
der Wireshark muss dann auf dem iobroker laufen oder

[Dolomiti]

Ich hatte an anderer Stelle auch schon mal das Problem, dass ich die Adresse +1 oder -1 eingeben musste. Manche Geräte/Programme fangen bei Null andere bei Eins an zu zählen.
Es wäre zum mitschneidern am einfachsten, wenn Wireshark auf dem ioBroker laufen würde, ansonsten musst du einen Switch haben, der an einem Port alles mitsniffen kann. So habe ich es bisher gemacht.

[Farmer-cb]

so wie es aussieht, habe ich den Fehler gefunden.
hier muss der Haken gesetzt sein:

seitdem läuft es

Dank trotzdem