Ja. Wir unterstützen nur Geräte, welches das Tunneling Protokoll unterstützen. Das Routing Protokoll wird weiterhin nicht unterstützt und es ist bisher auch nicht geplant dies umzusetzen 
Laut MDT Doku kann der Router aber auch Tunneling. Somit sollte es mit dem Gerät trotzdem problemlos gehen.
paresy
Hallo,
ich habe derzeit ein sehr ähnliches Problem. Setup:
Testweise habe ich wie im MDT-Dokument hier https://www.mdt.de/download/MDT_LSG_IP_Router_Interface.pdf beschrieben die Router-Applikation auf Non-Secure umgestellt, da ich KNX Secure noch nicht verwende und Fehler von dieser Seite ausschließen wollte. Das unten beschriebene Verhalten hat sich dabei nicht geändert.
Die G1 bekommen alle Statusmeldungen aus den TP-Linien 1.0, 1.1 und 1.2 mit und können dort auch alles schalten. Auch direkte Statusmeldungen untereinander (Temperaturen) und testweise auch Schaltobjekte funktionieren. Aus dem Gruppenmonitor der ETS lassen sich mit der Tunneladresse 15.0.1 Statusmeldungen an die G1 senden, Schaltaktionen der G1 sind im Monitor sichtbar.
→ Die TP- und IP-Linien funktionieren, auch untereinander
IPS kann auf den TP-Linien alles lesen und schreiben, auch die TP-Geräte bekommen alles von IPS mit. Sende ich über IPS #1 einen Text via DPT-16-Instanz, dann kommt dieses Telegramm im Gruppenmonitor, im IPS #2 und in den TP-Linien an - allerdings nicht bei den G1.
Vergleiche ich das über den ETS-Gruppenmonitor versendete, erfolgreich überall zugestellte Telegramm mit dem IPS-Telegramm, dann fällt folgendes auf (s. Screenshots, links ETS, rechts IPS):
(Ich habe dabei die Verbindungen zum IP-Router vor dem Versenden des Telegramms so hergestellt, dass einmal die ETS und einmal IPS die Tunnel-Adresse 1.0.5 bekommen hat, nur um unterschiedliche PAs als Faktor auszuschließen)
KNX-Kontrollbyte ETS: BC - 1011 1100
KNX-Kontrollbyte IPS: AC - 1010 1100
Schaut man sich das auf der Ethernet-Leitung mit Wireshark und dem KNXnet/IP Dissector an erschließt sich für das Kontrollbyte folgendes:
ETS:
Ctrl1: Prio = Low
1... .... = Frame Type: Standard (1)
..1. .... = Repeat On Error: No (1)
...1 .... = Broadcast Type: Domain (1)
.... 11.. = Priority: Low (3)
.... ..0. = Ack Wanted: No (0)
.... ...0 = Confirmation Error: No (0)
Ctrl2: Hops = 6
IPS:
Ctrl1: System Broadcast, Prio = Low
1... .... = Frame Type: Standard (1)
..1. .... = Repeat On Error: No (1)
...0 .... = Broadcast Type: System (0)
.... 11.. = Priority: Low (3)
.... ..0. = Ack Wanted: No (0)
.... ...0 = Confirmation Error: No (0)
Ctrl2: Hops = 6
Der Router blockt also die IPS-Telegramme, da sie nur in der selben Hauptlinie (System Broadcast) verteilt werden dürfen, nicht auf weitere Hauptlinien (Domain Broadcast). Damit sind Telegramme aus IPS nicht über Bereichskopplergrenzen hinweg routbar.
Das ist ärgerlich, da man unter einer TP-Linie keine IP-Linie anlegen darf, und daher der KNX/IP-Router als Bereichskoppler konfiguriert werden muss falls man seine Hauptline als TP konfiguriert (was durchaus sinnvoll ist) und KNX/IP-Geräte über das IP-Backbone angeschlossen hat. Somit sind diese KNX/IP-Geräte für/von IPS derzeit nicht erreichbar.
Ich sehe das als Bug in IPS, hier sollte es die Möglichkeit geben festzulegen, wie die KNX-Telegramme aus IPS gehandhabt werden sollen - als System- oder als Domain-Broadcast.
@paresy wie siehst Du das?
Ciao
Andreas
Hallo,
folgendes Update: Ich habe ein Proxy-Modul geschrieben, welches zwischen KNX-Gateway und UDP-Socket gehängt wird (die Proxy-Modul-Instanz mit dem KNX-UDP-Socket verbinden, dann das KNX-Gateway mit der Proxy-Modul-Instanz verbinden). Es injiziert das Domain Broadcast Flag falls nicht vorhanden.
→ Dann funktioniert alles so wie es soll: Die G1 bekommen die aus IPS gesendeten Telegramme vom MDT-Router ins KNX/IP geroutet.
Hier der Link zum Modul: GitHub - skyslasher/KNX-Domain-Broadcast-Flag-Injector
@dolocyl Kannst Du bitte testen, ob Dein Szenario mit diesem Proxy-Modul und dem MDT-Router so funktioniert wie Du es ursprünglich aufgesetzt hast?
Ciao
Andreas
Hi Andreas,
ich hatte leider noch keine Zeit mir das genauer anzusehen. Es sieht auf jeden Fall nach einem Bug oder eher Missing Feature für deine Buskonstellation aus. Wann wir dort eine Änderung einbauen, kann ich dir aber nicht genau sagen. Deine Aufbereitung ist aber Klasse und der Aufwand sollte überschaubar sein!
paresy
Hi Paresy,
Danke für die Antwort! Da IP-Linien eigentlich immer auf Domain-Level mit den TP-Linien verknüpft sind sehe ich meine Buskonstellation als nichts außergewöhnliches bzw. als normal an. Wahrscheinlich ist es bislang einfach nicht aufgefallen, da KNX/IP-Geräte noch nicht besonders verbreitet waren.
Ciao
Andreas
P.S.: Mein Proxy-Modul überlebt keinen IPS-Neustart, und ich habe keine Ahnung warum - selbst wenn ich sämtliches Coding in den Methoden auskommentiere. Es muss also irgendwie mit der Verbindung zum EIB-Gateway zusammenhängen. Wenn das Modul über Neustarts hinweg funktionieren würde kann die „offizielle“ Implementierung sich etwas Zeit lassen, da es ja einen akzeptablen Workaround gibt.
Das Log sagt:
10.02.2021 20:36:33 | 32437 | MESSAGE | KNX Domain Broadcast Flag Injector | Erstelle...
10.02.2021 20:36:33 | 00000 | DEBUG | ScriptEngine | Skriptausführung (Text) - Länge: 182 ~ Absender: RunScript
10.02.2021 20:36:33 | 00000 | DEBUG | ScriptEngine | Skriptausführung (Text) - Länge: 0 ~ Absender: RunScript ~ Dauer: 7 ms
10.02.2021 20:36:33 | 00000 | DEBUG | ScriptEngine | Skriptausführung (Text) - Länge: 188 ~ Absender: RunScript
10.02.2021 20:36:33 | 00000 | DEBUG | ScriptEngine | Skriptausführung (Text) - Länge: 0 ~ Absender: RunScript ~ Dauer: 6 ms
10.02.2021 20:36:33 | 36188 | MESSAGE | EIB Gateway | Erstelle...
10.02.2021 20:36:33 | 32437 | DEBUG | InstanceManager | Referenzzähler >1 (=2) für Instanz #32437
10.02.2021 20:36:33 | 26056 | MESSAGE | UDP Socket | Erstelle...
10.02.2021 20:36:33 | 32437 | MESSAGE | KNX Domain Broadcast Flag Injector | Entferne...Frage: Gäbe es Nebenwirkungen wenn wir immer auf Domain Ebene senden? Also das von dir vorgeschlagene Bit immer setzen?
paresy
Das wäre mir nicht bekannt. Die Filtertabellen der Router/Koppler haben ja bereits die Aufgabe Flooding zu vermeiden/unterdrücken. Das Flag soll eigentlich nur unwichtige/sensible Nachrichten (nach Definition des emittierenden Gerätes) definitiv im System-Gehege lassen. IPS hat allerdings keine gerätedefinierte Stellung, ob Nachrichten systemübergreifend sein sollen/dürfen, das liegt ja rein in der Hand des Anwenders.
Ich habe dieses eine Bit mal zur 5.6 eingebaut - dann haben wir genug Zeit um in der Beta-Phase ggf. Probleme zu identifizieren.
paresy
PS: Coole Arbeit mit deinem Filter Modul
Moin,
ich würde das Problem hier gerne mal nachstellen.
Ich habe ebenfalls die Topologie der Hauptlinie mit dem MDT Router (1.0.0) und zwei TP-Linien 1.1 und 1.2 mit Linienkoppler
Heißt, wenn ich einen weiteren IP-Router in die 2.0.0 hänge, kommen die Telegramme von IPS aus 1.0.x nicht in 2.0.x an? Habe ich das richtig verstanden?
Korrekt. Wenn die IP-Router 1.0.0 und 2.0.0 miteinander kommunizieren können und testweise auch auf „Alles weiterleiten“ gestellt sind (um versehentliches Filtern auszuschließen) sollten keine IPS-Telegramme, die über eine Tunnel-Adresse 1.0.x (dafür im EIB-Gateway nachschauen) gesendet werden in 2.x-Linien ankommen, ETS-Telegramme über eine Tunnel-Adresse 1.0.x jedoch schon.
Edit hierzu: Ich hatte während ich den Beitrag schrieb die Tunnel-Adressen von 15.0.1-15.0.5 auf 1.0.5-1.0.8 umgestellt, daher sind oben im Text die 15er-Adressen und ab den Screenshots die 1er-Adressen beschrieben. Ich habe aber sämtliche Schritte auch komplett mit den 1er-Adressen durchgeführt.
Ich bin heute nochmal exzessiv durch den ETS-Busmonitor geturnt. Ich habe (außer von IPS) keine Telegramme gefunden, bei denen das Domain Broadcast Flag nicht gesetzt war. Ich habe auch quer Beet testweise GAs an ein G1 konfiguriert - alles von TP wurde in die IP-Linie geroutet.
So, wie ich es erwartet habe, kommen meine Telegramme alle ordentlich an. Hätte mich auch gewundert, wenn IPS hier fehlerhaft wäre, denn mir fällt spontan eine Kundenanlage ein, wo dies definitiv funktioniert.
Mein Testaufbau:
Mit einer USB Schnittstelle auf auf die 2.0.x Linie gehängt - Telegramme von IPS sehe ich dort. So wie erwartet. Funktioniert also alles, wie es soll. Keine Änderung erforderlich.
Ich hatte Kontakt zu einem KNX Entwickler. Dieser sagte, dass das Flag, um das es hier geht, von IP-Routern hinsichtlich des Routings ignoriert werden sollte.
Soll ich weitere Tests durchführen?
Ich war jetzt neugierig:
Nix von dem Bit zu sehen, von dem Du sprichst. Verhält sich genau so, wie die ETS, wenn ich das richtig verstanden habe?
Edit:
Noch ein Edit:
Dieser hier ist direkt mit dem IP-Router 1.0.0 aufgenommen:
Wenn ich alles richtig verstanden habe, kann ich Dein Problem nicht nachstellen.
@DerStandart Was für eine IP Gateway nutzt du? Fakt ist, dass wir das Broadcast Type Bit für Domain nicht setzen. Es kann also sein, dass einige Gateways dieses Bit einfach erzwingen - was erklären würde, warum kaum Leute ein Problem damit haben.
paresy
Ihr setzt es in 5.5. nicht, aber in 5.6 ist es eingebaut?
Ich nutze den MDT SCN-IP100.02 IP Router. Ich teste gleich mal mit einem anderen.
Korrekt. Und die 5.6 mit diesem Fix gibt es nirgends außer bei mir auf dem Rechner
paresy
Test mit ABB IPR/S 2.1 gleiches Verhalten. Alles völlig ohne Probleme.
Habe meine Tests erweitert. Habe also weiter die IP-Router 1.0.0 (Hauptlinie) und 2.0.0 (Testlinie). Habe zusätzlich in der 2.0.x eine USB Schnittstelle hängen und auch in der 1.1.x eine USB Schnittstelle hängen. Mein letzter Test war, IP-Symcon in die 2.0.0 zu hängen und von dort Telegramme zu schicken. Die sind korrekt in der 1.1.x angekommen. Routingzähler 4. Passt alles.
Ich muss allerdings dazu sagen, dass ich die Linienkoppler und IP-Router nicht auf „Durchzug“ gestellt habe, sondern mit Filtertabellen arbeite. Das dürfte aber keine Auswirkungen haben.
Ich verstehe es richtig, dass deine Screenshots die Telegramme von IPS zeigen (drittes Byte BC)?