KNX-IP Interface oder Router

[Eraser]

Hallo!

Folgender derweil theoretischer Aufbau:

-) KNX-Geräte vom Haus in der Hauptlinie 1.0.x
-) KNX-Geräte vom Aussenbereich in der Linie 1.1.x
Die beiden Linien mittels Linienkoppler verbunden und jede Linie eine eigene SV
Dies sollte laut Forum der einfachste (kostengünstigste) Aufbau sein, um trotzdem eine separate Aussenlinie zu haben.

-) Die Hauptlinie soll dann an das Netzwerk angeschlossen werden (IP-Interface oder Router)
-) Am Netzwerk greifen die ETS, eine oder mehrere Visus auf den KNX-Bus zu.

Frage:
Sollte man bei dieser Konfiguration nun ein IP-Interface mit mehreren Tunneln oder einen IP-Router verwenden?
Wo sind da die Vor- und Nachteile? Funktionieren sollte ja beides oder?

mfg
Wolfgang

PS: Wenn ein Timberwolf (eventuell) eingebaut wird, reicht dann dieser komplett dafür aus oder wäre eine eigene IP-Schnittstelle(Router) trotzdem empfehlenswert?
Das ist wohl eine Frage für StefanW ...

[gbglace]

Mit dem Timberwolf genügt der Sver in der passenden Version selbst, da dieser Tunnel-Verbindungen zur Verfügung stellt. Routing und Multicast habe ich mich noch nicht mit auseinandergesetzt und in der Beschreibung gesucht.

Das ist soweit auch schon der unterschied IP-Interface vs Router, hast Du Visu Geräte oder Server (Gira-HS) oder andere KNX-IP sprechende Geräte (G1 via WLAN hier wohl auch nur Gira Router möglich) die Multicast benötigen wirst einen Router kaufen müssen, sonst genügt auch ein Interface oder der TW-Server.

Gibt aber schon einige Threads mit so ziemlich der gleichen Überschrift zu dem Thema. Schau mal da rein da findest dann noch mehr Details zu der Fragestellung.

Die Topologie ist zwar Sparversion, sollte aber passen sofern es im Innenbereich nicht mehr als 64 Geräte werden, da die Hauptlinien wohl trotz TP256 noch nicht soweit ausgebaut werden können, war mir zumindest so in der Zusamenfassung der letzten Threads zu dem Thema wieviele Geräte passen max in ein KNX-TP Universum.

[Eraser]

gbglace
Danke für deine Antworten!

Gira-HS oder G1 werde ich nicht haben, Logiken usw. würde ich dann mit dem Timberwolf direkt oder vlt. über EDOMI im Docker realisieren.

Also wäre dann IP-Router, allgemein gesagt, nur dann sinnvoll, wenn man KNX-IP-Geräte verwendet, welche Multicast benötigen
ODER / UND
wenn man mehrere Linien über KNX-IP statt KNX-TP verbinden will.

Hab auch im Forum danach gesucht, aber keinen direkten Vergleich dazu gefunden, was da die genauen Unterschiede dazu sind.
Ebenso das Heinle-KNX-Buch gelesen, aber leider ist dort nur allgemein aufgelistet, dass wenn man mehrere Verbindungen gleichzeitig braucht,
dass man einen Router braucht, obwohl das ja mit einem Interface mit mehreren Tunneln ja auch geht.


Ich stelle mir meinen Endausbau derweil so vor:

-) MDT Glastaster 2 Smart
-) Diverse Schalt-, Jalousie- und Dimmaktoren, Binäreingänge, sowie die KNX-Versorgungen und den Linienkoppler
-) Diverse Präsenzmelder
-) Enertex SmartMeter
-) Wetterstation
-) Anbindung der beiden Hörmann-Torantriebe über das HM-KNX-Modul
-) Anbindung der Wärmepumpe und WRL über das ISE KNX-Modul für Vaillant
-) Timberwolf für 1-Wire-Anbindung, KNX-Telgrammaufzeichnung
-) EDOMI im Docker auf dem Timberwolf für Logiken und Visu
-) Normales Touchpanel mit Zugriff auf die EDOMI-Visu über Ethernet
-) Zugriff auf das Netzwerk von außen über eine VPN-Verbindung oder Ähnliches

44 KNX-Geräte auf der Hauptlinie 1.0.x und 8 Geräte auf der Aussenlinie 1.1.x. Von daher gibt es keine Probleme für die Sparversion.

[DiMa]

gbglace
Also wäre dann IP-Router, allgemein gesagt, nur dann sinnvoll, wenn man KNX-IP-Geräte verwendet, welche Multicast benötigen
ODER / UND
wenn man mehrere Linien über KNX-IP statt KNX-TP verbinden will.

So ist es.

[StefanW]

Hallo Wolfgang,

Dies sollte laut Forum der einfachste (kostengünstigste) Aufbau sein, um trotzdem eine separate Aussenlinie zu haben.

Ja, sehe ich auch so.

Sollte man bei dieser Konfiguration nun ein IP-Interface mit mehreren Tunneln oder einen IP-Router verwenden?

Das kommt darauf an, was die Geräte benötigen. ETS braucht Tunneling und die meisten Visu (die ich kenne) ebenfalls. Göran hat das schon erklärt.

Wo sind da die Vor- und Nachteile? Funktionieren sollte ja beides oder?

Das sind zwei verschiedene Verbindungsarten mit eigenen Regeln.

• KNXnet/IP Tunneling sind One-to-All Verbindungen (von einem KNXnet/IP Tunneling Teilnehmer am Ethernet zum KNX TP [oder RF] Bus).
• KNXnet/IP Routing ist eine All-to-All Verbindung (als Multicast mit beliebig vielen KNXnetIP Routing Teilnehmern über einen Router auf den / die jeweiligen TP [RF] Busse).

Routing ist üblicherweise gefiltert und in der Bandbreite beschränkt (um die TP / RF nicht zu überfahren).

KNXnet/IP Router können immer auch gleichzeitig KNXnet/IP Tunneling, weil man letzteres (z.b. für die ETS) immer benötigt.

PS: Wenn ein Timberwolf (eventuell) eingebaut wird, reicht dann dieser komplett dafür aus oder wäre eine eigene IP-Schnittstelle(Router) trotzdem empfehlenswert?

Er reicht komplett aus. Achte darauf, den Timberwolf Server mit "KNX Schnittstelle" zu beziehen, nicht mit "KNX Busankoppler". Letzterer darf - wegen einer technischen Verordnung der KNX.org - nur einen Tunnel gleichzeitig offiziell unterstützen (weil für jede Tunneling Verbindung mittlerweile eine eigene phy. Adresse gefordert wird). Ich werde im Katalog noch darauf hinweisen.

Mit dem Timberwolf genügt der Sver in der passenden Version selbst, da dieser Tunnel-Verbindungen zur Verfügung stellt. Routing und Multicast habe ich mich noch nicht mit auseinandergesetzt und in der Beschreibung gesucht.

Hallo Göran. Der Timberwolf Server unterstützt zunächst nur KNXnet/IP Tunneling. Das Routing ist für ein späteres Update vorgesehen.

Also wäre dann IP-Router, allgemein gesagt, nur dann sinnvoll, wenn man KNX-IP-Geräte verwendet, welche Multicast benötigen
ODER / UND wenn man mehrere Linien über KNX-IP statt KNX-TP verbinden will.

Richtig.

Ich stelle mir meinen Endausbau derweil so vor

Ok, passt so aus meiner Sicht.


lg

Stefan

[gbglace]

Von daher sind eben die Unterschiede von der reinen Anzahl der Features IP-Interface zu IP-Router sehr begrenzt. Preisslich hingegen schon deutlicher.

Sofern Bei Dir im neuen Haus eine LAN / WLAN Infrastruktur vorhanden ist, wenn Du anfängst Deine ersten Aktoren / Taster zu parametrieren, kannst natürlich auch rein den TW-Server nutzen. Ansonsten gern für den Start ne USB-Schnittstelle, die braucht keine Fritzbox um das erste Baulicht zu installieren. Oder machst das am heimischen Schreibtisch und stöpselst auf der Baustelle nur noch zusammen.

[evolution]

..."KNX Schnittstelle" ... nicht mit "KNX Busankoppler". Letzterer darf - wegen einer technischen Verordnung der KNX.org - nur einen Tunnel gleichzeitig offiziell unterstützen (weil für jede Tunneling Verbindung mittlerweile eine eigene phy. Adresse gefordert wird).

