knxd und GIRA KNX IP Router mit IP Backbone

[MarkusWarg]

Moin,

wir haben hier ein paar 2167 (GIRA IP Router mit eingebauten BK/LK), die über einen IP Backbone kommunizieren sollen. Die Programmierung und Betrieb der geplanten Anlage soll über knxd passieren. D.h. knxd soll für die ETS die Programmierschnittstelle abbilden. Weiterhin soll der knxd aber auch analog zu einem X1 oder Home/Facility Server Datagramme abbekommen (Statusmeldungen) und Steuerbefehle absetzen.

Dachte mir eigentlich, das wäre relativ simpel - in meinem jugendlichen Leichtsinn

Wir haben ein Debian 12 mit zwei Netzwerkinterfaces. Eines für die Front, das 2. für knx Multicast.

ETS kann sich mit knxd verbinden, soweit kein Problem. Die 2167 bekommen im Backendnetz auch eine IP. Auch ok soweit.
knxd loggt auch, wenn ich in der ETS über Diagnose z.B. einen Schaltaktor ansteuern möchte (wir haben einige Aktoren vorher ohne knxd mit einer direkten Kabelverbindung zwischen Notebook mit ETS und IP Routern konfiguriert).

Der "primäre" IP Router, den ich mit knxd ansprechen möchte, hat die 10.128.0.202, die IP auf dem Backendinterface vom knxd Host ist 10.128.0.201.

Wir sind uns bzgl. der physikalischen Adresse für den knxd nicht sicher. Von der Topologie her ist der knxd ja eigentlich parallel zu den IP Routern im IP Backbone angesiedelt? Die 1.0.100 war jetzt mal ein Versuch, den knxd in den ersten Bereich zu legen.

Kann man überhaupt einen Mischbetrieb fahren? Eigentlich soll ja knxd über Multicast mit dem KNX IP Backbone sprechen. Auf der anderen Seite muss ich, weil die ETS in einem anderen IP Netz liegt wie knxd, doch mit tunneling zwischen ETS und knxd arbeiten?

Ich möchte keinen gesonderten KNX IP Koppler oder ein KNX USB Interface in dem Projekt haben, das sollten nach meinem Verständnis die KNX IP Router erledigen können.

Ist der erste Versuch mit IP Topologie und knxd. Wir sind über jeden Hinweis dankbar.

Grüße,

Markus

Hier die knxd.ini:

[A.ipt]
debug = debug-A.ipt
driver = ipt
filters = single
ip-address = 10.128.0.202
retry-delay = 5

[debug-A.ipt]
trace-mask = 0x3fe

[debug-main]
error-level = 0x9
trace-mask = 0x3fe

[debug-server]
name = mcast:knxd

[main]
addr = 1.0.100
client-addrs = 1.0.101:8
connections = server,A.ipt
debug = debug-main
systemd = systemd

[server]
debug = debug-server
discover = true
router = router
server = ets_router
tunnel = tunnel
​

[Smurf]

Was ist deine Frage?

Grundsätzlich: Adressbereiche im KNX-Netz sind Artefakte. Den meisten Routern oder Schnittstellen muss man zwar beibringen, welche Lines wo zu finden sind, damit sie physisch adressierte Pakete da hinschicken, wo sie hin sollen, bzw. diese ignorieren wenn sie dafür nicht zuständig sind. (Dito bei Gruppenadressen.)

Aber: das ist eine Eigenschaft des Routers. Vom Protokoll her hat KNX 65534 Adressen – das sind derart wenige, dass sich der knxd einfach für jede separat merkt, hinter welcher Schnittstelle er sie das erste Mal gesehen hat. Fertig.

[MarkusWarg]

grafik.png
Konkrekt, wir kommen seitens ETS von "außen" über eth0 auf das Linux, auf diesem läuft der knxd. Der KNX IP Backbone hängt dediziert am eth3. Der Linux Rechner macht dort nur DHCP, ansonsten ist das Netz aber rein für die KNX Datagramme reserviert.
Ich möchte nun mit dem ETS auf den knxd verbinden können um Monitoring machen zu können UND das KNX Netz zu programmieren.
Ich möchte weiterhin, dass der knxd auf dem Linux über eth3 mit den IP Routern im KNX Netzwerk spricht. Wobei mir im Endeffekt egal ist, ob das über multicast direkt oder über einen IP Tunnel zwischen knxd und *einem* der KNX IP Router quasi indirekt passiert.

Vergessen wir für den Moment mal die konkrete knxd Config von oben. Ist das Setup, wie wir uns das so verstellen, "korrekt"? Oder wäre ein anderes Setup besser? Die Separation der Wirknetze möchten wir allerdings unbedingt beibehalten. U.a. weil wir eh schon ein potentielles Multicast Setup auf eth2 haben.