Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[Simone]

Ich habe heute auch mal wieder die bekannten Meldungen und das mit Version 1.43

Dann kann ich jetzt endlich umsteigen weil es liegt nicht an 1.44

 
 2016-09-23 10:45:11	308547	KNX	26304	ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=248, Soll-Wert=249 / Raw: 061004200015044df8002900bce011232416010080	ERROR 2016-09-23 10:45:17	647491	KNX	26304	ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=249, Soll-Wert=250 / Raw: 061004200017044df9002900bce011081c0103008025a4	ERROR 2016-09-23 10:45:21	309571	KNX	26304	ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=250, Soll-Wert=251 / Raw: 061004200015044dfa002900bce011232416010080	ERROR

vor ein paar Tagen habe ich eine Tasterschnittstelle in Betrieb genommen da kamen diese Meldungen von einem falschen DPT das sah dann so aus

 
 2016-09-15 18:29:48	099775	KNX	23917	ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (noACK): Ist-Wert=114, Soll-Wert=117 / Raw: 061004200015044972002900bce011081802010080	ERROR 2016-09-15 18:29:49	097155	KNX	23917	ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (noACK): Ist-Wert=115, Soll-Wert=117 / Raw: 061004200015044973002900bce011021810010080	ERROR 2016-09-15 18:29:50	098565	KNX	23917	ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (noACK): Ist-Wert=115, Soll-Wert=117 / Raw: 061004200015044973002900bce011021810010080	ERROR 2016-09-15 18:29:51	098534	KNX	23917	ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=116, Soll-Wert=117 / Raw: 061004200015044974002900bce011232416010080	ERROR

[saegefisch]

Zur Info ein Update -vielleicht hilft es ja jemandem: Seit einiger Zeit fahre ich edomi nach zunächst mit global_knxMaxSendRate=25, jetzt seit 3 Tagen sogar mit global_knxMaxSendRate=30 an einem Enertex Router. Der kann laut Handbuch wohl 35 T/s; wie groß der Puffer ist, weiß ich gerade nicht. Edomi läuft auf dedizierter HW (NUC i3).

Seit der Umstellung auf 30 T/s weiterhin kein einziger Seq-Fehler. Beim Aktivieren des Projekts gehen die KNX-Balken nicht einmal mehr immer ins rote beim InitScan; der geht trotz steigender Zahl an GA weiterhin sehr zügig/zügiger. Für Szenen mit vielen GA (WZ: 20 Kanäle) ist es subjektiv etwas schneller geworden, kann aber auch täuschen; da ist DALI sicher eher der Flaschenhals.

Mein persönliches Fazit: edomi an sich (1.44 und 1.45) und der Enertex Router - bei ansonsten unveränderter Infrastruktur - waren ganz offensichtlich nie Verursacher meiner Seq-Fehler, sondern mir scheint mit diesen Erfahrungen einzig und allein die Umgebung von Edomi ausschlaggebend zu sein hinsichtlich Leistungspuffer für Verarbeitungsspitzen (volle Stunden, Mitternacht,...) und Netzwerkanbindung (VM auf qnap-NAS TS-251 offensichtlich nicht hinreichend/optimal für diese Anwendung). Die Seq-Fehler waren nie spürbar oder ein Problem, aber sie haben mich gestört.

[SeatSLF]

Seit der 2ten Beta von Enertex läuft die Verbindung, seit 1.46, seit Tagen ohne Seq. Fehler.

[WagoKlemme]

Interessant.
Kennt jemand zufällig die max. Telegrammrate der MDT SCN-IP000.02 IP-Schnittstelle ?

[heckmannju]

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

[BadSmiley]

heckmannju gehst du etwa fremd Jürgen?!

[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

[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.

[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.

[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?

[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

[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]

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.

[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.

[gaert]

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