ElabNET Technik Forum

Hallo,

eine Frage zum Verständnis der KNX-IP Schnittstellenfunktionalität. Der TWS wird ja bis zu 25 Tunnel von IP zu KNX bereitstellen können. Es können auch die Ziellinien bei mehreren TPUARTS festgelegt werden.
Ist es auch möglich jedem Tunnel eine fixe Zuordnung IP-Adresse zu Tunnel sprich PA in der KNX-Topologie zu verpassen?

Die Frage tauchte heute im KNX-UF auf. Bisherige Schnittstellen bieten eine solche Funktion nicht, hier werden die Tunnel quasi first come first serve auf die anklopfenden IP-Adressen verteilt.

Hintergrund ist wohl das man beim Logging eine fixe Zuordnung PA zu Gerät haben möchte welches sich auf der IP-Seite befindet. Kommt es aber zu Reboots der IP-Geräte kommt es wahrscheinlich zu neuen Reihenfolgen und PA-Zuordnungen. Verbale Beschreibungen der PA machen dann keinen wirklichen Sinn wenn man im Busmonitor nach bestimmten Geräten sucht.

Bin gerade im Zug und komme nicht an den TWS / ETS um da nach möglichen Optionen zu suchen.

Wenn noch nicht vorhanden, ist sowas überhaupt möglich oder sprechen da KNX-Protokollstandards dagegen?

Grüße
Göran

Hallo Göran,

gbglace hat geschrieben: ↑Do Sep 06, 2018 7:30 pmDer TWS wird ja bis zu 25 Tunnel von IP zu KNX bereitstellen können.

Ja, bei uns geht das schon und kommt mit der BETA 10 (nur in Verbindung mit internen KNX-Schnittstellen, also TWS 2500 / 2600 sowie die Hutschienenserver und je nach Lizenz). Später auch mit "TP-PRO" (gibt nur im Labor)

gbglace hat geschrieben: ↑Do Sep 06, 2018 7:30 pmEs können auch die Ziellinien bei mehreren TPUARTS festgelegt werden.

Ja, derzeit eine für Applikation und weitere für Logging.

In naher Zukunft bis drei IP Schnittstellen

gbglace hat geschrieben: ↑Do Sep 06, 2018 7:30 pmIst es auch möglich jedem Tunnel eine fixe Zuordnung IP-Adresse zu Tunnel sprich PA in der KNX-Topologie zu verpassen?

Also eine Zuordnung im vorneherein ist nicht vorgesehen, es wird aber eine Liste geben, welche IP welchen Tunnel belegt.

gbglace hat geschrieben: ↑Do Sep 06, 2018 7:30 pmDie Frage tauchte heute im KNX-UF auf.

Wo denn?

gbglace hat geschrieben: ↑Do Sep 06, 2018 7:30 pmBisherige Schnittstellen bieten eine solche Funktion nicht, hier werden die Tunnel quasi first come first serve auf die anklopfenden IP-Adressen verteilt.

Das ist der Standard (soweit ich ihn kenne, bin nicht perfekt).

gbglace hat geschrieben: ↑Do Sep 06, 2018 7:30 pmHintergrund ist wohl das man beim Logging eine fixe Zuordnung PA zu Gerät haben möchte welches sich auf der IP-Seite befindet. Kommt es aber zu Reboots der IP-Geräte kommt es wahrscheinlich zu neuen Reihenfolgen und PA-Zuordnungen. Verbale Beschreibungen der PA machen dann keinen wirklichen Sinn wenn man im Busmonitor nach bestimmten Geräten sucht.

Verstanden. Wieviele Leute brauche das und sind die Bereit einen Timberwolf Server zu kaufen?

gbglace hat geschrieben: ↑Do Sep 06, 2018 7:30 pmWenn noch nicht vorhanden, ist sowas überhaupt möglich oder sprechen da KNX-Protokollstandards dagegen?

