ElabNET Technik Forum

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.

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

Hallo Markus,

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

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.

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

Ach wir göttlichen...