Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
die unterschiedlichen Indexstände sind allein durch die Firmware begründet. Wenn Du Deinen I00 mit der V2.0 aktualisiert hast, bekommst du quasi I02.
Ich weiss aber nicht ob man direkt ohne den Umweg über V2.0 auf 3.3.8 updaten kann. Die V2.0 wird mit einem extra Tool aufgespielt danach kann man nur noch mit dem GPA weiter updaten.
Mir wurde (vor zwei Jahren) durch Gira auch zugesichert, das auch die alten Indexstände KNX Secure können werden. Man war sich aber noch nicht sicher wie das genau ablaufen soll, da der Schlüssel während des Updateprozess theoretisch abgegriffen werden kann. Sollte man keine Lösung finden mit der auch die KNX association leben kann, würde man das besagte Firmwareupdate notfalls im Werk vornehmen.
Wenn jemand hierzu inzwischen mehr weiß währe ich für weitere Infos dankbar.
p.s. 23.4. war wohl wegen mir (Änderung im Switch) - könnte von Zeitraum her passen, bin mir aber nicht 100% sicher. Die Kommunikation zw. Edomi und KNX Router laufen in einem separaten VLAN.
Von daher glaube ich nicht, dass das Problem bei Edomi Core bzw. MDT Router liegt sondern die Kommunikation durch ein Plugin oder durch äussere Einflüsse gestört wird. Ansonsten kann WireShark vielleicht weiterhelfen? Tipp: Evtl. könnt ihr Calimero (http://calimero-project.github.io) gleichzeitig laufen lassen um zu beobachten ob der Fehler auch da auftritt.
Hier mal ein Edomi-Log das entsteht wenn ich bei einem (beliebigen) Gerät die PA programmieren will und den Vorgang dann abbreche. Ich hatte solche Einträge im Error-Log auch schon beim Entladen eines Geräts.
ROUTER @ CE | DISCONNECT_REQUEST / Raw: 06100209001030000801c0a8020a0e57
ERROR
2018-05-23 19:18:04
775943
KNX
1562
KNX-Verbindung verloren.
Edomi ist über einen MDT IP Router angebunden. Vielleicht kann da ja mal jemand nachstellen? Wenn ja scheint es ja KNX-Telegramme zu geben die von Edomi nicht erkannt werden.
Beim "normalen" programmieren (= Applikation übertragen) passiert das nicht. Und das die Verbindung verloren geht wenn bestimmte Telegramme empfangen werden ist ja schon irgendwie unschön (auch wenn es sonst keine Auswirkungen zu haben scheint).
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.
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.
EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)
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?
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.)
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.
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).
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 ;-)
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar