OpenKNX IP-Router

[thewhobox]

Hat der Router eine korrekte Adresse und auch Applikation übertragen?

Gerne mal den Gruppenmonitor hier teilen. Dann kan man das besser nachvollziehen.

[Joeknx123]

Erster Test:
OpenKNX Router als Tunnel in OpenHab
Physikalische Adresse: 1.1.255 (in OpenHab eingestellt)
--> Es erscheint 1.1.255 als Quelle im Gruppenmonitor

Physikalische Adresse: 0.0.0 (in OpenHab eingestellt)
--> Es erscheint 15.15.1 als Quelle im Gruppenmonitor

Also auch nicht die echte Tunneladresse, die ja eigentlich 1.1.20-1.1.23 sein müsste.

Selber Test mit MDT IP-Interface:

Physikalische Adresse: 1.1.255 (in OpenHab eingestellt)
--> Es erscheint 1.1.255 als Quelle im Gruppenmonitor

Physikalische Adresse: 0.0.0 (in OpenHab eingestellt)
--> Es erscheint 1.1.4 als Quelle im Gruppenmonitor

Was eine echte Tunneladresse ist!

[Joeknx123]

Ich glaube ich muss das noch mal testen mit OpenHab. Vielleicht ist da auch irgendwas durcheinander gekommen beim ständigen Wechsel zwischen Tunnel und Router in OpenHab. Ich machen noch ein paar Screenshots und melde mich dann noch mal. Vielleicht sind die Fehler auch mit der neuen Version weg oder es lag an der falschen Adresse als ich den Router verwendet habe.

[thewhobox]

SearchRequestExtended

Daran Arbeite ich aktuell.
Das ist ja aber Teil von Core v2

Wir haben einfach nicht genügend Sockets um alles bedienen zu können.
UDP hat das gute, dass es nur ein Socket pro Port benötigt.
Bei TCP wird gleich für jede Verbindung ein Tunnel benötigt.

Vll gibt es mal eine Vesion wo auch nur eine TCP Verbindung unterstützt wird oder vll geht mit einem ESP32 auch mehr, aber aktuell gibt es wichtigere Baustellen.
Es gibt so vieles tolles, was ich noch gerne Einbauen würde^^

[traxanos]

Wenn du 4 Tunnel PAs hast. .201-.204 und dann vergibst einer deiner Anwendung die .201. Jetzt kommt eine Geräte ohne und bekommt eine .201. Nun verbindet sich dein Gerät mit der fest vergebene .201 und du hast eine Dublette.

Ich hab dann dammals angefangen meinen festen Geräten die .205.. zu geben und damit die Dubletten vermieden. Ich bin sogar noch einen Schritt weiter gegangen und habe mir ein Dummy mit .205 angelegt und konnte so GAs zuweisen (für die Filtertabelle auch wenn ich damals noch keinen Router hatte).

[mumpf]

Eigentlich musst du immer eine PA nutzen die nicht als TunnelPA genutzt wird.

Das verstehe ich nicht. Eigentlich sollte der Client exakt die Tunnel-PA bekommen. Der Tunnel repräsentiert ja auf der Linie das externe Gerät. Jegliche andere PA birgt die Gefahr der doppelten Vergabe.

Gruß, Waldemar

[traxanos]

Kurzer Test: ein Gira Router zB. macht das nicht. Du kannst den Tunnel 1.0.242 bekommen und wie du lustig bist Telegramme von zb. 14.5.22 senden - und die kommen auch so auf dem Bus an.

Also bekommst Du bei Tunneln mit 1.1.20-1.1.23 auch keine PA 1.1.70 zugewiesen, wenn Du diese verlangst.

Das wäre aber schlecht. Eigentlich musst du immer eine PA nutzen die nicht als TunnelPA genutzt wird. Wie willst du sonst sicherstellen, dass die PA nicht doppelt verwendet wird. Ein Client der 0.0.0 mitsendet bekommt im Zweifel genau die PA die du einem Gerät fest zugewiesen hast.

[mumpf]

Doch, wie oben schon beschrieben muss der Client dafür sorgen, dass die PA passt.
Wie das interface dann aber die Zuordnung für die Antworten managed: Keine Ahnung.

Danke für die Aufklärung. Ich hab jetzt verstanden, dass unser Verhalten nach Spec korrekt ist. Warum aber ein client, der einen Tunnel auf der 1.0-Linie bekommt, über diesen Tunnel als 12.1.7 reden darf, will nicht in meinen Kopf. Aber gut, dann ist das eben so. Wieder was gelernt...

Gruß, Waldemar

[meti]

Aber aktuell ist es nicht geplant Tunneling v2 im Openknx-IP-Router zu unterstützen.

Oh, schade. Darf ich fragen warum? TCP Verbindungen und SearchRequestExtended sind schon was nettes 😄

[thewhobox]

Ah, dass das in der v1 auch schon ging war mir nicht bekannt. Nur, dass es mega umständlich ist^^

Aber aktuell ist es nicht geplant Tunneling v2 im Openknx-IP-Router zu unterstützen.

Das Ändern der PA in openHub auf 0.0.0 oder eine sonstige frei PA würde das Problem bestimmt schnell lösen.

[meti]

Genau - die v2 ist ja abwärtskompatibel. KNXnet/IP Device Management um die IA einer aktiven Tunnelling Verbindung zu ändern war schon in der v1 drin (3/8/4 §3.2 IA assignment for KNXnet/IP Tunnelling connections) - aber halt super umständlich 🙃

Das Ersetzen von 0.0.0 passiert ja unabhängig von der Vergabe der Tunnel-IA (beim ConnectionResponse) individuell für jedes versendete CEMI-Frame.

[thewhobox]

erst ab Tunnelling v2

Ja, das Ändern der PA geht Grundsätzlich auch per Config Management Connection in der v2.
Das Ersetzen der 0.0.0, bzw nicht ersetzen, wenn was angegeben ist, war aber schon vorher in der Spek drin.

P.s.: Ja das ist dann "Extended Connection Request Information" ab v2 Tunneling.

[thewhobox]

Sonst passt das nicht, oder?

Ich habe dich schon richtig verstanden und auch oben schon beantwortet

Laut spek soll die PA vom Tunnel nur festgelegt werden, wenn diese 0.0.0 ist (sprich dann wird ihm eine zugewiesen)

Ergo wenn der Client dort schon eine PA angibt, soll diese eben nicht durch eine Tunnel PA ersetzt werden.
MDT allerdings unterstützt das nicht bei meinen Tests.
Hier muss aber der Client dafür sorgen, dass es a) eine korrekte PA ist und b) eine freie PA ist.

Sprich wenn man in das Feld 0.0.0 einträgt sollte dem Tunnel eine korrekte freie Tunnel PA zugewiesen werden.
(Gilt nicht für Routing!)

Auszug aus der Spek 3/8/4 2.2.2
image.png

1.1.20-1.1.23 auch keine PA 1.1.70 zugewiesen, wenn Du diese verlangst.

Doch, wie oben schon beschrieben muss der Client dafür sorgen, dass die PA passt.
Wie das interface dann aber die Zuordnung für die Antworten managed: Keine Ahnung.

Aber wie gesagt, dass müsste man mal mit Wireshark oder dem Bumonitor nachschauen.
Fakt ist aber, dass 1.1.0 definitiv und in jedem erdenklichen Fall die falsche PA ist

Gruß Mike

[meti]

Hi!

theoretisch gibt es noch die Option, dass der Tunnel Client auch eine PA beim Verbinden verlangt.
Laut spek soll die PA vom Tunnel nur festgelegt werden, wenn diese 0.0.0 ist (sprich dann wird ihm eine zugewiesen)

Das gibts, wenn ich mich korrekt erinnere, erst ab Tunnelling v2 - was openHAB (Calimero) an und für sich unterstützt. Bei v1 sollte die ConnectRequestInformation eine length von 4 haben, bei v2 - optional - wenn eine spezielle Tunneladresse angefordert wird eine length von 6 - die IA ist da einfach hinten dran gehängt.

Und ich frage mit, ob unser Router nicht bei einem Tunnel, der schreibend auf den Bus zugreift, immer die PA auf die Tunneladresse ändern müsste. Sonst passt das nicht, oder?

Kurzer Test: ein Gira Router zB. macht das nicht. Du kannst den Tunnel 1.0.242 bekommen und wie du lustig bist Telegramme von zb. 14.5.22 senden - und die kommen auch so auf dem Bus an.
Laut Spec soll die Adresse ersetzt werden, wenn 0.0.0 im CEMI als Source steht.

Ich habe das so verstanden, dass das ein alternativer Weg ist zu dem, was wir mit den Tunnelzuordnungen zu IP-Adressen bewirken möchten. Da kann der Client eine bestimmte Tunnel-PA anfordern und so idealerweise immer die gleiche bekommen.

... und muss dabei keine fixe IP haben.

[mumpf]

thewhobox, Ing-Dom: Danke für eure Antworten, aber ihr habt meinen eigentlichen Punkt noch nicht verstanden .

Der Gruppenmonitor-Mitschnitt im Beitrag #35 zeigt, dass OpenHab über einen Tunnel mit der PA 1.1.0 gesendet hat. Das darf meiner Meinung nicht sein, wenn die Topologie wie beim TE ist und die Tunnel 1.1.20-1.1.23 haben.

Ich habe daraus interpretiert, dass OpenHab einen Tunnel bekommt (welchen auch immer) und darüber Telegramme verschickt, die als Quelladresse 1.1.0 haben. Und ich frage mit, ob unser Router nicht bei einem Tunnel, der schreibend auf den Bus zugreift, immer die PA auf die Tunneladresse ändern müsste. Sonst passt das nicht, oder?

theoretisch gibt es noch die Option, dass der Tunnel Client auch eine PA beim Verbinden verlangt.

Das hatte hier auch mal Klaus Gütter erwähnt, soweit ich mich erinnere, muss die verlangte PA aber auch im Tunnel-Adressbereich liegen. Also bekommst Du bei Tunneln mit 1.1.20-1.1.23 auch keine PA 1.1.70 zugewiesen, wenn Du diese verlangst.
Ich habe das so verstanden, dass das ein alternativer Weg ist zu dem, was wir mit den Tunnelzuordnungen zu IP-Adressen bewirken möchten. Da kann der Client eine bestimmte Tunnel-PA anfordern und so idealerweise immer die gleiche bekommen.

Gruß, Waldemar