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.
Du weist ja garnicht ob da noch ein Koppler im Einsatz ist. Dann gehen die Telegramme auch nicht durch oder beachtest du die möglichen Sublinien?
Koppler können da ja nur hängen, wenn der IP-.Router als Bereichskoppler verwendet wird, also z.B. als 2.0.0.
Insofern würden hier nur Telegramme gedroppt die nicht 2.x.x sind.
Die Konsequenz ist, dass man dann die Tunnel drosseln muss, da man sonst die TP-Linie flutet und die Sendequeue überlastet..
D.h. kein schnelles Firmwareupdate eines Multicast-Teilnehmer über Tunnel.
Ich denke das Filtern ist keine gute Idee und macht glaube ich auch sonst keiner. Du weist ja garnicht ob da noch ein Koppler im Einsatz ist. Dann gehen die Telegramme auch nicht durch oder beachtest du die möglichen Sublinien? Im Tunnelmodus erwarte ich das alles durch geht. Für Tests hab ich auch gerne mal neben der 1.0 eine 2.0 auf der gleichen physikalischen Linie. Klar ist nichts was man produktiv macht, aber geht mit einem Interface normale problemlos.
eine sonderbehandlung nur für 15.15.255 halte ich nicht für sinnvoll. Das wäre nur die halbe Wahrheit denke ich.
Wenn ich das richtig verstehe ist die 15.15.255 ja ein Sonderfall auf dem KNX-Bus und eine Sonderbehandlung wäre in diesem Fall der richtige Weg.
Die Optimierung einstellbar also deaktivierbar zu machen, halte ich für die beste Option. Eventuell für beide Richtungen separat.
1: vermutlich das aufwändigste, aber auch das was das Problem am besten löst
2: wird vermutlich zu Folge Problemen führen, ist ja nicht ohne Grund drinnen
3: Sonderbehandlungen machen debugen echt nicht schön, Vorallen wenn man ein Jahr später nochmal drangeht
4: Ist eine Mischung aus 2&3
Würde daher für Lösungsansätze Nummer 1 Plädieren.
Ich habe mit Michael Sisamiwe sein Problem etwas analysiert.
Über Multicast mit LAN klappt nun alles, sofern bei pyhsikalisch adressierten Telegrammen "Weiterleiten" eingestellt ist.
Über WLAN gibt es nach wie vor Probleme, aber das liegt am Netzwerk. MC und WLAN ist immer so eine Sache.
Der Grund warum die PA 15.15.255 auf der TP-Linie nicht gefunden wird, wenn man in der ETS danach sucht und per Tunnel verbunden ist, ist eine Optimieung die im Zuge der letzten großen Überarbeitung des Tunneling (mit 16 statt 4 Tunnel) mit eingebaut habe.
Hintergrund ist der - der Tunnelserver im Router ist logisch dem sekundären INterface zuzuordnen, also der TP-Linie.
Daher bekommen die Tunnel auch PAs der TP-Linie.
Eigentlich ist es vorgesehen, dass auf den Tunneln und der TP-Linie exakt die gleichen Telegramme laufen.
Wenn nun aber ein Tunnel-Client (ETS oder Visu oder KNXFileTransferClient) große Datenmengen per Tunneling an den Router schicken und diese NICHT an einen Teilnehmer der TP-Linie adressiert sind sondern zB an einen KNX-IP Teilnehmer - dann flutet man die TP Linie mit Telegrammen, die da nichts verloren haben.
Weil die Kommunikation zum KNX-IP Teilnehmer sehr schnell ist, fallen großen Datenmengen an, die TP-Sendequeue läuft über.
Möglichkeit a)
man verlangsamt die Tunnel grundsätzlich auf "TP-Speed".
Möglichkeit b)
man sendet Teleramme, die offensichtlich nichts auf der TP-Lnie zu suchen haben, dahin auch gar nicht weiter.
Diesen Weg hab ich gewählt.
Welche Telegramme, die ich über einen Tunnel empfange, werden gedroppt:
- Unicast (also PA-Telegramme) mit Ziel Router selbst
- Unicast mit Ziel anderer Tunnel-Endpunkt
- Unicast mit Ziel außerhalb der eigenen Linie
und genau da liegt dann das Problem.
Sucht man nach 15.15.255 und befindet sich zB auf der Linie 1.1.0, dann wird das Telegramm gedroppt da es offensichtlich nicht auf diese Linie gehört.
Es gibt auch noch ein weiteres Problem. In die andere Richtung gibt es diese Optimierung auch. Unicast auf der TP-Linie wird nur an den Tunnel geschickt, wenn es auch für den Tunnel gedacht ist. Damit kann man aber über einen Tunnel nicht mehr so gut "beobachten"..
Jetzt gibts ein paar Möglichkeiten.
- Die Optimierung einstellbar machen
- Die Optimierung wieder ausbauen
- Sonderbehandlung für die 15.15.255
- Die Optimierung nur Richtung Tunnel wieder ausbauen
ich sehe keinen offensichtlichen Fehler in deinen Einstellungen. Genauso sag sah das bei meinem Test auch aus - das was ich gesagt hatte hab ich auch genau so getestet.. kann ich gerade nicht verstehen. Kannst du den TP separat aufzeichnen mit einer anderen Schnittstelle?
Stellst du "Phys. addresserte Telegramm" auf "Weiterleiten" statt "Filtern", wird es funktionieren. Damit wird die Linie aber auch ggf. mit völlig irrelevanten Traffic anderer Linien zugemüllt.
Bei mir klappt das nicht. Schau bitte nochmal drüber.
Mit dem OpenKNX-IP-Router wird die PA 15.15.255 nicht gefunden, egal mit welcher Schnittstelle (Multicast, Tunneling, Automatisch)
das ist mit den Default-Einstellungen plausibel.
Grund:
Der Router wird wahrscheinlich nicht die PA 15.15.0 haben, und somit verwirft er das Unicast-Telegram an die 15.15.255, denn es ist ja nicht für "seine" Linie (oder Bereich) bestimmt.
Das Prüfen ob ein Gerät erreichbar passiert per Device_Descriptor_Read etc.. (Unicast).
Stellst du "Phys. addresserte Telegramm" auf "Weiterleiten" statt "Filtern", wird es funktionieren. Damit wird die Linie aber auch ggf. mit völlig irrelevanten Traffic anderer Linien zugemüllt.
Versetzte ich das betroffene Geräte von Hand in den Programmiermodus, wird die PA in der Diagnose unter "Programmiermodus"
- bei "Direkt erreichbar" unter Verwendung der Schnittstellenadresse 0.0.1 (Multicast?) nicht gefunden
Das Verhalten kann ich NICHT reproduzieren. Sowohl die 15.15.255 als auch andere PAs werden erkannt und gelistet.
Auch das ist erklärbar: PA im Progmode werden per SystemBroadcast gesucht und beschrieben ("InAddrRead").. da ist das Routing egal.
Das macht ja auch Sinn, denn genau für diesen Anwendungsfall braucht man das ja so.
ich habe heute den OpenKNX IP-Router in Betrieb genommen. Es hat soweit alles geklappt.
An einem Punkt hänge ich und bräuchte dazu einen Tipp / Hinweis.
Folgendes ist mir aufgefallen:
Ich habe bei einem Sensormodul mit Hilfe des KnxTransferClient eine neue Firmware übertragen. Dabei wird auch (bei diesem Firmware-Update) die PA des Gerätes gelöscht bzw. auf Default zurückgesetzt.
Bislang (mit dem alten ABB Router) bin ich immer so vorgegangen, dass ich in der ETS die Diagnosefunktion "Überprüfung der PA" verwendet habe und nach 15.15.255 gesucht. Die PA wurde natürlich gefunden und so konnte ich über "LED Ein" den Programmiermodus am Gerät aktivieren.
Mit dem OpenKNX-IP-Router wird die PA 15.15.255 nicht gefunden, egal mit welcher Schnittstelle (Multicast, Tunneling, Automatisch)
Versetzte ich das betroffene Geräte von Hand in den Programmiermodus, wird die PA in der Diagnose unter "Programmiermodus"
- bei "Direkt erreichbar" unter Verwendung der Schnittstellenadresse 0.0.1 (Multicast?) nicht gefunden
- bei "Direkt erreichbar" unter Verwendung der Schnittstellenadresse 1.0.249 (Tunnel) gefunden
Ja, das hab ich Ing-Dom schon gemeldet. Ist aber eher ein Schönheitsfehler, denn warum sollte man ein TP-Gerät zum proggen eines IP-Gerätes verwenden ?
Nimm einfach den Router selbst zum proggen (am besten die Multicast-Schnittstelle), dann klappt das und ist auch noch viel schneller.
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.
?
Einen Kommentar schreiben: