Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Bluefox]

@tschombe:

ah, cool, danke…

Ich glaub ich hab jetzt das richtige objekt und finde da unter:

native->params folgendes:

{
  "type": "tcp",
  "bind": "192.168.2.20",
  "port": "502",
  "comName": "",
  "baudRate": "9600",
  "dataBits": "8",
  "stopBits": "1",
  "parity": "none",
  "deviceId": "1",
  "slave": "0",
  "showAliases": false,
  "directAddresses": false,
  "round": "2",
  "poll": "5000",
  "recon": "60000",
  "pulsetime": "5000",
  "maxBlock": "20",
  "disInputsOffset": "10001",
  "coilsOffset": "1",
  "inputRegsOffset": "30001",
  "holdingRegsOffset": "40001"
}

muss ich da etwas mit timeout einfügen? `
Habe modbus erweitet. Bitte vom git updaten.

[tschombe]

Super!!!!

Was jetzt geht:

• Timeout konfigurierbar, dadurch bekomme ich jetzt auch über VPN einen Connect!!!

• Sauber Disconnect beim Disablen des Adapters, dadurch wird der Port meines COM-Servers frei!!!

Habe gerade 2 Holding register gelesen (über VPN!!!),

allerdings ist mein Adapter dann wieder auf Rot gesprungen:

Verbunden mit host: falsch

Lebenszeichen: falsch

Verbunden mit modbus: wahr

Nach dem start von iobroker wird der Adapter grün und bleibt es auch, so lange bis ich auf den Tab "Objekte" wechsle um mir

die Datenpunkte des modbus Adapters anschaue, wenn ich dann zurückwechsle auf "Instanzen" ist er rot…

hier das log dazu von der aktuellen Version (und der Adapter steht dank der neu entdeckten Expertenfunktion auf debug):

inMem	2016-10-20 16:52:17.460	debug	message modbus.0.* modbus.0.info.pollTime val=61, ack=true, ts=1476975137459, q=0, from=system.adapter.modbus.0, lc=1476975137459
inMem	2016-10-20 16:52:17.459	debug	message modbus.0.* modbus.0.holdingRegisters.1_value1 val=15, ack=true, ts=1476975137458, q=0, from=system.adapter.modbus.0, lc=1476975137458
inMem	2016-10-20 16:52:17.457	debug	message modbus.0.* modbus.0.holdingRegisters.0_value0 val=0, ack=true, ts=1476975137457, q=0, from=system.adapter.modbus.0, lc=1476975137457
inMem	2016-10-20 16:52:17.402	debug	message modbus.0.* modbus.0.info.connection val=true, ack=true, ts=1476975137398, q=0, from=system.adapter.modbus.0, lc=1476975137398
modbus-0	2016-10-20 16:52:17.398	info	Connected to slave
modbus-0	2016-10-20 16:52:14.215	info	starting. Version 0.4.2 in D:/GitHub/iobroker/node_modules/iobroker.modbus
modbus-0	2016-10-20 16:52:14.191	debug	statesDB connected
modbus-0	2016-10-20 16:52:14.186	debug	objectDB connected
host-conentfst08	2016-10-20 16:52:13.587	info	instance system.adapter.modbus.0 started with pid 11132

Vielleicht liegt es aber auch an der "magern" VPN Verbindung, ich teste auf jeden Fall heut abend nochmal im Heimnetzwerk

[tschombe]

Hi,

so, sitze jetzt zu Hause im Heimnetz und habe folgenden Testaufbau:

Windows Notebook mit ioBroker-Installation (nur admin und modbus Adapter, aktuell aus github ) und Wireshark

iobroker gestartet, modbus Adapter ist deaktiviert.

Dann modbus Adapter aktiviert, modbus Adapter wird grün

wechsel auf Objekte und zurück, modbus Adapter ist rot.

(Verbunden mit host: falsch, Lebenszeichen: falsch, Verbunden mit modbus: wahr)

Der Zustand bleibt dann so, kein neuer "Poll-Versuch" o.ä. des Adapters, keinerlei Logeinträge mehr.

Im Anhang ein Zip-File mit dem zugehörigen Wireshark-Protokoll und dem ioBroker-Log.

Kannst du da irgendetwas erkennen?

[tschombe]

um zwischenzeitlich irgendwie weiter zu kommen hab ich auf meinem Windows testsystem

mal den modbus-slave Simulator im RTU over TCP Modus laufen lassen.

Da verbindet sich der Adapter und bleibt auch auf grün, allerdings funktioniert das Schreiben

der Werte nicht richtig. Teilweise werden die Werte nicht übernommen.

Hier ein Auszug aus dem Log:

inMem	2016-10-20 19:34:32.922	debug	message modbus.0.* modbus.0.holdingRegisters.1_value1 val=44, ack=true, ts=1476984872921, q=0, from=system.adapter.modbus.0, lc=1476984872921
modbus-0	2016-10-20 19:34:31.895	error	Cannot write [0]: [object Object]
inMem	2016-10-20 19:34:31.418	debug	message modbus.0.* modbus.0.holdingRegisters.1_value1 val=48, ack=false, ts=1476984871418, q=0, from=system.adapter.admin.0, lc=1476984871418
inMem	2016-10-20 19:34:28.396	debug	message modbus.0.* modbus.0.holdingRegisters.0_value0 val=6, ack=true, ts=1476984868396, q=0, from=system.adapter.modbus.0, lc=1476984868396
inMem	2016-10-20 19:34:26.892	debug	message modbus.0.* modbus.0.holdingRegisters.0_value0 val=8, ack=false, ts=1476984866891, q=0, from=system.adapter.admin.0, lc=1476984866891
inMem	2016-10-20 19:34:22.419	debug	message modbus.0.* modbus.0.holdingRegisters.1_value1 val=44, ack=true, ts=1476984862418, q=0, from=system.adapter.modbus.0, lc=1476984862418
inMem	2016-10-20 19:34:19.411	debug	message modbus.0.* modbus.0.holdingRegisters.0_value0 val=6, ack=true, ts=1476984859410, q=0, from=system.adapter.modbus.0, lc=1476984859410
inMem	2016-10-20 19:33:56.363	debug	message modbus.0.* modbus.0.info.pollTime val=14, ack=true, ts=1476984836363, q=0, from=system.adapter.modbus.0, lc=1476984836363
inMem	2016-10-20 19:33:56.362	debug	message modbus.0.* modbus.0.holdingRegisters.1_value1 val=55, ack=true, ts=1476984836362, q=0, from=system.adapter.modbus.0, lc=1476984836362
inMem	2016-10-20 19:33:56.361	debug	message modbus.0.* modbus.0.holdingRegisters.0_value0 val=5, ack=true, ts=1476984836361, q=0, from=system.adapter.modbus.0, lc=1476984836361
inMem	2016-10-20 19:33:56.358	debug	message modbus.0.* modbus.0.info.connection val=true, ack=true, ts=1476984836352, q=0, from=system.adapter.modbus.0, lc=1476984836352
modbus-0	2016-10-20 19:33:56.348	info	Connected to slave
modbus-0	2016-10-20 19:33:55.588	info	starting. Version 0.4.2 in D:/GitHub/iobroker/node_modules/iobroker.modbus
modbus-0	2016-10-20 19:33:55.562	debug	statesDB connected
modbus-0	2016-10-20 19:33:55.556	debug	objectDB connected
host-conentfst08	2016-10-20 19:33:50.938	info	instance system.adapter.modbus.0 started with pid 16736

Auch dazu hab ich mal einen Wireshark Mitschnitt generiert.

Anscheinend verhält sich mein "Live" Device etwas anders als der Simulator :( :( :(

[tschombe]

Vielleicht noch hilfreiche Information zum Problem mit dem Simulator:

wenn einmal das Schreiben schiefgegangen ist, bekommt der Adapter auch keine Werteänderungen mit

wenn ich die im Simulator ändere

[Bluefox]

@tschombe:

Vielleicht noch hilfreiche Information zum Problem mit dem Simulator:

wenn einmal das Schreiben schiefgegangen ist, bekommt der Adapter auch keine Werteänderungen mit

wenn ich die im Simulator ändere `
Danke. Bitte noch mal updaten

[tschombe]

Ja, wieder einen Schritt weiter!!!

Das Schreiben hat zur Simulation funktioniert :mrgreen: :mrgreen: :mrgreen:

Habe dann gleich nochmal gegen Live getestet.

Da ist mir aufgefallen, das ich ab und zu einen Timeout bekomme, dann versucht der Adapter anscheinend nicht mehr neu zu verbinden:

inMem	2016-10-20 23:25:08.277	debug	message modbus.0.* modbus.0.info.connection val=false, ack=true, ts=1476998708276, q=0, from=system.adapter.modbus.0, lc=1476998708276
modbus-0	2016-10-20 23:25:08.276	warn	Poll error count: 1 code: {"err":"timeout"}
inMem	2016-10-20 23:25:03.276	debug	message modbus.0.* modbus.0.info.connection val=true, ack=true, ts=1476998703272, q=0, from=system.adapter.modbus.0, lc=1476998703272
modbus-0	2016-10-20 23:25:03.271	info	Connected to slave
modbus-0	2016-10-20 23:25:03.116	info	starting. Version 0.4.3 in D:/GitHub/iobroker/node_modules/iobroker.modbus

Anschliessend passiert nichts mehr

Ich lass jetzt mal die Simulation im Dauertest bis morgen früh laufen

