Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[BadSmiley]

heckmannju gehst du etwa fremd Jürgen?!

[heckmannju]

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

[WagoKlemme]

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

[SeatSLF]

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

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

[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

[gaert]

Wenn diese Einstellung aktiviert ist passiert zunächst garnix - erst wenn der berüchtigte SeqCounter-Error auftritt wird die Verbindung neu aufgebaut.

[WagoKlemme]

Bei mir wars aktiviert, habs jetzt wieder deaktiviert. Ist auch kontraproduktiv, wenn ich keine Probleme habe.

[gaert]

Schön zitiert Nur: Dieser Neuaufbau der Verbindung ist garnicht aktiviert per Default... Ausserdem: Was hat das mit "Live-Monitor friert ein" zu tun?!

[heckmannju]

Ja, das ist zwar eine Änderung - aber dies greift nicht in die Kommunikation ein. Es wird optional lediglich eine neue Verbindung aufgebaut, falls der genannte Fehler auftreten sollt.

Seit 1.44 arbeitet mein Live-Monitor anscheinend wieder und hat sich bis jetzt noch nicht "aufgehängt" - vorher musste ich bis zu 5x am Tag das Live-Projekt neu starten ...

[gaert]

Ja, das ist zwar eine Änderung - aber dies greift nicht in die Kommunikation ein. Es wird optional lediglich eine neue Verbindung aufgebaut, falls der genannte Fehler auftreten sollt.

[WagoKlemme]

1.44

• KNX-Kommunikation:
  • bei abweichendem Sequence-Counter um mehr als 1 Zähler kann die KNX-Verbindung ggf. neu aufgebaut werden (Basis-Konfiguration: global_knxReconnectOnSeqErr=true)
  • dies könnte als Workaround für Probleme mit einigen IP-Schnittstellen/Router hilfreich sein
  • Wichtig: Dieses Feature ist noch ungetestet, da ich den Fehler nicht reproduzieren/erzeugen kann!

Irgendwas verstehe ich grad nicht.

[gaert]

Sollte alles Zufall sein - in 1.44 wurde weder an der KNX-Kommunitkation noch am Live-Monitor etwas verändert

[coliflower]

Seit 1.44 arbeitet mein Live-Monitor anscheinend wieder und hat sich bis jetzt noch nicht "aufgehängt" - vorher musste ich bis zu 5x am Tag das Live-Projekt neu starten ...

Meistens habe ich bis zu einem Tag keine Fehler, danach doch wieder ... Solange die Logik richtig arbeitet, sind diese Fehlermeldungen für mich derzeit sekundär ...

[WagoKlemme]

Lustig, jetzt (1.44) habe ich Squencecounter Fehler. Vorher nie. IP MDT.

 [TABLE="class: log, border: 0, cellpadding: 0, cellspacing: 0, width: 0, height: 12"]
 	 		[TR="class: sErr"]
 			[TD]2016-09-16 11:57:23[/TD]
 			[TD]841474[/TD]
 			[TD]KNX[/TD]
 			[TD]11174[/TD]
 			[TD]ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=135, Soll-Wert=136 / Raw: 061004200015044c87002900bce010221d15010040[/TD]
 		[/TR]
 	 [/TABLE]