KNX/EIB Mögliche Ursachen für Fehler "Das Gerät Antwortet nicht in angemessener Zeit"?

[wknx]

Nabend KNX-User,

ich bin gerade mit meiner ersten (noch recht übersichtlichen) Testinstallation beschäftigt und hänge da nun an einem Problem: Bekomme beim Versuch den Gira SmartSensor zu programmieren immer wieder die Meldung "Das Gerät Antwortet nicht in angemessener Zeit" und habe auch nach Suchen dieser Meldung hier im Forum keine Lösung finden können.

Grundsätzlich muss die Kommunikation schon funktionieren: Konnte die vollständige Programmierung schon mal erfolgreich abschließen, auch wenn das bereits 3 Anläufte brauchte und schließlich rund 20 Minuten gedauert hat die Applikation hoch zu laden. Bin mir nicht sicher ob das normal ist, aber angesichts der Datenrate von KNX auch nicht so ungewöhnlich.

Hatte auch schon den Hinweis gefunden, dass man auf kurze Pakete umschalten soll. Ich vermute hier ist die Kompatiblitätsoption "Verwende reduzierte Bus-Kommunikation" (BusAccessLegacyMode) gemeint, konnte damit allerdings auch keine Abhilfe schaffen.

Meine Umgebung:

• MDT SCN-IP000.02 IP-Interface
  • Weitere Geräte: MDT NT mit Diagnose-Funktion + MDT Taster-Interface + Gira SmartSensor
• ETS5 Lite: 5.5.2 (Build 665)
• Windows10 in VirtualBox auf Ubuntu Host; Netzwerk im BridgeMode

Irgendwelche Ideen was ich noch versuchen kann bzw. prüfen sollte?
Fehlen noch irgendwelche Angaben für die Diagnostik?

Gruß
Wilhelm

[Jannnn]

Guten morgen,
Ich habe ab und an ein ähnliches Problem. Ich vermute, dass es am Access point (unify uap ac pro) liegt. Nach ein paar Versuchen funktioniert es. Sobald ich den Laptop per Kabel ans LAN packe, klappt es sofort.
IP Router: Abb IPR/S
WIN 10 mit ETS 5.5.2

[wknx]

Guten Abend Jannnn,

bei mir läuft die Kommunikation komplett über Kabel-LAN. Je nach Anschluss-Kabelstrecke hängen allerdings noch 1-3 Switches dazwischen. Hatte ansonsten noch nie Probleme mit der Verbindung, aber bisher auch keine echtzeitkritische Kommunikation.

Mein zentraler Switch (HP ProCurve HP 1810-24G v2) wird auch später zum Einsatz kommen, in sofern wäre es also blöd wenn es an dem hakt. Werde da noch mal im Fehlerlog nach Auffälligkeiten schauen. Probiere es aber auch noch mal mit direkter Verbindung über einen anderen Switch und werde dann berichten.

Gruß
Wilhelm

[wknx]

Update: Mit einem anderen Switch funktioniert es leider auch nicht besser.
Noch andere Ideen?

[rosebud]

Zu meinem täglichen Umgang gehört eine Anlage mit um die 600 Smart-Sensoren. Mit ETS3f gab es nie Probleme, das Elend begann mit ETS4.

OS: WinXP-SP3. Anschluß über USB-Schnittstelle. Laden grundsätzlich von derselben Linie aus, ohne Linienkoppler und IP-Gerümpel dazwischen. Beim ersten Laden nach dem Import von ETS3f auf ETS4 ist man mit 20 Minuten dabei, es kann auch anderthalb Stunden werden. Danach geht es schneller.

Der Smartie hat einen dollen Softwarefehler: Arbeitet man mit demselben Sollwert für Heizen und Kühlen bei automatischer Funktionsauswahl, dann werden Heiz- und Kühlventil gleichzeitig angesteuert.

[wknx]

Nabend rosebud,

das liest sich ja etwas ernüchternd.

Der erwähnte Softwarefehler würde mich nicht betreffen. Mit den einmaligen 20 Minuten kann ich auch leben, wenn ich weiß dass es normal ist. Mein primärer Usecase für 1 oder 2, maximal 3 Geräte im Hause: Zugriff auf alle ansonsten nur selten manuell und feingranular steuerbaren Funktionen erlauben. Also z.B. Rolläden einzeln ansteuern. Vom Bedienkonzept erfüllt fühle ich mich da gut aufgehoben was ich mit der einmalig erfolgreichen Programmierung im Rahmen des Anwendungsuploads schon ein bisschen ausprobieren konnte.

Wäre die ETS3 heute noch irgendwo zu bekommen?

