[Fehler] ModBus-Adapter 2.0.3

Stabilostick

Ups, du hast verschlimmbessert. Die anderen Adapter (Master) bringen jetzt den folgenden Fehler:

2018-06-21 11:02:26.973 - info: host.ARBEITSZIMMER instance system.adapter.modbus.1 started with pid 25028
2018-06-21 11:02:27.412 - debug: modbus.1 objectDB connected
2018-06-21 11:02:27.422 - debug: modbus.1 statesDB connected
2018-06-21 11:02:27.436 - info: modbus.1 starting. Version 2.0.3 in C:/dev/iobroker/node_modules/iobroker.modbus, node: v8.11.1
2018-06-21 11:02:27.951 - info: history.0 enabled logging of modbus.1.inputRegisters.30775_AC_Leistung_Gesamt
2018-06-21 11:02:27.992 - info: history.0 enabled logging of modbus.1.inputRegisters.30803_Netzfrequenz
2018-06-21 11:02:28.032 - info: history.0 enabled logging of modbus.1.inputRegisters.30843_Batterie_Strom
2018-06-21 11:02:28.072 - info: history.0 enabled logging of modbus.1.inputRegisters.30845_Batterie_SOC
2018-06-21 11:02:28.112 - info: history.0 enabled logging of modbus.1.inputRegisters.30849_Batterie_Temperatur
2018-06-21 11:02:28.152 - info: history.0 enabled logging of modbus.1.inputRegisters.30851_Batterie_Spannung
2018-06-21 11:02:28.192 - info: history.0 enabled logging of modbus.1.inputRegisters.30855_Batterie_SetSpannung
2018-06-21 11:02:28.232 - info: history.0 enabled logging of modbus.1.inputRegisters.30861_Last_Leistung
2018-06-21 11:02:28.272 - info: history.0 enabled logging of modbus.1.inputRegisters.30867_Einspeiseleistung
2018-06-21 11:02:28.312 - info: history.0 enabled logging of modbus.1.inputRegisters.30869_PV_Gesamtleistung
2018-06-21 11:02:28.352 - info: history.0 enabled logging of modbus.1.inputRegisters.30873_Einverbrauchserhöhung
2018-06-21 11:02:29.514 - error: modbus.1 Socket Error
2018-06-21 11:02:29.514 - error: modbus.1 Client in error state.
2018-06-21 11:02:29.514 - warn: modbus.1 On error: {"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect","address":"127.0.0.1","port":502}
2018-06-21 11:02:29.515 - debug: modbus.1 Socket closed with error
2018-06-21 11:02:29.515 - debug: modbus.1 Cleaning up request fifo.
2018-06-21 11:02:30.521 - debug: modbus.1 Closing client on purpose.
2018-06-21 11:02:30.521 - debug: modbus.1 Closing client on purpose.

apollon77

Ja ich sehe den grund … aber da bin ich jetzt raus ...

@Bluefus muss da ran. Das kann so nicht gehen ...

Stabilostick

Achtung, die von Bluefox auf Github eingestellte Version 2.0.4 ist weiterhin fehlerbehaftet. Es funktionieren bei TCP-Typ jetzt weder Master- noch-Slave-Konfigurationen. Damit Master wieder geht, in Datei "modbus-client-tcp.js" die Zeile 25 von

tcp.host = tcp.bind || 'localhost';

nach

tcp.host = tcp.host || 'localhost';

ändern.

Zudem sind mindestens in der Datei "slave.js" ab Zeile 150 weitere Anpassungen nötig, damit der Wert von "tcp" definiert ist:

     options: {
     tcp: {
            hostname: '127.0.0.1',  //??????
            port: parseInt(options.config.tcp.port, 10) || 502
     }},

Übrig bleibt dann als nächstes die undefinierte "server"-Variable/Objekt? in

.compose(server.tcp.complete)

ein paar Zeilen weiter unten.

Da gebe ich erst einmal auf… Ich kann leider kein Javascript.

JackWolfskind

Habe auch gerade festgestellt das Modbus TCP mit der Version 2.0.4 nicht mehr geht und daher ein Issue auf github aufgemacht…

Update:

Mit der 2.0.6 ist Modbus TCP wieder gefixt!

Stabilostick

Nur der Master-Typ. Slave braucht noch.

Stabilostick

Bluefox hat eine neue Revision der v2.0.6 auf Guthub bereitgestellt. Der TCP-Slave Modus soll laut seiner Angabe gefixed sein.

Zwar sind die augenscheinlichen Exceptions jetzt weg. Leider findet bei mir aber mit der neuen Version keine Kommunikation statt. Der Status des Adapers bleibt auf gelb stehen.

