OpenKNX IP-Router

[Ing-Dom]

Es gibt 2 neue Releases, die inhatlich identisch sind:

V0.3.0 als Nachfolger der V0.1.3 - das ist die "Release" Applikation.
- 16 Tunnel, reservierbar
- unterstützt REG1-LAN-TP-Base (ESP32)
- viele kleinere Bugfixes und Verbesserungen

Für die Nutzer der "Beta" Applikation gibt es die V5.2.0-BetaBase
Achtung: Bei Update einer V5.x.x bitte beachten: Beitrag 213
wie erwähnt, inhaltlich gleich zur V0.3.0.

Ein Wechsel/Update zwischen Beta und Release ist nicht möglich, außer durch ein komplett Neues programmieren des Gerätes, Laden der knxprod.
Konservative, auf Stabilität wert legende Nutzer wählen Release.
Experimtierfreudige Nutzer, die das Neuste haben wollen aber dafür auch mal mit Bugs zurechtkommen können die Beta wählen.

Hinweis zur Hardware:
aktuell ist nur das REG1-Eth (RP2040 basiert) lieferbar, REG1-LAN-TP-Base (ESP32) ist noch im Test.
Für den Einsatz als IP-Router ist aber der REG1-Eth genauso gut geeignet.

[olemaan]

Habe das Update auf V5.2.0 per KNX-Upload durchgeführt. Das Firmewareupdate hat soweit geklappt.
Die knxprod habe ich importiert und das Programmieren der physikalischen Adresse funktionierte auch problemlos.

Ich kann jedoch nicht die Applikation programmieren. Fehlermeldung entweder Verbindungsqualität ist zu schlecht oder "Connection closed after too many TL errors to 1.1.0"

Während des Programmierversuchs blinkt erst die KNX-LED, dann geht diese und die IP-LED aus und die Func- sowie die Prog-LED leuchten kurz auf. Sieht aus, als ob der Router neu startet.

Ich kann per ETS über den Router problemlos auf alle anderen Geräte auf dem Bus zugreifen und diese auch programmieren.
Wegen der Meldung, dass die Verbindungsqualität schlecht sei, habe ich auch die Kabel getauscht, was allerdings keine Veränderung gebracht hat.
Habe dann auch nochmal die Firmeware per USB aufgespielt, auch danach war das gleiche Verhalten zu beobachten.
Der Router bekommt vom DHCP-Server seine IP und lässt sich auch anpingen.

Wie sollte man denn beim Update der Applikation in der ETS vorgehen? Ich habe das alte Gerät gelöscht und dann den Router neu hinzugefügt.

Grüße
Ole

[Ing-Dom]

Ach Mist, das hatte ich ganz vergessen. Sorry. Ist nur bei der Beta nötig!

Bei einem Update einer V5.x.x Firmware muss der ETS /knx Speicher der Geräte gelöscht werden.

Das erfolgt am einfachsten über das Drücken der Prog-Taste beim Power-UP oder über die Konsole

[olemaan]

Jupp, das war's. Problem behoben.😊
Danke!

[c4orbi]

Servus,

ich hab heut meinen IP Router versucht in Betrieb zu nehmen.
Dazu hab ich die FW 0.3.0 geflashed und die erzeugte knxprod in die ETS importiert.

Beim Vergeben der phy. Adresse bekomme ich folgende Fehlermeldung:
image.png

Ich verwende einen Testaufbau mit Enertex 1280 SV und BEG USB-C KNX Schnittstelle.

Die Topologie sieht folgendermaßen aus:
image.png

[mumpf]

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.

Gruß, Waldemar

[c4orbi]

Ok, dann muss ich den erstmal ins IP Netzwerk bringen.

[Sisamiwe]

Hallo,

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

Liegt das ein einer Einstellung?

Kann jemand einen Tipp geben?
Danke Euch.

[Ing-Dom]

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.

Screenshot 2025-08-10 211116.png

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.

[Sisamiwe]

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.

Meine Einstellungen im Router:
image.png
image.png

Überprüfung der physikalischen Adresse:
image.png

ETS Bus-Aktivität:
image.pngund beim "Gerät im Programmiermodus":

mit Schnittstelle automatisch kein Erfolg
image.png
Mit Schnittstelle "Tunneling": erfolgreich
image.png

[Ing-Dom]

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?

[Ing-Dom]

Ich verwende einen Testaufbau mit Enertex 1280 SV und BEG USB-C KNX Schnittstelle.

Die Topologie sieht folgendermaßen aus:

Der Bug ist gefunden und lokal schon gefixt.

Es folgt bald eine 5.2.1-Beta - für den Release-Pfad muss ich mal sehen..

[Ing-Dom]

sorry dass es länger gedauert hat, aber da war noch ein Bug mit einem falsch gesetzten repeat flag.

https://github.com/OpenKNX/OAM-IP-Ro...tag/5.2.2-Beta

[Ing-Dom]

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

Meinungen?

[Molybdean]

Mein Senf dazu

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.