Vorschlag: Selbstheilung edomi wegen KNX-Fehler

[KNX2013]

Ich habe das Problem identifiziert, nachdem ich auf CentOS 7 ge-updatet hatte und dies keine Besserung brachte.
Für diejenigen, die es interessiert:
Ich hatte etliche Datenarchive, die teils auf 1 Jahr Aufzeichnung standen. Seitdem diese Werte auf "sinnvolle" Zeiträume reduziert wurden, trat bei mir der SequenceCounter Fehler nicht mehr auf.

Grüße
KNX2013

[KNX2013]

Hmm... Ich habe eine Siemens N148/22.
Mein Edomi läuft nicht in einer VM, sondern auf der o.g. Hardware.

Aber ich gehe eher davon aus, dass das Problem mit der ausgelasteten CPU zu tun hat.
Auch kurz nach der Projektaktivierung ist die CPU ausgelastet - die Uhr in meiner Visu bleibt mehrere Minuten stehen.
Beim Laden von aufwendigen Visu-Seiten (viele Diagramme), kommt auch ab und zu die CPU-Warnung...
So wirklich kann ich mir das bei einem Quad core mit 1,6GHz nicht erklären.

Und wie angesprochen: Die "verlorenen" Telegramme treten aus meiner Sicht immer in Kombination mit ausgelasteter CPU auf.

Ich reboote jetzt mal die Kiste. Mal sehen, ob das was bringt.

Gruß
KNX2013

[gogo20012002]

Hatte den Fehler auch immer. Habe dann EDOMI raus aus der VMWare genommen und auf dedizierte Hardwar installiert. Hat nicht geholfen. Nachdem ich jedoch vom MDT IP Router auf das ebenfalls verbauter GIRA S1 umgestellt habe, war der Spuk sofort vorbei und bis heute nicht mehr aufgetreten.

[KNX2013]

Hallo zusammen,

ich habe das Thema "Sequence Counter abweichend" auch schon seit längerer Zeit. Es tritt sporadisch nachts kurz nach 0 Uhr auf.
Nach einigen Recherchen hier im Forum hatte ich schnell das Backup in Verdacht.
Aufgrund dessen habe ich mir die "CPU-Warnung" per Push-Nachricht auf WhatsApp eingerichtet.
Und siehe da: die CPU-Warnung kommt immer zur gleichen Zeit. Letztes Wochenende hatte ich den abweichenden SequenceCounter kurz nach dem Aktivieren des Projekts. Wieder in Verbindung mit einer CPU-Warnung:

[TR="class: sErr, bgcolor: #FFFFFF"]
[TD]2021-01-22 00:03:28[/TD]
[TD]224124[/TD]
[TD]KNX[/TD]
[TD]495[/TD]
[TD]DE < | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=196, Soll-Wert=197 / Raw: 0610042000170445c4002900bce011cd3904030080006a[/TD]
[TD]ERROR[/TD]
[/TR]
[TR="class: sErr, bgcolor: #FFFFFF"]
[TD]2021-01-24 10:11:49[/TD]
[TD]320749[/TD]
[TD]KNX[/TD]
[TD]3053[/TD]
[TD]DE < | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=30, Soll-Wert=31 / Raw: 06100420001904471e002900bce01110000905008000141da6[/TD]
[TD]ERROR[/TD]
[/TR]
[TR="class: sErr, bgcolor: #FFFFFF"]
[TD]2021-01-25 00:03:34[/TD]
[TD]207845[/TD]
[TD]KNX[/TD]
[TD]3053[/TD]
[TD]DE < | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=237, Soll-Wert=238 / Raw: 0610042000170447ed002900bce011cd39010300800000[/TD]
[TD]ERROR[/TD]
[/TR]

Mein System hat folgende Konfiguration:
Pentium J3160 (4x1.6GHz)
4 GB RAM
120GB SSD

Aus meiner Sicht sollte das System doch nicht so arg in die Knie gehen?
Im "Regelbetrieb" habe ich keine übermäßigen CPU Lasten. (s. Screenshot)
Nach der Projektaktivierung kann ich des Öfteren Verzögerungen feststellen.
Nutzt Edomi bzw. CentOS mehrere CPU Kerne? Die CPU sollte das doch eigentlich packen?

Was denkt ihr?

Danke & Gruß
KNX2013

[saegefisch]

Nein, gar nichts mehr oder so sporadisch, dass es mir nicht auffällt und egal ist.

[ChrisChros]

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

Hattest du seit den Einstellungen an der Schnittstellen noch mal Probleme mit verlorenen Verbindungen?

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

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

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

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

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

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]

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

[crewo]

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

Das wäre doch mal einen Versuch wert!

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