Hmm, ich denke die Standards würden es nicht merken, wenn "zufällig" immer die gleiche IP den gleichen Tunnel und damit die gleiche PA bekommt.

==> Ich bespreche das gerne mit meinem KNX Spezialisten, aber am Ende des Tages kosten solche Features schnell einen vierstelligen Betrag, daher muss ich schon wissen, ob man das wieder hereinholt, weil es ein signifikantes Problem vieler löst.

Womöglich wäre es ein "Professional Plus" Feature für Integratoren.

lg

Stefan

Hi Stefan,

Hier der Link
https://knx-user-forum.de/forum/%C3%B6f ... ittstellen

Naja oft hab ich von solchen Wünschen auch noch nicht gelesen. Wahrscheinlich weil bisher auch noch nicht soviele IP-Geräte gleichzeitig am Bus aktiv sind und man deswegen die Suche nach Fehlern via Busmonitor nicht auf jene konzentriert, oder viele hinter einem eibd hängen. Mit der doch sehr guten Langzeit Diagnose direkt ab Werk im TWS könnte ich da nun auch nur reines Interesse anmelden weniger ein Problembeseitigungsbedürfnis. Wer seinen Bus in der Familie via diverser Tablets/Handys bedient hätte da dann eine größere Transparenz wer da was ausgelöst hat.

Grüße Göran

Wie ist das denn mit den Containern im Portainer?
Hat da nicht jeder seine eigene virtuelle Netzwerkschnittstelle und damit auch eine eigene IP?
Dann hätte man alleine mit einigen Containern im TWS mehrere IP-Geräte, die auf die KNX-Schnittstelle zugreifen.

Ist nur eine Idee, evtl. völlig daneben da ich mich mit Containern sowas von gar nicht auskenne...

Ich denke das hängt davon ab wie die kaskadiert sind. Auf der TWS Ebene ist da jedes Schnittstelle ein echtes KNX-Gerät und hat eine eigene Adresse.

Wenn Du jetzt in einem Container eine eibd/knxd Instanz startest wird genau dieser Container quasi ein Gerät sein, da der Wind dort einen Tunnel der TWS Schnittstelle einnimmt. Alles was dann an Handys und Tablets die Visu nutzt und via andere Container diesen einen eibd nutzt sind quasi auf der KNX-Seite nicht zu identifizieren, da sie alle mit dem Tunnel des eibds arbeiten und nur als das Gerät eibd in Erscheinung treten.
Nutzen die verschiedenen Container jeweils eigene Verbindungen des TWS also einen der 25 Tunnel, dann sind es auch auf der KNX-Seite eindeutig identifizierbar Geräte. Offen ist halt ob die Eindeutigkeit über die Lebensdauer des Systems oder nur für die eine Login-Session gilt.

gbglace hat geschrieben: ↑Do Sep 06, 2018 9:28 pm Mit der doch sehr guten Langzeit Diagnose direkt ab Werk im TWS könnte ich da nun auch nur reines Interesse anmelden weniger ein Problembeseitigungsbedürfnis. Wer seinen Bus in der Familie via diverser Tablets/Handys bedient hätte da dann eine größere Transparenz wer da was ausgelöst hat.

Da in den meisten fällen DHCP genutzt werden dürfte, sind die IP-Adressen ohnehin Schall und Rauch. Im Sinne einer Nachvollziehbarkeit, würde es ja reichen den Clientnamen zu loggen.

Gruss
Jochen.

Ja DHCP nutze ich da auch, lasse die Fritze aber dennoch immer wieder die gleiche IP vergeben.

Auf jeden Fall eine Option, mit dem Clientnamen, wer es sauber haben will muss den dann halt einfach pflegen (sprechende Bezeichnung), wie überall. Einfach plug and play ist nur selten ganz sauber für das menschliche Gehirn und Ordnungssinn optimiert, siehe GA's in ETS-Inside.