Gruß
Wilhelm

[SeatSLF]

Kannst du in deiner Schnittstelle einstellen, ob die auch langsame Kommuniktion beherrscht bzw. da der Haken da ist.

[rosebud]

Ich schlage vor, mal in die Runde zu fragen, ob jemand eine Lizenz dafür abzugeben hat. Ich persönlich arbeite am liebsten mit ETS3f, weil sie perfekt und ausgereift funktioniert.

Mit ETS4 und 5 (fast wie bei Firefox: Alle zwei Wochen ein Riesen-Update) versucht man, den Fuß in die Tür von Anwendungen zu bekommen, in denen KNX nichts verloren hat, weil es mit 9.600 Baud viel zu langsam ist, z.B. Multimedia. Wofür war KNX gedacht? Steuern von Lampen, Jalousien, Raumheizungen. 9.600 Baud stellen nur minimale Anforderungen an die Verkabelungsstrategie (z.B. im Vergleich zu LON). Daß man mit IP-Kopplern rumwurstelt, bringt nix, denn der Flaschenhals Geschwindigkeit wird nur verschoben.

Kurzum: Mit dem ganzen Anwendungserfinden fährt man das System an die Wand, weil man es mit Forderungen konfrontiert, die es vom Konzept her nicht erfüllen kann.

An SeatSLF: Die Geschwindigkeit der Kommunikation spielt keine Rolle. Brocken wie den Smartie lade ich grundsätzlich von derselben Linie. Ohne Ausnahme.

Ach so, der Smartie: Wir haben häufig Ausfälle wegen des Druck-Dreh-Knopfes. Er reagiert nicht mehr auf Druck. Dann hilft nur Austausch des Vorderteils.

[wknx]

Kannst du in deiner Schnittstelle einstellen, ob die auch langsame Kommuniktion beherrscht bzw. da der Haken da ist.

Wo würde man das denn üblicherweise einstellen?

In den Parametern und im Webinterface habe ich keine entsprechend Option gefunden.
Ist das die Option "Verwende reduzierte Bus-Kommunikation" (BusAccessLegacyMode) aus der Projektkonfiguration?

[SeatSLF]

Bei dem Router konnte man das in der ETS in der Router Applikation von MDT einstellen.
Daher dachte ich das es so einen Punkt auch im Interface gibt.

[Klaus Gütter]

Hallo Wilhelm,

hast du dafür schon einen Support Case bei my.knx.org eingestellt?

Gruß, Klaus

[eghetto]

BTW, das gleiche Problem tritt auch bei mir ganz sporadisch mit meiner MDT-Schnittstelle auf. Ich nutze ETS 5.5.2.

[wknx]

Bei dem Router konnte man das in der ETS in der Router Applikation von MDT einstellen.
Daher dachte ich das es so einen Punkt auch im Interface gibt.

Beim Interface scheint es keine entsprechende Option zu geben.

rosebud : LongFrame-Support kam erst mit ETS5 dazu. In sofern hätte ich mir zumindest vorstellen, dass der SmartSensor als vergleichsweise alte Hardwareplattform dieses Feature noch nicht unterstützt. Was dasThema IP-Interfaces angeht: Die Geschwindigkeit halte ich an der Stelle für nachrangig. Vorteil ist sehe ich primär in der Flexibilität auf Infrastrukturseite.

hast du dafür schon einen Support Case bei my.knx.org eingestellt?

Nein bislang nicht. Hatte nur versucht bei Gira anzufragen.

[rosebud]

Long frame support bringt auch nicht viel, weil die Musik mit nur 9.600 Baud spielt. Je longer der frame, umso größer das Risiko, daß ein anderer Teilnehmer dazwischenfunkt und der frame wieder neu begonnen werden muß. Egal wie long der frame, das Bild eines Klingelknopfdrückers wird nie per KNX übertragen werden. Man stelle sich vor: 60 Kilopixel mit 9.600 Baud...

Der SmartSensor war nie vorgesehen, Bildchen o.ä. zu senden oder zu empfangen.

Long frame ist m.E. eine Totgeburt, weil KNX viel zu langsam ist für Multimedia.

[Klaus Gütter]

Je longer der frame, umso größer das Risiko, daß ein anderer Teilnehmer dazwischenfunkt und der frame wieder neu begonnen werden muß

Ganz bestimmt nicht. Kein Teilnehmer darf in ein laufendes Frame "dazwischenfunken". Der Bus muss für mindestens 50 Bitzeiten frei sein, bevor ein Sendevorgang starten kann.

Long frames sind nicht für Multimedia, sondern vor allem zum *viel* schnelleren Laden der Geräte.

Gruß, Klaus