Alle Enertex-Geräte abgestürzt

[Uwe!]

DAS habe ich schon verstanden.

Aber aus dem Auftreten von (kleiner 5?) Fällen mit teilweise sehr speziellen Umgebungsbedingungen den prinzipiellen Einsatz von Geräten eines Herstellers zu verteufeln, das halte ich für unverhältnismäßig.

Um das mal klar von meiner Seite zu sagen: 100% Zustimmung.
(obwohl ich willisurfs Aussage nicht als Verteufelung verstanden habe.)

Der Fehler ist nachvollziehbar, für die Betroffenen sehr ärgerlich, er sollte korrigierbar sein, aber ja, es trifft nur sehr, sehr wenige und ich für meinen Teil bin sowohl von den Produkten als auch der Mannschaft dahinter voll überzeugt, empfehle die gern weiter und nutze Enertex über all da, wo sie ein passendes Produkt im Programm haben.

Trotzdem hoffe ich, dass dieser Fehler beseitigt wird.

PS: hatte das schon geschrieben, nur nicht losgeschickt, bevor Michaels Post kam, und seh ihn jetzt erst danach....)

[mmmm]

TL;DR: Ich kann das Problem bei mir isolieren und in endlicher Zeit reproduzieren.

Ganze Story:
Bei mir gab es vor ca. 3 Wochen wieder einen Freeze, diesmal habe ich mir gut Zeit zum Analysieren genommen.

Ich habe seit dem letzten Vorfall auf einer zweiter IP Schnittstelle (Weinzierl 730) einen Busmonitor 24/7 mitlaufen und auf der IP Schnittstelle von Enertex einen Gruppenmonitor. Dadurch konnte ich sehen, welches Telegram wann zuletzt empfangen wurde und was sonst noch so auf dem Bus los war.
Wie bisher auch lief der der Bus nach dem Absturz noch wunderbar weiter, lediglich die Enertex Geräte waren aus dem Rennen.

Ich bin kein guter Autor langer texte, daher folgende Erkenntnisse in Stichpunkten:

1. Um den Zeitpunkt des Absturzes herum waren fehlerhafte Telegramme auf dem Bus unterwegs. Teilweise so, dass Physikalische Adressen von der ETS nicht mehr im Busmonitor angezeigt wurden. Diese sind nicht 24/7 vorhanden.

2. Zum Zeitpunkt des Absturzes war eine für meine Verhältnisse sehr hohe aber legitime (hab mir die Telegramme angesehen) Buslast vorhanden, wir sprechen hier von 4-5 T/s, normal ist bei mir 1 T/s bis 1T/2s.

3. Es waren wieder Fehler im Logmem. Wieder passen diese nicht zur Absturzzeit. Fehlercode war ausschließlich 177.

4. Bei den Fehlern sind in fast allen Fällen die Adressen 1.1.57 und 1.1.249 beteiligt. Adresse 1.1.249 gibt es in meiner Programmierung nicht. Auch ein Linienscan bringt keine 1.1.249. (dazu im folgenden Punkt mehr).

5. Die 1.1.57 gibt es hingegen sehr wohl. Da das Gerät nicht wichtig ist (Sensor für Spaßzwecke), habe ich dieses vom Bus getrennt um zu sehen ob Fehler und Abstürze aufhören. Stand fast 2 Wochen nach der Trennung des Gerätes: Installation und Enertex Geräte laufen stabil. Die Fehler im logmem sind weg. Fehler im Busmonitor ebenfalls nicht mehr feststellbar. Ich habe mehrfach die Telegramme im Busmonitor durchsucht und die 1.1.249 ist nicht ein einziges mal dabei gewesen. Zwischen der nicht existenten 1.1.249 und der potentiell defekten 1.1.57 liegen nur 2 Bit (00010001 00111001 vs 00010001 11111001) ich vermute dass hier Bit gekippt sind. Vermutlich kommt dieser defekt vom Gerät selbst.
Ein konkurrierendes Gerät scheidet meines Erachtes aus, da die 0 bei der KNX Kollissionsvermeidung Vorrang hat. Sprich aus der 249 könnte eine 57 werden, aber nicht einfach umgekehrt. Aber das auch nur falls ich das richtig Verstanden habe...

