Ankündigung

**henfri** · 11.06.2016, 17:45

Hallo,

über die Verbindung mit der IP-SS und mit dem KNXD im IP-SS Modus funktioniert die Verbindung jetzt. Dennoch: Vielleicht hat jemand eine Idee, warum es via Routing nicht funktioniert. Mit der ETS funktioniert auch Tunneling vom gleichen Rechner.

Das Programmieren der PA funktioniert allerdings weiterhin nicht.
Log aus der Suite:

Code:

[Programmiere] 1.0.51 Bodenfeuchte Temperatur / Relative Luftfeuchtigkeit
[Programmiere] Initialisiere ...
[Programmiere] Lese KOs ...
[Programmiere] Lese Parameter ...
[Programmiere] Fortschritt: 1/36
[Programmiere] Bitte 'Programmieren' Knopf drücken...
[Programmiere] Ein Fehler ist aufgetreten.
de.konnekting.deviceconfig.ProgramException: Problem writing individual address
    at de.konnekting.deviceconfig.Program.program(Program.java:109)
    at de.konnekting.suite.ProgramDialog$4.run(ProgramDialog.java:192)
    at java.lang.Thread.run(Thread.java:745)
    at de.konnekting.suite.BackgroundTask$1.run(BackgroundTask.java:59)
Caused by: de.root1.slicknx.KnxException: Waiting for answer of type de.konnekting.mgnt.protocol0x00.MsgAck timed out.
    at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.expectSingleMessage(ProgProtocol0x00.java:201)
    at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.expectSingleMessage(ProgProtocol0x00.java:226)
    at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.expectAck(ProgProtocol0x00.java:238)
    at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.writeIndividualAddress(ProgProtocol0x00.java:388)
    at de.konnekting.mgnt.KonnektingManagement.writeIndividualAddress(KonnektingManagement.java:70)
    at de.konnekting.deviceconfig.Program.program(Program.java:105)
    ... 3 more

[Programmiere] Fertig! Dauer: 3005 ms

Debug-Info vom Softserial:

Code:

PROGBUTTON toggle
PROGBUTTON 1


knxToolsEvents index=0
internalComObject index=0
buffer[0]       hex=0x0         bin=0
buffer[1]       hex=0x1         bin=1
buffer[2]       hex=0x10        bin=10000
buffer[3]       hex=0x33        bin=110011
buffer[4]       hex=0x0         bin=0
buffer[5]       hex=0x0         bin=0
buffer[6]       hex=0x0         bin=0
buffer[7]       hex=0x0         bin=0
buffer[8]       hex=0x0         bin=0
buffer[9]       hex=0x0         bin=0
buffer[10]      hex=0x0         bin=0
buffer[11]      hex=0x0         bin=0
buffer[12]      hex=0x0         bin=0
buffer[13]      hex=0x0         bin=0
protocolversion=0x0
msgType=0x1
handleMsgReadDeviceInfo


knxToolsEvents index=0
internalComObject index=0
buffer[0]       hex=0x0         bin=0
buffer[1]       hex=0x15        bin=10101
buffer[2]       hex=0x0         bin=0
buffer[3]       hex=0x0         bin=0
buffer[4]       hex=0x0         bin=0
buffer[5]       hex=0x0         bin=0
buffer[6]       hex=0x0         bin=0
buffer[7]       hex=0x0         bin=0
buffer[8]       hex=0x0         bin=0
buffer[9]       hex=0x0         bin=0
buffer[10]      hex=0x0         bin=0
buffer[11]      hex=0x0         bin=0
buffer[12]      hex=0x0         bin=0
buffer[13]      hex=0x0         bin=0
protocolversion=0x0
msgType=0x15
handleMsgReadIndividualAddress