Diese Aussage ist verwirrend. Ein Busankoppler hat immer nur eine eigene PA und wird keine Tunnelverbindung für ein anderes als für das vorgesehene Gerät zur Verfügung stellen. Und mit "KNX Schnittstelle" ist hier sicherlich eine KNX IP-Schnittstelle (KNX IP-Interface) gemeint und diese hat schon immer mehr als eine Tunnelverbindung zur Verfügung stellen können, auch wenn hierfür nur eine PA benötigt wird.
Eraser Du solltest unbedingt darauf achten, dass Du eine von der KNX Association zertifizierte KNX IP-Schnittstelle verwendest, um potentielle Fehler zu vermeiden. Denn Probleme mit nichtzertifizierten Schnittstellen sieht man anhand der immer wiederkehrenden Probleme bei e.g. Loxone immer wieder.

[StefanW]

Oh mei....

Es handelt sich bei "KNX Busankoppler" vs. "KNX Schnittstelle" um zwei verschiedene Ausführungen der von uns angebotenen KNX Interfaces in Verbindung mit dem Timberwolf Server. Das geht auch klar aus dem Kontext hervor.

Es hat rein gar nichts mit sonstigen Busankopplern und Schnittstellen von irgendwelchen anderen Anbietern zu tun...

[evolution]

Stellt sich dann nur die Frage, ob die Schnittstellen von Kai-Uwe auch KNX zertifiziert sein werden. Denn nur den Stack zu zertifizieren reicht hierfür nicht aus...

Es hat rein gar nichts mit sonstigen Busankopplern und Schnittstellen von irgendwelchen anderen Anbietern zu tun...

Anders herum wird ein Schuh daraus: Wir sind hier im KNX-Bereich und der TE benötigt eine KNX Tunnelverbindung zu IP. Und mit einem Busankoppler bekommt er diese eben nicht, auch nicht von Kai-Uwe, selbst wenn es sich um einen zertifizierten Busankoppler handelt. Das kann man dem TE durchaus auch im KNX Jargon klarmachen und muss ihn nicht mit herstellerspezifischen Bezeichnungen überfrachten.

[StefanW]

Nein, die Frage stellt sich nicht, weil diese selbstverständlich zertifiziert sind bzw. in der neueren Version sein werden.

[DirtyHarry]

Das kommt darauf an, was die Geräte benötigen. ETS braucht Tunneling und die meisten Visu (die ich kenne) ebenfalls. Göran hat das schon erklärt.

ETS braucht Tunneling ist nicht richtig. Die ETS kann per Tunneling und Routing auf den Bus zugreifen. Per Tunneling halt schneller und stabiler als mit Routing, was besonders bei Nutzung von WLAN auffällt.

[Eraser]

Achte darauf, den Timberwolf Server mit "KNX Schnittstelle" zu beziehen, nicht mit "KNX Busankoppler"

Da käme dann für mich mit Docker-Funktionalität dann nur mehr der 2500 oder 2600 in Frage, richtig?

Oder machst das am heimischen Schreibtisch und stöpselst auf der Baustelle nur noch zusammen.

Bei mir ist das dann einfacher, da der Neubau direkt neben dem Elternhaus steht.
Werde die Geräte schon mal vorab mittels USB-KNX-Schnittstelle programmieren.

[Eraser]

OK dann werde ich eine IP-Schnittstelle mit Unterstützung für mehrere Tunnel verwenden.
Da hat dann jeder Tunnel eine eigene Phys. Adresse auf dem KNX-Bus korrekt?

[evolution]

Da hat dann jeder Tunnel eine eigene Phys. Adresse auf dem KNX-Bus korrekt?

Korrekt. Je nach ausgewähltem Modell (Hersteller), können diese Adressen auch individuell vergeben werden.

[StefanW]

Ich fürchte, es gibt da ein paar Missverständnisse.

Anders herum wird ein Schuh daraus: Wir sind hier im KNX-Bereich und der TE benötigt eine KNX Tunnelverbindung zu IP. Und mit einem Busankoppler bekommt er diese eben nicht, auch nicht von Kai-Uwe, selbst wenn es sich um einen zertifizierten Busankoppler handelt.

Doch, mit UNSEREM schon.

