KNX/EIB Hager KNX-Gateway TYF120 - Mehrere Verbindungen nicht möglich

[azzkikrboy]

Hallo zusammen,

ich habe ein Problem mit dem HAGER TYF120 KNX IP-Gateway. Ich möchte das GW zum Programmieren und zur Anbindung von openHAB (zur Steuerung meiner SONOS und bald hoffentlich echo.DOT) benutzen.

Laut Datenblatt bietet die Schnittstelle 5 gleichzeitige IPTunneling Verbindungen. Eben zur gleichzeitigen Programmierung und Visu z.B.

Nun bekomme ich nie mehr als eine zum laufen

Wenn z.B. der openHAB läuft, bekomme ich in der ETS5 die Fehlermeldung, dass die Schnittstelle schon benutzt wird ... Gleiches auch wenn ich einen KNX Bus Monitor auf meinem iPhone laufen lasse und dann die ETS starte.

Hier mal der Ausschnitt aus dem HB:

KNXnet/IP Tunneling Schnittstelle zum Bus
Über ein Datennetzwerk und die IP Schnittstelle kann eine direkte Verbindung von einem PC im Netzwerk
zum Bus hergestellt werden. Damit ist der Zugriff auf den Bus von jedem Punkt in einem Datennetzwerk möglich.
Die IP Schnittstelle bietet bis zu fünf KNXnet/IP Tunneling Verbindungen, so dass z.B. gleichzeitig visualisiert und mit der ETS3 konfiguriert werden kann.
Hinweis
Für eine stabile Kommunikation über KNXnet/IP Tunneling muss die IP Schnittstelle für jede KNXnet/IP Tunneling Verbindung eine eigene physikalische Adresse verwenden. Diese zusätzlichen physikalischen Adressen dürfen nicht mit der physikalischen Adresse des Gerätes identisch sein und dürfen auch von keinem anderen Busgerät verwendet werden. In der ETS sollten diese physikalischen Adressen durch Dummy-Geräte belegt werden.

In der ETS hat die Schnittstelle selbst die 1.1.64 (freigehalten habe ich die 1.1.62 und 1.1.63).

Und wo soll ich bitte die eigene phys.addr. angeben?
So, und jetzt bin ich mit meinem Latin am Ende, denn viel Konfigurieren kann man ausser der IP@ nicht.

PS: Ja ich weiss, es ist kein Router, den brauch ich "eigentlich" auch nicht ... ich will doch nur 2 von den 5 möglichen Verbindungen gleichzeitig nutzen

Vielen Dank für eure Hilfe.

[Beleuchtfix]

Hast du mal versucht, ob es eine Web-Config Seite gibt?

Viel Erfolg
Florian

[spassbird]

Sonst auch gern mal an die Anleitung in der Applikationsbeschreibung halten.
Dafür die Applikation von Hager für ETS 4 runterladen und in der ETS4 oder ETS5 einbinden.

Anleitung hier https://www.hager.de/files/download/...WAY_ETS_DE.PDF

Es muss für jeden Tunnel ersteinmal eine physikalische Adresse Aangelegt werden, die es in Deiner Gerätestruktur noch nicht gibt.
Dann solltest Du dieser phsyikal. Adresse auch eine IP Adresse zuweisen können.

[Gast]

Anleitung hier https://www.hager.de/files/download/...WAY_ETS_DE.PDF

Und Knöpfchen für 5-10s drücken, vielleicht liegt's ja daran?

"Die automatische Adressvergabe für KNXnet/IP Tunneling und ObjectServer wird gestartet, wenn die Programmiertaste im Betrieb länger als 5 Sekunden, aber weniger als 10 Sekunden gedrückt wird. Während der Adressvergabe blinkt die Programmier-LED. Das Gerät prüft, welche physikalischen Adressen durch andere an der Buslinie angeschlossene Busgeräte bereits genutzt werden. Diese Adressen werden bei der Adressvergabe nicht verwendet."

[azzkikrboy]

Hallo zusammen,

erste mal DANKE für die schnellen Antworten ...

So, das mit der Adressvergabe habe ich natürlich in der Applikationsbeschreibung gelesen , aber für mich war die variante über ETS vergeben "besser" als automatisch.
Nur kann ich in der ETS halt nur eine eingeben, eben die Adresse, die die ETS nutzt ... naja.
Ich hab dann einfach mal auf das magische Knöpfchen gedrückt ... und schon gehts

Aber nun weiss ich halt nicht, welche Adressen genutzt werden ... die ETS zeigt mir die neue an die von 1.1.63 zu 1.1.115 gewechselt hat ... Welche anderen sind denn jetzt aktiv? Welche gebe ich in der openHAB config an?

Danke

[Gast]

Welche gebe ich in der openHAB config an?

Gar keine, das Feld "# knx:busaddr=..." kannst du auskommentiert lassen. Du musst nur die IP-Adresse des Interfaces angeben. Die PA der Tunnel muß OpenHAB nicht kennen.

[spassbird]