knxToolsEvents index=0
internalComObject index=0
buffer[0]       hex=0x0         bin=0
buffer[1]       hex=0x15        bin=10101
buffer[2]       hex=0x0         bin=0
buffer[3]       hex=0x0         bin=0
buffer[4]       hex=0x0         bin=0
buffer[5]       hex=0x0         bin=0
buffer[6]       hex=0x0         bin=0
buffer[7]       hex=0x0         bin=0
buffer[8]       hex=0x0         bin=0
buffer[9]       hex=0x0         bin=0
buffer[10]      hex=0x0         bin=0
buffer[11]      hex=0x0         bin=0
buffer[12]      hex=0x0         bin=0
buffer[13]      hex=0x0         bin=0
protocolversion=0x0
msgType=0x15
handleMsgReadIndividualAddress


knxToolsEvents index=0
internalComObject index=0
buffer[0]       hex=0x0         bin=0
buffer[1]       hex=0x15        bin=10101
buffer[2]       hex=0x0         bin=0
buffer[3]       hex=0x0         bin=0
buffer[4]       hex=0x0         bin=0
buffer[5]       hex=0x0         bin=0
buffer[6]       hex=0x0         bin=0
buffer[7]       hex=0x0         bin=0
buffer[8]       hex=0x0         bin=0
buffer[9]       hex=0x0         bin=0
buffer[10]      hex=0x0         bin=0
buffer[11]      hex=0x0         bin=0
buffer[12]      hex=0x0         bin=0
buffer[13]      hex=0x0         bin=0
protocolversion=0x0
msgType=0x15
handleMsgReadIndividualAddress


knxToolsEvents index=0
internalComObject index=0
buffer[0]       hex=0x0         bin=0
buffer[1]       hex=0x14        bin=10100
buffer[2]       hex=0x10        bin=10000
buffer[3]       hex=0x33        bin=110011
buffer[4]       hex=0x0         bin=0
buffer[5]       hex=0x0         bin=0
buffer[6]       hex=0x0         bin=0
buffer[7]       hex=0x0         bin=0
buffer[8]       hex=0x0         bin=0
buffer[9]       hex=0x0         bin=0
buffer[10]      hex=0x0         bin=0
buffer[11]      hex=0x0         bin=0
buffer[12]      hex=0x0         bin=0
buffer[13]      hex=0x0         bin=0
protocolversion=0x0
msgType=0x14
handleMsgWriteIndividualAddress
memUpdate: index=1 data=0x10
memUpdate: index=2 data=0x33
DeviceFlags after =0x7F
memUpdate: index=0 data=0x7F
sendAck errorcode=0x0 indexinformation=0x0

Woran kann das liegen?

Gruß,
Hendrik

**Eugenius** · 11.06.2016, 18:08

Die Suite in DEBUG Modus gestartet?
Kommunikationsproblem können an mehreren LAN Adaptern, vor allem VirtualBox, liegen.

**henfri** · 11.06.2016, 18:17

Hallo Eugenius,

VirtualBox ist installiert, läuft aber nicht.
Ich habe die Suite jetzt im DEBUG Modus gestartet. Damit hat dann die Verbindung zum KNXD im IP-SS Modus nicht funktioniert (ging vorher!). KNXD beendet direkt zur IP-SS verbunden --> Bus-Monitor geht.
Programmieren (alles) --> Geht auch.
Programmieren (nur KO) --> geht nicht

Code:

de.konnekting.deviceconfig.ProgramException: Programming failed
    at de.konnekting.deviceconfig.Program.program(Program.java:202)
    at de.konnekting.suite.ProgramDialog$4.run(ProgramDialog.java:192)
    at java.lang.Thread.run(Thread.java:745)
    at de.konnekting.suite.BackgroundTask$1.run(BackgroundTask.java:59)
Caused by: de.root1.slicknx.KnxException: No device responded for enabling prog-mode on address 1.0.51
    at de.konnekting.mgnt.KonnektingManagement.startProgramming(KonnektingManagement.java:96)
    at de.konnekting.deviceconfig.Program.program(Program.java:132)
    ... 3 more
Caused by: de.root1.slicknx.KnxException: Waiting for answer of type de.konnekting.mgnt.protocol0x00.MsgAck timed out.

Das ist echt komisch. Mal funktioniert die Verbindung überhaupt nicht, mal funktioniert sie. Aber nie ging das Programmieren (ich habe ja alle Varianten mehrmals versucht).
Ich bin da etwas ratlos.
Das Debug-Log hängt an.