Ich denke es gibt ein Missverständnis durch unsere Produktbezeichnung. Wir haben - eigentlich zur Vereinfachung - unsere "USB TP-UART2+ KNX Interface im Hutschienengehäuse für den Timberwolf Server" als "KNX Busankoppler" benannt. Hierzu der Katalog-Ausschnitt:

2018-01-18_WG_KNX-Busankoppler_Katalogausschnitt_746x606.jpg


Diese Bezeichnung ist offenbar unglücklich, weil "Busankoppler" seit Jahren im Zusammenhang mit zweiteiligen Taster verwendet werden, bei denen der Busankoppler in der UP-Dose verbaut und das dann darauf Bedienteil aufgesetzt wird. Unser Wording führte zu Missverständnissen, für die ich mich entschuldige.

==> Wir ändern hiermit die Bezeichnung für unsere KNX Interfaces ab sofort ab, wie folgt:

Wir bieten drei (3) Varianten unserer KNX Interfaces an.

• WG KNX TP-UART USB: Dies ist das oben im Katalogausschnitt abgebildete 1HE Hutschienengerät mit USB und KNX TP und unterstützt eine (1) physikalische Adresse und damit bei zertifizierter Betriebsweise eine (1) KNXnet/IP Tunneling Connection gleichzeitig (unzertifiziert, z.B. mit dem eibd würden es beliebig viele Tunnel sein). Je nach Server können mehrere solcher "WG KNX TP-UART USB" an einem Server betrieben werden. Angesteckt in der gleichen Linie oder in verschiedenen Linien.
  Dieses Gerät haben wir im Katalog (und ich in meiner Erklärung oben) bisher als "KNX Busankoppler" bezeichnet. Wir ändern die Bezeichnung nun, um Missverständnisse in der Zukunft auszuräumen. Unser Gerät hat nichts mit sonstigen Busankopplern von anderen Herstellern zu tun und ist diesen auch nicht gleichzusetzen.
• WG KNX Schnittstelle USB: Dies ist die erweiterte Version, die bis zu 25 physikalische Adressen unterstützen wird und damit - je nach Softwareausstattung ebenfalls bis zu 25 KNXnet/IP Tunneling Connection gleichzeitig.
• WG KNX Schnittstelle integriert: Das ist das in einigen Modellen der Timberwolf Server im Gehäuse integrierte KNX Interface. Auch dieses wird bis zu 25 physikalische Adressen unterstützen und damit - je nach Softwareausstattung - bis zu 25 KNXnet/IP Tunneling Connection gleichzeitig. Je nach Servervariante können auch mehrere solcher WireGate KNX Busankoppler an einem Server betrieben werden um diese Leistungsfähigkeit das ggfls. auf mehrere Linien aufzuteilen.

Wir werden diese Interfaces künftig so benennen wie oben in blau bezeichnet.

Unsere Server und Schnittstellen bieten ein paar Freiheitsgrade, die es früher im KNX Bereich nicht gab, u.a. dass am Server (je nach Modell) bis zu zwölf (12) Interfaces mit verschiedenen Aufgaben gleichzeitig angeschlossen werden können. Nach meinem Wissen gab es das so noch nicht. Daher mag es Kollisionen zwischen bisherigen geltenden Regeln und dem Wording gegenüber den mit unserem Produkt neu geschaffenen Möglichkeiten geben.

==> Ich bin für Vorschläge in der Namensgebung - die Kollisionen mit bisherigen Bezeichnungen / Regeln vermeiden hilft - durchaus dankbar. Wenn Euch etwas diesbezügliches auffällt, freuen wir uns auf einen Hinweis an support at wiregate dot de.



Hallo Wolfgang,

Da käme dann für mich mit Docker-Funktionalität dann nur mehr der 2500 oder 2600 in Frage, richtig?

Jein. Weil es wird für ALLE Server auch die "WG KNX Schnittstelle USB" als Zubehör geben, das dann ebenfalls bis zu 25 phy. Adressen unterstützt und je nach Softwareausstattung bis zu 25 Tunnel-Connection.

Liefertermin für die "WG KNX Schnittstelle USB" wird Ende Frühjahr / Anfang Sommer 2018 sein. Wer bis dahin die jetzt bereits für Tester verfügbaren Interface "WG KNX TP-UART USB" gekauft hat, wird umtauschen können.

Werde die Geräte schon mal vorab mittels USB-KNX-Schnittstelle programmieren.