Ich verwende diese Konfiguration:

In der Anleitung zum Adapter steht:

Partner IP Address = IP address of modbus partner.

Port = TCP Port of modbus partner if configured as master (client) or own port if configured as slave(server).

Die Eingänge sind Holding Registers.

Mit diesen Einstellungen hat V1.1.1 des Adpaters funktioniert. Jetzt wirft der Adapter v2.0.6(neu) den Fehler

2018-06-28 11:56:28.913 - info: host.ARBEITSZIMMER instance system.adapter.modbus.2 started with pid 45604
2018-06-28 11:56:29.331 - debug: modbus.2 objectDB connected
2018-06-28 11:56:29.342 - debug: modbus.2 statesDB connected
2018-06-28 11:56:29.342 - info: modbus.2 starting. Version 2.0.6 in C:/dev/iobroker/node_modules/iobroker.modbus, node: v8.11.1
2018-06-28 11:56:29.612 - debug: modbus.2 Slave ready to start
2018-06-28 11:56:29.682 - debug: modbus.2 server is listening on port
2018-06-28 11:56:29.682 - debug: modbus.2 initiating read coils request handler.
2018-06-28 11:56:29.682 - debug: modbus.2 setting request handler
2018-06-28 11:56:29.682 - debug: modbus.2 initiating read discrete inputs request handler.
2018-06-28 11:56:29.682 - debug: modbus.2 setting request handler
2018-06-28 11:56:29.682 - debug: modbus.2 initiating read holding registers request handler.
2018-06-28 11:56:29.682 - debug: modbus.2 setting request handler
2018-06-28 11:56:29.682 - debug: modbus.2 initiating read input registers request handler.
2018-06-28 11:56:29.682 - debug: modbus.2 setting request handler
2018-06-28 11:56:29.682 - debug: modbus.2 initiating write multiple coils request handler.
2018-06-28 11:56:29.682 - debug: modbus.2 setting request handler
2018-06-28 11:56:29.682 - debug: modbus.2 initiating write multiple registers request handler.
2018-06-28 11:56:29.682 - debug: modbus.2 setting request handler
2018-06-28 11:56:29.682 - debug: modbus.2 initiating write single coil request handler.
2018-06-28 11:56:29.682 - debug: modbus.2 setting request handler
2018-06-28 11:56:29.682 - debug: modbus.2 initiating write single register request handler.
2018-06-28 11:56:29.682 - debug: modbus.2 setting request handler
2018-06-28 11:56:29.692 - error: modbus.2 uncaught exception: listen EADDRNOTAVAIL 192.168.179.28:502
2018-06-28 11:56:29.692 - error: modbus.2 Error: listen EADDRNOTAVAIL 192.168.179.28:502
at Object._errnoException (util.js:1022:11)
at _exceptionWithHostPort (util.js:1044:20)
at Server.setupListenHandle [as _listen2] (net.js:1350:19)
at listenInCluster (net.js:1408:12)
at doListen (net.js:1517:7)
at _combinedTickCallback (internal/process/next_tick.js:141:11)
at process._tickCallback (internal/process/next_tick.js:180:9)
2018-06-28 11:56:29.692 - info: modbus.2 terminating
2018-06-28 11:56:29.703 - error: Caught by controller[0]: { Error: listen EADDRNOTAVAIL 192.168.179.28:502
2018-06-28 11:56:29.703 - error: Caught by controller[0]: at Object._errnoException (util.js:1022:11)
2018-06-28 11:56:29.703 - error: Caught by controller[0]: at _exceptionWithHostPort (util.js:1044:20)
2018-06-28 11:56:29.703 - error: Caught by controller[0]: at Server.setupListenHandle [as _listen2] (net.js:1350:19)
2018-06-28 11:56:29.703 - error: Caught by controller[0]: at listenInCluster (net.js:1408:12)
2018-06-28 11:56:29.703 - error: Caught by controller[0]: at doListen (net.js:1517:7)
2018-06-28 11:56:29.703 - error: Caught by controller[0]: at _combinedTickCallback (internal/process/next_tick.js:141:11)
2018-06-28 11:56:29.703 - error: Caught by controller[0]: at process._tickCallback (internal/process/next_tick.js:180:9)
2018-06-28 11:56:29.703 - error: Caught by controller[0]: code: 'EADDRNOTAVAIL',
2018-06-28 11:56:29.703 - error: Caught by controller[0]: errno: 'EADDRNOTAVAIL',
2018-06-28 11:56:29.703 - error: Caught by controller[0]: syscall: 'listen',
2018-06-28 11:56:29.703 - error: Caught by controller[0]: address: '192.168.179.28',
2018-06-28 11:56:29.703 - error: Caught by controller[0]: port: 502 }
2018-06-28 11:56:29.703 - error: host.ARBEITSZIMMER instance system.adapter.modbus.2 terminated with code 0 (OK)
2018-06-28 11:56:29.703 - info: host.ARBEITSZIMMER Restart adapter system.adapter.modbus.2 because enabled

