Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[saegefisch]

Yippie!

[gaert]

Ein roter KNX-Balken hat eigentlich keine Bedeutung, denn dies signalisiert nur, dass die max. Telegrammrate (edomi.ini) erreicht ist. Das ist ja nix schlimmes

Das kurze Erscheinen von "Queue" ist vollkommen egal - dies ist rein technisch bedingt (die Statusseite wird asynchron refreshed und ist daher manchmal "schneller" als das Backend).

[saegefisch]

@enertegus: Das Handbuch.pdf sagt 35T/s (Tunnel) und 48T/s (Routing) , wenn ich mich nicht irre... Daher lohnt dann doch die Frage: Wie groß ist der Puffer denn beim Enertex IP-Router?

ein Update: Von Enertex habe ich auf meine Anfrage sehr rasch eine klare Antwort bekommen - fand ich gut, dass erlebt man leider andernorts auch mal anders. Danke, Enertex: "Der Eingangspuffer bei KNXnet/IP Routing reicht für bis zu 250 Telegramme (je nach Telegrammgröße). Bei KNXnet/IP Tunneling reicht der Eingangspuffer für bis zu 125 Telegramme."

Damit sollte ich selbst mit meinen 30T/s auf der sicheren Seite sein - weiterhin exakt Null Fehler dazu. Ich bleibe daher bis auf Weiteres dabei.

Beim InitScan nach Aktivierung hatte ich früher stets kurz mal "rot" wegen des Traffics am eingestellten Limit, aber keine Meldung. Jetzt bleiben die Balken immer grün, aber in 1/10 der Fälle leuchtet ganz kurz ein angst-roter "Queue"-Fehler auf.

@Christian: Ist das eine Info, dass die Queue gefordert war (was vielleicht eher ein warnendes "gelb" statt "rot" ausdrücken würde) oder ist das ein Problem und da ist irgend etwas nicht verarbeitet worden oder verloren gegangen? Da ich keine Auswirkungen spürte, gehe ich vom 1. Fall aus.

[saegefisch]

oh ha, der Erfahrungsbericht war richtig gut...ich gebe drei Punkte von zwei möglichen...

[gaert]

Das wäre ja furchtbar Noch schlimmer: Unter Menschen gehen - draußen!!! Rausgehen ist wie Fenster öffnen - nur krasser...

[saegefisch]

wie?...nicht, dass Dir bald "die Liste" ausgeht... am Ende musst Du noch an den Strand oder am Haus bauen oder an Deiner Visu arbeiten...

[gaert]

Ok, danke für die Recherche Dann bleibt's wie's ist (soll mir recht sein)

[Fisch]

Habe gerade eine Rückmeldung vom Entwickler des Soft IP Routers bekommen.
Es ist tatsächlich nicht in Ordnung, dass eine Channel ID0 verwendet wird.
Damit verhält sich EDOMI, wie so oft absolut Standardkonform.

[Fisch]

Da hast du Recht, du wirst das sicher nicht ohne Grund extra implementiert haben.
Ich habe jetzt selbst auch noch im Standard nachgesehen, konnte jedoch auch nichts über ein Verbot der Channel ID0 finden.

[gaert]

Es ist richtig, dass eine ChannelID 0 ignoriert wird - irgendwo werde ich das mal gelesen haben in der Spezifikation, sonst hätte ich dieses Verhalten wahrscheinlich nicht implementiert. Eine Änderung wäre kein Problem, die Frage ist nur ob eine ChannelID 0 nun erlaubt ist oder nicht?! Da offenbar alle Hardware-Router bei 1 beginnen würde ich fast dazu tendieren zu glauben, dass dieses Vorgehen das richtige ist...?

[Fisch]

Hallo,

Ich hatte Edomi mal in Verbindung mit der Betaversion vom PNX Soft IP Router von PeaKNX getestet.
Dabei ist mir aufgefallen dass der Soft IP Router beim Tunnelindex 0 zu zählen anfängt. Dies scheint mit EDOMI Probleme zu machen.
Edomi beendet direkt nach dem erfolgreichem Verbinden mit dem Router, und der Rückmeldung des Routers mit der Tunnel ID 0 die Verbindung.
Wenn ich vorher einen anderen Teilnehmer (z.B. Openhab) verbinde, und EDOMI die Tunnel ID 1 bekommt, bleibt die Verbindung aufrecht.

Ich war diesbezüglich auch schon in Kontakt mit dem Entwickler des PNX Soft IP Routers. Dieser meinte, dass im KNX Standard über eine nicht erlaubte Tunnel ID 0 nichts zu finden ist. Jedoch scheinen alle Hardware Router erst mit der ID 1 zu beginnen. Er wird das in der Router-Software so ändern, dass mit der ID 1 begonnen wird. Damit sollte es da keine Probleme mehr geben.

Trotzdem wäre es vielleicht sinnvoll EDOMI, die Tunnel ID 0 auch beizubringen, damit Probleme dieser Art in Zukunft nicht mehr auftauchen.

Grüße
Franz

[saegefisch]

@enertegus: Das Handbuch.pdf sagt 35T/s (Tunnel) und 48T/s (Routing) , wenn ich mich nicht irre... Daher lohnt dann doch die Frage: Wie groß ist der Puffer denn beim Enertex IP-Router?

[enertegus]

Hi, ohne das ich eine Antwort wüsste. Müsste man bei der Frage nicht auch die Telegrammgrösse angeben? VG Jürgen

Nein am Ende sind das "Timing" Probleme. Jedes Telegramm muss innerhalb 1 Sekunde bestätigt werden. Sollte das aus irgendwelchen Gründen länger dauern, wird das Telegramm verworfen.
Lt. KNX Standard muss der Tunnel 50 Telegramme vorhalten können (wenn ich mich recht erinnere) - ob da im Einzelfall auch mehr gespeichert werden, kann ich noch nicht mal von unseren sagen. Bei 50 T/s wäre das eben eine Sekunde. Wenn die Sekunde um ist, muss das Telegramm eh gelöscht werden.
Die Sache mit Sequenzcounter ist ein reines Timingproblem und hat erst mal weniger mit der Puffergröße im Router zu tun.

[gaert]

Nochmals zur Erinnerung: Diese "SeqCounter-Fehler" sind keine Fehler im engeren Sinne, sondern ein Hinweis(!) darauf, dass die Kommunikation hakt (i.d.R. Timing-Probleme - z.B. zu hohe Telegrammrate oder eben Netzwerk-Auslastung, etc.). Die Kommunikationspartner werten den SeqCounter natürlich aus und wiederholen ggf. das Telegramm - bis zu einem gewissen Grad, denn irgendwann geht u.U. nix mehr.

eibd/knxd, ETS und andere sind davon genauso betroffen, nur zeigen diese den "Fehler" nicht an... EDOMI hat's also erst aufgedeckt und einen langen Thread im Forum erzeugt Grundsätzlich ist es also ratsam, die Netzwerkumgebung etwas "ernster" zu nehmen - also "kurze Wege" etc. Und die Telegrammrate ist ebenso einen Blick wert, denn die Telegrammpuffer unterscheiden sich offenbar deutlich je nach Router-Modell. Natürlich muss in diesem Kontext auch die maximale physische KNX-Rate bedacht werden - die IP-Seite lässt sich schön hochsetzen, aber irgendwann kapituliert dann der Router/Schnittstelle, da er die Telegramme schließlich auch noch auf den Bus bringen muss.

[EinAnfaenger]

Bei mir läuft Edomi z.Zt. in einer Test-Umgebung als VM auf meinem Laptop. Zuerst hatte ich die Anbindung meines Laptops über WLAN und den IP Router am LAN Anschluss des Internet-Routers. An dem LAN Anschluss (über einen Switch) hing aber auch noch mein Entertain Receiver. Hier kam es auch immer wieder zu Seq.-Fehlern, aber ich konnte die Verbindung auch problemlos mit 2-3 HD Streams komplett lahmlegen, so dass auch mit der ETS nix mehr ging. Dann habe ich am Laptop die LAN Schnittstelle und den IP Router an einen extra Port an meinen Speedport-Router gehängt und das WLAN am Laptop deaktiviert. Seit dem hatte ich keinen einzigen Seq. Fehler mehr. Von der Ethernet-Bandbreite her sollten das auch in der anderen Konfiguration kein Problem sein, aber die Entertain Multicasts haben den IP Router (MDT) wohl überfordert. Für den Produktiv-Betrieb werde ich später wohl für den ganzen IP/KNX Kram ein VLAN einrichten.

Gruß,
Thomas