Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[enertegus]

Bitte auch die Ausgabe von tunnel xx, wobei xx die Nummer ist, die EDOMI belegt.

[woda]

Hier die Daten von meinem Router:

# stats
uptime: 6 days, 0:06
KNX communication statistics:
TX to IP (all): 701118 (ca. 69 t/m, 1 t/s)
TX to KNX: 3679 (ca. 0 t/m, 0 t/s)
RX from KNX: 335932 (ca. 33 t/m, 0 t/s)
Overflow to IP: 2
Overflow to KNX: 0
TX tunnel re-req: 255

#

[enertegus]

Wer also mal telnet bemühen kann, bitte hier posten. Wer sowohl unseren als auch einen anderen Router hat, kann ja mal unter hoher Last einen wireshark mitschneiden. Offenbar gibt es ja mit einer Telegrammratenbegrenzung auf 10 Telegramme keine Probleme mehr, also muss es mit den Antwortzeiten und der Abfolge zusammenhängen, auf welcher Seite der Kommunikation auch immer.

[gaert]

Das Problem wird vermutlich bei EDOMI zu suchen sein, ich weiß nur nicht wo ich suchen soll Ich habe mich für mein Verständnis penibel an die Spec gehalten - die meisten Schnittstellen/Router funktionieren ja auch. Ist leider schwer zu rekonstruieren, v.a. ohne die entsprechende Hardware... (Nein, bitte keine HW zusenden - ich habe genug zu tun )

[enertegus]

naja, beim Tunnel is ein Handshake notwendig, sodass sicher dieses in Verbindung mit dem "das Telegramm ist am Bus angekommen" eine min. Zeit vorgibt. Wie gesagt, telnet würde schon die ersten Hinweise geben, was falsch läuft - das könnte ja beide Seiten betreffen. Beim EibPC haben wir zwar keine unendlche Datenrate, aber sicher mehr als 37 pro Sekunde, da ist aber nie was aufgefallen, bei den Tests. Und bei den Zertifizierungstests sowieso nicht.Ich will auch nichts kategorisch ablehnen, vielleicht ist ja mal eine Antwort zu spät oder aus sonstigen Gründen fehlerhaft. Schließlich ist ja der Anwender mit eigener Hardware, VM und v.a. Auslastung etc. unterwegs.
Ich könnte ein kleines Programm schreiben, wo unendlich schnell gegen null konvergiert , aber wir sollten mal das Problem eingrenzen...Man kann ja auch die Belastung künstlich erhöhen, um zu sehen, ob es damit zusammenhängt und sich reproduzieren lässt.

[heckmannju]

EDOMI sollte "unendliche" Datenraten schaffen - der Flaschenhals dürfte entweder die Schnittstelle sein oder die KNX-Installation ist irgendwie fehlerhaft (störanfällig verkabelt bzw. falsch parametriert).

und der Verkablung kann es kaum liegen wenn es mit MDT funktioniert.

[gaert]

EDOMI sollte "unendliche" Datenraten schaffen - der Flaschenhals dürfte entweder die Schnittstelle sein oder die KNX-Installation ist irgendwie fehlerhaft (störanfällig verkabelt bzw. falsch parametriert).

[enertegus]

Das mit der Datenrate kann ein Hinweis sein. Allerdings wäre da zu untersuchen, wo das Problem genau liegt. Beim Router oder Edomi. Bitte mal mit telnet einloggen und stats und die tunnel xx Komandos hier posten. Die Tunnelverbindung ist recht perfomant und schaft ca. 37 Telegramme pro Sekunde im Dauertest kontinulierlich ohne Fehler auf den Bus zu bringen.

[woda]

Selbes Problem, die Reduzierung der Datenrate in EDOMI auf 10 Telegramme pro Sekunde scheint aber was zu bringen.
Seit dem kamen die Fehler nicht mehr...

---

# maximale Telegramrate 
#    EDOMI sendet mit maximal dieser Telegrammrate auf den KNX-Bus.
#    Je nach Auslastung kann die Telegrammrate auch geringer ausfallen, obwohl ein größerer Wert angegeben wurde.
#    1..oo = Telegramme pro Sekunde (die Telegrammrate sollte i.d.R. nicht größer als 20 sein)
global_knxMaxSendRate=10

[SeatSLF]

der Counter in Edomi zeigt an das es sich immer um einen verschiebt,
ich habe es noch nie geschafft da "pünktlich" vor dem Rechner zu sitzen.
Da es alle paar Tage willkürlich kommt, mal Früh's, mal Abends.

Es benötigt keinem manuellen Eingriff und man bekommt es auch nicht mit,
außer das man es im Fehlerlog sieht.

Der Counter in der Kommunikation weicht dann um 1 ab, und fängt sich dann wieder von allein.

Firmware ist die aktuelle von eurer Seite.

[enertegus]

ab und zu hat man verlorene Verbindungen, aber im Betrieb bekommt man es nicht mit.
Man kann es genau nicht eingrenzen, es kommt alle paar Tage mal vor und dann ist wieder Tage lang Ruhe.

Wenn Verbindungen verloren gehen, werden da Error angezeigt bzw. zeit der Counter im Telnetinterface da was an? Grundsätzlich sollte die Gegenstelle bei fehlendem ACK nochmal nachfragen.

[SeatSLF]

ab und zu hat man verlorene Verbindungen, aber im Betrieb bekommt man es nicht mit.
Man kann es genau nicht eingrenzen, es kommt alle paar Tage mal vor und dann ist wieder Tage lang Ruhe.

[enertegus]

Hallo Jürgen,
um ehrlich zu sein bin ich gar nicht auf Enertex zugegangen, da ich mir davon relativ wenig verspreche.

Nun das ist Schade. Wenn Du Dir die Mühe machst, mit einem Wireshark Telegramme aufzunehmen, hätten wir das schon mal verfolgt.

bei denen es mit dem Enertex funktioniert

Mir wäre da nichts anderes bekannt. Oder bestehen hier Probleme?

[gaert]

Ursprünglich war eibd sogar in EDOMI "integriert" (lange vor der Veröffentlichung von EDOMI). Aber das Thema hatten wir ja schon intensivst diskutiert...

Der große Nachteil daran: eibd läßt sich nicht wirklich integrieren, sondern höchstens halbwegs kontrolliert starten und beenden. Die Socket-Kommunikation ist zwar recht simpel, aber auch nicht gerade komfortabel zu integrieren - es würden einige Statusinfos für EDOMI fehlen etc...

Daher wird es bis auf Weiteres erstmal dabei bleiben: Eine IP-Schnittstelle/Router ist Pflicht - oder eben die Nutzung von eibd/knxd auf eigene Faust...

[heckmannju]

Sprich Edomi ist dann der IP Router. Wenn man schon seine Hüdde einem System anvertraut, dann doch besser auf einer Hardware

Finde ich auch eine Gute Idee! Funktioniert sehr zuverlässig auch total unzertifiziert.....