Gruß,
Hendrik

Angehängte Dateien

KonnektingSuite.log.0.zip (4,3 KB, 0x aufgerufen)

**tuxedo** · 12.06.2016, 10:45

Ich glaube ich muss mal eine Howto für die Suite und Fehleranalyse schreiben...

Um aber mal auf die Problematik hier einzugehen:

1) Was ist bitte eine "IP-SS"? Es gibt nur IP-Schnittstelle und IP-Router ...

2) Wenn die Suite richtig eingestellt ist, dann wird sie, nach dem Start und nach dem ersten Telegramm das sie entdeckt hat, in ihrer Konsole folgendes (auf deutsch) ausgeben:

Code:

KONNEKTING Suite - Version 1.0.0-BETA4-SNAPSHOT Build 2016-06-12_11-26-00 DEBUG MODE!
Operating system: Linux
KNX connection: IP-Router: 1.0.254@224.0.23.12
KNX telegramm discovered. Connection seems to be okay.

Wichtig ist die letzte Zeile. Erscheint das nicht in den ersten 5 Minuten ist entweder nix auf deinem Bus los, oder die Schnittstelle ist falsch konfiguriert.

3) KNX über netzwerk im WLAN ist Problematisch. Stelle sicher dass du eine Kabelverbindung benutzt.

4) Schau in deinen Netzwerkeinstellungen nach, ob es weitere Netzwerkgeräte gibt. Deaktiviere alle die du definitiv nicht brauchst. Mit beta3 kann es sein dass das falschen netzwerkgerät gewählt wird, weil es sich in den Windows-Einstellungen in der Hierarchie nach vorne gemogelt hat. Die Suite nimmt automatisch das mit der höchsten Prio (sieht man an der Metrik in der Routing-Tabelle von Windows)

5) Wenn dein Sketch mit Debug-Ausgaben läuft, dann muss die Suite auch im Debug Modus laufen... Es gibt zwei Batch-Files zum starten. Eine mit DEBUG und eine ohne. Welcher Modus aktiv ist, erkennst du an der ersten Zeile in der Konsole der Suite:

KONNEKTING Suite - Version 1.0.0-BETA4-SNAPSHOT Build 2016-06-12_11-26-00 DEBUG MODE!

Läuft die Suite im falschen Modus, passt das Timing zwischen Suite und Hardware nicht, und das Programmieren geht schief. Deinem Log-zufolge, läuft die Suite aber im Debug-Modus.

Deinem Log zufolge hat das Programmierung auch mind. 1x geklappt.

Logs sollte man nicht einfach unkommentiert posten. Es ist einfacher ein Log zu lesen wenn man weiß was der User gerade gemacht hat, bzw. machen wollte.
Das Ende des Logs sieht so aus, als ob du nach dem erfolgreichen programmieren inkl. PA nochmal programmieren wolltest, aber dieses mal ohne PA. Und irgendwie scheinst du zu ungeduldig gewesen zu sein und hast während die eine Aktion lief, eine weitere angestoßen?

Fehler bitte einzeln und isoliert betrachten. Zum nachvollziehen von Fehler ist es kein Schaden, wenn du die Suite frisch startest und auf kürzestem Weg den Fehler versucht zu reproduzieren und dann die Suite wieder beendest. Dann die .log.0 sichern und dazu schreiben was genau du gemacht hast und wie sich der Fehler äußert.

Für beta4 wird es hier in Sachen logging nochmal eine kleine Verbesserung geben, die die Analyse nochmals einfacher macht.

Zum Thema "unzuverlässiges" Programmieren an sich:

Öffne in Windows eine Kommandozeile und führe "ipconfig /all", gefolgt von "route print" aus. Beide Ausgaben rauskopieren und hier posten.

**henfri** · 12.06.2016, 11:10

Moin

Zitat von tuxedo Beitrag anzeigen

Um aber mal auf die Problematik hier einzugehen:

1) Was ist bitte eine "IP-SS"? Es gibt nur IP-Schnittstelle und IP-Router ...

