Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[gaert]

Die Wartezeit bis zum Reconnect ist einstellbar (edomi.ini) - default sind 3 Sekunden (glaub' ich).

"KNX-Verbindung verloren" wird in der Tat zweimal geloggt, dies ist strenggenommen noch ein Bug (historisch bedingt). Dies betrifft allerdings nur das Logging selbst, die Verbindung geht nur einmal verloren Hintergrund ist das protokollieren in verschiedenen Logs (System-Log, Trace-Log und Fehler-Log). Dieses Verhalten hängt von den Einstellungen in der edomi.ini ab (global_logTraceLevelKnx).

Die Reihenfolge von DISCONNECT_REQUEST und TUNNELING_REQUEST ist hier "zufällig", da die Kommunikation asynchron stattfindet. Es handelt sich ja um einen DISCONNECT_REQUEST(!), d.h. es wird nur höflich gebeten...

Generell glaube ich nicht an überforderte Hardware, zumindest habe ich auf meiner relativ lahmen HW noch nie(!) derartige Probleme feststellen können - nach über 1 Jahr mehr oder weniger Dauerbetrieb und zig "Experimenten" mit Telegrammrate etc... Zudem scheint es mit diversen anderen Schnittstellen/Routern keine Probleme zu geben - daher würde ich dies ausschließen. Interessant zu wissen wäre m.E., ob das Problem auch in einer Umgebung auftritt, in der ein anderer Router keine Probleme macht. Somit könnte man schonmal "allgemein" Faktoren (Hardware, Netzwerk, etc.) ausschließen.

EDIT:
Die Sache mit den doppelten Logeinträgen habe ich inzwischen gefixt.

[heckmannju]

Ist es HW oder eine VM auf der eure edomi läuft?

[DirtyHarry]

Ich habe meine Probleme immer auf das Netzwerk hier geschoben, nach dem ich eibd mit drauf gemacht habe und den Gira V3-Router als Zugang über eibd nutze, habe ich nun seit 4 Tagen nur den 1 Fehler vom InitScan (Es sind nicht alle Gas mit Lesen-Flag versehen). Was ich bisher noch nicht getestet habe, ist die BJ IP-Schnittstelle als Zugang für eibd zu nutzen. Diese hat nämlich immer wieder Fehler (EDOMI @ CE | DESCRIPTION_REQUEST / Timeout nach 10s / ErrMsg: Kein DESCRIPTION_RESPONSE vom Router erhalten gefolgt von KNX-Verbindung verloren.) produziert und zuletzt sogar nur noch kurze Zeit nach einem Neustart von Edomi funktioniert.

Wobei das ja jetzt nur zeigt, die Verbindung zwischen Edomi und Eibd funktioniert, wie es mit Eibd und dem Router/Schnittstelle aussieht, interessiert Edomi natürlich wenig.
Hat eibd eigentlich auch eine Logdatei, in der solche Fehler gelistet werden vento66?

[salixer]

Hi,

prinzipiell würde ich empfehlen, den ersten Reconnect quasi sofort auszulösen, denn in der Wartezeit hat man ja keine Busverbindung. Falls der fehlschlägt, sollte man das dann alle X Sekunden wiederholen.

Dass das nur ein Logging-Problem ist, habe ich mir gedacht, wollte nur darauf hinweisen, da es kosmetisch nicht schön aussieht

Was genau meinst du mit "asynchroner Kommunikation", bzw. wo ist etwas asynchron? Die Telegramme im Eingang sollten auf jeden Fall in der richtigen Reihenfolge abgearbeitet werden, sonst gibt es Probleme. Auch ist es so, dass nach dem DISCONNECT_REQUEST vom Router (KNXnet/IP Server) die Verbindung auf jeden Fall beendet wird. Höflich bitten würde ich nur so weit unterschreiben, dass der KNXnet/IP Client selbst entscheiden kann, wann und wie er seine Verbindung beendet. Der DISCONNECT_REQUEST wird ja überhaupt erst nur durch den vorhergehenden Fehler ausgelöst.

Ich denke zur Fehlerfindung helfen nur Wirshark-Logs, um zu sehen, was wirklich auf der Leitung los ist.

[enertegus]

Generell glaube ich nicht an überforderte Hardware, zumindest habe ich auf meiner relativ lahmen HW

Hast Du auch eine VM im Einsatz?

noch nie(!) derartige Probleme feststellen können

willkommen im Club

nach über 1 Jahr mehr oder weniger Dauerbetrieb und zig "Experimenten" mit Telegrammrate etc... Zudem scheint es mit diversen anderen Schnittstellen/Routern keine Probleme zu geben - daher würde ich dies ausschließen.

Naja, auf welcher Seite ein Problem liegt, kann so nicht festgestellt werden. Timing etc. spielt eine Rolle. Wir bräuchten einen Telegrammmitschnitt, um zu sehen, ob die Verbindung tatsächlich ein Telegramm auf der Edomi oder auf der Router Seite verliert. Wenn da kein weiteres Interesse besteht oder die User mit der Begrenzung auf 10 Telegramme pro Sekunde leben (ich glaub der HS mach sogar 7 per Standard) , soll's mir auch Recht sein.

[coliflower]

Ich würde schon so ein Wirshark-Log zur Verfügung stellen, leider mangelt es mir an der Bedienung dieser Software :-(
Außerdem habe ich nur einen GIRA KNXnet/IP-Router ...

[SeatSLF]

Momentan habe ich auf meinem Router die Beta von Salixer am laufen, mal schauen wie es läuft.
Ich kann leider nur an Wochenenden Wireshark mitlaufen lassen.

[salixer]

Wollte noch anmerken, dass ich die nächsten beiden Wochen Urlaub habe. Da wird sich bezüglich Firmware oder Wireshark-Log prüfen von unserer Seite also erst mal nichts tun.

[Simone]

Hi,

erstmal finde ich es toll, dass sich Enertex/ salixer für sowas Zeit nimmt.

Ich habe die Fehler auch mit einer Siemens IP Schnittstelle (Beitrag 536) und werde das Problem mittelfristig wie Baumhaus123 mit einem empfohlenen Router zb. MDT lösen

Da es mich trotzdem interessiert was da eigentlich los ist, hier meine Überlegungen/Zusammenfassung

- lahme Hardware/Netzwerk kann doch ausgeschlossen werden, wenn es mit dem MDT Router keine Probleme mehr gibt (Rückmeldung @Baumhaus123
- wenn die Fehler bei mir auftreten manchmal nur 50 oder auch über 1000 werden in dieser Zeit meine Datenarchive nicht mehr befüllt, danach schreibt er wieder ins Archiv
- vermutlich wird in dieser Zeit auch eine Information vom Bus an Edomi verloren gehen (nocht nicht getestet) zb. KO-Lastüberschreitung >LBS aktivieren
- die Fehler kommen bei mir nicht unbedingt sofort nach dem Start von Edomi, es gibt wie von anderen bereits erwähnt keinen bestimmten Rhythmus
- was macht der MDT anders?

Aktuell teste ich mit 15 Telegrammen/sek. (wieder Fehler) als nächstes werde ich 10 Telegramme wie von Woda empfohlen testen

[enertegus]

- lahme Hardware/Netzwerk kann doch ausgeschlossen werden,

grundsätzlich sind die KNX Router stark unterschiedlich performant. Während für das Routing ein Performancetest Bestandteil der KNXnetIP Prüfung ist, ist das für das Tunneling nicht der Fall (ob es das inzwischen ist, weiß ich nicht). Offenbar tritt das Problem bei Telegrammratenbegrenzung nicht auf, d.h. der Edomi schickt nicht weniger als z.B. 10 Telegramme pro Sekunde. Unsere telnet-Verbindung sagt bei den Usern die das probiert haben, dass, wenn da mehr als 10 Telegramme geschickt werden, die Telegramme, die der Router an Edomi schickt, nicht beantwortet werden (In unseren Tests, schafft unser Router bei Tunnelverbindung dauerhaft >35 Telegramme/s).
Und das ist dann eben der Punkt. Wenn es stimmt, dass die Telegramme nicht mehr vom Edomi verarbeitet werden, läge das Problem auf der Edomi Seite, wenn nicht auf der Router Seite. Rausfinden kann man das eben nur mit Wireshark, weil der Log würde zeigen: Die Telegramme kommen erst gar nicht vom Edomi auf das LAN oder - kommen und werden dann aber nicht vom Router sauber verarbeitet. Dass der Fehler zudem z.B. beim Videostreamen häufiger auftritt oder wegen mir bei Edomi in der VM eher als im nativen System, ist zumindest ein Indiz...aber wie gesagt, können wir auch so belassen.

[gaert]

EDOMI läuft i.d.R. ja auf relativ performanter x86-Hardware, von daher glaube ich eher weniger an ein Performanceproblem seitens EDOMI. Die KNX-Kommunikation läuft als eigenständiger Prozess und braucht so gut wie keine Ressourcen (top). Das "Nadelöhr" wäre maximal der DB-Zugriff (Queue), aber das spielt nur EDOMI-intern eine Rolle - nicht nach aussen (Netzwerk). Und für mich ist das wichtigste Indiz die Tatsache, dass es mit anderen Routern funktioniert (dies meine ich jetzt nur hinsichtlich der Performance - etwaige Fehler in der Implementierung seitens EDOMI kann ich natürlich nicht ausschließen).

Was ich dann allerdings nicht verstehe: Warum funktioniert's offenbar mit eibd/HS/etc.? Welche Telegrammrate nutzt eibd/knxd überhaupt?!

[enertegus]

EDOMI läuft i.d.R. ja auf relativ performanter x86-Hardware, von daher glaube ich eher weniger an ein Performanceproblem seitens EDOMI. !

Aus meiner Hardwareerfahrung kann ich sowas nicht ausschließen: Auch im EibPC gab es anfangs genug Nettigkeiten, die man so nicht gedacht hatte. i.d.R. sagt auch nicht aus, was sonst noch so läuft, und die Top Auswertung ist sicher nicht granular genug Es kommt wohl hier z.B. auf die Rückmeldungezeit an (muss <1s sein).
Ich sage sicher nicht, dass Edomi ein Performancefresser ist, das wir noch nie einen Fehler in der Software hatten - die Unterschiede zum eibd und Edomi kenn ich nicht. Von dieser Ecke z.B. Smarthome.py, etc. gabs da nie gemeldete Probleme.

[Simone]

Muß für das Wireshark Log der Edomi Port gespiegelt und geloggt werden (in der VM dann eher schwierig)? und dann irgendwie Fehler herbeizaubern

[enertegus]

Direkt was am Host ankommt spiegeln, wär das Beste. Ob es dann am Ende in der VM stecken bleibt oder im Host etc. wäre ja erst mal egal

[Simone]

ok, die Fritzbox soll das wohl auch können. Ich probier das mal, obwohl ich mit dem Log vermutlich nichts anfangen kann
Capture.PNG