[1.6.0 RC8] Nutzung und Umgang mit physikalischen Adressen
Verfasst: Do Dez 31, 2020 2:45 pm
Hallo zusammen,
wir hatten ja gerade erst diesen Thread von Tom. Da ging es zwar auch um die PAs, aber nachdem ich im Test mit der 0.12.0-dev der CometVisu unterwegs bin, habe ich da aktuell in den mir zur Verfügung stehenden Diagnosetools wieder Effekte, die ich mir nicht zu erklären weiß.
Wie hatte Tom so schön geschrieben:
Nun hatte ich die CometVisu 0.12.0-dev mal streng nach Anleitung installiert. Das führt defaultmäßig dazu, dass eine ENV-Variable "KNX_PA" mit dem Inhalt "1.1.238" vergeben wird. Das pass gundsätzlich zum meinem Linienaufbau und die PA ist auch frei. Damit taucht die im Aufruf des knxd dann auch als "-e 1.1.238" auf.
Wenn ich jetzt aber über die Oberfläche der "0.12.0-dev"-CV einen Schaltbefehl auf einen meiner Aktoren sende, sehe ich sowohl im Busmonitor des Wolfes, als auch in der Diagnose der ETS als Quell-PA des Telegramms die "1.1.5". Das ist jetzt aber etwas, was ich überhaupt nicht erwartet hätte. Die 1.1.5 ist schließlich die Zusatz-PA, die laut Interface-Seite dem Container mit der IP 172.17.0.6 zugeordnet wurde. In dem Teil läuft aber doch die CV 0.11.2. Aus der habe ich den Schaltimpuls aber nicht gegeben. Das Verhalten ändert sich übrigens nicht, wenn ich in der ENV-Variablen die "0.0.0" eintrage. Auch den Cache habe ich in meinem Firefox schon gelöscht.
Wenn ich aus dem Wiregate-Container etwas sende, dann taucht das im Monitor mit dem Ursprung "1.1.4" auf. Da ist meine Welt ja noch irgendwie in Ordnung...
Aber das Bild oben verwirrt mich aktuell doch massiv.
Mal völlig losgelöst von dem gestrigen Test einer CV-Version die im Unterbau einen knxd in der Version 0.14 nutzt. Da scheint sich was in der API beim Umgang mit den Tunneln und den Adressen geändert zu haben. Da steht im Wiki zum knxd in der "adress-section" so schön "Starting with version 0.11, this address is not used for tunnelling clients, see [multicast-server-section].". Da war dann gestern im Container am knxd neben dem gesetzten "-e" auch der "-E" zu sehen. Wobei der "-E" sich wiederum laut Doku auf Client-Adressen bezieht. Was ist denn da dann wieder zu berücksichtigen? Ich blicks langsam echt nicht mehr....
Aber wie immer, die Hoffnung stirbt ja bekanntlich zuletzt.
Ich wünsche euch allen aber mal schon einen guten Rutsch! Auf das 2021 schönere Überraschungen für uns parat hat als 2020!
Beste Grüße
Jens
wir hatten ja gerade erst diesen Thread von Tom. Da ging es zwar auch um die PAs, aber nachdem ich im Test mit der 0.12.0-dev der CometVisu unterwegs bin, habe ich da aktuell in den mir zur Verfügung stehenden Diagnosetools wieder Effekte, die ich mir nicht zu erklären weiß.
Wie hatte Tom so schön geschrieben:
Mal zur Konfig bei mir:
- TSW2600 mit der Basis-PA 1.1.222 und den Zusatz-PAs beginnend bei 1.1.4 dann durchgängängig bis hoch zu 1.1.28
- Folgende Container laufen aktuell auf dem Wolf Wobei aktuell nur die drei Markierten jeweils einen der Tunnel des Wolfs belegen
- Das führt aktuell bei mir auf der Schnittstellen-Seite "KNX Schnittstellen & Tunnel Verwaltung" zu folgender Zuordnung:
- Im Wiregate-Plugin-Container (markiert mit 1) läuft nun "/usr/bin/eibd -u -i ipt:172.17.0.1:3700 -d/var/log/eibd.log -e 0.0.0", wobei der eibd die Version "0.0.5" hat.
- Im über die APP aktivierten Container der produktiven Visu 0.11.2 (markiert mit 2) läuft "knxd -i iptn:172.17.0.1:3700 -e 0.0.0 -u -d/var/log/eibd.log -c", wobei der knxd die Version "0.1.0" hat.
- Und zu guter letzt der " CometVisuTest"-Container mit dem "0.12.0-dev"-Image. Dort läuft der "knxd -i iptn:172.17.0.1:3700 -e 1.1.238 -u -d/dev/stdout -c". Der knxd hat hier ebenfalls die Version "0.1.0"
Nun hatte ich die CometVisu 0.12.0-dev mal streng nach Anleitung installiert. Das führt defaultmäßig dazu, dass eine ENV-Variable "KNX_PA" mit dem Inhalt "1.1.238" vergeben wird. Das pass gundsätzlich zum meinem Linienaufbau und die PA ist auch frei. Damit taucht die im Aufruf des knxd dann auch als "-e 1.1.238" auf.
Wenn ich jetzt aber über die Oberfläche der "0.12.0-dev"-CV einen Schaltbefehl auf einen meiner Aktoren sende, sehe ich sowohl im Busmonitor des Wolfes, als auch in der Diagnose der ETS als Quell-PA des Telegramms die "1.1.5". Das ist jetzt aber etwas, was ich überhaupt nicht erwartet hätte. Die 1.1.5 ist schließlich die Zusatz-PA, die laut Interface-Seite dem Container mit der IP 172.17.0.6 zugeordnet wurde. In dem Teil läuft aber doch die CV 0.11.2. Aus der habe ich den Schaltimpuls aber nicht gegeben. Das Verhalten ändert sich übrigens nicht, wenn ich in der ENV-Variablen die "0.0.0" eintrage. Auch den Cache habe ich in meinem Firefox schon gelöscht.
Wenn ich aus dem Wiregate-Container etwas sende, dann taucht das im Monitor mit dem Ursprung "1.1.4" auf. Da ist meine Welt ja noch irgendwie in Ordnung...
Aber das Bild oben verwirrt mich aktuell doch massiv.
Mal völlig losgelöst von dem gestrigen Test einer CV-Version die im Unterbau einen knxd in der Version 0.14 nutzt. Da scheint sich was in der API beim Umgang mit den Tunneln und den Adressen geändert zu haben. Da steht im Wiki zum knxd in der "adress-section" so schön "Starting with version 0.11, this address is not used for tunnelling clients, see [multicast-server-section].". Da war dann gestern im Container am knxd neben dem gesetzten "-e" auch der "-E" zu sehen. Wobei der "-E" sich wiederum laut Doku auf Client-Adressen bezieht. Was ist denn da dann wieder zu berücksichtigen? Ich blicks langsam echt nicht mehr....
Aber wie immer, die Hoffnung stirbt ja bekanntlich zuletzt.
Ich wünsche euch allen aber mal schon einen guten Rutsch! Auf das 2021 schönere Überraschungen für uns parat hat als 2020!
Beste Grüße
Jens