Ja, SS=Abkürzung Schnittstelle. Sorry für die Verwirrung.

2) Wenn die Suite richtig eingestellt ist, dann wird sie, nach dem Start und nach dem ersten Telegramm das sie entdeckt hat, in ihrer Konsole folgendes (auf deutsch) ausgeben:

Code:

KONNEKTING Suite - Version 1.0.0-BETA4-SNAPSHOT Build 2016-06-12_11-26-00 DEBUG MODE!
Operating system: Linux
KNX connection: IP-Router: 1.0.254@224.0.23.12
KNX telegramm discovered. Connection seems to be okay.

Und das kam meist nicht. Sondern die oben inline geposteten Fehlermeldungen.
Das liegt -wenn ich dich richtig verstanden habe NICHT an DEBUG vs. nicht-Debug, denn das ist erst relevant beim Programmieren. Wahrscheinlicher ist, dass es an der Netzwerk-Verbindung liegt (welcher Ethernet Adapter) Richtig?

4) Schau in deinen Netzwerkeinstellungen nach, ob es weitere Netzwerkgeräte gibt. Deaktiviere alle die du definitiv nicht brauchst. Mit beta3 kann es sein dass das falschen netzwerkgerät gewählt wird, weil es sich in den Windows-Einstellungen in der Hierarchie nach vorne gemogelt hat. Die Suite nimmt automatisch das mit der höchsten Prio (sieht man an der Metrik in der Routing-Tabelle von Windows)

Ok, daran kann es durchaus liegen. Momentan funktioniert es zuverlässig in allen drei Modi (Routing (KNXD), IP-Schnittstelle ('physische'), IP-Schnittstelle (KNXD)). Connection seems ok kommt sofort.
Hier ipconfig /all und route print:
http://pastebin.com/raw/XFLnkJwc

5) Wenn dein Sketch mit Debug-Ausgaben läuft, dann muss die Suite auch im Debug Modus laufen... Es gibt zwei Batch-Files zum starten. Eine mit DEBUG und eine ohne. Welcher Modus aktiv ist, erkennst du an der ersten Zeile in der Konsole der Suite:

Daran wird mein Programmier-Problem liegen.
Idee/Vorschlag für die Beta4: Kann man das nicht detektieren?

Läuft die Suite im falschen Modus, passt das Timing zwischen Suite und Hardware nicht, und das Programmieren geht schief. Deinem Log-zufolge, läuft die Suite aber im Debug-Modus.

Jetzt ja. Anfangs immer im normalen Modus.

Deinem Log zufolge hat das Programmierung auch mind. 1x geklappt.

Ja; anfangs war immer das Problem, dass keine KNX-Verbindung ('connection seems ok' kam nicht; stattdessen eine Fehlermeldung).
Als die KNX Verbindung klappte, gab es dann wahrscheinlich das Timing-Problem.

Logs sollte man nicht einfach unkommentiert posten. Es ist einfacher ein Log zu lesen wenn man weiß was der User gerade gemacht hat, bzw. machen wollte.
Fehler bitte einzeln und isoliert betrachten. Zum nachvollziehen von Fehler ist es kein Schaden, wenn du die Suite frisch startest und auf kürzestem Weg den Fehler versucht zu reproduzieren und dann die Suite wieder beendest. Dann die .log.0 sichern und dazu schreiben was genau du gemacht hast und wie sich der Fehler äußert.

Sorry. Werde ich verbessern.

Das Ende des Logs sieht so aus, als ob du nach dem erfolgreichen programmieren inkl. PA nochmal programmieren wolltest, aber dieses mal ohne PA. Und irgendwie scheinst du zu ungeduldig gewesen zu sein und hast während die eine Aktion lief, eine weitere angestoßen?

Das kann ich nciht ausschließen.

**tuxedo** · 12.06.2016, 11:28

Zitat von henfri Beitrag anzeigen

Und das kam meist nicht. Sondern die oben inline geposteten Fehlermeldungen.
Das liegt -wenn ich dich richtig verstanden habe NICHT an DEBUG vs. nicht-Debug, denn das ist erst relevant beim Programmieren. Wahrscheinlicher ist, dass es an der Netzwerk-Verbindung liegt (welcher Ethernet Adapter) Richtig?