[Bluefox]

@tschombe:

Ja, wieder einen Schritt weiter!!!

Das Schreiben hat zur Simulation funktioniert :mrgreen: :mrgreen: :mrgreen:

Habe dann gleich nochmal gegen Live getestet.

Da ist mir aufgefallen, das ich ab und zu einen Timeout bekomme, dann versucht der Adapter anscheinend nicht mehr neu zu verbinden:

inMem	2016-10-20 23:25:08.277	debug	message modbus.0.* modbus.0.info.connection val=false, ack=true, ts=1476998708276, q=0, from=system.adapter.modbus.0, lc=1476998708276
modbus-0	2016-10-20 23:25:08.276	warn	Poll error count: 1 code: {"err":"timeout"}
inMem	2016-10-20 23:25:03.276	debug	message modbus.0.* modbus.0.info.connection val=true, ack=true, ts=1476998703272, q=0, from=system.adapter.modbus.0, lc=1476998703272
modbus-0	2016-10-20 23:25:03.271	info	Connected to slave
modbus-0	2016-10-20 23:25:03.116	info	starting. Version 0.4.3 in D:/GitHub/iobroker/node_modules/iobroker.modbus

Anschliessend passiert nichts mehr

Ich lass jetzt mal die Simulation im Dauertest bis morgen früh laufen `
Nach einem timeout bei Poll versucht Adapter in 60 Sekunden sich wieder zu verbinden

[tschombe]

Oh, da war ich zu ungeduldig :lol: :lol: :lol:

[tschombe]

Dauertest in der Simulation über nacht bestanden :D

Jetzt zu meinem eigentlichen Problem, der Ankopplung an die Lüftung :cry:

die Kommunikation zwischen Adapter und dem COMServer geht leider nicht.

Ich habe jetzt mal 4 Wireshark-Mitschnitte gemacht. Dabei verwende ich die folgenden

Konstellationen:

Master: Slave: Test: Wireshark-Protokoll

Simulator (ModbusPoll) Simulator (ModbusSlave) GEHT sim-sim.pcapng

iobroker modbus Adapter Simulator (ModbusSlave) GEHT broker-sim.pcapng

Simulator (ModbusPoll) Live (WuT COMServer) GEHT sim-live.pcapng

iobroker modbus Adapter Live (WuT COMServer) FAIL broker-live.pcapng

Ich hoffe du kannst dir mal die Wiresharks anschauen und siehst irgendetwas

Ich weis sonst nicht was ich noch Einstellen oder Testen könnte :cry: :cry: :cry:

[tschombe]

Komisch,

ich hab mir die Wireshark-Mitschnitte mal angeschaut von

broker-live und sim-live. Den Inhalt kann ich leider nicht wirklich interpretieren,

aber die ersten Pakete scheinen ja wirklich identisch zu sein, nur das der

Adapter nach dem 10. Paket anscheinend irgendwie nicht mehr weitermacht :(

Hast du evtl noch eine Idee für mich was ich noch testen könnte oder wie ich an der Stelle weiterkommen kann?

Auf der Gegenstelle (COM-Server) habe ich leider überhaupt keine Diagnosemöglichkeiten :evil:

[Bluefox]

@tschombe:

Komisch,

ich hab mir die Wireshark-Mitschnitte mal angeschaut von

broker-live und sim-live. Den Inhalt kann ich leider nicht wirklich interpretieren,

aber die ersten Pakete scheinen ja wirklich identisch zu sein, nur das der

Adapter nach dem 10. Paket anscheinend irgendwie nicht mehr weitermacht :(

Hast du evtl noch eine Idee für mich was ich noch testen könnte oder wie ich an der Stelle weiterkommen kann?

Auf der Gegenstelle (COM-Server) habe ich leider überhaupt keine Diagnosemöglichkeiten :evil: `
Ich habe mal den Traffic angeschaut. Es währe einfacher, wenn du in beiden Fällen gleiche Register lesen wurdest. Du liest:

