Hallo zusammen,
ich beobachte ein Verhalten, das ich mir nicht erklären kann, und hoffe auf Hinweise von euch.
Setup
- MDT SCN-IP000.03 IP-Interface (A7.1a)
- Tunnel "Kanal 1" → physikalische Adresse `1.1.2`: eine eigene Software (`knx-nats-bridge` auf xknx), die KNX-Telegramme mitliest und auf NATS publisht
- Tunnel "Kanal 3" → physikalische Adresse `1.1.4`: ETS Gruppen-Monitor
Problem
Wenn ich aus dem ETS-Tunnel (1.1.4) ein Telegramm auf bestimmte GAs sende, sieht der Bridge-Tunnel (1.1.2) das Telegramm **nicht** — bei anderen GAs **doch**. Beide Tunnel hängen am selben IP-Interface.
Test 1 — funktioniert nicht
ETS-Group-Monitor sendet auf `14/3/3` (DPT 5.010 Zählimpulse):
```
17:37:08 1.1.4 Tunnelling Kanal 3 → 14/3/3 $02 | 2
```
→ kein Eintrag im Bridge-Reader, keine Zeile im nachgelagerten Log.
Test 2 — funktioniert
ETS-Group-Monitor sendet auf `14/3/4` (DPT 1.005 Alarm):
```
17:52:46 1.1.4 Tunnelling Kanal 3 → 14/3/4 $01 | Alarm
```
→ Bridge sieht es ~600 ms später, Telegramm landet sauber im nachgelagerten Log.
Was identisch ist zwischen beiden GAs
- Selber Bus-Empfänger: `1.1.160 Basalte Core S4` mit einer "Dummy"-Applikation, einziges Group-Object pro GA
- Kommunikations-Flags am Group-Object identisch (K, L, S, Ü, A gesetzt)
- Linie/Topologie identisch (1.1)
- "Weiterleiten" am Linienkoppler explizit aktiviert (für die Test-GA) und Linienkoppler programmiert → keine Änderung
Was sich unterscheidet
- DPT (5.010 vs 1.005)
- Object-Länge (1 Byte vs 1 Bit)
Empirisches Muster
Über mehrere Tage hinweg: DPT-1.005-Alarm-GAs werden zwischen Tunneln zuverlässig forwarded, DPT-5.010-Counter/Zählimpuls-GAs nicht. Auch eigene Writes vom Bridge-Tunnel auf `15/4/*` (DPT 14.056 PV-Werte) sieht der Bridge-Tunnel selbst nicht zurück (= erwartet, anti-loop), aber andere Bus-Geräte / andere Tunnel-Clients sehen sie auch nicht.
Frage
Wie entscheidet das IP-Interface, ob es ein Telegramm zwischen zwei aktiven Tunneling-Verbindungen forwarded? Im Handbuch finde ich dazu nichts, und das Interface hat ja im Gegensatz zum IP-Router keine Filtertabelle. Hat das Verhalten mit dem DPT oder mit der Telegramm-Länge zu tun, oder gibt es eine interne "aktive GA-Liste" die nur befüllt wird wenn bestimmte Bus-Geräte ein passendes Group-Object haben?
Danke!
ich beobachte ein Verhalten, das ich mir nicht erklären kann, und hoffe auf Hinweise von euch.
Setup
- MDT SCN-IP000.03 IP-Interface (A7.1a)
- Tunnel "Kanal 1" → physikalische Adresse `1.1.2`: eine eigene Software (`knx-nats-bridge` auf xknx), die KNX-Telegramme mitliest und auf NATS publisht
- Tunnel "Kanal 3" → physikalische Adresse `1.1.4`: ETS Gruppen-Monitor
Problem
Wenn ich aus dem ETS-Tunnel (1.1.4) ein Telegramm auf bestimmte GAs sende, sieht der Bridge-Tunnel (1.1.2) das Telegramm **nicht** — bei anderen GAs **doch**. Beide Tunnel hängen am selben IP-Interface.
Test 1 — funktioniert nicht
ETS-Group-Monitor sendet auf `14/3/3` (DPT 5.010 Zählimpulse):
```
17:37:08 1.1.4 Tunnelling Kanal 3 → 14/3/3 $02 | 2
```
→ kein Eintrag im Bridge-Reader, keine Zeile im nachgelagerten Log.
Test 2 — funktioniert
ETS-Group-Monitor sendet auf `14/3/4` (DPT 1.005 Alarm):
```
17:52:46 1.1.4 Tunnelling Kanal 3 → 14/3/4 $01 | Alarm
```
→ Bridge sieht es ~600 ms später, Telegramm landet sauber im nachgelagerten Log.
Was identisch ist zwischen beiden GAs
- Selber Bus-Empfänger: `1.1.160 Basalte Core S4` mit einer "Dummy"-Applikation, einziges Group-Object pro GA
- Kommunikations-Flags am Group-Object identisch (K, L, S, Ü, A gesetzt)
- Linie/Topologie identisch (1.1)
- "Weiterleiten" am Linienkoppler explizit aktiviert (für die Test-GA) und Linienkoppler programmiert → keine Änderung
Was sich unterscheidet
- DPT (5.010 vs 1.005)
- Object-Länge (1 Byte vs 1 Bit)
Empirisches Muster
Über mehrere Tage hinweg: DPT-1.005-Alarm-GAs werden zwischen Tunneln zuverlässig forwarded, DPT-5.010-Counter/Zählimpuls-GAs nicht. Auch eigene Writes vom Bridge-Tunnel auf `15/4/*` (DPT 14.056 PV-Werte) sieht der Bridge-Tunnel selbst nicht zurück (= erwartet, anti-loop), aber andere Bus-Geräte / andere Tunnel-Clients sehen sie auch nicht.
Frage
Wie entscheidet das IP-Interface, ob es ein Telegramm zwischen zwei aktiven Tunneling-Verbindungen forwarded? Im Handbuch finde ich dazu nichts, und das Interface hat ja im Gegensatz zum IP-Router keine Filtertabelle. Hat das Verhalten mit dem DPT oder mit der Telegramm-Länge zu tun, oder gibt es eine interne "aktive GA-Liste" die nur befüllt wird wenn bestimmte Bus-Geräte ein passendes Group-Object haben?
Danke!
Kommentar