Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[nno]

Du kannst mir eine PN mit deiner E-Mailadresse schicken und ich schicke dir eine Beta-Firmware

An der Stelle erstmal vielen Dank an salixer, finde ich Klasse, dass ihr euch hier im Forum engagiert um das Problem zu lösen.

Leider hat die Beta-Firmware 1.039 für den Enertex IP Router bei mir nichts geholfen. Beim Aktivieren des EDOMI Projeks kommen immer folgende 3 Fehlermeldungen:

ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (noACK): Ist-Wert=105, Soll-Wert=101 / Raw: 061004200015044169002900bce011081603010041
ROUTER @ CE | DISCONNECT_REQUEST / Raw: 06100209001041410801c0a8b2150e57
KNX-Verbindung verloren.

Der Grund ist wohl, dass beim Aktivieren des Projeks einige GAs abgefragt werden (Position Rolläden, Zustand Fensterkontakte etc.). D.h. da feuert EDOMI innerhalb kurzer Zeit viele Anfragen an den KNX Bus und dann kommt es wohl zu dem Problem. Im laufenden Betrieb habe ich den Fehler bis jetzt noch nicht bekommen.

Es hat aber geholen in der edomi.ini die maximale Telegrammrate von 20 auf 10 zu ändern (global_knxMaxSendRate=10). Damit klappt das Aktivieren des Projekts jetzt wieder ohne Fehler. Bin gespannt, ob das von Dauer ist, oder nur ein vorübergehender Workaround.

[salixer]

Das Problem wird bei dir einfach sein, dass neben den EDOMI-Anfragen, die auf den Bus gesendet werden, natürlich auch noch die ganzen Antworten der Geräte auf den Bus wollen. Kommen auf die 20 Anfragen pro Sekunde nur 20 Antworten von verschiedenen Busteilnehmern, sind wir schon bei 40 Telegrammen pro Sekunde auf dem Bus. Damit ist der Bus schon mehr als ausgelastet.
Könntest du mal einen längeren Log-Ausschnitt posten?

[gaert]

Offenbar puffert der Router nur wenige Telegramme?! Mein Eibmarkt-Teil speichert angeblich 300 Telegramme (oder so) zwischen - somit ist in gewissen Grenzen die Buslast unabhängig von der IP-Seite...

[woda]

salixer
Selbes Ergebnis wie bei nno.
Die Begrenzung auf 10 Telegramme/Sekunde hilft hier zuverlässig. Wieviele Telegramme kann der Router puffern?

[SeatSLF]

Ich bin mit einer bereitgestellten Beta bei 15T/sec und wenn es keine Fehler gibt werde ich am WE wohl mal wieder auf 20 erhöhen

[nno]

Könntest du mal einen längeren Log-Ausschnitt posten?

Ja, kann ich gerne machen, komme aber vermutlich erst morgen Abend dazu. Was für ein Log wäre denn sinnvoll? EDOMI Monitor-Log, ETS Gruppenmonitor, ...? Ich würde den ETS Gruppenmonitor mal laufen lassen, allerdings dann mit der ETS nicht auch über den IP Router gehen, sondern meine Gira USB Schnittstelle nehmen. Macht das Sinn?

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

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

[gaert]

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

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

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.

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

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

[WagoKlemme]

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

[gaert]

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