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] KNX IP Tunnel und zugehörige PAs?

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

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#11

Beitrag von gbglace »

Die Vergabe der PA sollte soweit Aufgabe der IP-Schnittstelle sein, solange der Client keine sich selbst vorkonfigurierte PA hat. Problematisch ist es eben wenn du am TWS bastelst ein Container sich resettet und der TWS dann die freie PA einem anderen Client zuordnet, wenn dann der Container oder was anderes wieder online ist kann es kollidieren. Insofern würde ich wenn solche festen PA im Client verdrahtet werden eher von hinten beginnen als von vorn.

Insofern fände ich es smart wenn die Schnittstelle also der TWS per IP eine definierbares Mapping macht. Und undefinierte IP-Adressen dann eben PA's aus einem nicht reservierten Bereich vergibt. Also ähnlich der Funktionalität der DHCP-Server, die funktionieren mittlerweile ja auch so weit zuverlässig, dass man das in dem Server implementiert und nicht mehr in jedem Client hart verdrahten muss als fixe IP.

Das der OH sich selbst die 1.1.4 gezogen hat ist schon sehr sehr merkwürdig, woher soll er denn wissen daß die PA im Projekt nicht verwendet wird. Warum der TWS allerdings diese Adresse vergeben sollte, wenn sie nicht in der Range der definierten Tunnel liegt ist auch eigenartig.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#12

Beitrag von StefanW »

Hallo Maarkus,

es gibt da zwei Aussagen von Dir, die mir etwas Rätsel aufgeben (weil das so nicht funktionieren sollte).

1. Du schreibst: "Diesen kann ich mit einen beliebigen Port zwischen 3671 - 3700 mit dem TWS verbinden". Das sollte nicht möglich sein. Es sollte nur der EINE Port funktionieren, der in der Übersicht auch angegeben ist. Da wir mehrere KNX-Daemons parallel laufen lassen können, wird aus dem größeren angegebenen Bereich 3671 bis 3700 jeweils EINER pro Daemon verwendet, es sollte also nur der EINE Port funktionieren, der auch angezeigt wird.

==> Kannst Du das bitte nochmal überprüfen?


2. Und Du schreibst: "Interessanterweise hat mein OH Container nämlich mit unkonfigurierter PA (0.0.0) zwar funktioniert, sich aber automatisch z.B. die 1.1.4 zugeordnet. 1.1.4 entspricht dabei nicht den Tunnel PAs, die ich vergeben habe,". Auch das sollte nicht funktionieren. Der KNX Daemon sollte ausschließlich nur die konfigurierten PAs zuteilen wie mit der ETS programmiert und anschließend in der KNX Schnittstellenverwaltung angezeigt.

==> Kannst Du das bitte nochmal überprüfen?

Womöglich hast Du zwei Fehler gefunden und wenn dem so ist, möchte ich das UNBEDINGT kurzfristig lösen, weil wir wollten nächste Woche die V 1.6 IP 3 ausrollen und solche Fehler will ich umgehend fixen.

Es wäre toll, wenn Du das nochmal überprüfen könntest und auch bitte Screenshots damit machst, weil sonst glauben das die Entwickler womöglich nicht.

Merci

Stefan
Zuletzt geändert von StefanW am Di Mai 19, 2020 9:45 am, insgesamt 2-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#13

Beitrag von starwarsfan »

Hallo Markus,

Schuss ins Blaue: Du hast nicht etwa noch ein zweites IP-Interface im Netz, von welchem OH die 1.1.4 bekommt?
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -

Ersteller
Marinux
Reactions:
Beiträge: 125
Registriert: Fr Apr 12, 2019 3:04 pm
Hat sich bedankt: 9 Mal
Danksagung erhalten: 51 Mal

#14

Beitrag von Marinux »

starwarsfan hat geschrieben: Di Mai 19, 2020 6:33 am Hallo Markus,

Schuss ins Blaue: Du hast nicht etwa noch ein zweites IP-Interface im Netz, von welchem OH die 1.1.4 bekommt?
Hi Yves,

nein, das kann ich ausschließen. Ich werde das Problem heute versuchen nachzustellen und hier posten.
Gruß Markus

TWS 960Q #360, VPN geschlossen, Reboot verboten

Ersteller
Marinux
Reactions:
Beiträge: 125
Registriert: Fr Apr 12, 2019 3:04 pm
Hat sich bedankt: 9 Mal
Danksagung erhalten: 51 Mal

#15

Beitrag von Marinux »

Hallo Stefan,

ich glaube die Screenshots kann ich mir sparen. Alles was gestern passierte kann ich heute nicht mehr reproduzieren.

Weder werden undefinierte PAs zugewiesen, noch kann ich statische PAs vergeben. Heute morgen haben sich ETS und OpenHAB in umgekehrter Reihenfolge verbunden :-) Die PA die man in OpenHAB definieren kann forciert keine PA Auswahl des Tunnels und führt dann bei einem mismatch zur Disfunktion. 0.0.0 in OH ist somit die richtige Wahl. Somit anscheinend alles so, wie ihr es prophezeit habt.

Ein Kleinigkeit stimmt jedoch, ich kann den OH Container und auch die ETS sowohl über Port 3700 also auch 3671 verbinden.

Mea culpa
Zuletzt geändert von Marinux am Di Mai 19, 2020 11:35 am, insgesamt 2-mal geändert.
Gruß Markus

TWS 960Q #360, VPN geschlossen, Reboot verboten

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#16

Beitrag von gbglace »

Ach wir göttlichen...:laughing-rolling:
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Antworten

Zurück zu „KNX“