Mehr als ein Gerät im Programmiermodus

[raffix]

Hallo zusammen,

dieses Problem ist ja schon einige Male im Forum diskutiert worden. Leider weiß ich mir nicht mehr zu helfen und dachte vielleicht hat jemand noch eine Idee.
Ich habe vier Linien (inklusive Hauptlinie) also drei Linienkoppler und wenn ich ein neues Gerät in Betrieb nehme, taucht immer mal wieder die Meldung auf "Mehr als ein Gerät im Programmiermodus". Alle Linienkoppler sind von MDT und standardmäßig konfiguriert (siehe Screenshot).

Wenn ich das betreffende Gerät nicht im Programmiermodus habe, zeigt die Diagnose in der ETS auch kein Gerät im Programmiermodus. Aktiviere ich den Programmiermodus zeigt es 15.15.255 (*4) manchmal auch (*3) an, so als wären 4 Geräte im Programmiermodus, was definitiv nicht der Fall ist. Deaktiviere ich den Programmiermodus am betreffenden Gerät wieder, zeigt die Diagnose brav: Kein Gerät im Programmiermodus.

Wie löse ich das Problem dann immer?! Ich ziehe den Stecker, also resette die Busspannung (Hauptlinie und betreffende Sublinie), danach geht es wieder. Aber warum tritt das Problem überhaupt auf?

[random]

Hallo Raffix,

ich kann mir 2 Ursachen für das Problem vorstellen.
Ursache 1 hat mit der Schnittstelle zu tun. Ich habe das mit der ETS 5 manchmal, wenn ich den Laptop aus dem Ruhezustand erweckt habe. Da sollte ein Neustart des Laptops dein Problem kurzfristig beheben. Es kann natürlich wieder auftreten. Aber das schöne an Computern ist ja wenn Sie einen Fehler machen dann wenigstens immer den selben.

Die 2. Möglichkeit ist, dass du eine Ringleitung auf dem Bus hast. So werden die Telegramme im Kreis geschickt und wiederholen sich dadurch.
Das kann auch eine Verbindung zwischen Linie und Hauptlinie zwischen 2 Linien oder ggf. auch zwischen (Haupt-) Linie und Bereichslinie (Backbone) sein. Um dir dabei zu helfen wäre es hilfreich wenn du einen Screenshot von deiner Topologie hoch lädst und sagst in welcher Linie das Problem auftritt.
Eventuell kannst du das Problem über den Gruppenmonitor eingrenzen wenn du dir das Routing von den Telegrammen ansiehst. In einer Linie ohne Verstärker sollte das immer eine gerade Zahl (2;4;6) sein.

[vento66]

Ich würd sagen Main und Sublinie am LK vertauscht.

[givemeone]

oder du hast ein Linux Gerät mit knxd im Netzwerk....

[raffix]

Ursache 1 hat mit der Schnittstelle zu tun. Ich habe das mit der ETS 5 manchmal, wenn ich den Laptop aus dem Ruhezustand erweckt habe.

Aktuell nutze ich eine Schnittstelle von Weinzierl (IP Interface 731, also kein Router). Der dazugehörige PC wird immer neu hochgefahren, den Ruhezustand verwende ich nicht. Das kann ich also ausschließen.

Die 2. Möglichkeit ist, dass du eine Ringleitung auf dem Bus hast. So werden die Telegramme im Kreis geschickt und wiederholen sich dadurch.

Da ich ganz sicher gehen wollte, habe ich jede Leitung gerade noch einmal überprüft und auch einzeln in der Verteilung getrennt. Es gibt keine Ringleitung. Ich habe zwar zwei Enden, die einen Ring bilden würden, so sie denn angeschlossen wären. Sie sind aber nicht angeschlossen und enden auf Reihenklemmen (und sind auch nicht gebrückt).

In einer Linie ohne Verstärker sollte das immer eine gerade Zahl (2;4;6) sein.

Das ist sehr interessant. Ist bei mir definitiv nicht der Fall. Es gibt Telegramme, die eine ungerade Zahl haben (5) und welche die eine gerade Zahl bei den Hops haben (6). Die 6 kommt bei GroupValueRead vor, wenn ich mit ETS was abfrage, die Response hat dann einen Hop von 5. Bei mir haben fast alle Telegramme eine 5, egal ob sie aus Linie 1.1, 1.2 oder 1.3 kommen (die Schnittstelle sitzt ja auf der Hauptlinie). Antworten, die direkt aus der Hauptlinie kommen, haben eigentlich immer einen Hop von 6.

Ich würd sagen Main und Sublinie am LK vertauscht.

Gute Idee, aber das ist definitiv nicht der Fall. Die Hauptlinie ist nur 30cm lang und darauf befinden sich nur die Koppler (und dort geht es überall in "Main" rein), das Logikmodul, IP Interface und die Busspannung. Das ist alles recht übersichtlich.

oder du hast ein Linux Gerät mit knxd im Netzwerk

Sehr guter Hinweis. Das kann ich tatsächlich nicht ausschließen, weil bei mir ein Raspi läuft, der für die Visu Zugriff auf die IP-Schnittstelle hat. Genau hier werde ich ansetzen und den Raspi abeklemmen, wenn das Problem das nächste Mal auftritt.


Schon mal vielen Dank an alle für die reichlichen Ideen. Ich werde beim nächsten Auftreten auf die Punkte achten und hier berichten, wenn ich a) die Ursache gefunden habe oder b) weiterhin auf dem Schlauch stehe.

[gbglace]

der für die Visu Zugriff auf die IP-Schnittstelle hat. Genau hier werde ich ansetzen und den Raspi abeklemmen, wenn das Problem das nächste Mal auftritt.

Tja der wird es wohl sein, der liest durch die Schnittstelle alles und ist murks implementiert und schickt alles wieder zurück.

[fhartlieb]

Selbiges Problem hatte ich auch häufig früher… es war zum Mäuse melken. Bei mir waren es letztendlich zwei Probleme:

• RPi mit selfbus-KNX-Adapter und eibd/knxd
• eine alte MDT-IP-Schnittstelle die schon immer „auffällig“ war

seit meinem neuen Aufbau mit Hauptlinie + 2x SUB LK + neuem MDT IP-Interface + neuen Netzteil hatte ich das Problem („mehrere Geräte im Prog-Mode“) nicht mehr

[uzi10]

Hab dauernd das Problem mit meinen Programmierkoffee wo eine Weinzierl Schnittstelle eingebaut ist. Was kann da sein? Neu installiern oder konfiguriern?.
immer wenn ich bei einen Gerät die Programmiertaste drück, schreibt die ets das hin, was nicht stimmt.und die analyse auch so sagt

[Poeschie]

Ich habe das Problem auch, habe aber als Ursache den Raspberry auf dem nodeRED mit einer KNX Anbindung läuft ausfindig machen koennen.

[random]

Zitat von random Beitrag anzeigen
In einer Linie ohne Verstärker sollte das immer eine gerade Zahl (2;4;6) sein.



Das ist sehr interessant. Ist bei mir definitiv nicht der Fall. Es gibt Telegramme, die eine ungerade Zahl haben (5) und welche die eine gerade Zahl bei den Hops haben (6). Die 6 kommt bei GroupValueRead vor, wenn ich mit ETS was abfrage, die Response hat dann einen Hop von 5. Bei mir haben fast alle Telegramme eine 5, egal ob sie aus Linie 1.1, 1.2 oder 1.3 kommen (die Schnittstelle sitzt ja auf der Hauptlinie). Antworten, die direkt aus der Hauptlinie kommen, haben eigentlich immer einen Hop von 6.

Wenn deine Schnittstelle in der Hauptlinie sitzt und du nur die 3 Linien hast ist das so auch richtig. Das Routing beginnt mit 6 und zählt für jeden Linen-/Bereichskoppler oder Verstärker 1 runter. Somit hast du im Bereich 1 immer die 5 für Telegramme aus Linie 1.1 1.2 und 1.3 (wenn du keinen Verstärker verwendest)

Wenn es nicht an deinem Visualisierungsserver liegt kannst du bei der Topologie auch mal in jeder Linie 1 Gerät in den Programmiermodus setzen, die Linien am Linienkoppler abklemmen und schauen ob du evtl doch noch auf die Linie kommst bzw das Gerät noch als im Programmiermodus angezeigt wird obwohl keine Verbindung mehr bestehen sollte.

[Ratzenvogel]

Ich würde trotz deiner vorherigen Überprüfung die Topologie und Verdrahtung nochmal genau überprüfen.

Auch wenn es sich wie ne Floskel anhört die man sowieso an der Hotline gesagt bekommt, mir hat das schon paar mal den ein oder anderen Fehler aufgezeigt: Die Anlage soweit reduzieren bis der Fehler einzugrenzen ist.

Vielleicht auch mal Sub für Sub abstecken, sodass nur noch die Linie mit deinem neuen Gerät drauf hängt. Oder auch nur das neue Gerät und die Schnittstelle auf den Bus hängen und nochmal prüfen, aus dem Bauch heraus würde ich sagen, dass der Fehler dann nicht mehr auftaucht.

Der Komfort von einer Busleitung - hier mal kurz ne Wand durchgebohrt und nochmal ne Leitung abgegriffen - führt leider manchmal dazu, dass die Geräte auf den falschen Linien sitzen. z.B. 1. OG ist bei dir Linie 2, der Taster an der Wohnungstür wurde aber vom Treppenhaus(Mainline) reingebohrt aus irgendeinem Grund.

Ansonsten würde ich mir auch immer noch ne Reserve USB Schnittstelle in die Laptoptasche werfen, die ist manchmal gold wert. Ich trau den Netzwerkkartentreibern immer nicht ganz

[raffix]

[...] habe aber als Ursache den Raspberry auf dem nodeRED mit einer KNX Anbindung [...]

Sehr guter Hinweis, denn das habe ich auch so bei mir. Vermutlich schießt bei mir auch der Raspi mit NodeRed que.