Vorschlag: Selbstheilung edomi wegen KNX-Fehler

[saegefisch]

edomi + KNX-Router hängen auch bei mir an einem manged Switch in einem eigenen Haus-VLAN.

Vielen Dank allerseits, nach den ganzen Vorschlägen:
* Werde es einfach mal versuchen, die beiden mit einem unmanged-Switch davor direkt zu verbinden, um das Thema LAN auszuschließen - oder es darauf zurück zu führen im besten Fall...
* Den KNX-Router noch mal prüfen, vielleicht gibt etwas, was ich an den Tunneln verändern kann.

[crewo]

Ich dachte es wurde hier in den div. Beiträgen schon ein eigenes VLAN als Lösung beschrieben. Im Prinzip könnten schon hier einige UDP/TCP-Broadcast-Schleudern den hardwareseitig eher schwachbrüstigen KNX-Router aus dem Tritt bringen. Ich würde mal vermuten, umso weniger Traffic hier in "seinem" Netzwerksegment unterwegs ist, umso zuverlässig funktioniert die Kommunikation über seine Tunnelverbindungen.

Haben die Kandidaten mit den Problemen mal ihr LAN analysiert, z.B. mit einem Wireshark? Es muss ja nicht immer gleich ein VLAN-Konstrukt sein, eventuell hilft auch das gezielte Eindämmen von Datenschleudern im LAN.

[saegefisch]

crewo Interessante Theorie...könnte passen... im selben VLAN habe ich auch mein SMA Energymeter, dass per Multicast in <1s-Takt Daten schickt...auf die ich allerdings auch nicht auf dem edomi-Server verzichten mag...

[enertegus]

Also ich habe auch einen ENERTEX Secure und echte Hardware, leider trotzdem viele dieser Meldunge

Was sagt denn logmem (Telnetkommando)?

[Winni]

Hallo enertegus ,

hab' jetzt gestern erstmal von 1.026 auf 1.028 upgedated, ist auf den ersten Blick ruhiger geworden:

KNX.jpg
Ob's auf lange Sicht besser wird, muss ich erst abwarten, fahre aber morgen früh für 'ne Woche in Urlaub. Trotzdem hier mal die gewünschte Info:

KNXIP Secure Telnet Server, v1.028
(no more than 58 characters per command)

Password: *********

# logmem
RAM log memory enabled ...
no entry in RAM log cache

# tunnel 1
Tunnel 1..................: open (CCID 225)
KNX address...............: 01.00.241
HPAI control..............: 192.168.5.22:50000
HPAI data.................: 192.168.5.22:50001
Connect. type.............: TUNNEL_CONNECTION
Communication.............: UDP CONNECTION
TX tun req................: 15707
TX tun re-req.............: 2
RX tun req................: 2184
RX tun re-req (identified): 0
RX tun req (wrong seq.)...: 0
Current tunnel buffer.....: 0 %
Connected since (UTC).....: 09:47:55 21-08-2019

#

Viele Grüße,
Winni

[maxl]

ich hatte vor dem Update auf die 2.0 auch diese Fehler im Log DE < | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK):.... seit dem Update vorige Woche sind diese Fehler nicht mehr aufgetaucht !?

jetzt hab ich nur noch Täglich pünktlich 43-45 sekunden nach Mitternacht ein CE < | DISCONNECT_REQUEST und gleich darauf ein KNX-Verbindung verloren hatte ich aber vorher auch schon fast täglich - keine Ahnung warum

nachdem das ganze keine Beeinträchtigung im Betreib darstellt sehe ich das aber ganz entspannt - Error anzeigen an den Visu´s sind ausgeschaltet.

[enertegus]

Hallo enertegus ,

hab' jetzt gestern erstmal von 1.026 auf 1.028 upgedated, ist auf den ersten Blick ruhiger geworden:

KNX.jpg
Ob's auf lange Sicht besser wird, muss ich erst abwarten, fahre aber morgen früh für 'ne Woche in Urlaub. Trotzdem hier mal die gewünschte Info:
# logmem
RAM log memory enabled ...
no entry in RAM log cache

Dann hat hier schon mal der Router kein Problem.

# tunnel 1
Tunnel 1..................: open (CCID 225)
KNX address...............: 01.00.241
HPAI control..............: 192.168.5.22:50000
HPAI data.................: 192.168.5.22:50001
Connect. type.............: TUNNEL_CONNECTION
Communication.............: UDP CONNECTION
TX tun req................: 15707
TX tun re-req.............: 2
RX tun req................: 2184
RX tun re-req (identified): 0
RX tun req (wrong seq.)...: 0
Current tunnel buffer.....: 0 %
Connected since (UTC).....: 09:47:55 21-08-2019

2x hat der Router von der Gegenstelle keine Antwort bekommen und musste wiederholen. Du könntest den Timeout für das Tunnelling im telnet mit

tunneltime 2.5

auch mal erhöhen.

Unser Enertex Secure Router und das Secure Interface können auch TCP anstelle von UDP. gaert
: Wäre es nicht möglich, dass Edomi die Kommunikation via TCP macht, dann müsste man die Sequenznummern nicht mehr berücksichtigen und hätte vom Timing her kein Problem.

[crewo]

Unser Enertex Secure Router und das Secure Interface können auch TCP anstelle von UDP

Das wäre doch mal einen Versuch wert!

[saegefisch]

enertegus : wieder daheim...hier meine Daten aus dem Router

Neustart wegen verlorenem Connect:
2019-08-22 22:28
2019-08-19 06:44
2019-08-18 23:19
2019-08-17 01:59
2019-08-11 11:49
2019-08-10 05:12
2019-08-06 22:43
2019-08-06 22:00
2019-08-06 14:31
2019-07-21 03:35
2019-07-17 02:54
...

KNXnet/IP telnet server, v1.043

# stats
uptime: 26 days, 18:42
KNX communication statistics:
TX to IP (all): 3261960 (ca. 84 t/m)
TX to KNX: 173301 (ca. 4 t/m)
RX from KNX: 1416709 (ca. 36 t/m)
Overflow to IP: 48
Overflow to KNX: 1356
TX tunnel re-req: 103

# tunnel 1
Tunnel 1......: open (CCID 97)
KNX address...: 01.00.255
HPAI control..: edomi-IP:50000
HPAI data.....: edomi-IP:50001
Connect. type.: TUNNEL_CONNECTION
TX tun req....: 55934
TX tun re-req.: 0
RX tun req....: 4405
RX tun re-req (identified): 0
RX tun req (wrong seq.)...: 1

Kann man daraus einen Grund für die Verbindungsabbrüche erkennen? Die Overflows sind möglicherweise auffällig. Besser Rate in edomi senken? Derzeit 30, laut Handbuch kann der enertex ja 35.

Umgebung: Eigenes VLAN für "Haus" (inkl. SMA-EnergyMeter, d.h. ~1s Multicast), edomi + KNX-Router an physikalisch gleichem Switch

[enertegus]

enertegus : wieder daheim...hier meine Daten aus dem Router
Overflow to IP: 48

Die Gegenstelle hat 48 Telegramme nicht beantwortet (ggf. auch beim Öffnen/Schließen des Tunnels)

Overflow to KNX: 1356

Der Router konnte 1356 Telegramme nicht auf den Bus bringen, vermutlich zuviele Telegramme in kurzer Zeit - mehr als 40/s gehen beim alten Router nicht. Dabei muss man bedenken, z.B. 20 Lesefragen => 20 Antworten plus Telegramme des normalen Busverkehrs..., also sind hier ca. 15 eine gute Wahl.

TX tunnel re-req: 103

Der Router hatte bei 103 Telegrammen nicht binnen 1s Antwort erhalten. Andere Hardware für Edomi?

Besser Rate in edomi senken?

s..o

[saegefisch]

Danke für die Rückmeldung.
Habe jetzt die Telegrammrate in edomi herab gesetzt. Ich werde sehen...

An der edomi-HW sollte es nicht liegen: Dedzierte core-i3 (ohne VM), Regellast bei 1-6%
Sind die 103 in Bezug auf die Uptime?

[enertegus]

Danke für die Rückmeldung.
Habe jetzt die Telegrammrate in edomi herab gesetzt. Ich werde sehen...
An der edomi-HW sollte es nicht liegen: Dedzierte core-i3 (ohne VM), Regellast bei 1-6%
Sind die 103 in Bezug auf die Uptime?

Die gesamte Infrastruktur kann theoretisch das Problem sein, Latenzzeiten etc.. Schließlich muss das UDP Telegramme 2x hin und her laufen. Oder einfach Stoßlasten, oder oder...
Die 103 sind seid uptime.

[gaert]

Nicht umsonst ist die Defaulteinstellung in EDOMI 20/s - so nutze ich das auch ohne Probleme seit Jahren (zwar mit einem Eibmarkt-Router, aber das sollte keine Rolle spielen).

[saegefisch]

Der Router konnte 1356 Telegramme nicht auf den Bus bringen, vermutlich zu viele Telegramme in kurzer Zeit - mehr als 40/s gehen beim alten Router nicht. Dabei muss man bedenken, z.B. 20 Lesefragen => 20 Antworten plus Telegramme des normalen Busverkehrs..., also sind hier ca. 15 eine gute Wahl.

Seit dem 23.08. Rate etwas reduziert auf 29/s gesetzt: Keine Verbindungsabbrüche mehr seit dem. Aber via Telnet zeigt mir der Router mit jedem edomi-Neustart immer noch steigende "Overflow to KNX". Die 30/s waren offenbar in meiner spezifischen Umgebung (LAN, edomi, KNX-Router) kritisch.

Test mit 25/s und auch mit dem edomi-Standard 20/s: Router zeigt weiterhin mit jedem Neustart steigende Fehlerzahlen, wenngleich das Delta mit sinkender Rate erwartungsgemäß kleiner wird.

Test mit 15/s: Erst damit liefert der Router tatsächlich keinen höheren Fehlerwert mehr an (also Delta = 0)

Ich habe mich jetzt erst einmal wieder für die 20/s Standardwert entschieden - und folge dem weisen Rat von Christian. Danke für Eure Mithilfe, die (letztlich total banale und selbst gemacht) Ursache nun doch in diesem Thread zu finden. Ursache ist immer besser als Symptom. Meine Selbstheilung lass' ich aber ganz sicher dennoch aktiv - sischa isss sischa...

[GeorgGGs]

Grüß euch, das mit dem "Eibmarkt-Router" hat mich hellhörig gemacht. Den hab ich auch mit einer eigenen NUC i3 auf dem Edomi läuft und diese Tunneling-Request Fehler bekomme ich auch, so um die 1000 im Zeitraum einer Woche . Ich habe bisher alle Schuld auf das Eibmarkt-Gateway geschoben, aber scheinbar ist es doch nicht schuld. An den Defaulteinstellung hab ich nichts geändert, jetzt probiere ich es mal mit einem eigenen VLAN.