Ankündigung
Einklappen
Keine Ankündigung bisher.
verlorene KNX Verbindung
Einklappen
X
-
Ich hab in letzter Zeit auch wieder vermehrt den Fehler. Hab das Gefühl es hat was mit dem Netzwerk zu tun. Irgendwelche clients die vll. nur 100Mbit haben aber auf dessen Geschwindigkeit auf Auto stehen oder so. Bei mir hat es wieder angefangen nachdem ich mein Netzwerk neu aufgebaut hab. Aber auch unerklärlich und ich denke das mein Netzwerk sehr gut aufgebaut ist
-
Ich streu dann mal wieder mein „hab KEINEN MDT Router/Interface und trotzdem diese Fehler“ ein..
- Likes 1
Einen Kommentar schreiben:
-
Ich habe auch den MDT-Router SCN-IP100.02 und hatte ebenfalls immer wieder den Fehler mit dem abweichendem Sequence Counter. Hatte den Fehler dann via config unterdrückt, um nicht immer 1000 neue Fehler im Log zu haben.
Habe jetzt mal das Update auf 1.08 installiert und die neuste Edomi Version. Mal schauen ob der Fehler wieder auftaucht, wenn ich die config wieder zurückstelle. Aber scheint ja ein allgemeines Problem mit der MDT-Router und Edomi zu sein.
Einen Kommentar schreiben:
-
Würde ich gerne, wenn ich einfacher dazukäme. (Dachte ursprünglich auch, dass sei ein Installieren und Vergessen Gerät...jetzt ist es eher eins zum Vergessen.)
Und wenn ich jetzt vermutlich ein mobiles Gerüst mieten muss, so möchte ich den Zugang nicht nur einfach zum Abmontieren und prüfen verwenden, sondern wohl eher grad für ein Ersatz. Und dann möglicherweise von einem anderen Hersteller.
Und da ich keine Garantie mehr habe, rechne ich auch nicht mit viel Kulanz von Elsner. Aber ich werde sicher mal anfragen, ob sie diese Symptome kennen oder gar eine gewisse Serie betroffen war.
Einen Kommentar schreiben:
-
Ich habe den Suntracer bei 2Objekten seid gut 2Jahren im Einsatz.
Installieren und vergessen. Bin von dem Ding echt begeistert.
Lass das Ding doch mal bei Elsner prüfen.
Einen Kommentar schreiben:
-
So, wieder mal paar Erkenntnisse bei diesem Thema.
Diese Nacht ist mir aufgefallen, dass sich mal die Jalousien bewegt haben (was sie natürlich nicht sollten) und heute Vormittag waren alle Jalousien unten, obwohl es schon längst hell war.
Hab dann gesehen, dass im Edomi keine aktuellen Werte der Wetterstation geliefert wurden. (Somit war das Verhalten erklärbar.)
In der ETS konnte ich auch keine Werte der Wetterstation auslesen, zudem hatte ich immer wieder im Gruppenmonitor grau markierte Zeilen mit Quelle 15.15.242 bzw. 15.15.241 (anstatt die des Aktors).
Auch sonst konnte ich bei anderen KNX-Devices keine Werte manuell auslesen. (Im Gruppenmonitor lief aber trotzdem Traffic durch.)
Hab dann den IP-Router wieder mal kurzzeitig vom KNX-Bus getrennt und wieder angehängt. Leider hat das überraschenderweise keinen Erfolg gebracht. Wetterstation lieferte immer noch nichts.
Also die Zusatzspannung der Wetterstation (Elsner Suntracer KNX) getrennt und wieder verbunden. Danach lieferte die Wetterstation wieder normale Werte und ich konnte auch alles manuell auslesen.
Diese Wetterstation (war von Anfang an ein teurer Fehlkauf) macht mir jetzt schon seit ein paar Wochen Probleme (aber definitiv nicht im gleichen Zeitraum wie meine KNX-Fehlermeldungen). Musste jetzt schon 3-4x die Spannung trennen, damit sie wieder reagierte. Also die scheint langsam abzusterben.
Kann es sein, dass diese Wetterstation durch ein Fehlverhalten auch den IP-Router so beeinflussen kann, dass ich auch z.T. andere Devices nicht mehr manuell über den IP-Router auslesen kann und auch Edomi dann Probleme bekommt?
Wir waren jetzt den Tag unterwegs und am Abend zurückgekommen. Und die Wetterstation liefert wieder keine Werte bzw. ist eingefroren. Da leider die ganze Beschattung von diesen Werten abhängt, hat das doch einen grossen Einfluss.
Leider wurde die Wetterstation auf der Aussenseite unseres Flachdaches in ca. 6m Höhe montiert. Ich komme da weder mit einer Leiter noch vom Dach her hin.
Ich könnte die Wetterstation mal ein paar Tage von der Spannung (und evtl. Bus) trennen und schauen, ob ich dann keine Fehlermeldungen mehr im Edomi erhalte (da ich diese unterdessen täglich habe, sollte man das gut erkennen).
Bedeutet zwar, dass ich in dieser Zeit die Jalousien manuell betätigen muss, aber wenns der Fehlereingrenzung dient.
Einen Kommentar schreiben:
-
Schwierig zu sagen. Bin überrascht, dass ETS öfters die Verbindung verliert als Edomi. Läuft dein ETS evtl. über ein WLAN (direkt oder indirekt)? Dies könnte eine Erklärung sein, da UDP Pakete nicht übertragssicher sind wie mit TCP.
Auch die Energiesparoptionen können diese Probleme verursachen. Mir ist auch schon aufgefallen, dass ich manchmal die Verbindung verliere, wenn ich mein Laptop schnell zu- und dann sofort aufgeklappt habe. Eventuell wird da ein Prozess gestört oder abgebrochen. Das Phänomen habe ich noch nicht festgestellt, wenn ich den Laptop zuklappe und ihn zugeklappt weiter laufen lasse. Dies kann man auch mit laufende Pinganfragen feststellen.
Counter-Abweichungen kommt daher, da Edomi die Pakete vermutlich streng inkrementiert. Auf Grund UDP kann es vorkommen, dass Counter nicht immer das ist was erwartet - passiert häufig wenn eine "Race Condition" stattfindet (siehe: https://de.wikipedia.org/wiki/Race_Condition ). Hier fehlt eine Kollisionsverarbeitung und in im besten Fall zeigt Visu nur etwas Falsches an (was dann auch früher und später wieder korrigiert wird). Wenn es richtig dumm wird, dann laufen die Logiken anders als erwartet.
Zurück zum Thema Verbindungsabbrüche, meine Vorschläge:
* Logge die Pings zu deinem Router / Switch
* Logge die Pings zu deinem IP Router
* Lasse ETS noch mal laufen (kabelgebunden und deaktiviere die Energiesparoptionen)
* Lasse Edomi laufen (kabelgebunden)
Siehst da etwas? Praktischer wäre natürlich, wenn man einen 2. IP Router hätte (oder z.B. Wiregate mit TPUART).Zuletzt geändert von pitschr; 31.05.2018, 11:28.
Einen Kommentar schreiben:
-
Bei mir hängt am MDT Router (v1.08) an der einen Tunnel IP Edomi und an der zweiten ETS.
Jetzt habe ich mal die letzten drei Tage den Gruppenmonitor in der ETS mitlaufen lassen. Dieser hat 9x die Verbindung verloren.
Parallel dazu hat Edomi 4x die Verbindung verloren und 2x Counter Abweichungen:Code:[TABLE] [TR] [TD]28.05.2018 22:18:58,697[/TD] [TD]Beginn der Aufzeichnung[/TD] [/TR] [TR] [TD]29.05.2018 20:30:48,355[/TD] [TD]Verbindung verloren[/TD] [/TR] [TR] [TD]29.05.2018 20:31:48,388[/TD] [TD]Verbindung hergestellt[/TD] [/TR] [TR] [TD]30.05.2018 09:30:24,725[/TD] [TD]Verbindung verloren[/TD] [/TR] [TR] [TD]30.05.2018 09:31:10,707[/TD] [TD]Verbindung hergestellt[/TD] [/TR] [TR] [TD]30.05.2018 09:33:39,967[/TD] [TD]Verbindung verloren[/TD] [/TR] [TR] [TD]30.05.2018 09:34:21,453[/TD] [TD]Verbindung hergestellt[/TD] [/TR] [TR] [TD]30.05.2018 13:37:35,644[/TD] [TD]Verbindung verloren[/TD] [/TR] [TR] [TD]30.05.2018 13:38:35,687[/TD] [TD]Verbindung hergestellt[/TD] [/TR] [TR] [TD]30.05.2018 16:27:41,374[/TD] [TD]Verbindung verloren[/TD] [/TR] [TR] [TD]30.05.2018 16:28:41,402[/TD] [TD]Verbindung hergestellt[/TD] [/TR] [TR] [TD]30.05.2018 18:06:44,230[/TD] [TD]Verbindung verloren[/TD] [/TR] [TR] [TD]30.05.2018 18:07:44,273[/TD] [TD]Verbindung hergestellt[/TD] [/TR] [TR] [TD]30.05.2018 18:38:54,951[/TD] [TD]Verbindung verloren[/TD] [/TR] [TR] [TD]30.05.2018 18:39:54,983[/TD] [TD]Verbindung hergestellt[/TD] [/TR] [TR] [TD]30.05.2018 19:16:55,741[/TD] [TD]Verbindung verloren[/TD] [/TR] [TR] [TD]30.05.2018 19:17:55,770[/TD] [TD]Verbindung hergestellt[/TD] [/TR] [TR] [TD]30.05.2018 19:49:06,441[/TD] [TD]Verbindung verloren[/TD] [/TR] [TR] [TD]30.05.2018 19:50:06,469[/TD] [TD]Verbindung hergestellt[/TD] [/TR] [TR] [TD]31.05.2018 07:29:52,157[/TD] [TD]Ende der Aufzeichnung[/TD] [/TR] [/TABLE]
Edomi.png
Ich kann da keinen Zusammenhang erkennen. Bei den Zeitpunkten im Edomi Log kann ich mit Sicherheit sagen, dass nur der Standard Busverkehr am laufen war. Also keine ETS Prog oder Edomi Deployments.
Jetzt gehen mir auch die Ideen aus wie man den Fehler noch eingrenzen kann.
Einen Kommentar schreiben:
-
Kannst du dich vielleicht errinnern was du da gemacht hast? Evtl. Update (Router, Edomi)? Änderung im Netzwerk / Einstellungen?Zitat von rdeckard Beitrag anzeigenDenn das Problem ist da und komischerweise ja erst seit ein paar Monaten.
Wenn du noch einen Server hast (evtl. den gleichen wo Edomi läuft), dann könntest du auch mit Calidomus (ein Java Programm) mitaufzeichnen und ggf. mit Edomi gegen vergleichen. Ich gehe davon aus, dass die eintreffenden Pakete bei Edomi und Calidomus ziemlich gleich sein müssten (ausser Channel ID).Zitat von rdeckard Beitrag anzeigenEvtl. könnte ich hier mal den KNX-Bus länger tracen (über ein USB-Interface) und dann schauen, ob es etwas gibt, dass zum Zeitpunkt des Fehlers verdächtig wäre. Ist für mich aber relativ aufwändig, da ich keinen Laptop jetzt mehrere Tage nur an den Bus hängen kann.
Grund: Calidomus unterstützt auch einige "exotische" Pakete wie z.B. (A_IndividualAddress_Read-PDU). Siehst du da den Stabilitätsunterschied? Kannst evtl. die KNX Fehler mitteilen, die du auf Edomi siehst?
Selbst wenn das Problem beim Router besteht, gilt es zuerst abzuklären ob das Problem auf Grund Abweichung im KNX Spezifikation auftritt oder nicht. Andere Hersteller könnten "fehlertoleranter" sein. Mir als ITler ist lieber ich falle so recht fest auf die Fresse, als wenn das Problem irgendwie verschleiert wird. Der Endbenutzer sieht es natürlich anders ;-)Zuletzt geändert von pitschr; 28.05.2018, 09:41.
Einen Kommentar schreiben:
-
hjk
Mir liegt es fern, voreilig einen Schuldigen zu benennen. Deshalb versuche ich auch meist eine neutrale Wortwahl zu verwenden. (Und selbst wenn es am Ende wirklich am MDT-Router liegen sollte, so muss das nicht heissen, dass diese generell fehlerhaft sind. Es kann ja nur ein Defekt meines Gerätes oder ein paar wenige mehr sein.)
Da ich in der IT-Branche arbeite, weiss ich, wie komplex solche Dinge sein können und wie (verständlicherweise) alle involvierten Parteien zuerst mal das Problem von sich weisen. (Das bekannte Ping-Pong-Spiel)
Gemäss euren Tests scheint es nicht am MDT-Router zu liegen und gemäss gaert liegt es auch nicht an Edomi. Gut, nur nützt mir das halt herzlich wenig. Denn das Problem ist da und komischerweise ja erst seit ein paar Monaten.
Leider kann ich das Problem bis jetzt nicht reproduzieren. Es geschieht völlig zufällig. Somit kann ich auch nicht versuchen, die Ursache(n) einzugrenzen.
Fakt ist sicher, dass das Problem auf dem IP-Router entsteht. Also der Übergang zwischen IP-Netz und KNX-Bus. Da diesen Übergang nur die ETS (selten) und vorallem Edomi nutzen, wird das Problem dort natürlich sichtbar (Fehlerlogs oder im schlimmeren Fall fehlende Funktionalität).
Ein KNX IP-Router hat ja zwei Bereiche, die ihn beeinflussen/stören können. Der KNX-Bus und das IP-Netzwerk. Von beiden Bereichen könnte er fehlerhafte Pakete erhalten, die seine Funktion beeinträchtigen. Natürlich könnte MEIN IP-Router selber einen Defekt aufweisen, was aber eher etwas unwahrscheinlich ist, da ich ja nicht der einzige mit diesem Verhalten bin.
Falls jetzt der KNX-Bus oder das IP-Netzwerk die Ursache dafür sind, dann muss man ja irgendwelche Anzeichen dafür haben.
Meine anderen KNX-Komponenten scheinen seit 2,5 Jahren stabil zu laufen (der Grossteil übrigens MDT-Produkte). Wäre der Bus fehlerhaft oder würde durch fehlerhafte Telegramme überflutet, müsste ich das vermutlich auch an anderen KNX-Komponenten bemerken. (Gut, der IP-Router ist natürlich die Komponente, die wohl am meisten genutzt wird und somit auch als erstes von Problemen betroffen sein würde. Zumindest würde man es hier in Edomi sehr schnell bemerken. Andere KNX-Komponenten werden vielleicht in der Zeitdauer des Problems gar nicht benutzt und somit bemerkt man es dort gar nicht.)
Evtl. könnte ich hier mal den KNX-Bus länger tracen (über ein USB-Interface) und dann schauen, ob es etwas gibt, dass zum Zeitpunkt des Fehlers verdächtig wäre. Ist für mich aber relativ aufwändig, da ich keinen Laptop jetzt mehrere Tage nur an den Bus hängen kann.
Das zweite Standbein ist ja das IP-Netz. Ich konnte z.B. gestern die IP-Adresse des KNX IP-Routers nicht mehr pingen, als die ETS ebenfalls die Verbindung verlor.
Für mich war das aber eher ein Problem am IP-Router und nicht an der Connectivity bis zum IP-Router. Denn alle anderen Netzwerkkomponenten konnte ich normal anpingen. Ich habe auch sonst keine Ausfälle im Netzwerk. Mein Netzwerk hat wegen 5 IP-Kameras, die non-stop auf das NAS streamen und zusätzlich IPTV (z.t. 4K Streams) sicher eine ständige Grundlast, aber die verwendeten IP-Switche (HPE 1920-48 und UniFi 16 POE-150W) sind dafür ausgelegt und laufen im Keller in einem 19"-Rack.)
Und selbst wenn mein IP-Netz wirklich "schlecht" oder überlastet wäre, warum ist einzig der KNX-IP-Router davon betroffen?
Leider habe ich kein Ersatz KNX-IP-Router im Hause, sonst hätte ich das schon längstens getestet. Ohne jetzt dem IP-Router die Schuld zu geben, finde ich es in meinem Fall die effizienteste Variante, mit einem Austausch das Problem besser eingrenzen zu können. Leider ist dies mit finanziellem Aufwand verbunden. (Aber zumindest hätte ich dann auch ein Reserve IP-Router im Hause, was glaub nicht so schlecht ist. Ich merke nämlich, wieviel bereits jetzt über Edomi läuft und somit unterdessen eine grosse Abhängigkeit von IP-Router und Edomi entstanden ist.)
Einen Kommentar schreiben:
-
Nach unseren bisherigen Testergebnissen mit Edomi liegt das mit sehr hoher Wahrscheinlichkeit nicht am Router.
Die Tests laufen noch weiter.
- Likes 1
Einen Kommentar schreiben:
-
Gestern Abend wieder mal eine "gröbere" Sache mit diesem komischen Problem. Wie so oft aus heiterem Himmel plötzlich mehrere hundert KNX-Fehlermeldungen in Edomi.
In diesem Fall auch mit "echten" Auswirkungen, sprich Edomi konnte keine KNX-Befehle mehr absetzen. (Meine Frau wollte die manuell gestartete Gartenbewässerung via Edomi abschalten, was zwar am Aktor zum Glück noch ankam, aber in der Edomi-Visu nicht mehr korrekt angezeigt wurde.)
In Edomi zählten die KNX-Fehler im Sekundentakt (oder gar weniger) hoch. (Hab den Edomi-Server neu gestartet.)
Hab dann in der ETS4 versucht zu schauen, ob ich auf dem Bus ebenfalls massive Fehler sehe. Dort war komischerweise Ruhe.
Als ich dann im Gruppenmonitor manuell mal paar GAs auslesen wollte, wurden diese grün eingefärbt (was glaub Wiederholungen bedeutet) und kein Resultat angegeben. Danach ist in der ETS auch die MDT-Router-Schnittstelle auf rot gegangen. Bisschen später wieder auf verbunden, dann wieder weg. Also hier war das erste Mal, dass ich auch direkt in der ETS Probleme mit dem MDT-Router hatte.
Und selbst, als der MDT-Router wieder mal kurz verbunden war, konnte ich keine Info davon auslesen.
Hab dann den MDT-Router mal vom Bus getrennt, etwas gewartet und wieder an den Bus angehängt. Das hat ihn scheinbar wieder "beruhigt". D.h. ich hatte danach in der ETS wieder ein normales Verhalten. Im Gruppenmonitor keine grünen Einträge mehr, wieder normaler Traffic und Werte Auslesen und Applikationen schreiben funktionierte ebenfalls.
Da es schon spät wurde, bin ich dann ins Bett, wobei mir das Ganze schon etwas Sorgen bereitete. (Gerade, wenn wir dann mal in den Urlaub fahren und z.B. die automatische Beschattungssteuerung nicht mehr funktionieren würde, was in unserem Fall mit grossen Fenstern das Haus extrem aufheizt.)
Hab vom Bett noch bisschen auf dem iPad mit Edomi rumgespielt. Die Visu zeigte nur den Status von einigen Aktoren. Werte der KNX-Wetterstation wurden jedoch ständig aktualisiert. Als ich ein paar Befehle an die Schlafzimmer-Jalousie schickte, passierte nichts. Auch das Licht konnte ich nicht steuern, obwohl der Status korrekt angezeigt wurde. Später fiel mir dann auf, dass Edomi irgendwie meine Befehle extrem verzögert (ca. 15 Min.) absetzte. D.h. irgendwann bewegten sich dann die Jalousien doch.
(Mir ist noch in Erinnerung geblieben, dass ich mal in der Edomi Administration etwas von KNX-Queue und ein Wert 70 sah. Vielleicht war dies die Ursache für dieses Verhalten.)
Heute Morgen habe ich dann das Projekt nochmals aktiviert und zurzeit scheint wieder alles normal und stabil zu laufen.
Ich denke, das gestrige Problem mit der Verzögerung lag daran, dass ich Edomi nach dem MDT-Router Reset nicht mehr neu aktiviert habe. (Den Edomi-Server habe ich ja noch vor dem MDT-Router Reset neu gestartet.)
Für mich scheint das Problem schon eher am MDT-Router zu liegen. Ich habe/hatte ja eigentlich nur Probleme mit Dingen, welche über den MDT-Router gehen (Edomi und ETS), aber KNX selber (über Taster) schien völlig normal zu funktionieren.
Ob der Router evtl. vom Netzwerk "gestört" wird, kann ich im Moment noch nicht beurteilen, da sich das Netzwerk ansonsten normal verhält.
Ich befürchte, ich muss wohl meinen KNX-Router mal auswechseln (am besten durch ein anderer Hersteller, um dies auszuschliessen.)
Welchen KNX-Router würd ihr zurzeit mit Edomi empfehlen? Enertex?Zuletzt geändert von rdeckard; 27.05.2018, 10:25.
Einen Kommentar schreiben:
-
Korrekt - alles Handarbeit.
EDOMI unterstützt ausschließlich "normale" GA-Telegramme - alles andere ist nicht implementiert (und wird es auch nicht werden). Wenn also auf dem Bus "exotische" Dinge passieren, kann ich für nix garantieren.
Einen Kommentar schreiben:
-
Soviel ich weiß, hat gaert das selbst implementiert. Nix Bibliothek!Zitat von pitschr Beitrag anzeigenIch weiss nicht welche Bibliothek Edomi für die KNX Kommunikation nutzt.
Einen Kommentar schreiben:
-
Deine Fehler sind auf APCI = 0x0100 (A_IndividualAddress_Read-PDU) zurückzuführen, und da Raw nicht korrekt gelesen werden konnten wurde keine TUNNELING_ACK Pakete zurückgeschickt. Resultat: Router bekommt keine Rückmeldung von Edomi und schliesst deshalb die Verbindung.
Also das Verhalten ist gemäss KNX Spezifikation korrekt.
Ich weiss nicht welche Bibliothek Edomi für die KNX Kommunikation nutzt. Aber Calidomus unterstützt A_IndividualAddress_Read-PDU, somit soll der Fehler beim Calidomus nicht auftreten. So wie ich sehe ist dein Problem beim Edomi und nicht MDT.
Einen Kommentar schreiben:

Einen Kommentar schreiben: