Schwierigkeiten bei der Inbetriebname OpenKNX IP-Router auf REG1-LAN-TP-Base

[kewin]

Hallo,

ich habe nun nach Bewältigung einiger Hürden (USB Treiber, Toolbox etc.) den IP-Router Version 0.6.1 auf neuester Hardware in Betrieb nehmen können. Alles inkl. Programmierung, Netzwerkverbindung etc. war letztendlich erfolgreich.

Nun möchte ich den Router per IP-Tunneling als ETS Schnittstelle einsetzen. Allerdings sind mein ETS PC und der Router in verschiedenen VLANs und daher ist kein Multicast möglich. Ich habe deshalb in der ETS den NAT-Modus gewählt.

Folgendes funktioniert, wenn ich den IP-Router per NAT in der ETS als Projektschnittstelle auswähle:

• In der Schnittstelleneinrichtung wird die Gruppenadresse vom Tunnel richtig erkannt
• In der Schnittstelleneinrichtung gibt die Testfunktion ein "OK" an
• Geräte programmieren läuft - auch den IP Router selbst
• Linienscan funktioniert
• Der Gruppenmonitor funktioniert

Was nicht funktioniert:

• Der Busmonitor läuft nicht. Er findet die Schnittstelle nicht:
  grafik.png
• Das MDT Update Tool funktioniert auch nicht. Es meldet: "Festgestellte maximale Telegrammlänge der Schnittstelle von 0 ist nicht ausreichend für das Update eines Gerätes!"

Ich habe auch einen EIBPort im selben VLAN wie den IP-Router. Wenn ich den als Schnittstelle ebenfalls im NAT-Modus verwende funktioniert alles.

Meine Frage: Gib es noch bekannte Einschränkungen als ETS Schnittstelle im NAT-Modus? Hat jemand eine Idee, wo ich suchen muss?

[thewhobox]

Die Fehlermeldung zum Busmonitor ist doch recht eindeutig?
Der Router unterstützt kein Busmonitor.
Kann er auch gar nicht, da er dann seine Routing Fähigkeit verlieren würde.

Zum Fehler mit dem Update Tool von MDT müsste man mal mit Wireshark schauen, was das abfragt.

Ansonsten gibt es keine Einschränkungen im NAT Modus.

[kewin]

Okay, danke. Ich wollte den IP Router eigentlich nur als IP Interface einsetzen, weil mein EIBPort keinen Long-Frame Support bietet. Der EIBPort kann auch Routing und Tunneling, aber zumindest wenn Routing nicht aktiviert ist funktionieren die Tunnel auch für den Busmonitor.

Dann wäre es interessant entweder eine reine "IP Interface" App zu haben oder das Routing abschalten zu können.

Was mir auch aufgefallen ist: Wenn ich NTP aktiviere erscheinen keine Kommunikationsobjekte in der ETS um Datum und/oder Uhrzeit zu lesen.

[traxanos]

Ein Router kann keine Daten senden. Der Router kann nur Routen. Der ntp ist nur für den Router selber.

[kewin]

Danke. Alles klar. Da hat mich der Hilfetext verwirrt. Busmonitor ist auch nicht wirklich ein Problem, wenn sonst alles möglich ist. Falls ich den wirklich mal bräuchte habe ich noch den EIBPort als alternative Schnittstelle.

Dann bleibt nur die Frage, warum das MDT Update Tool nicht funktioniert. Aber da könnte auch im MDT Tool ein Fehler sein. Beim EIBPort berechnet es die Telegrammgrösse auch falsch (12 Byte statt 15 Byte) und verweigert ein Update. Das war der Hauptgrund für den IP Router als neues Interface. Mal die nächste Version von MDT abwarten.

[mumpf]

Du könntest ja das machen, was Mike vorschlägt

Zum Fehler mit dem Update Tool von MDT müsste man mal mit Wireshark schauen, was das abfragt.

und ihm die Aufzeichnung schicken. In den meisten Fällen sieht man dann das Problem.

Gruß, Waldemar

[thewhobox]

12 Byte statt 15 muss nicht falsch sein.
Die werden das vermutlich auch über FunctionProperties gelöst haben. Da hat man nun mal 3 Bytes, die man nicht für Daten selbst verwenden kann.

Hab es aber noch nie selbst verwendet und auch keine mdt Geräte zum testen da.
Du müsstest das also selbst mal aufzeichnen.

[Ing-Dom]

da immer wieder die gleichen Fragen zur Router Applikation kommen, hab ich die Infos mal in Form einer FAQ in der Funktoinsbeschreibung der OpenKNX IP-Router Applikation hinterlegt

[kewin]

Sehr hilfreich. Dann wäre aber meine Anregung für die selbe Hardware eine IP Interface App zu haben sinnvoll:

• Kein Routing
• Tunneling
• TCP Support
• NTP mit Kommunikationsobjekten
• Busmonitor
• Im Idealfall auch mal KNX Secure
• Eventuell noch weitere Funktionen aus anderen Apps integriert

Für mich ist der Router auch so als Ergänzung zum EIBPort nutzbar für Long Frame Support. Ich muss mir nur noch das MDT Thema ansehen. Braucht noch etwas Zeit.

[traxanos]

Wichtig: KO und Busmonitor schließen sich aus. Sobald der verwendete TP Ankoppler im Busmonitor-Modus ist, kann dieser keine Telegramme mehr senden. Ich würde daher den Busmonitor komplett gedanklich trennen. Übrigens kannst du per Geräte-Konsole ein OpenKNX Gerät in den Busmonitormodus versetzen (mit allen Nachteilen). Wenn du also nur mal temporär was prüfen möchtest, reicht das. Damit verteste ich hier zuhause alles mögliche.

[kewin]

Beim EIBPort geht Busmonitor parallel zu allem anderen. Laut Anleitung sogar Routing. Hab ich aber nie probiert.
Ist auch etwas speziell: Es gibt nur eine Dummy-Applikation mit Kommunikationsobjekten, hauptsächlich damit Filtertabellen in Kopplern stimmen und zur Dokumentation. Die eigentliche Kommunikation braucht keine Konfiguration in der ETS. Wird im Gerät über Webinterface und ETS Projektimport konfiguriert. Aber irgendwie schafft der das mit dem Busmonitor. Hab mich selbst nie im Detail damit beschäftigt, wie der Busmonitor technisch arbeitet.

Ist wohl eine Beschränkung vom verwendeten TP Ankoppler. Wie gesagt, für mich kein grosses Problem.

[Ing-Dom]

Dann wäre aber meine Anregung für die selbe Hardware eine IP Interface App zu haben sinnvoll:

• Kein Routing
• Tunneling
• TCP Support
• NTP mit Kommunikationsobjekten
• Busmonitor
• Im Idealfall auch mal KNX Secure
• Eventuell noch weitere Funktionen aus anderen Apps integriert

klar wäre das sinnvoll oder wünschenswert.
Wann fängst du mit der Implementierung an ?

[gbglace]

Beim EIBPort geht Busmonitor parallel zu allem anderen.

Das zeigt erstmal nur das der EIBPort als KNX-HW eher ein reines KNX-Interface ist und hinten dran dann auf der IP Seite einfach nur eine bunte Software wie man sie mit HA usw. kennt.
Für den Busankoppler hat es damit alle Möglichkeiten auch den Busmonitor anzubieten.

Routing anzubieten ist dann eher Pseudorouting wie es früher via knxd auch schonmal gemacht wurde und im wiregate implementiert war.
Technisch möglich aber entlang der Strukturierung in der ETS hochgradig intransparent.

Die eigentliche Kommunikation braucht keine Konfiguration in der ETS.

Was die Sache halt beweist.
Ob man das als Vorteil verstehen mag bin ich mir immer unschlüssig. Klar ist es für die Serverhersteller einfacher nur das ETS Projekt zu laden und dann dem User die interne Erstellung von Datenpunkten/Objekten/Entitäten abzunehmen aber transparent für den KNX-Bus selbst ist das alles absolut nicht.

Ist wohl eine Beschränkung vom verwndeten TP Ankoppler.

Absolut nein.
Ein Busankoppler darf das nur so wie es beim openKNX-Router und beim EIB-port implementiert ist.

Der EIB-Port ist halt mit allem was er als Logik/Visu-Server tut kein KNX-Gerät, sondern einfach nur eine SW die KNX spricht und das rein auf der IP Seite. Dort einfach dem Datenstrom abhört und hier und da selbst was rein kippt. nichts anderes machen HA / NR / OH / und auch alle KNX-HW Server die selbst keine KO für Ihre Datenpunkte vorhalten also auch ein Gira HS oder X1 letzter zumindest in Teilen.

Ausnahme ist der TWS, der hat für das wo er als Server und Visu usw. mit dem KNX interagiert explizite KO in der ETS Applikation.

[traxanos]

Beim EIBPort geht Busmonitor parallel zu allem anderen.

da stellt sich aber noch die frage ob man das gleiche unter dem busmonitor versteht. ein echter busmonitor ist ein anderer betriebsmodus. in diesem modus bekommst du sowas wie ein ACK mit. ich kenne den EIBPort nicht, aber ggf. gibt es auch nur die empfangen telegramme aus (was auch indirekt eine art busmonitor ist, aber nicht das gleiche).

[kewin]

Danke für die Erklärungen. Da hab ich etwas gelernt. Lässt sich offensichtlich nicht vergleichen.

(Bezüglich Busmonitor meinte ich, dass der ETS Busmonitor mit dem EIBPort als Schnittstelle funktioniert, nicht einen eigenen Busmonitor.)