USB-KNX Interface hängt

[RichiAviator]

Liebe KNX-Freunde
Seit einigen Wochen habe ich unregelmässig Ausfälle meines USB-KNX Interfaces. Das äussert sich so, dass zwar Telegramme von meinem Hausserver zum Bus gesendet werden. Die umgekehrte Richtung funktioniert aber gar nicht mehr. Es werden also keine Telegramme der Temperaturfühler und Statusinformationen der Aktoren übertragen, so dass er Server blind ist.
Im Gruppenmonitor der ETS läuft die Anlage problemlos weiter. Es werden alle Telegramme (Temperaturfühler und Status-Infos) dargestellt, aber keine über USB übertragen.
Ein Rausziehen und wieder Reinstöpseln des Steckers am Interface löst das Problem jeweils, ist aber keine Lösung auf Dauer.

Ich verwende als USB Interface den Lingg&Jancke Kombibaustein "eibDUO plus", einen Schaltaktor mit Bus-Spannungsversorgung und USB Interface (siehe Bild).
Darin eingebaut ist offenbar ein Weinzierl Interface (VendorID 0e77, ProductID 014).

Nun meine Fragen:
- Hatte jemand ähnliche Erlebnisse und gibt es dafür Lösungen?
- Was kann zu einem solchen Effekt führen?
- Wie kann ich die Ursache weiter einkreisen?
- Kann ein blockiertes USB-Interface von der Serverseite her oder über die ETS reaktivieren?

Herzlichen Dank im Voraus für eure Unterstützung
Richi

[Klaus Gütter]

Hallo Richi,

was ist das für ein "Hausserver"? Bietet der vielleicht irgendwelche Diagnosemöglichkeiten?

Gruß, Klaus

[RichiAviator]

Hallo Klaus

Ja, der Server stammt aus dem Hause iBricks.ch. Er bietet recht viele Diagnose-Möglichkeiten. Ich habe seit 10 Tagen ein Log aktiv, das den gesamten Telegramm-Verkehr zum KNX-Bus aufzeichnet. Die einzige Regelmässigkeit, die ich finden kann ist ein Relais-Einschaltkommando an einen MDT-3fach-Aktor mit Strommessung (AZI-0316.01). Das ist meistens das letzte Telegramm, das vor dem Ausfall, oder das erste nach dem Ausfall das gesendet wurde. Senden tut die Anlage ja weiterhin, also werden diese Telegramme auch weiterhin aufgezeichnet.

Was vielleicht noch zu erwähnen wäre ist der Umstand, dass ich an der (momentan einzigen) Linie im Moment 60 Geräte hängen.
Ich könnte mir vorstellen, dass ich langsam an die Limite der Speisung gelange.

Andererseits frage ich mich, ob ein simples Kontaktproblem zu diesem Fehler führen kann. Ich habe allerdings vor zwei Tagen das Kabel ersetzt und den Fehler heute Morgen erneut gehabt. Müsste also an der Buchse liegen.

Ein weiteres Problem könnte in der Falcon-Software liegen. Da hat der Server Hersteller neulich versucht auf die neue Version 5 umzustellen, was aber zu sporadischen Fehlern führte, so dass wir wieder zurück auf die Version v2.1.5213.27900 gewechselt haben.

Bin weiterhin zeimlich ratlos.
Richi

[Klaus Gütter]

Der Falcon 2.1 schreibt eigene Logdateien nach C:\Program Files (x86)\Common Files\EIBA sc\Log.

Dein Satz "Senden tut die Anlage ja weiterhin, also werden diese Telegramme auch weiterhin aufgezeichnet." lässt mich jetzt auch etwas ratlos zurück. Ich dachte, das wäre das Problem, dass eben nichts mehr auf deinem Server ankommt - wie kann dann etwas aufgezeichnet werden?

[RichiAviator]

Hallo Klaus

Vielen dank für den Pfad der Falcon-Logs. Darin finden sich unendlich viele Fehlermeldungen, die alle das USB-Gerät betreffen.
Allerdings kann daraus nicht viel gewinnen, was auf die Ursache hinweisen würde. Hier ein paar Zeilen des Logs:
D 27.08.2016 T 07:02:16.096 error writing to device
D 27.08.2016 T 07:02:16.096 File: .\UsbConnector.cpp Line: 340
error in InternalWriteWithDataConfirm, DeviceWriteError = 1
D 27.08.2016 T 07:02:16.096 ReadLocalIndividualAddress failed! hr = 0x1
D 27.08.2016 T 07:02:16.096 File: .\UsbConnector.cpp Line: 538
PerformBCUInit failed, hr = 80004005
D 27.08.2016 T 07:02:17.097 File: .\ConnectorBase.cpp Line: 1379
error during DeviceWrite: TraceLastError(0x48f 1167) Das Gerät ist nicht angeschlossen.

oder in einem anderen Log:
D 29.08.2016 T 08:29:25.636 File: c:\Builds\21\KNX\Falcon\Sources\Sources\Falcon\Fal conCommon\AutoSafeQueue.h Line: 136
error during OutputAutoQueue 0xc0042a17
D 29.08.2016 T 08:30:06.800 File: .\Connectionless.cpp Line: 429
WriteToConnector fails DeviceWriteError=255

Und schliesslich fand ich all die Zeitpunkte an denen das USB-Interface in den Ausstand getreten war:
D 10.12.2014 T 21:28:47.549 File: .\DlgConnectionManager.cpp Line: 272
No default connection in listbox!!
D 28.12.2014 T 17:05:57.550 File: .\DlgConnectionManager.cpp Line: 272
No default connection in listbox!!
D 10.08.2016 T 10:23:07.241 File: .\DlgConnectionManager.cpp Line: 272
No default connection in listbox!!
D 17.08.2016 T 06:43:28.880 File: .\DlgConnectionManager.cpp Line: 272
No default connection in listbox!!
D 19.08.2016 T 07:16:50.041 File: .\DlgConnectionManager.cpp Line: 272
No default connection in listbox!!
D 27.08.2016 T 07:14:11.940 File: .\DlgConnectionManager.cpp Line: 272
No default connection in listbox!!
D 29.08.2016 T 07:31:31.807 File: .\DlgConnectionManager.cpp Line: 272
No default connection in listbox!!

Ich werd mal versuchen, die Linien aufzuteilen und so die Hauptlinie um rund 10 Geräte zu entlasten.
Parallel dazu habe ich vorgesehen, den Datenverkehr zum KNX-Bus mal über ein IP-Interface laufen zu lassen.
Allerdings möchte ich wieder zurück auf USB, da ich so auch dann eine Verbidnung habe, wenn das Ethernet einmal ausfallen sollte.

Gruss
Richi