Je nach Zeitplan für die Umsetzung Deines Projektes (also falls unser Server verfügbar ist) kannst Du Dir die Anschaffung einer USB-KNX-Schnittstelle auch sparen, weil Du mit dem Timberwolf Server den gleichen Komfort der Einfachheit hast.

Es genügt völlig,

• den Timberwolf Server an Stromversorgung anschließen und einschalten
• ein LAN-Kabel (wie mitgeliefert, ungekreuzt) in Ethernet von Server und Notebook (oder via WLAN)
• per USB eines unserer beiden KNX-Interfaces anschließen (sofern nicht integriert)
• ETS hochfahren

und schon bietet sich der Timberwolf Server als IP-Schnittstelle in der ETS an. Ohne jegliche Konfiguration am Server. Man muss sich nicht einloggen, des geht out-of-the-Box.

Es ist also genauso einfach, wie wenn man eine USB-Schnittstelle (oder IP-Schnittstelle / IP-Router) aus der Schachtel nimmt und an KNX und USB / Ethernet anschließt. Auspacken, anschließen, fertig.


Hinweis 1: Wir verwenden in unseren Produkten die dritte Generation des KNX-Controllers: Durch die in unseren KNX Interfaces verbauten zertifizierten Siemens / Infinion Chips vom Typ "TP-UART2+" wird wegen der höheren Baudrate zum Chip (115.000 Baud anstatt 19.200 Baud) und dem doppelten Schreibpuffer ein um ca. 16 % höherer Paketdurchsatz erzielt als gegenüber dem Vorgänger 'TP-UART2' (also ohne '+' am Ende). Damit operiert diese Generation KNX-Controller ganz nahe am theoretischen Maximum.

Hinweis 2: Mit unserem Server kann man auch mehrere unserer angebotenen KNX-Interfaces anstecken und mit mehreren Linien verbinden (jedes Interface natürlich nur an jeweils eine Linie). Dies ermöglicht der ETS einen parallelen Download auf mehrere Linien gleichzeitig, was den Durchsatz beim Programmieren deutlich erhöht. Je nach Servermodell lassen sich bis zu drei (3) - beim Timberwolf Server 2600 auch zwölf (12) unserer KNX Interfaces gleichzeitig parallel betreiben.

Beides zusammen, also 16% Durchsatzsteigerung pro Interface und parallele Programmierung auf mehrere Linien gleichzeitig bringt schon eine beträchtliche Verbesserung.

Hinweis 3: Der überarbeitete 64 Bit KNX Stack wird 8.000 Objekte mit 64.000 Assoziationen unterstützen. Ab der Version 2.0 können - je nach Softwareausstattung - bis zu drei (3) solcher Stacks / Applikationen parallel (pro Interface einen Stack) in einem Server betrieben werden. Wobei die Stacks nicht nur auf TP-Interfaces sondern einer davon auch auf KNXnet/IP (Ethernet) gebunden werden kann. Mithin sind dann 24.000 Objekte mit zusammen 192.000 Assoziationen möglich. Zunächst.
Damit man eine solche schiere Anzahl von Objekten auch in hinreichender Zeit programmieren kann, unterstützt unser Stack eine Programmierung per "Direkter Verbindung" über IP. Das bedeutet, dass der Server nicht via IP Tunneling über sein eigenes TP-Interface programmiert wird, sondern mit der deutlich höheren KNXnet/IP Geschwindigkeit. Zudem unterstützt unser Stack auch partielles Programmieren. Alleine die Programmierung via "Direkte Verbindung" ermöglicht einen um den Faktor 5 bis 10 (das hängt auch vom ETS Rechner ab) erhöhten Durchsatz.

Ich erwähne das, weil Du nun mit einer IP-Schnittstelle planst. Es wäre nur - hinsichtlich Performance - ungeschickt, einen Timberwolf Server mit sehr vielen Objekten über eine andere IP-Schnittstelle / USB-Schnittstelle zu programmieren, weil dann insbesondere letzterer Geschwindigkeitsvorteil durch die "Direkte Verbindung" entfällt.

Ich hoffe, ich konnte das Missverständnis durch unsere unglückliche Produktbezeichnung auflösen. Ab der morgigen Katalogausgabe sollten wir die geänderte Produktbezeichnung umgesetzt haben.


Stefan