6. Ich habe weitere Statistiken aus dem IP interface via Telnet geholt. Keine davon hat etwas Relevantes gezeigt.

7. Das Interface war nicht total aus dem Rennen. Ich konnte weiterhin Telegramme auf den Bus senden, die Telegramme waren für andere Geräte sichtbar. Dies jedoch mit mehreren Sekunden Verzögerung. Ich konnte mit dem Interface KEINE Telegramme empfangen, auch nicht mit entsprechender Wartezeit.

8. Die 1174 haben nicht auf Telegramme reagiert. Leider habe ich verpennt zu überprüfen ob diese denn Ihren Status auf den Bus senden, wenn ich sie via Handbedienung am Display ansteuere.

9. Im Gegensatz du den letzten Abstürzen, bei denen ich nur die betroffenen Enertex Geräte vom Bus getrennt habe, habe ich diesmal den LS der SV aus- und wieder eingeschaltet. Danach lief alles wieder.

Meine bisherige Vermutung: Eines der Geräte (1.1.57 - Kein Enertex Gerät) hat einen Defekt. Hohe Buslast verstärkt den Effekt. Dies vertragen die Enertex Geräte schlecht. Die Busankopplung der Enertex Geräte scheint dabei nicht komplett außer Gefecht (vllt schlägt daher auch kein Watchdog zu?). Der Effekt könnte dabei selbstverstärkend sein, da mit dem Wegfall der Enertex Geräte auch die Telegrambestätigungen selbiger ausbleiben, dadurch sind zu diesem Zeitpunkt ein Haufen Pakete mit Retry-Flag unterwegs. Aber das alles ist erstmal nur Raterei.


Danach habe ich die 1.1.57 wieder in die Installation eingebunden:

10. Kurz nachdem die 1.1.57 wieder am Bus war, waren wieder Fehler im Logmem. Wieder 177er.

11. Drei Tage nachdem die 1.1.57 wieder am Bus war kam der nächste Freeze. Leider habe ich nicht isoliert getestet ob sich alle Enertex Geräte verabschiedet hatten. Wenigstens die LAN Schnittstelle war weg. Nach einem Reboot alles wie vorher.


Ich hatte zwar diesmal dran gedacht zu testen ob die 1174 noch einen Status auf den Bus senden (Ja tun sie), dafür aber vergessen zu testen ob sie das gleiche Fehlerbild wie sonst zeigen (die Uhrzeit ist schon fortgeschritten ).


Weiterer Plan:
1. Nochmal so weiterlaufen lassen und testen ob es sich ein weiteres mal reproduzieren lässt.
2. Die 1.1.57 an anderer Stelle in den Bus einbinden. Und testen ob das Problem weiter besteht oder sich erledigt.

Bisher sieht es so aus als ob das Gerät 1.1.57 defekt ist und ich das Problem in meiner Installation binnen weniger Tage reproduzieren kann.

[meti]

Welches Gerät ist denn dein 1.1.57?

[traxanos]

Ja das würde mich auch interessieren.

Das der Fehler durch ein "defektes" Telegramm ausgelöst wird, ist vermutlich allen soweit klar. Nur leider sind in einer gesunden Installation solche Telegramme eher selten. Wenn du jetzt ein Gerät hast, das diesen Fehler "provozieren" kann, hätte das den Vorteil, dass man den Fehler im Stack leichter finden kann.

Vorausgesetzt Enertex hat an der Beseitigung des Fehlers ein Interesse

[mmmm]

Ist vorgestern dann nochmal abgestürzt. Da hat man dann sehr deutlich gemerkt, dass das LAN Interface noch senden kann, aber einige Sekunden Verzögerung hat.

Jetzt ist das Gerät wieder aus der Installation genommen und ich beobachte mal.

Die 1.1.57 ist ein Lingg&Janke 85501 Wasserzähler.

Wollte das Gerät dann ja nochmal an anderer Stelle einbinden um das weiter zu analysieren, aber dazu brauch ich erst ein bisschen Zeit.

[mbrockeu]

Hallo Zusammen,