Auf dem Modbus-Master 192.168.179.28 ist der Port 502 nicht geöffnet (war noch nie).

Die Konfiguration auf dem Master, die mit Version 1.1.1 funktioniert hat, sieht so aus:

Die Dokumentation des Masters sagt dazu:

IP, Gerärt, Funktion, Adresse = Eingabe der IP-Adresse und der herstellerspezifischen Angaben des Modbus-Geräts (= Slave), an das der Wert gesendet wird

Was nun? Mache ich etwas falsch? Muss ich 127.0.0.1 angeben beim Slave (funktioniert aber auch nicht!)?

apollon77

du hast bei ioberoker in der Konfig aber "Master" ausgewählt. Wenn DU lesen willst bist Du eher ein Slave oder ?!

Stabilostick

Zwischenzeitlich ging der Master Mode bei der Version 2.0.6 (ohne neu) auch nicht. Im vorletzten Post zeige ich die Slave-Konfiguration für 2.0.6neu. Und ich will nicht lesen. Der ferne Master 192.168.179.28 schreibt in mich (192.168.179.56) als Slave rein.

Also dürfte der ioBroker also gar nicht bei einer Slave-Konfiguration auf den Master zugreifen, oder?

Wenn ich das so richtig verstanden habe…

Stabilostick

In der Version 1.1.2 stand noch in der Datei modbus-tcp-client.js

            if (!this.protocolVersion) { this.protocolVersion = 0; }
            if (!this.port) { this.port = 502; }
            if (!this.host) { this.host = 'localhost'; }
            if (!this.autoReconnect) { this.autoReconnect = false; }
            if (!this.reconnectTimeout) { this.reconnectTimeout = 0; }

Edit: Quatsch, was ich hier gerade schreibe. Steht nicht im Zusammenhang. Der Server-Prozess in modbus-tcp-server.js macht da nichts anderes:

            if (!this.port) {
                this.port = 502;
            }

            if (!this.hostname) {
                this.hostname = '0.0.0.0';
            }
          server.listen(this.port, this.hostname, function (err) {
[...]

Stabilostick

Der Modbus-Master hat auch ein Log.

2018.06.28 23:10:01 [R854/V1.30.2] ( 39) Message: #FFFFFFFA Cannot connect to Modbus device

Die Netzwerksockets sind am Master wie folgt:

Stabilostick

Setze ich die Partner-ID auf 127.0.0.1, dann überwacht der ioBroker (192.168.179.56) den lokalen Port 502:

 TCP    127.0.0.1:502          0.0.0.0:0              ABHÖREN       [node.exe]

Jedoch sagt der Master weiterhin, dass er keine Verbindung zum Slave aufbauen kann.

Stabilostick

Das zeigt Ananas, ein Modbus Slave, gestartet auf dem ioBroker-Rechner an: 7446_2018-06-29_12_09_07-ananas_-modbus_tcp_server_at__192.168.179.56.png Der Modbus-Master funktioniert also.

Stabilostick

Oookkkkkkaaaayyyyy,

wenn ich die Parter-ID in der Modbus-Adapter-Konfiguration beim Typ Slave auf 0.0.0.0 stelle, funktioniert augenscheinlich die Kommunikation (muss noch weiter testen).

Hmm, muss das (jetzt) so sein?

Bluefox

Es ist ein Fehler in der Dialog beim Label.

Partner IP muss "Eigene IP" heissen.

Stabilostick

Aber mit 127.0.0.1 geht es nicht.

Slave geht nur mit 0.0.0.0 (alle Interfaces?) oder 192.168.179.56, also ein bestimmtes lokales Netzwerk-Interface.

Könntest Du bitte auch die Doku in der README.md anpassen:

Bislang:

Partner IP Address = IP address of modbus partner.

Port = TCP Port of modbus partner if configured as master (client) or own port if configured as slave(server).

Danke für Deine super Leistungen rund um den ioBroker!

NEWS

[Fehler] ModBus-Adapter 2.0.3

Support us

1.1k
Online

31.2k
Users

78.4k
Topics

1.2m
Posts

NEWS

[Fehler] ModBus-Adapter 2.0.3

Support us

1.1kOnline

31.2kUsers

78.4kTopics

1.2mPosts

1.1k
Online

31.2k
Users

78.4k
Topics

1.2m
Posts