OpenKNX IP-Router

[olemaan]

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.

[traxanos]

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.

[Ing-Dom]

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.

[thewhobox]

Da eh immer auf eine Antwort auf das FunctionPropertyInvoke gewartet wird, wird da auch nix geflutet.

Und wer einen Multicast Teilnehmer (also der eh schon auf IP ist) über Tunnel updatet ist auch selbst schuld ^^

[traxanos]

Fluten kamst du auch per ip ebene. Das kannst du nur mit einer Ratelimiz vermeiden. Normale Kommunikation bedarf ja einer Bestätigung wie Mike schon sagt, somit ist da das Risiko überschaubar

[Ing-Dom]

Da eh immer auf eine Antwort auf das FunctionPropertyInvoke gewartet wird, wird da auch nix geflutet.

das spielt ja keine Rolle, denn die Antwort kommt sehr schnell, da die über IP kommt.
Und das muss abgefangen werden wenn man die Optimierung wieder ausbaut.

Und wer einen Multicast Teilnehmer (also der eh schon auf IP ist) über Tunnel updatet ist auch selbst schuld ^^

konkret bin ich auf das Problem gestoßen da der KNXFileTransferClient so seine Probleme mit Multicast hat (hatte?)

Aber es geht nicht nur um FW-Update. Auch Applikation laden kann ja mitunter viele Daten übertragen.
Und sehr viele User nehmen immer Tunnel..

[thewhobox]

das spielt ja keine Rolle, denn die Antwort kommt sehr schnell, da die über IP kommt.

Dann geht es aber an das Gerät direkt. Hier finde ich eine Filterung auch Sinnvoll. Genauso das Filtern direkt zu anderen Tunneladressen.
Denn auf der TP Linie darf kein zweites Gerät mit der gleichen PA sein.

Weiter würde ich aber nicht filtern.
Sprich wenn über den Tunnel die 13.12.255 auf der Linie 2.3 angesprochen wird, sollte dieses Telegramm auf die Linie.
Topologisches Filtern sollte nur der Router, da hier wirklich eine Linie überquert werden soll.

KNXFileTransferClient so seine Probleme mit Multicast hat (hatte?)

schwierig zu sagen, da die Probleme immer nur bei anderen Auftreten und es bei mir funktioniert.
Aber gefühlt ist es besser geworden.

[sunshine000]

Zunächst einmal bin ich sehr dankbar für dieses Projekt.
Ich habe die Hardware selbst zusammengebaut, die Firmware gebrannt und sie läuft erfolgreich. Mit ETS gesendete Befehle reagieren normal, aber das Debug-Fenster zeigt den Fehler 0d 00:03:51: Allgemein: Warnung: Die Schleife hat länger als üblich gedauert (80 >= 50).
1. Ich kann beim Tunneln keine anderen KNX-Geräte programmieren und herunterladen. Unterstützt die Firmware diese Funktion?
2. Nachdem ich die Parameter gemäß Sisamiwe Neuer Benutzer konfiguriert habe, kann ich andere KNX-Geräte per Multicast programmieren und herunterladen.


0d 00:03:27: ================================================== ==============================
0d 00:03:27:
0d 00:03:27: Open # OpenKNX.de
0d 00:03:27: +----+
0d 00:03:27: # KNX wiki.openknx.de - forum.openknx.de
0d 00:03:27:
0d 00:03:27: ======================== Information ===========================================
0d 00:03:27: Device
0d 00:03:27: ID: REG1-Eth
0d 00:03:27: Name: OpenKNX REG1 LAN Gateway
0d 00:03:27: Serial number: 00FA:106D8B1C
0d 00:03:27: Firmware
0d 00:03:27: Name: IP-Router
0d 00:03:27: Version: 0.3.0
0d 00:03:27: Number: $A11F
0d 00:03:27: KNX-Type: Router (091A)
0d 00:03:27: CPU-Mode: Single-Core
0d 00:03:27: Programming
0d 00:03:27: Address: 15.4.0 (Configured)
0d 00:03:27: Version: 0.3
0d 00:03:27: Number: $A11F
0d 00:03:27: Runtime
0d 00:03:27: Free memory: 161.238 KiB (min. 161.176 KiB)
0d 00:03:27: Free stack size: Core0: 4760 bytes
0d 00:03:27: Watchdog: Running (16s)
0d 00:03:27: Hostname: OpenKNX-106D8B1C
0d 00:03:27: Network: Established (192.168.5.209)

[Ing-Dom]

1. Ich kann beim Tunneln keine anderen KNX-Geräte programmieren und herunterladen. Unterstützt die Firmware diese Funktion?

ja, dafür muss aber die Topologie stimmen.

das Debug-Fenster zeigt den Fehler 0d 00:03:51: Allgemein: Warnung: Die Schleife hat länger als üblich gedauert (80 >= 50).

das ist unkritisch, so lange das nicht im Sekundentakt auftritt

[sunshine000]

ja, dafür muss aber die Topologie stimmen.

Vielen Dank für Ihre Antwort.
1. Wie Sie bereits erwähnt haben, ermöglicht die Topologie normales Herunterladen und Debuggen. Welche Überlegungen liegen dieser Konfiguration zugrunde?
2. Gibt es derzeit eine Möglichkeit, KNX-Geräten, die nicht in der Topologie enthalten sind, das normale Herunterladen und Debuggen über einen Tunnel zu ermöglichen? Kann beispielsweise das ABB KNX IP-Routing-Gateway diese Funktionalität bereitstellen oder wird diese Funktion in einem zukünftigen Update hinzugefügt?

[thewhobox]

zeigt den Fehler 0d 00:03:51: Allgemein: Warnung:

Wie die Konsole zeigt, ist das nur eine Warnung und kein Fehler.

1. Ich verstehe die Frage nicht. Welche Konfiguration meinst du?
2. Du kannst die KNX-IP Pakete mit Wireshark aufzeichnen. Das hat aber nix mit dem IP Router selbst zu tun.

[sunshine000]

Wie die Konsole zeigt, ist das nur eine Warnung und kein Fehler.

1. Ich verstehe die Frage nicht. Welche Konfiguration meinst du?
2. Du kannst die KNX-IP Pakete mit Wireshark aufzeichnen. Das hat aber nix mit dem IP Router selbst zu tun.

Vielen Dank für Ihre Antwort.
1. Das Problem wurde behoben. Ich kann KNX-Geräte nun normal debuggen und herunterladen, nachdem ich sie auf dem KNX IP-Gateway konfiguriert habe.
2. Gibt es derzeit eine Möglichkeit, KNX-Geräte, die nicht in der Topologie enthalten sind, über einen Tunnel normal herunterzuladen und zu debuggen? Das ABB KNX IP-Routing-Gateway bietet diese Funktion beispielsweise. Wird diese Funktion in einem zukünftigen Update hinzugefügt?