Alle Enertex-Geräte abgestürzt

[mmmm]

ich habe ebenfalls das Problem, dass sich bei mir gelegentlich alle Enertex KNX Devices gleichzeitig aufhängen, bzw. keine Buskommunikation mehr betreiben (via Display sind die Geräte funktionsfähig). Betroffen sind ein SecureInterface (im Jung Branding) und zwei LED Sequencer, alle anderen Geräte am Bus funktionieren weiterhin. Das Problem tritt unregelmäßig auf (vor ca. 2 Monaten das erste mal, dafür 2x diese Woche). Die Entertex Geräte wurden vor 2 Monaten alle auf die zu diesem Zeitpunkt aktuellste Firmware geflashed (allerdings unabhängig davon, nicht als Reaktion auf das Problem).

Ich habe eben logmem auf dem IPInterface ausgelesen, muss aber dazu sagen, dass sich dieses seit dem letzten Neustart NOCH NICHT aufgehängt hatte, d.h. derzeit funktioniert es! Dennoch ist in Logmem ein Eintrag zu finden, der vllt hilft der Sache auf die Spur zu kommen. Leider kann ich mit dem Output nichts anfangen.
Zum Zeitpunkt des Fehlers im Log (heute Morgen) liefen die Geräte jedenfalls problemfrei. Fehlereintrag wie folgt:

# logmem
RAM log memory enabled ...
Attention: Reading can disturb new incomming log in cache or runtime performance
06:25:59 22.09.2023:
Code: 177
Val: 0x9c-0x11-0xf9-0x9c-0x11-0x39-0x08-0x0c-0xe5-0x00-0x80-0x00-0x00-0x00-0x31-0x1b-0x11-0x00-0x87-0x00​D

EDIT:
Ich habe KEINE nicht zertifizierten Geräte, das exotischste ist ein BES RF Bewegungs-/Präsenzmelder

EDIT2:
Ich hatte hier den Post zwischenzeitlich gelöscht, weil nur ein einzelnes Gerät abgestürzt war und ich dachte dass es sich um einen anderen Fehler handelt, mitlerweile sind der zweite 1174 und das IP Gateway aber auch hinterher. Busmonitor hatte ich in der ETS mitlaufen, aber keine Hinweise auf Fehler darin.

EDIT3:
Als untypische Besonderheiten habe/hatte ich hier ein paar "tote" Enden, sprich nicht angeschlossene Geräte, da 2 Stockwerke noch nicht ausgebaut sind. Diese habe ich zum Fehlerausschluss jetzt mal abgeklemmt um auszuschließen dass der Fehler daher rührt (Kriechstrom über unisolierte Enden oder sowas). Ebenfalls war ein unkonfiguriertes Gerät dabei, welches jetzt auch weg ist.

EDIT 4:
Habe eben noch ein altes Weinzierl 730er LAN Interface mit dran geschmissen und daran den Busmonitor gehängt. Damit sollte man dann auch die Telegramme sehen die unmittelbar dann folgen oder gelaufen sind, wenn das SecureInterface schon nichts mehr sendet.

[enertegus]

Nur zur Info:
Der Logmem 177 in unserem Router bedeutet defektes Telegramm.

# logmem
RAM log memory enabled ...
Attention: Reading can disturb new incomming log in cache or runtime performance
06:25:59 22.09.2023:
Code: 177
Val: 0x9c-0x11-0xf9-0x9c-0x11-0x39-0x08-0x0c-0xe5-0x00-0x80-0x00-0x00-0x00-0x31-0x1b-0x11-0x00-0x87-0x0​

0x9C ist das CRTL Byte des Datagramms, also Standard Frame, low priority, dann kommt das Gerät 1.1.249, dann scheint es so als ob ein weiteres Telegramm mitten in das gerade laufende gesendet wird, diesmal von 1.1.57. Diese beiden Geräte sind betroffen, wobei die beide nicht notwendigerweise die Verursacher sind. Vielleicht hilft das trotzdem beim Suchen.

[traxanos]

Ich hab das Problem leider auch immer noch (wenn auch nur sehr sehr selten). Das ärgerliche ist, warum der Stack so unrobust ist und aussteigt. Egal wieviel defekte Telegramme gesendet werden, ein Stack darf nicht einfach aussteigen. Das zeigt nur das der Stack das Fehlerhändling nicht im Griff hat. Mir ist aber auch klar, es ist sehr schwierig so einen Fehler zu finden, da sich sowas nur schlecht reproduzieren läßt.

[willisurf]

Ein Stresstest müsste eigentlich Teil der Zertifizierung des Stacks sein. So kenne ich es zumindest aus dem Automobilbereich für CAN Vernetzung.

[mmmm]

Nur zur Info:
Der Logmem 177 in unserem Router bedeutet defektes Telegramm.
[...]

Vielen Dank!