• Input Registers bei LIve

• Holding Registers bei Simulator.

Ist das so gewollt?

Unit ID stimmt bei Live?

Live system schickt nicht mal einen Antwort. Einfach schweigt auf der Applikationsebene.

[tschombe]

oh, da ist dann irgendwas an der Konfiguration danebengegangen.

Wenn alles läuft würd ich gerne sowohl HoldingRegister lesen / schreiben (Adresse 0 und 1)

und die InputRegister 0 und 3 lesen.

Fürs erste bin ich jetzt nochmal zurückgegangen auf ein einziges InputRegister (0).

Soll ich nochmal neue Mitschnitte erzeugen?

Ich bin gerade dabei Webstorm zu installieren und mal schauen ob ich irgendwie Debugging zum laufen Bekomme.

Ich bin eigentlich .NET Entwickler, aber die node.js Tools für Visual Studio stürzen bei mir ständig ab :( :( :(

[Bluefox]

@tschombe:

oh, da ist dann irgendwas an der Konfiguration danebengegangen.

Wenn alles läuft würd ich gerne sowohl HoldingRegister lesen / schreiben (Adresse 0 und 1)

und die InputRegister 0 und 3 lesen.

Fürs erste bin ich jetzt nochmal zurückgegangen auf ein einziges InputRegister (0).

Soll ich nochmal neue Mitschnitte erzeugen?

Ich bin gerade dabei Webstorm zu installieren und mal schauen ob ich irgendwie Debugging zum laufen Bekomme.

Ich bin eigentlich .NET Entwickler, aber die node.js Tools für Visual Studio stürzen bei mir ständig ab :( :( :( `
Ich wollte die Pakete vergleichen. Das währe schon praktisch wenn du absolut gleiche Konfigurationen bei sim und live hättest. Achte aber bitte auf UnitID. Ich denke da konnte auch was nicht passen.

[tschombe]

ok, ich mache nochmal neue Aufzeichnungen mit erstmal nur einem inputregister an Adresse 0,

bei meiner Lüftung ist laut Dokumentation die SlaveID = 1, das ist doch die UnitID, oder?

Bei dem COM-Umsetzer davor kann ich da leider nichts konfigurieren.

Bei dem ModbusPoll Client kann ich gar keine UnitID angeben, und bei dem Modbus Slave kann ich einen Haken

(Ignore UnitID setzen, den hab ich jetzt mal extra NICHT gesetzt)

[tschombe]

So, jetzt nochmal die 4 Wireshark-Mitschnitte.

Ich hoffe ich hab immer die richtige Konfiguration verwendet.

Verhalten immer noch das selbe, UnitID ist bei mir auf 1 gesetzt.

Hoffentlich kannst du irgendetwas erkennen, für mich sieht das am Anfang alles gleich aus,

nur das es bei der "Live" Kommunikation irgendwie nicht mehr weitergeht

[tschombe]

Und mir ist gerade wieder was aufgefallen:

Beim LIVE-System steht 201 auf dem Register (stellt eine Temperatur * 10 dar, also 20.1°)

Auf der Simulation steht auf dem Register 15 (hab ich dann mal probehalber auf 20 und wieder auf 15 gesetzt um zu sehen ob wertänderungen

ankommen). Da hab ich im iobroker die 15 bzw 20 gesehen.

Als ich dann umkonfiguriert hab auf das Live-System kam auch einmal die 201 im iobroker an!!! aber dann keine zyklischen refreshes mehr

[Bluefox]

Konnte was finden. Kannst du probieren?

[tschombe]

Ja ich probiere nachher aus, bin allerdings grad unterwegs

[tschombe]

SUPER!!! LESEN GEHT!!!!

Hab gleich Schreiben von Holding Register getestet, da gibt's noch Probleme:

host-lxccuhost2	2016-10-21 20:57:07.333	info	Restart adapter system.adapter.modbus.0 because enabled
host-lxccuhost2	2016-10-21 20:57:07.331	error	instance system.adapter.modbus.0 terminated with code 0 (OK)
modbus-0	2016-10-21 20:57:07.271	info	terminating
TypeError:	2016-10-21 20:57:07.245	error	at TCP.onread (net.js:526:21)
TypeError:	2016-10-21 20:57:07.245	error	at Socket.Readable.push (_stream_readable.js:127:10)
TypeError:	2016-10-21 20:57:07.245	error	at readableAddChunk (_stream_readable.js:165:9)
TypeError:	2016-10-21 20:57:07.245	error	at emitReadable (_stream_readable.js:404:5)
TypeError:	2016-10-21 20:57:07.245	error	at emitReadable_ (_stream_readable.js:408:10)
TypeError:	2016-10-21 20:57:07.245	error	at Socket.EventEmitter.emit (events.js:92:17)
TypeError:	2016-10-21 20:57:07.245	error	at Socket. (_stream_readable.js:746:14)
TypeError:	2016-10-21 20:57:07.245	error	at Socket.EventEmitter.emit (events.js:95:17)
TypeError:	2016-10-21 20:57:07.245	error	at Object. (/opt/iobroker/node_modules/iobroker.modbus/lib/modbus-tcp-rtu-client.js:135:66)
TypeError:	2016-10-21 20:57:07.245	error	Object ��d has no method 'join'
uncaught	2016-10-21 20:57:07.238	error	exception: Object ��d has no method 'join'
TypeError:	2016-10-21 20:57:07.224	error	at TCP.onread (net.js:526:21)
TypeError:	2016-10-21 20:57:07.224	error	at Socket.Readable.push (_stream_readable.js:127:10)
TypeError:	2016-10-21 20:57:07.224	error	at readableAddChunk (_stream_readable.js:165:9)
TypeError:	2016-10-21 20:57:07.224	error	at emitReadable (_stream_readable.js:404:5)
TypeError:	2016-10-21 20:57:07.224	error	at emitReadable_ (_stream_readable.js:408:10)
TypeError:	2016-10-21 20:57:07.224	error	at Socket.EventEmitter.emit (events.js:92:17)
TypeError:	2016-10-21 20:57:07.224	error	at Socket. (_stream_readable.js:746:14)
TypeError:	2016-10-21 20:57:07.224	error	at Socket.EventEmitter.emit (events.js:95:17)
TypeError:	2016-10-21 20:57:07.224	error	at Object. (/opt/iobroker/node_modules/iobroker.modbus/lib/modbus-tcp-rtu-client.js:135:66)
TypeError:	2016-10-21 20:57:07.224	error	Object  has no method 'join'
uncaught	2016-10-21 20:57:07.217	error	exception: Object  has no method 'join'
modbus-0	2016-10-21 20:57:07.182	info	Connected to slave
modbus-0	2016-10-21 20:57:06.171	info	Disconnected from slave 192.168.2.20
modbus-0	2016-10-21 20:57:06.165	error	Cannot write [0]: {"err":"timeout"}
modbus-0	2016-10-21 20:56:49.819	info	Connected to slave
modbus-0	2016-10-21 20:56:49.609	warn	Serial is not available