KNX Verbindung abwarten ... Edomi start nicht erfolgreich

[ShaSam]

Hallo zusammen,
ich bin gerade dabei das erste Edomi Projekt bei mir daheim zu starten. Installation etc. alles erfolgreich. Nun wollte ich meinen IP Router bei Edomi bekannt machen und andocken.

Folgendes habe ich in der edomi.ini eingetragen:

# ---------------------------------------------------------------------
# Modul-Konfiguration: KNX-Gateway
# ---------------------------------------------------------------------

# KNX-IP-Router: IP-Adresse
#       IP-Adresse der KNX-IP-Schnittstelle/-Router.
global_knxRouterIp='192.168.100.11'

global_paSelf='1.2.4'

# KNX-IP-Router: UDP-Port
#       Über diesen Port wird die UDP-Verbindung initialisiert.
global_knxRouterPort=3671

# KNX-IP-Router: gewünschter UDP-Port für den Control-Endpoint
#       Dieser Port ist frei wählbar, darf aber nicht anderweitig genutzt werden.
global_cEserverPort=50000

# KNX-IP-Router: gewünschter UDP-Port für den Data-Endpoint
#       Dieser Port ist frei wählbar, darf aber nicht anderweitig genutzt werden.
global_dEserverPort=50001

# maximale Telegramrate
#       EDOMI sendet mit maximal dieser Telegrammrate auf den KNX-Bus.
#       Je nach Auslastung kann die Telegrammrate auch geringer ausfallen, obwohl ein größerer Wert angegeben wurde.
#       1..oo = Telegramme pro Sekunde (die Telegrammrate sollte i.d.R. nicht größer als 20 sein)
global_knxMaxSendRate=20

# InitScan: maximale Anzahl der Abfragen (Requests)
#       Die entsprechend definierten Gruppenadressen werden ggf. mehrfach abgefragt, falls keine Antwort (Response) erfolgt.
#       1..oo = Anzahl der Abfragen pro Gruppenadresse
global_InitScanTry=5

# InitScan: Anzahl der Überprüfungen pro Abfrage
#       Nach jeder Abfrage wird auf die Antwort der Busteilnehmer gewartet.
#       Jeder Wartezyklus dauert etwa 1 Sekunde.
#       1..oo = Anzahl der Zyklen
global_InitScanTryCheck=30

# InitScan: normale Telegramme (Write) auch akzeptieren
#       Statt ausschließlich auf Response-Telegramme zu warten, können bei Bedarf auch gewöhnliche Write-Telegramme als Antwort akzeptiert werden
#       true = Write-Telegramme auch akzeptieren
#       false = nur Response-Telegramme akzeptieren
global_InitScanWrite=false

# KNX-Gateway: minimale Wartezeit der Hauptschleife
#       0..oo = Millisekunden
global_knxWait=10

# Heartbeat-Intervall
#       Mit diesem Intervall wird der Heartbeat an den KNX-IP-Router gesendet, um die Verbindung aufrecht zu erhalten.
#       1..oo = Interval in Sekunden
global_knxHeartbeat=30

# Heartbeat-Timeout
#       Nach Ablauf dieser Zeit wird eine ausbleibende Heartbeat-ACK als Verbindungsfehler gewertet.
#       1..oo = Timeout in Sekunden
global_knxHeartbeatTimeout=5

# Open-Timeout
#       Nach Ablauf dieser Zeit wird eine ausbleibende Open-ACK als Verbindungsfehler gewertet.
#       1..oo = Timeout in Sekunden
global_knxOpenTimeout=10

# Wartezeit bis zum nächsten Reconnect
#       Nach einem Verbindungsabbruch zum KNX-IP-Router wird i.d.R. einige Sekunden gewartet, bis die Verbindung erneut aufgebaut wird.
#       1..oo = Wartezeit in Sekunden
global_knxReconnectWait=3

# Senden-Timeout
#       Timeout für ACK und Quittungs-Telegramm.
#       1..oo = Timeout in Sekunden
global_knxWriteTimeout=1

# Statistik: Sende-/Empfangsrate in diesem Intervall mitteln
#       Die Sende-/Empfangsrate wird mittelwertig in diesem Intervall berechnet.
#       1..oo = Intervall in Sekunden
global_knxRateInterval=1

# Verhalten bei abweichendem Sequence-Counter
#       Wenn der Sequence-Counter um mehr als 1 Zähler vom Sollwert abweicht, kann die Verbindung optional neu aufgebaut werden.
#       true = Telegramm verwerfen und Verbindung neu aufbauen (nicht Spezifikations-konform!)
#       false = Telegramm verwerfen
global_knxReconnectOnSeqErr=false

# Abweichenden Sequence-Counter protokollieren
#       Wenn der Sequence-Counter vom Sollwert abweicht, wird dies optional protokolliert.
#       true = abweichenden Sequence-Counter protokollieren
#       false = deaktivieren (in der Statistik ebenfalls ignorieren)
global_knxLogSeqErr=true

Habe danach neugestartet und Edomi bleibt bei dem Status: KNX Verbindung abwarten... hängen und Connection wird nicht aufgebaut.

Als IP Router habe ich einen ABB IPR/S3.1.1 mit der IP 192.168.100.11 der EDOMI Server ist in einem anderen Subnetz 192.168.17.12

Routing technisch ist alles sauber. Ich erreiche vom EDOMI Server auch die IP Adresse per Ping.

Was mache ich falsch?

[ShaSam]

folgendes habe ich in den Logs gefunden:

2016-11-07 15:50:07014004KNX1466EDOMI @ CE | DESCRIPTION_REQUEST an 192.168.100.11:3671 / Raw: 06100203000e0801c0a8110cc350Ok2016-11-07 15:50:18002530KNX1466EDOMI @ CE | DESCRIPTION_REQUEST / Timeout nach 10s / ErrMsg: Kein DESCRIPTION_RESPONSE vom Router erhaltenERROR2016-11-07 15:50:18013552KNX1466EDOMI @ CE | DISCONNECT_REQUEST / Raw: 06100209001000000801c0a8110cc350Ok2016-11-07 15:50:18013727KNX1466KNX-Verbindung verloren.ERROR

wenn ich telnet 192.168.100.11 3671 mache bekomme ich weder von meinem Rechner welches im selben Netz hängt oder vom EDOMI Server (hängt in einem anderem Netz) ein Verbindungsfehler. Muss der telnet auf den IP Router gehen?

[vento66]

Zumindest an deinen IP Router! Du willst Dich doch mit dem KNX verbinden oder?

[ShaSam]

Verstehe die Frage nicht ganz. Ich möchte mich mit EDOMI via IP auf den IP Router von ABB verbinden. Mit der ETS5 klappt da auch wunderbar.

[ShaSam]

Habe das Problem herausgefunden. Lag an meiner VM, die ich in VM Ware Workstation gestartet hatte. Dort hatte ich die Einstellung NAT drinnen, welches nicht funktioniert. Habe es auf Bridge umgestellt und es funktioniert. Jetzt kann ich mit großer Freude an die Visualisierung dran gehen