Also da zum Zeitpunkt des Fehlers ja kein Problem mit den Enertex Geräten vorhanden war, wird das nicht der eigentliche Fehler sein, dennoch ist das befremdlich. Ich werde das heute nochmal untersuchen, welche beiden Geräte da beteiligt sind.
Zudem habe ich mit gerade noch ein Skript gebastelt, dass periodisch logmem, busload und stats vom interface zieht und persistent wegloggt.

[Uwe!]

Das ärgerliche ist, warum der Stack so unrobust ist und aussteigt. Egal wieviel defekte Telegramme gesendet werden, ein Stack darf nicht einfach aussteigen. Das zeigt nur das der Stack das Fehlerhändling nicht im Griff hat.

Ich hab ja schon seit Jahren das Problem, das mein EinPC "abstürtzt", genau genommen ist es das Problem, dass er nicht mehr mit dem Bus kommuniziert. Und ja, das scheint "nur" zu passieren, wenn kaputte Telegramme unterwegs sind. Bei mir war es die Schnittstelle der WP, die da zumindest 90% verursacht hat. Aber ich bin bei Dir und hatte das hier auch schon geschrieben, das der Stack so was abkönnen muss ohne abzustürzen.

[enertegus]

Ein Stresstest müsste eigentlich Teil der Zertifizierung des Stacks sein. So kenne ich es zumindest aus dem Automobilbereich für CAN Vernetzung.

Wird auch gemacht. Aber wenn Teilnehmer die Randbedingungen nicht einhalten, ist das Verhalten nicht mehr definiert. Der Stresstest der KNXA bezieht sich also auf genormte Bedingungen und an sich korrekte Telegramme in sehr großer Anzahl. Das war nicht das Problem. Der Router "stürzt" ja auch nicht ab, sondern sagt, eben, dass hier ein defektes Telegramm empfangen wurde. Egal, ob man dieses Alleinstellungsmerkmal gutheißen mag oder nicht. Aber natürlich kann bei z.B. Spannungsspitzen auf dem Bus auch die Hardware komplett aussteigen oder anhalten. Und wenn man die groß genug macht, sicher auch Geräte zerstören. Das ist aber nun ja ein ganz anderer Stress.
Es mag auch Fälle geben, die irgendwie den Stack zum Anhalten bringen, ich kann das natürlich nicht ausschließen. Den OP hatte ich eine Mail geschrieben, dass wir das defekte Gerät abkaufen (zum Neupreis), sodass wir das auch mal hier nachstellen können, er hatte aber nicht entsprechend geantwortet.

@Uwe: Wir haben hier auch eine Dimplex mit so einem alten KNX Modul. Das ist aber übelste Grütze und leider auch nicht zertifiziert, die Hardware ist, naja reden wir nicht drüber. Bei uns kommen da auch immer wieder Fehler von diesem Gerät im logmem, die dann den Stack nicht zum Stehen bringen. Es kann also sehr wahrscheinlich sein, dass neben den logischen Telegrammfehlern auch physikalische hinzukommen, was ich in Deinem Fall stark vermute.Vielleicht auch unter hoher Telegrammlast etc. Das kann man aber nur dem Modul untersuchen.
EDIT: Es gibt natürlich auch Telegramme beim "Stresstest", die an sich ungültig sind (rein von den Daten). Aber hier testet man halt trotzdem nur eine begrenzte Anzahl von Möglichkeiten

[traxanos]

Hallo enertegus ,

also der OP bin ich. Und ich hab da nichts dergleichen angeboten bekommen. Da auch immer alle meine Enertex Geräte betroffen sind, bis auf der SmartMeter (was aber auch eine ältere Plattform ist), welches Gerät wolltet ihr den abkaufen? Und das Problem ist eher ein Software- und keine Hardwarefehler. Somit bringt das auch nicht sonderlich viel.

Was man mir aber geschrieben hatte, ich möge doch mal bitte den Fehler ohne mein Symcon (Symbox) versuchen nachzustellen. Wie lange den bitte? Einige Monate bis der Fehler auftritt? Und solange klappt halt das Haus nicht mehr, weil die Zentrale fehlt? Dabei nutzt die Symbox ein "KNX BAOS MODUL 830", dass auch zertifiziert ist. Mittlerweile baue ich eigene OpenKNX Geräte, vermutlich müsste ich diese nun auch abklemmen. Dabei traf der Fehler auch ohne OpenKNX Geräte auf, welche aber ebenfalls zertifizierte KNX Module verwenden.

Der Stresstest der KNXA bezieht sich also auf genormte Bedingungen und an sich korrekte Telegramme in sehr großer Anzahl.

Das ist für mich kein Stresstest. Fehlerhafte Telegramme kommen in der Realität immer wieder vor. Teste ich nur mit "korrekten Telegrammen", dann ist das max. ein Funktionstest aber kein Stresstest.

