Programmieren des Enertex Secure Router bei mir extrem langsam

[enertegus]

Lt. Mitschnitt sehe ich das erste Telegramm vom Router bei #652 (T-Connect) bei 19:18:45. Um 19:18:50 Uhr ist das fertig. Das scheint so (5s) wie normal.
Du programmierst offenbar über Routing, das würde ich grundsätzlich auf Tunnelling umstellen, da sonst noch die Multicastschoße vom Win dabei ist. Dennoch ist das im Normalfall möglich.
Allerdings geht es schon mal bei #35 los, erst noch unauffällig, dann würgt aber das System mit einen T-Disconnect die Verbindung ab. Das könnte auch ein anderes Routing Device im Backbone sein. Danach wird es heftig und über 1.1.151 und 1.1.150 werden T Connects angesprochen, die kommen alle mit einem Hopcount 5, also liefen über einen Router.
Das dauert dann bis zum #652.
Welche anderen Geräte hast Du im Projekt: Loxone, proprietäre Lösungen, etc. ? Kann auch ein Topologieproblem sein. Der Router an sich ist m.E. ok.

[zaphood]

Vielen Dank für deine Analyse und die Mühe.

Was habe ich an Systemen: ISE Hue Gateway für die Leuchten, Weinzierl Enocean GW für ein paar Fenstersensoren und Openhab 2.5 als Visu und Logikengine (letzteres hatte ich aber auch schon einmal probeweise runtergefahren und dann programmiert, um eben genau das auszuschliessen. Hat aber auch nichts geändert).

Programmierung über Tunneling hat bei mir noch nie funktioniert. Wenn ich über den alten oder neuen Router programmiere, muss ich IMMER über den Routermodus gehen. Wüsste nicht wo ich da was einstellen kann?

Hopcount 5 über einen Router? Du meinst, dass zwischen dem PC und dem Router ein Subnetz liegt? Also der Router und der PC liegen im selben LAN Segment...

Ein anderes Routing-Device kann ich ausschliessen, ausser dem Router gibts nichts was zwischen KNX und IP vermittelt.

Topologie ist eine einzelne Linie. Linienkoppler und Aufteilung kommt erst noch, das ist in Vorbereitung für den weiteren Ausbau.

Bei den ganzen Überlegungen will mir nicht runter, warum das mit dem alten Enertex Router alles völlig problemlos läuft und nur der neue Schluckauf bekommt.

[zaphood]

Ich hab den Fehler gefunden....Schande über mich. Dein Hinweis auf Programmieren via Tunnel hat mich die Interfaces mehrfach checken lassen, und der Router war als Tunnel für die ETS nie ansprechbar. War am Ende eine Combo aus dicken Fingern und schlechten Augen, also mal wieder Fehler in OSI Schicht 8 (Anwender)...

Gatewaymaske beim Router auf 255.255.255.255... finde den Fehler *lol*

Programmieren geht nun ruckzuck, so wie das sein sollte.

Frage mich nur, warum der Tunnel für Openhab problemlos tat und auch Programmierung via Multicast generell ging...?

Wieder was gelernt.

Und vielen herzlichen Dank an enertegus für seine Mühe und die richtigen Denkanstöße!

Schönen Abend
Frank

[enertegus]

Gatewaymaske beim Router auf 255.255.255.255... finde den Fehler *lol*
Frage mich nur, warum der Tunnel für Openhab problemlos tat und auch Programmierung via Multicast generell ging...?

Naja, wenn der Router eine falsche Netzwerkmaske bei den Verbindungsoptionen bekommt oder mitteilt, wird das Verhalten von der KNXA entsprechend definiert sein (Ablehnung der Verbindung). Freie Lösungen kümmern sich nicht immer um alle Eventualitäten und werden auch nicht von Testtools dazu gezwungen ... Multicast ist hier halt anders definiert - muss ja eben vom Multicast die Daten entgegennehmen und nicht von einer P2P Verbindung.
Freut mich jedenfalls, wenn es jetzt geht, der Router tut was er soll und alle Probleme gelöst sind