Hallo zusammen,

erste mal DANKE für die schnellen Antworten ...

So, das mit der Adressvergabe habe ich natürlich in der Applikationsbeschreibung gelesen , aber für mich war die variante über ETS vergeben "besser" als automatisch.
Nur kann ich in der ETS halt nur eine eingeben, eben die Adresse, die die ETS nutzt ... naja.
Ich hab dann einfach mal auf das magische Knöpfchen gedrückt ... und schon gehts

Aber nun weiss ich halt nicht, welche Adressen genutzt werden ... die ETS zeigt mir die neue an die von 1.1.63 zu 1.1.115 gewechselt hat ... Welche anderen sind denn jetzt aktiv? Welche gebe ich in der openHAB config an?

Danke

Du könntest ja nun, wo die anderen Adressen vergeben wurden, ja mal den Bus scannen und sehen welche Geräteadressen erkannt werden.
Dann ziehst Du die ab, die Du selbst in der ETS für Sensoren und Aktoren vergeben hast. Im Idealfall, bleiben 4 Adressen übrig und das sollten die für die
weiteren Tunnel sein.

[scott74]

Jetzt muss ich auch mal hier etwas nachfragen, weil ich am verzfeifeln bin.
In Verwendung ist die ETS 5.5.3 mit dem hier beschriebenen IP-Interface TYF120.
Auch ich wollte die zusätzlichen Physikalischen Adressen von vorne selbst vergeben. Aber nun... dann gebe ich mich geschlagen, und lasse diese vom System vergeben.
Jetzt will auch nicht mal das klappen.
Wenn ich den Programmierknopf für 5 bis 10 Sekunden drücke und anschließend den Linienscan mache, dann sehe ich, dass das System 5 neue physikalischen Adressen vergeben hat.
Soweit top. Was mache ich jetzt mit denen?
Wie ist die genaue Schrittfolge:
1. Programmierknopf drücken
2. Linienscan durchführen, um die neuen "Tunneling-Adressen" herauszufinden.
3. Dummy-Adressen zu den neuen "Tunneling-Adressen" anlegen
4. Unter Bus > Verbindungen > Schnittstellen neue konfigurierte Schnittstellen hinzufügen und denen die physikalischen Adressen aus 3 zuordnen inkl. der IP-Adresse (ich nutze eine feste IP-Adresse und alle sollen in meinem Fall die 192.168.178.55 bekommen)

Wenn dem so ist, dann frage ich mich, was ich falsch mache. Nach der eingabe der physikalischen Adresse bekomme ich die Warnung mit:
"Setting local IA failed, because requested IA 1.1.44 is already in use as additional address."
Drücke ich dann auf Test, dann sagt er OK.

Bin für jeden Versuch mir zu helfen den Knoten aufzulösen, extrem dankbar.
Viele Grüße
scott

P.S.
Traurig finde ich auch, dass Hager keine aktualisierte Version der Applikationsbeschreibung oder der Produktdatenbank selbst bereitstellt.

[scott74]

Möchte mich hier noch mal in Errinerung bringen und mich freuen, wenn jemand meine grauen Zellen etwas wachrütteln könnte.
Ich komme mit dem Thema echt nicht weiter.
Danke.

[spassbird]

Und die neuen physikalischen Adressen beissen sich nicht mit einem bereits vorhandeneN Gerät mit gleiche Adresse?.
oftmals werden die Adressen ja hintereinander vergeben, also immer fünf Stück am Block.
Probier doch mal eine erste Adresse für das Interface zu programmieren, die genug Abstand zu den anderen hat.
z.B. 1.1.250
Dann sollten die weiteren 251, 252, 253 und 254 sein.
Vllt klappt das besser.

[scott74]

spassbird Danke für die Hinweise. Leider haben sie aber nix neues gebracht. Daraufhin habe ich bei Hager angerufen.

Rückmeldung:
Die Schnittstelle kann die zusätzlichen Adressen offenbar nur über den automatischen Weg zuweisen. Also Knöpfchen für 5 bis 10 Sekunden drücken.
Auslesen kann man die über den Linienscan.
Also auch das haben wir hier schon beschrieben.
Nix neues also, außer Bestätigung.
So wie ich es vor hatte, die zusätzlichen Adressen sichtbar in den Schnittstellen-Einstellungen zuzuweisen, klappt auch nicht.
Das IP-Gateway würde sich die zusätzlichen Adressen selbst ziehen, wenn erfoderlich bzw. wenn man externe Visu verwendet, dann muss man der Visu eine der zusätzlichen Adressen mitgeben/zuweisen. Da bin ich schon auf meine Experimente mit EDOMI gespannt.
Der Kollege hat kompetent zugegeben, dass das suboptimal ist, wird sich aber nicht ändern.
Ich warte dann nur, bis ich zum ersten mal in einen echten Bedarf nach mehreren Tunnel-Verbindungen habe. Bin gespannt ob es dann wirklich funktioniert.
Bis dahin ein Blindflug.