Hallo,
ich habe derzeit ein sehr ähnliches Problem. Setup:
- MDT IP-Router (Serie .03) auf TP-Hauptlinie 1.0 (PA 1.0.0) mit Tunnel-Adressen 15.0.1-15.0.5, davon haben die ETS eine und je ein IPS eine bekommen. Router steht auf „Durchzug“ (alles weiterleiten)
- Zwei TP-Linien (1.1 und 1.2) mit Linienkopplern auf die Hauptlinie
- IP-Hauptlinie 14.0 mit zwei Gira G1 (PA 14.0.1 und 14.0.2)
- Dummy-Objekt für die GAs der G1 in der Hauptlinie
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