Richtig.

Ok, daran kann es durchaus liegen. Momentan funktioniert es zuverlässig in allen drei Modi (Routing (KNXD), IP-Schnittstelle ('physische'), IP-Schnittstelle (KNXD)). Connection seems ok kommt sofort.
Hier ipconfig /all und route print:
http://pastebin.com/raw/XFLnkJwc

Da sieht man auch schon den Fehler:

Du hast Virtuaklbox UND VMWare installiert. Beide bringen Netzwerkadapter mit sich (VirtualBox Host-Only Ethernet Adapter und VMware Virtual Ethernet Adapter for VMnet1 und VMware Virtual Ethernet Adapter for VMnet8).

In der Routiungtabellle findet man:

Code:

        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.56.1    266
        224.0.0.0        240.0.0.0   Auf Verbindung    192.168.177.42    266
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.253.1    276
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.31.1    276

224.0.0.0 ist das Multicast-Netzwerk, welches auch für KNX genutzt wird.

Man sieht dass bevor deine eigentliche Netzwerkverbindung (192.168.177.42) in der Liste auftaucht, der Virtualbox Host Only Adapter auftaucht (192.168.56.1).

Die Suite fängt an auf 224.x.x.x zu kommunizieren, und überlässt es dem Betriebssystem das richtige Netzwerkinterface auszuwählen. In deinem Fall landet die Kommmunikation auf dem Virtualbox Netzwerkinterface... Und da hängt halt kein KNX dran.

Kurz gesagt: Dein Windows ist falsch konfiguriert. Die Suite kann da eigentlich nix für.

Dennoch wird die beta4 in der Lage sein zu schauen auf welchem Netzwerkinterface die KNX Verbindung vorhanden ist, und dann Netzwerkinterface-spezifisch verbinden. Bis dahin: Unnötige Netzwerkinterfaces abschalten!

5) Wenn dein Sketch mit Debug-Ausgaben läuft, dann muss die Suite auch im Debug Modus laufen... Es gibt zwei Batch-Files zum starten. Eine mit DEBUG und eine ohne. Welcher Modus aktiv ist, erkennst du an der ersten Zeile in der Konsole der Suite:

Daran wird mein Programmier-Problem liegen.
Idee/Vorschlag für die Beta4: Kann man das nicht detektieren?

Nein, nicht direkt. Wenn der Sketch mit Debug läuft, dann reagiert er langsamer, bzw. gibt Antworten nicht sofort zurück. Die Suite kann das nicht direkt detektieren. Durch langwieriges try&error könnte sie ggf. das passende Timing herausfinden, aber 1) ist das kein normaler Anwendungsfall und 2) dauert das programmieren dann noch länger.

Debug-Modus ist eben Debug-Modus und kein Standardfall. Was man tun könnte, ist das in der Suite konfigurierbar machen. Man könnte beim ersten Start der Suite fragen in welchem Modus sie laufen soll, und ob bei jedem Start gefragt werden soll. Aber auch hier muss man die richtige Entscheidung treffen, sonst funktioniert das nicht.

Als die KNX Verbindung klappte, gab es dann wahrscheinlich das Timing-Problem.

Scheint so. Aber deiner "ipconfig /all" Ausgabe zufolge, nutzt du eine WLAN Verbindung?
KNX über WLAN ist fehleranfällig. Das geht manchmal, und öfters mal nicht. Schuld ist oft der Accespoint und auch noch das verwendete Multicast-protokoll. Es ist eben nicht sichergestellt, dass ein UDP-Datenpaket auch ankommt. Man sendet es ab und muss darauf vertrauen DASS es ankommt. Im LAN geht das in 99,9% der Fälle gut. Im WLAN ist das Risiko größer dass Pakete verschluckt werden.
Ich schaffs bei mir recht selten über den Laptop über WLAN mit der ETS ein Gerät zu programmieren. Über LAN klappt's immer.

Vielleicht bau ich mal in Zukunft, basierend auf dem REG-Controller eine KNX Schnittstelle die TCP verwendet und dann auch über WLAN klappt (ist dann aber nur für Konnekting und nicht für die ETS).

**henfri** · 12.06.2016, 13:00

Hallo,

vielen Dank für die Analyse.
Ich werde dann in Zukunft alle Adapter deaktivieren und LAN verwenden.
Vielleicht wäre hier ein Hinweis beim Start der Suite möglich (wenn die Konfiguration nicht passt).

Man sieht dass bevor deine eigentliche Netzwerkverbindung (192.168.177.42) in der Liste auftaucht, der Virtualbox Host Only Adapter auftaucht (192.168.56.1).

Die Suite fängt an auf 224.x.x.x zu kommunizieren, und überlässt es dem Betriebssystem das richtige Netzwerkinterface auszuwählen. In deinem Fall landet die Kommmunikation auf dem Virtualbox Netzwerkinterface... Und da hängt halt kein KNX dran.

Kurz gesagt: Dein Windows ist falsch konfiguriert. Die Suite kann da eigentlich nix für.

Weisst du, wie die ETS das umgeht? Da habe ich keine Probleme.

Gruß,
Hendrik

**henfri** · 12.06.2016, 14:45

Hallo,

ich habe jetzt gerade noch einmal eine Programmierung versucht.
Suite und Arduino laufen in Debug mode.
Auf Arduino in KNX-Programmiermodus gewechselt (D3).
Das Programmieren endet mit

Code:

[Programmiere] Fortschritt: 34/36
[Programmiere] Beende Programmierung...
[Programmiere] Ein Fehler ist aufgetreten.
de.konnekting.deviceconfig.ProgramException: Programming failed
    at de.konnekting.deviceconfig.Program.program(Program.java:202)
    at de.konnekting.suite.ProgramDialog$4.run(ProgramDialog.java:192)
    at java.lang.Thread.run(Thread.java:745)
    at de.konnekting.suite.BackgroundTask$1.run(BackgroundTask.java:59)
Caused by: de.root1.slicknx.KnxException: Waiting for answer of type de.konnekting.mgnt.protocol0x00.MsgAck timed out.
    at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.expectSingleMessage(ProgProtocol0x00.java:201)
    at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.expectSingleMessage(ProgProtocol0x00.java:226)
    at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.expectAck(ProgProtocol0x00.java:230)
    at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.writeProgrammingMode(ProgProtocol0x00.java:418)
    at de.konnekting.mgnt.KonnektingManagement.stopProgramming(KonnektingManagement.java:132)
    at de.konnekting.deviceconfig.Program.program(Program.java:190)
    ... 3 more

[Programmiere] Fertig! Dauer: 54620 ms

Log der Suite:
http://pastebin.com/c4tTZcNB

Log vom Debug-Port des Arduino:
http://pastebin.com/ipLynx3z

Verbunden bin ich per LAN-Kabel.
Das Problem ist reproduzierbar (immer bei Schritt 34).

Noch eine Frage:
So, wie es jetzt ist, muss man für das Ändern von KO und Parametern immer an den Programmier-Taster, oder? Das ist für meinen Anwendungszweck recht unpraktisch :-(

Gruß,
Hendrik

**tuxedo** · 12.06.2016, 19:23

Weisst du, wie die ETS das umgeht? Da habe ich keine Probleme.

Die ETS testet alle Netzwerkinterfaces durch. Für beta4 bin ich dran dass die Suite das auch kann.

So, wie es jetzt ist, muss man für das Ändern von KO und Parametern immer an den Programmier-Taster, oder?

Nein, nur der "rote" knopf in der Suite braucht den Prog-Button am Device. Alles andere nimmt die physikalische Adresse des Geräts. D.h. nur beim ersten mal muss man den roten knopf und den ProgButton benutzen. Danach nicht mehr.

Deinen Fehler muss ich mir mal in einer ruhigen Minute anschauen.

**heckmannju** · 17.07.2016, 16:15

Hi,

Gibt es eine Möglichkeit irgentwo anzugeben an welche Netwerkschnittstelle man will ich kann die VMWare Schnittstellen nicht einfach abschalten da ich sie brauche.

Oder kann meine Fehlermeldung beim Start von Konnekting von was anderes kommen? Konfiguriert ist die verbindung mit IP-Interface mit einer noch nicht belegten PA 1.1.248

Mit TPUART ist da nur der USBStick TUL von Busware gemeint?

Code:

KONNEKTING Suite - Version 1.0.0-BETA3 Build 2016-04-13_09-07-40
Operating system: Windows 7
Fehler beim Öffnen der KNX Verbindung: TUNNELING
de.root1.slicknx.KnxException: Error connecting to KNX: timeout connecting to control endpoint wiregate945/192.168.102.26:3671
    at de.root1.slicknx.Knx.<init>(Knx.java:174)
    at de.konnekting.suite.Main.<init>(Main.java:168)
    at de.konnekting.suite.Main$21.run(Main.java:764)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Caused by: tuwien.auto.calimero.exception.KNXTimeoutException: timeout connecting to control endpoint wiregate945/192.168.102.26:3671
    at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:188)
    at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.<init>(KNXnetIPTunnel.java:131)
    at tuwien.auto.calimero.link.KNXNetworkLinkIP.<init>(KNXNetworkLinkIP.java:142)
    at tuwien.auto.calimero.link.KNXNetworkLinkIP.<init>(KNXNetworkLinkIP.java:180)
    at de.root1.slicknx.Knx.<init>(Knx.java:167)
    ... 16 more

Viele Grüsse
Jürgen

**tuxedo** · 18.07.2016, 06:56

Hallo Jürgen,

die Lösung des "mehrere Netzwerkschnittstellen"-Proböems kommt mit beta4. Dauert noch ein bisschen.
Du kannst ggf. bis dahin die Metrik der einzelnen Netzwerkschnittstellen so anpassen, dass die Multicast-adressen primär über die richtige Netzwerkschnittstelle geleitet werden. Dann musst du deine VMWAre Schnittstelle nicht ganz abschalten.

Siehe auch: http://serverfault.com/questions/464...-the-wrong-one

Mit TPUART ist da nur der USBStick TUL von Busware gemeint?

Wenn die passende Firmeare drauf ist: Ja, unter anderem.

TPUART meint alles, was einen KNX Transceiver als TPUART drin hat und direkt dessen Protokoll spricht. Das kann also auch ein Siemens BCU mit angeschlossenem RS232-USB Adapter sein.

**tuxedo** · 14.09.2016, 10:00

Die Netzwerkschnittstellenerkennung in beta4 ist nun "fertig" und kann getestet werden. Bei mir funktioniert's sowohl unter Windows als auch Linux.

Gibt es hier freiwillige die die beta4 der Suite dahingehend vorab schon testen und feedback geben würden?
Es geht eigentlich nur drum die Suite zu entpacken+starten, des Setup-Dialog aufrufen und zwei Dinge testen:

1. Den Auto-Erkennen-Knopf... Damit sollte die passende Schnittstelle eigentlich immer gefunden werden
2. Das manuelle Auswählen der Schnittstelle über eine DropDown Box.

Nach dem anwenden der Einstellung wird die Suite neu gestartet und geschaut ob die Suite dann nach dem Start die Verwendung der richtigen Schnittstelle meldet und auch von einem Erfolg bzgl. des Empfangs von Telegrammen berichtet.

**eghetto** · 14.09.2016, 10:22

Ich werde versuchen mal heute Abend zu testen. Das ursprüngliche Problem lässt sich - glaube ich - initial auf meine Anfrage zurückführen. Gibt es irgendwo eine vorbereitete 32bit-Version für Windows zum Download?

**tuxedo** · 14.09.2016, 10:37

Welche initiale Anfrage? Sehe im Thread hier nix (sorry, hab ein hirn wie ein sieb).

Download-Link würden die tester per PN bekommen. Ist ja quasi die beta zur beta4.

Ankündigung

Keine KNX Verbindung / Problem writing individual address

Keine KNX Verbindung / Problem writing individual address

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar