UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Frage] [1.6.0 RC8] Nutzung und Umgang mit physikalischen Adressen

Diskussionen über die KNX-Funktionen im Timberwolf Server
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
blaubaerli
Reactions:
Beiträge: 2308
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 884 Mal
Danksagung erhalten: 677 Mal

[1.6.0 RC8] Nutzung und Umgang mit physikalischen Adressen

#1

Beitrag von blaubaerli »

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:
tofele hat geschrieben: Sa Dez 26, 2020 4:34 pm Ich brauche etwas Schwarmintelligenz, ich steh auf dem Schlauch, trotz vielem Lesen hier im Forum heute.
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
    31-12-_2020_12-46-26.jpg
    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:
    31-12-_2020_13-10-24.jpg
  • 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"
Jetzt meinte ich mal verstanden zu haben, dass sowohl der eibd, als auch der knxd bei Nutzung des Parameters "-e 0.0.0" so etwas wie eine "automatische Zuordnung" einer freien PA aus dem Haushalt der dem Wolf zugeordneten "Zusatz-PAs" vornehmen würde.

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. :confusion-scratchheadyellow:

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.... :angry-banghead: :confusion-scratchheadyellow:

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! :handgestures-thumbupright:

Beste Grüße
Jens
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
wiregate1250 & timberwolf168 (2600er), VPN offen, Reboot nach Vereinbarung
Benutzeravatar

Chris M.
Reactions:
Beiträge: 1190
Registriert: Sa Aug 11, 2018 10:52 pm
Wohnort: Oberbayern
Hat sich bedankt: 234 Mal
Danksagung erhalten: 853 Mal
Kontaktdaten:

#2

Beitrag von Chris M. »

Der knxd 0.1.0 ist im Wesentlichen der eibd 0.0.5.1. Hier gilt noch das alte verhalten, dass alle Bus-Kommunikation darüber mit der PA des eibd/knxd passieren.

Ob am Bus nun die -e Addresse auftaucht oder nicht müsste damit zusammen hängen wie der knxd an den Bus angeschlossen ist (TP, Tunnel, Router)
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.

TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache

Ersteller
blaubaerli
Reactions:
Beiträge: 2308
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 884 Mal
Danksagung erhalten: 677 Mal

#3

Beitrag von blaubaerli »

Hallo Chris,

die Methode ist aber ja mit dem „iptn“ offensichtlich in allen drei Instanzen identisch gewählt. Wenn da ja was unterschiedlich wäre, dann könnte das ja sein. Wenn aber nach deiner Aussage die hier genutzte Version des knxd und dem eibd im Verhalten und von der API eigentlich identisch sind, dann blick ich das nicht.

Beste Grüße
Jens
Zuletzt geändert von blaubaerli am Do Dez 31, 2020 9:23 pm, insgesamt 1-mal geändert.
wiregate1250 & timberwolf168 (2600er), VPN offen, Reboot nach Vereinbarung

Ersteller
blaubaerli
Reactions:
Beiträge: 2308
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 884 Mal
Danksagung erhalten: 677 Mal

#4

Beitrag von blaubaerli »

Hallo zusammen,

ist das wieder ne peinliche Nummer....... :angry-banghead: :angry-banghead: :angry-banghead: :angry-banghead: :angry-banghead: :angry-banghead: :angry-banghead:

Das war beim Konfigurieren eindeutig wieder ein: :text-blondmoment:

Wenn man in der ENV-Variablen "CGI_URL_PATH" für die Testinstanz auch "/proxy/visu/cgi-bin/" statt "/proxy/visutest/cgi-bin/" einträgt, darf man sich in der Tat nicht wundern.

Dann auch noch behaupten, dass man das streng nach Anleitung gemacht hat... :liar: :think: :crying-yellow:

Also Asche auf mein Haupt, damit ist nun erklärt, wieso die mir nicht schlüssig erscheinende PA genutzt wurde. Wenn man das nicht richtig macht, kann da auch mal was falsches rauskommen......

Was das wieder für ne Zeit gekostet hat....

Beste Grüße
Jens
wiregate1250 & timberwolf168 (2600er), VPN offen, Reboot nach Vereinbarung

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#5

Beitrag von Robert_Mini »

Ging mir gestern auch so.
Wollte schnell mal eine Lampe in OpenHAB + Alexa auf dimmbar umstellen.
Hat mich fast 1h gekostet und zwischenzeitlich ging gar nichts mehr per Alexa zu schalten...

Am Ende war es ein " zuviel bei den GA-Definitionen :angry-banghead: :angry-banghead: :angry-banghead:

Über die proxy bin ich auch schon mal gestolpert. Hab mich gewundert, warum die CV nuf geht, wenn beide Container laufen, weil im proxy der andere eingetragen war.

Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Ersteller
blaubaerli
Reactions:
Beiträge: 2308
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 884 Mal
Danksagung erhalten: 677 Mal

#6

Beitrag von blaubaerli »

Hi Robert,

das gehört glaube ich zum Thema Lernkurven. Der Chris hätte verdammt noch mal in der CV Anleitung die Stelle mit der Doku für die Testinstanz aber gefälligst auch was auffälliger markieren können.... :laughing-rolling:

Beste Grüße
Jens
Zuletzt geändert von blaubaerli am Sa Jan 02, 2021 3:37 pm, insgesamt 1-mal geändert.
wiregate1250 & timberwolf168 (2600er), VPN offen, Reboot nach Vereinbarung
Antworten

Zurück zu „KNX“