Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
OpenHab wählt selbst einen Tunnel, warum man da trotzdem etwas einstellen kann, weiß ich auch nicht.
Das ging mir nicht aus dem Kopf. Ich glaube, das Feld ist missverständlich. Bei der Auswahl "Router" muss OpenHab eine PA bekommen, denn jedes Routing-Gerät hat seine eigene PA (1.1.0 darf es trotzdem nicht sein). Bei "Tunnel" sollte da eigentlich nichts stehen, denn OpenHab weiß ja auch nicht, welchen Tunnel es bekommt.
Ing-Dom, thewhobox: Müsste nicht der Router beim Tunnelling (schreibend auf TP) in die Telegramme immer die PA des Tunnels schreiben? Was anderes darf da doch gar nicht stehen, oder?
mumpf 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)
Bei tests hat eine vorgabe der PA aber nur zu einem Verbindungsabbruch geführt.
Man müsste mal iwie versuchen das aufzuzeichnen und schauen was openhub da verschickt.
Ich könnte mir eher vorstellen, dass diese PA für das Routing verwendet wird (auch wenn dann die Bezeichnung falsch wäre).
Da muss es dann aber eine PA aus einer Ebene höher sein (1.0.255 zum Beispiel).
Aber ja, selbst wenn man die Tunnel PA ausdrücklich vergibt *muss* es eine freie PA sein, die auch keinen Koppler darstellt (kein 1.1.0)
wenn man sich da mal eine Wiresharkaufzeichnung eines Tunnelaufbaubs von OpenHAB anschauen könnte, wäre das schon hilfreich...
Und ja: für Routing braucht das IP-Only Gerät eine PA, idealerweise aus einer IP-Linie. Die ETS nimmt hier idr 0.0.1
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.
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.
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!)
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
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.
Zuletzt geändert von thewhobox; 15.02.2024, 10:16.
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.
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...
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.
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.
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).
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^^
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
.
Kommentar