nachdem ich mein LED Dimmer von Enertex aus dem Support wieder zurückbekommen habe wollte ich probieren, ob das Problem nun weg ist.
Es hat leider nicht lange gedauert bis das Teil wieder nicht erreichbar war.

Bei mir ist das Problem damals im April mit das erste mal aufgetreten, es äußerte sich unter anderem wie folgt:
1. Keine Telegramme wurden entgegengenommen, Licht konnte entweder nicht ein oder ausgeschaltet werden
2. der Bus wurde mit Telegrammen überschwemmt und meine Taster und PMs reagierten alle nicht mehr > nach dem abklemmen hat sich alles normalisiert und es lief wieder
3. Das Gerät war irgendwann nicht mehr erreichbar
4. Das Firmwareupdate ist immer abgebrochen

Bei mir Betraf es nur das REG Gerät, ich habe noch 3 DK die funktionieren alle ohne Probleme.

Parametrisiert war das Gerät auf 2x TW und 1x EK, bei den TW war auch HCL aktiviert und ich hatte irgendwie die Vermutung damit fing das Problem erst an.

Das Gerät war jedenfalls jetzt im Support, es konnte nix festgestellt werden, aktuelle Firmware wurde noch einmal geflasht.

Ich habe jetzt das gleiche Applikationsprogramm noch einmal drauf gemacht und es hat keine 2h gedauert bis das Gerät nicht mehr reagiert. Klemme lösen würde helfen, oder Werksreset.

Aktuell lasse ich ihn ohne Applikation laufen um zu schauen ob er sich einfach aufhängt und danach werde ich mal den Standard mit 2xTW und 1x EK testen.

[mbrockeu]

Nach einer Nacht Erkenntnis habe ich für mich folgendes festgestellt:

1. Gerät ohne Applikation war lange erreichbar
2. Applikation mit TW funktioniert auch, Steuerung über PMs und Taster möglich

Bei der Verwendung von HCL gibts aber die Probleme. Einschaltverhalten ist Uhrzeitgesteuertes Dimmen, soweit kein Problem funktioniert. Status für HCL ist inaktiv.

Wenn ich HCL aktiviere über Taster oder ETS, dann reagiert kein Taster oder PM mehr auf dem System. Ich kann meine Lampen, egal welche über Taster oder App nicht ausschalten. Lediglich über die ETS direkt auf der GA. Sobald HCL wieder inaktiv ist funktioniert alles wie gehabt.

Jemand ne Idee?

[Schuhmi]

Hallo mbrockeu,

nach den zuletzt geschriebenen Informationen scheint das Problem entweder von einer fehlerhaften Parametrierung oder von einem Bug in der Applikation zu kommen.
Ich denke, dass das Problem aber nichts mit dem Titel des "Alle Enertex Geräte hänge sich auf" zu tun hat.

Ich würde mir gerne ihren Fall noch einmal am Montag genauer ansehen. Am besten sie schreiben noch eine email an den Enertex-Support. Dann könnten wir zusammen nächste Woche ihr Projekt evtl. über eine Remote Session ansehen.

Viele Grüße

[mmmm]

Edit: Frohes neues Jahr euch allen

TL;DR: Ich kann das Problem bei mir isolieren und in endlicher Zeit reproduzieren.

War ich dann doch etwas voreilig... hier mal ein Update:

Der Sensor hängt seit einiger Zeit wieder am Bus, diesmal an anderer Stelle eingebunden. Das Logmem ist auch wieder gut gefüllt, aber die Enertex Geräte zeigen keine Anzeichen von Schwäche...

Ich bin nicht ganz sicher was die Position der Einbindung damit zu tun hat, schließlich ist am Ende alles parallel geschaltet. Der Sensor hing auch nicht am Ende eines KNX Astes, sondern mitten drin, Geräte davor und danach funktionieren fehlerfrei. Auch jetzt an seiner neuen Position gibt es ja Fehler. Aber meine Enertex Geräte störts nicht...

Neuer Plan:
1. Nochmal einige Zeit so hängen lassen und schauen ob es sich wirklich nicht so reproduzieren lässt.
2. Wieder an seiner ursprünglichen Position einbinden und beobachten.