Fakt ist aber, es betrifft nur Enertexgeräte, somit ist das ein herstellerspezifisches Problem. Wir reden hier also nicht von irgend welchen Spannungsspitzen die Geräte tatsächlich auch zerstören können. Für mich war nach dem Vorschlag die Symbox außerbetrieb zu nehmen, der Support-Case geschlossen.

Das logmem hab ich auf dem Schirm, aber leider bin ich bisher nicht zuhause gewesen bei der Störung. Aber vielleicht mögt ihr mal eine Tabelle der Codes liefern. Das Logmem ist immer wieder voll bei mir.

249 und 19 kommen immer wieder vor.

[enertegus]

Sorry ich bezog mich auf den knxheu.
Zu den fehlerhaften Telegrammen hatte ich ja schon ergänzt, dass da sehr wohl fehlerhafte geschrieben werden, sicher nicht aber alle denkbaren. Und schon gar nicht, solche, die physikalisch nicht mehr stimmen also falsche Timings, Busarbitrierung etc. aufweisen. An solche Testumgebungen sind wir aber gebunden, das geht leider nicht anders.

Wenn man den Fehler eingrenzt und nachstellt, sehen wir uns das dennoch gerne an, daher auch das Angebot das defekte Gerät zu kaufen.
Die Errorcodes sind nicht ohne das Verständnis des Quellcodes zu erklären, daher veröffentlichen wir die hier nicht. Das würde leider viel zu weit führen. 249 z.B. ist so Kandidat: ein Wiederholungstelegramm unter bestimmten zusätzlichen Fehlerbedingungen im Stack, die das abgefangen hatten. Aber wenn ich das richtig verstehe, läuft der Router weiter und meldet hier nur. Also insofern hier nicht das Problem.

[traxanos]

enertegus

Der Router läuft immer weiter. Nur die Kommunktion setzt aus. Sprich ich kann Bus- oder Gruppenmonitor öffnen, aber es kommt nichts vom Bus bzw erreicht den Bus. Aber wie gesagt, ich hab es bisher nicht geschafft ein Logmem nach einem solchen Ausfall abzusetzen. Aber bin mir auch nicht sicher, ob das klappt. Logmem schein kein Ringbuffer zu sein. Hatte eben nur Einträge vom Juli. Und nach dem Logmem war der Buffer leer und wurde wieder mit heutigen Einträgen gefüllt. Somit wird das logmem also auch nichts bringen (das muss dringend ein Ringbuffer werden).

[enertegus]

Es ist ein Ringbuffer. Wenn aber der Prozess nichts mehr empfängt, kann auch nichts in den Ringpuffer geschrieben werden.
EDIT: Da wäre vermutlich der letzte Eintrag der interessante

[traxanos]

Ok, vielleicht war es Zufall. Ich kann mir zwar gerade nicht vorstellen, dass seit 2 Monaten keine "Fehler" vorhanden war, und dann zufällig nach dem Aufruf logmem paar Aufgetreten sind, aber Zufälle gibt es ja manchmal doch Und nein der Router lieft noch. Ich beobachte weiter.

[enertegus]

es kann auch so sein, dass die Ausgabe des Logmems tatsächlich den Router in Schwierigkeiten gebracht hat
"Attention: Reading can disturb new incomming log in cache or runtime performance" - das haben wir zu Diagnosezwecken dann aber auch so erlaubt.

[Uwe!]

Wir haben hier auch eine Dimplex mit so einem alten KNX Modul. Das ist aber übelste Grütze und leider auch nicht zertifiziert, die Hardware ist, naja reden wir nicht drüber. Bei uns kommen da auch immer wieder Fehler von diesem Gerät im logmem, die dann den Stack nicht zum Stehen bringen. Es kann also sehr wahrscheinlich sein, dass neben den logischen Telegrammfehlern auch physikalische hinzukommen, was ich in Deinem Fall stark vermute.Vielleicht auch unter hoher Telegrammlast etc. Das kann man aber nur dem Modul untersuchen.

Danke für's Feedback. Ich hab ja vor einiger Zeit auf das neue Modul umgestellt. Das hat wie gesagt eine deutliche Verbesserung gebracht. So aus dem Bauch würde ich sagen 90% weniger Probleme. Ob die 10% vom neuen Modul (das ist aber eigentlich zertifiziert) oder von was anderem kommt, keine Ahnung.
Doofe Frage: Welche Geräte haben/können logmem? Ist mir noch nicht über den Weg gelaufen.

Wie traxanos schon geschrieben hat. Das Problem ist halt, dass solche kaputten Telegramme den Stack zum Stillstand bringen können. Das sollte nicht sein und scheint (fast?) nur euren Stack zu treffen.

[Techi]

Blödes Timing.
Ich wollte in Kürze über 60 Dimmerkanäle von DMX auf direktes KNX Umstellen und hatte dabei die Enertex 1174-REG gesetzt gesehen.
Das wird jetzt wohl erst mal nichts werden. 😒