Ubiquity Unifi Dream Machine Pro als Multicast-Router zwischen KNX IP-Routern

[petertau]

Wenn du deine KNX-Bereiche trennen willst und bestimmte Zentralfunktionen gemeinsam nutzen willst, nutz', dazu die Filtertabellen ("Firewall") der KNX-Linienkoppler, dazu sind sie da.

Mir ist nicht klar, warum es von vornherein vorteilhafter sein soll, KNX-TP-Linienkoppler gegenüber KNX-IP-Routern einzusetzen. Schließlich beinhalten KNX-IP-Router die Linienkopplungsfunktion und bieten ebenfalls Filtertabellen. Wenn man auf KNX-Ebene sauber trennen will, kommt man um Filtertabellen nicht herum, egal ob man die Telegramme über TP oder IP versendet. Für mich ist Linienkopplung mit Filtertabellen über TP und Linienkopplung mit Filtertabellen über IP hinsichtlich der KNX-Abschottung gleichwertig. Oder habe ich da etwas falsch verstanden?

Diese neue Masche, sein Netzwerk zu segmentieren und dann weil's "unkomfortabel" ist wieder die FW zu durchlöchern und broadcasts von Hü nach Hott zu schicken, werde ich nie verstehen.

Ich lerne gerne dazu, wie man eine IP-Separierung von einzelnen Wohneinheiten besser löst als über separate Subnets in VLANs. Von einer Durchlöcherung der Firewall zwischen den VLANs soll jedenfalls keine Rede sein. Die separaten VLANs sollen im Wesentlichen Zugang zum Internet ermöglichen und per Default voneinander abgeschottet sein. Es geht mir nur darum, die aufgrund von KNX-IP-Komponenten erforderliche Schnittstelle zwischen TP und IP möglichst sinnvoll zu implementieren. Jedenfalls liegt auf der Hand, dass pro Wohneinheit ein Übergang zwischen TP und IP geschaffen werden muss.

Meine Quintessenz aus intensiver Forumssuche (nicht nur hier) ist die, dass die Anbindung von IP-basierten KNX-Komponenten immer wieder Probleme bereitet. Manche Komponenten bringt man nur mit Tunneling zum Laufen, andere wieder nur mit Routing. Diese Erfahrungsberichte Dritter haben mich dazu bewogen, eher auf KNX-IP-Router als auf KNX-IP-Interfaces zu setzen, weil mir nur bei KNX-IP-Routern beide Möglichkeiten offenstehen. Oder liege ich mit dieser Annahme falsch?

Heute habe ich vom MDT Support gelernt, dass ein MDT KNX-IP-Router bei Adressvergabe x.y.z mit z ungleich 0 und unterhalb einem TP-Linienkoppler mit Adresse x.y.0 wie ein KNX-IP-Interface reagiert. Es stünde also technisch nichts im Wege, mein Setup auch auf Basis von KNX-IP-Interfaces zu testen.

Bislang scheue ich aber den Aufwand, zumal zwischen den KNX-IP-Routern ohnehin fast nichts übertragen werden muss, da geht es bestenfalls um ein paar Gruppenadressen von der Wetterstation und ähnlichen zentralen Komponenten. Insofern denke ich mir, wenn der KNX-IP-Router schon die Linienkopplung mit sich bringt, warum diese nicht gleich mitnutzen? Das führt mich zu folgendem Zitat:

Solange du mit IGMPv2 hinkommst, kannst du das über den mDNS-Relay der UDMP machen (und natürlich Snooping einschalten). Wenn SSDP und/oder IGMPv3 ins Spiel kommen, bzw. mDNS-Repeater (Sonos..), kann das die UDMP nicht, jedenfalls nicht ohne Zusatzdienste, die man enwteder über einen Proxy bereitstellt oder halt selber Container auf der UDMP dafür installiert. Keine Ahnung, was KNX/IP da erfordert. Ich würde so einen Setup nicht fahren.

Verstehe ich Dich richtig, dass Du davon ausgehst, dass die UDMP die erforderlichen Multicast-Anforderungen nativ nicht hinbekommt? Wenn ja - genau diese Vermutung meinerseits hat mich zu diesem Thema und meiner eingangs gestellten Frage geführt.

[BlackDevil]

Wenn SSDP und/oder IGMPv3 ins Spiel kommen, bzw. mDNS-Repeater (Sonos..), kann das die UDMP nicht, jedenfalls nicht ohne Zusatzdienste, die man enwteder über einen Proxy bereitstellt oder halt selber Container auf der UDMP dafür installiert..

Daher kam das, sorry

[Marino]

Mir ist nicht klar, warum es von vornherein vorteilhafter sein soll, KNX-TP-Linienkoppler gegenüber KNX-IP-Routern einzusetzen.

Echt nicht?

TP: Anschließen, läuft. Egal, was das Netzwerk macht und ob eines Vorhanden ist..
IP: Benötigt eine vorhandene, funktionierende Netzwerkinfrastruktur, die nicht jeder einfach aufbauen und warten kann, wie man öfter liest.

Zudem sind Linienkoppler deutlich günstiger, als IP-Router. Im Falle MDT so 180€ (LK) gegen 240€ (IP-Router).

Das sind nur die naheliegensten Vorteile...

Viele Grüße
Nils

[gbglace]

IP ist per Definition als unsicher zu betrachten. KNX-TP auch, nur hat KNX-TP den Vorteil, wenn Du nicht die passende grüne Leitung in den Fingern hast, dann erfährt da auch der eine Nachbar nichts von dem was der andere so schaltet. Wenn Du die beiden IP-Strippen zusammenhängst dann musst Du direkt recht hohen Aufwand betreiben die Kommunikation zwischen den Bereichen abzusichern aber zugleich spezifischen Datenverkehr durchzulassen. Und dann ist der KNX-Datenverkehr im Medium IP offensichtlich von besonderer Qualität, was die bedingte Durchlässigkeit erschwert.

Allein aus diesem Grund für ein paar so simple Sachen wie die Wetterstation tue ich mir dann doch sowas nicht an, aufwändiges IP-Equipment, unnötig teure KNX-HW.

Deine Argumentation hat nur den Punkt als Vorteil versucht raus zu schälen, das man mit einem KNX-IP-Router auch KNX-Tunneling kann und das Du schon einmal halt fälschlicher Weise Geld ausgegeben hast. Ist immer so ein Ding wenn man was falsch gemacht hat das sich schön zu reden.

Noch konntest Du uns auch noch nicht sagen wo denn gerade der zwingende Bedarf an KNX-IP-Routing liegt im Sinne der KNX-Kommunikation von non-KNX-TP Komponenten die in der Anlage sind. Einfach so auf Verdacht sich sowas reinzubauen, wozu?

Also wenn Dein Sound System, in wie vielen Stück HW? Kein KNX-IP-Routing erfordert. Hau 3 Router weg kaufe 3 LK und eine kleine SpVg und werde glücklich.

Einen solchen Router auf eine PA ungleich 0 zu setzen, um ihn als reine Schnittstelle zu verwenden, ja mei wenn Da kein Bedarf besteht das wer anders die Anlage mal warten kann mach das so.

[petertau]

Noch konntest Du uns auch noch nicht sagen wo denn gerade der zwingende Bedarf an KNX-IP-Routing liegt im Sinne der KNX-Kommunikation von non-KNX-TP Komponenten die in der Anlage sind. Einfach so auf Verdacht sich sowas reinzubauen, wozu?

Es gibt bereits jetzt schon vier KNX-IP-Komponenten in meinem Setup und ich kann mir nicht vorstellen, dass es in Zukunft weniger werden! Beim Testen verschiedener Lösungen habe ich bereits selbst die Erfahrung gemacht, dass manchmal nur IP-Tunneling oder manchmal nur IP-Routing funktioniert. Ich denke da sehr langfristig: Es liegt auf der Hand, dass Komponenten mit großen Nutzdatenbedarf eher auf KNX-IP setzen werden. Beispiel Visualisierung. Wie soll ich Videostreams integrieren, wenn die Visu auf KNX-TP basieren würde? Bislang habe ich Komponenten, die in der Konnektivität zu zickig waren, einfach vermieden. Warum aber gewisse Formen der IP-Konnektivität ausschließen?

Mir erscheint IP-Routing langfristig erfolgsversprechender, wenn es nicht gerade um Bus-Provisionierung geht. IP-Routing sehe ich als Äquivalent zu KNX-Komponenten am TP-Bus. Mit IP-Routing gibt es von vornherein kein hartes Limit, wieviel Teilnehmer am Bus hängen. Beim IP-Tunneling sieht das eben ganz anders aus.

Zitat von petertau Beitrag anzeigen
Mir ist nicht klar, warum es von vornherein vorteilhafter sein soll, KNX-TP-Linienkoppler gegenüber KNX-IP-Routern einzusetzen.



Echt nicht?

Der Sinn meiner Frage erschließt sich im Zusammenhang mit dem ursprünglich gestellten Thema. Wenn man bereits eine IP-Verkabelung zu den Wohneinheiten hat, ist es hardwaremäßig nicht sofort einleuchtend, ein TP-Kabel parallel zum IP-Kabel nachzuziehen und statt einem KNX-IP-Router einen TP-Linienkoppler plus KNX-IP-Interface zu kaufen. Mit dem Nachteil, dass damit kein IP-Routing unterstützt wird.

[petertau]

Es freut mich, dass offenbar alle Teilnehmer hier in dieser Diskussion die Alternative einer TP-basierten Kopplung der Wohneinheiten trotz vorhandener IP-Verkabelung gehen würden. Solch ein Lösung erscheint mir dann zu 100% sachgerecht, wenn hier Linien gekoppelt werden sollen, die ohnehin stark miteinander interagieren. Warum dann einen Medienbruch. Lieber ein einheitliches TP-Netz. Verständlich, nachvollziehbar.

Mein Anwendungsfall ist davon aber abweichend: Aus Gründen der Internetkonnektivität und der Nutzdatenübertragung für VoIP, Sat>IP und einer KNX-IP-Visu besteht ohnehin schon eine IP-Verkabelung in die Wohneinheiten hinein. Für die KNX-Standardfunktionen ist jede Wohneinheit im Grunde autark und braucht nicht zwingend Daten aus anderen Linien. Alles kann auch ohne die anderen Linien KNX-mäßig bedient werden. Ich muss bereits zumindest ein KNX-IP-Interface in jeder Wohneinheit haben, um die KNX-IP-Visu und andere KNX-IP-Teilnehmer einzubinden, und es liegt auf der Hand, dass in Zukunft bei entsprechendem Nutzdatenanfall immer mehr Komponenten KNX-IP benötigen.

Um also noch die fehlenden Wetterdaten und Vergleichbares in die Wohneinheiten zu bringen, widerstrebt es mir, parallel zur vorhandenen IP-Verkabelung noch eine TP-Verkabelung nachzurüsten und anstelle eines einzelnen KNX-IP-Routers einen KNX-TP-Linienkoppler samt KNX-IP-Interface einzusetzen.

Möglicherweise liegt der Grund der allgemein vorgeschlagenen Doppelverkabelung TP und IP in die Wohneinheiten darin, dass

(i) KNX-IP und Multicast ein Marketing-Gag der KNX Association ist, der überhaupt nicht funktioniert und deshalb gemieden werden muss oder dass

(ii) KNX-IP sehr kompliziert ist und keiner der Beitragenden bislang eine Antwort gegeben hat, wie man das hinbekommen könnte.

Klar, Multicast ist kompliziert. Aber genau deshalb frage ich nach, ob jemand Erfahrungen mit Multicast gemacht hat. Ich möchte gerne eine Bewertung vornehmen, um zu einer vernünftigen Entscheidung zu gelangen. Dazu braucht es aber Fakten und keine Meinungen. Nur anhand von Fakten und Erfahrungsberichten kann ich mich weiterbilden und etwas dazulernen.

Im Moment erinnert mich die Diskussion an einen Dialog zwischen einem KNX-Jünger und einem Altelektriker, der einen simplen, direkt mit dem Verbraucher verdrahteten Lichtschalter für viel besser als dieses moderne KNX-(TP)-Gedöns hält, das nie die Zuverlässigkeit des Lichtschalters haben kann.

Ich bin Euch ja dankbar dafür, dass Ihr Euch die Zeit nehmt, über mein Problem nachzudenken. Nach gefühlt 20 Off-Topic-Beiträgen (DiMa ausgenommen) würde ich mich aber dennoch sehr freuen, wenn wir wieder zurück zum Thema Multicast finden!

Wie realisiert man KNX-IP mit Multicast über unterschiedliche Subnetworks?
Was braucht es dafür, um die damit verbundenen Probleme zu lösen?

Fakten, Fakten, keine Meinungen - und TP dürfte klar sein, brauchen wir nicht weiter diskutieren - die Fallback-Lösung für das Vermeiden von Multicast habe ich damit schon... :-)

[DiMa]

Von einer Durchlöcherung der Firewall zwischen den VLANs soll jedenfalls keine Rede sein. Die separaten VLANs sollen im Wesentlichen Zugang zum Internet ermöglichen und per Default voneinander abgeschottet sein. Es geht mir nur darum, die aufgrund von KNX-IP-Komponenten erforderliche Schnittstelle zwischen TP und IP möglichst sinnvoll zu implementieren. Jedenfalls liegt auf der Hand, dass pro Wohneinheit ein Übergang zwischen TP und IP geschaffen werden muss.

Das ist aber gar nicht dein Problem. Was du willst, ist zwischen IP-Netzwerksegmenten bestimmte KNX-Telegramme zu routen. Das ganze noch über KNX-IP-Routing, was zwingend Multicast erfordert und das ist prinzipbedingt schon mal zwischen Netzwerksegmenten suboptimal (eigentlich nicht vorgesehen). Du baust dir also maximale Hürden auf und suchst dann einen Weg, sie einzureißen. Das macht keinen Sinn. M.E. ist deine ganze KNX-Netzwerkplanung broken by design. Du brauchst ein KNX-Netz, in dem du die Wohneinheiten durch separate Linien trennst. Gemeinsame GA werden dann über die Filtertabellen durchgelassen. Wenn du das aus irgendwelchen Gründen unbedingt mit KNX-IP-Routern statt LK machen willst, dann gehören alle KNX-IP-Router in ein eigenes Subnetz. Damit hast du dann keine deiner Probleme.

Dein Ansatz, alles in ein Subnetz pro Wohneinheit zu packen ist falsch, da KNX-IP-Routing eben nicht wie IP-Routing funktioniert! Ich weiss nicht, ob da einfach nur der Name "Router" für die KNX-IP-Router für dich irreführend ist - aber der routet nur zwischen KNX-Linien, mit L3-Routing was die UDM & Co. macht hat das nichts zu tun.

Jedenfalls liegt auf der Hand, dass pro Wohneinheit ein Übergang zwischen TP und IP geschaffen werden muss.

Das brauchst du aber nur für den Zugriff z.B. für eine Visu und das geht auch mit Tunneling. Das lässt sich auch von einem L3-Switch/Router routen. KNX-IP-Routing ist ein eigenes Protokoll, das ist nix was über TCP/UDP getunnelt wird. Deshalb heißt das andere Protokoll ja auch tunneling...

Meine Quintessenz aus intensiver Forumssuche (nicht nur hier) ist die, dass die Anbindung von IP-basierten KNX-Komponenten immer wieder Probleme bereitet.

Nö. Probleme bereitet i.d.R. das reziproke Verhältnis von gewünschter Netzwerkomplexität und den zugehörigen Kompetenzen.

Manche Komponenten bringt man nur mit Tunneling zum Laufen, andere wieder nur mit Routing.

Mit Ausnahme des Gira HS (erfordert zwingend KNX-IP-Routing) stimmt das nicht. Tatsächlich braucht man mit Ausnahme des eigentlichen Anwendungsfalls Medienübergang TP-Ethernet (für große Strecken) praktisch nie einen KNX-IP-Router.

Heute habe ich vom MDT Support gelernt, dass ein MDT KNX-IP-Router bei Adressvergabe x.y.z mit z ungleich 0 und unterhalb einem TP-Linienkoppler mit Adresse x.y.0 wie ein KNX-IP-Interface reagiert.

Das ist immer so bei einem KNX-IP-Router, da dieser zwingend eine x.x.0 PA braucht. Wenn er eine andere PA hat, kann er nicht KNX-IP-Routen. Weil er keine eigene Bereichslinie begründen würde.

Es stünde also technisch nichts im Wege, mein Setup auch auf Basis von KNX-IP-Interfaces zu testen.

Du kannst die Komponenten so einsetzen. Dein Setup ist dann ein völlig anderes. Siehe oben.

Verstehe ich Dich richtig, dass Du davon ausgehst, dass die UDMP die erforderlichen Multicast-Anforderungen nativ nicht hinbekommt?

Wenn KNXnet/IP SSDP braucht: Geht nicht "nativ" (=da kannst du nichts anklicken). Ob das so ist recherchiere ich nicht für dich - wie gesagt: Diese Netzwerkarchitektur von dir wäre m.E. broken by design. Wenn mDNS-Relay reicht, geht's vmtl. "nativ", wäre aber immer noch keine gute Idee.

Wenn ja - genau diese Vermutung meinerseits hat mich zu diesem Thema und meiner eingangs gestellten Frage geführt.

Ja, du scheinst hier wirklich konzentriert mitzulesen. Bevor du dann die nächste Überraschung erlebst: Modbus und CAN kann die UDM übrigens auch nicht Routen. Auch nicht mit entsprechenden IP-Gateways...

Wie soll ich Videostreams integrieren, wenn die Visu auf KNX-TP basieren würde?

Wenn du glaubst, dass die Videostreams (oder irgendeine Visu) über KNX übertragen werden, hast du aber bis jetzt nicht so wirklich verstanden, wie diese Lösungen funktionieren. Oder mal die technischen Handbücher von solchen Komponenten gelesen...

Mir erscheint IP-Routing langfristig erfolgsversprechender, wenn es nicht gerade um Bus-Provisionierung geht.

Das ist dein Eindruck nach dem Feedback, welches du hier bekommst und deiner Feststellung, dass das alles nicht so funktioniert (funktionieren kann) wie du dir das vorstellst? 😮

Was ist "Bus-Provisionierung"?

Mit IP-Routing gibt es von vornherein kein hartes Limit, wieviel Teilnehmer am Bus hängen.

Herr im Himmel, lies' mal ein Handbuch! Wieviele TN am Bus hängen hat überhaupt nichts mit KNX-IP-Routing oder Tunneling zu tun, sondern einzig und allein was mit der SV (na gut, ggf. noch mit LK/LV). Du mischst gerade auch noch munter LAN und KNX. Das sind nicht mal die gleichen Medien! Du bindest keine KNX-Geräte über IP an, sondern über das grüne Kabel (oder von mir aus auch RF). Du kannst mit KNXnet/IP Liniensegmente und/oder Bereiche statt mit grünen Kabel über Ethernet koppeln. Ein KNX-IP-Router ersetzt dann den LK und führt einen Medienübergang KNX-IP und auf der anderen Seite umgekehrt durch. Die KNX-Geräte werden weiterhin über KNX-Kabel angeschlossen.

Die Anzahl der über IP auf den Bus zugreifenden nicht-KNX-Geräte ist bei KNX-IP-Interfaces limitiert, typischerweise auf 1-7 Tunnel pro Interface. Das hat nichts mit der Anzahl der Busteilnehmer zu tun. Bei Verwendung des KNXnet/IP ("KNX-IP-Router") Protokolls statt TCP/UDP ("KNX-IP-Interface") ist die Anzahl der über IP auf den Bus zugreifenden nicht-KNX-Geräte nur durch die Badnbreite von LAN und KNX-IP-Router limitiert.

Vielleicht sollte man für Leute wie dich KNX-IP-Router besser TP-Ethernet-LK nennen...

Wenn man bereits eine IP-Verkabelung zu den Wohneinheiten hat, ist es hardwaremäßig nicht sofort einleuchtend, ein TP-Kabel parallel zum IP-Kabel nachzuziehen und statt einem KNX-IP-Router einen TP-Linienkoppler plus KNX-IP-Interface zu kaufen.

Stimmt. Dafür koppelt man dann die Bereiche via Ethernet mittels KNX-IP-Router. Aber man packt die dann nicht in unterschiedliche Netzwerksegmente, weil man meint, iptables funktioniert auch für KNX!

(i) KNX-IP und Multicast ein Marketing-Gag der KNX Association ist, der überhaupt nicht funktioniert und deshalb gemieden werden muss oder dass

(ii) KNX-IP sehr kompliziert ist und keiner der Beitragenden bislang eine Antwort gegeben hat, wie man das hinbekommen könnte.

(iii) Du verstehst nicht mal im Ansatz die Technik und versuchst auch nicht zu verstehen, was dir hier erklärt wird. Es macht echt keinen Spaß. Ich bin 'raus.

[ppent]

Auch wenn Sonos irgendwo nur als Beispiel genannt wurde, vielleicht kannst du die selbe Lösung auch für dich verwenden:
http://kuhl-consulting.com/2020/11/2...m-machine-pro/
https://community.ui.com/questions/D...e-0b780290ea68

Sprich, auf einem externen System ein Multicast-Relay aufsetzen?

[gbglace]

Beispiel Visualisierung. Wie soll ich Videostreams integrieren, wenn die Visu auf KNX-TP basieren würde?

Seit wann ist ein Videobild KNX? Das hat doch überhaupt gar nichts mit KNX-IP oder KNX-TP zu tun, das hat mit gar nichts KNX zu tun.

Eine Visu wird immer einen IP-LAN Anschluss haben, weil das Ding ja meist ne Webseite ins LAN / Internet via VPN verteilt. Wie dann der Visu-Server mit dem KNX im Hintergrund eine Verbindung aufbaut ist dann eine ganz andere Frage und da kenne ich keine die nur per IP-Routing funktionieren. Und wie das Ding an Deine Webcam kommt um das Bild zu integrieren hat ja nichts mit KNX zu tun.

@ Dima ist aber schön das Du das nochmal mit mehr Fachverstand zum Thema-Netzwerk erklärst.

Ich hatte hier auch schon was langes runter getippt aber das hätte der TE ja nicht hören wollen.

Von daher nun mal noch ein paar Ergänzungen gekürzt.

Ich denke da sehr langfristig: Es liegt auf der Hand, dass Komponenten mit großen Nutzdatenbedarf eher auf KNX-IP setzen werden.

Was soll denn im Bereich Lichtschalter an/aus Rollo hoch /runter ein hoher Nutzdatenbedarf sein? Schau Dir doch mal die Mengenverhältnisse der Datentypen in deinen GA an, was da so üblich an Datenmengen transportiert wird. Die 14 byte Nachrichten auf dem Tasterdisplay sind da schon das deutlich obere Ende der Fahnenstange. Was erwartest Du denn da noch? Und selbst wenn der KNX-Standard da mal komplett aufgebohrt wird und dann IP-only Datentypen für diese Bandbreite kommen sollte, gehe ich mal nicht davon aus, dass das dann ein heute verfügbarer IP-Router per Firmwareupgrade lernen wird können. Und selbst wenn dann kommt das definitiv nicht ins TP-Medium kann also eigentlich auch non-KNX bleiben, kann also auch MQTT oder so sein.

Insofern vollkommen irrelevant der Gedanke.

Einen KNX-IP-Backbone nutzt man in Installationen wo erheblicher Datentransfer nicht nur innerhalb einer TP-Linie sondern auch noch über mehrere Linien untereinander stattfindet und dann die übergeordneten Hauptlinien oder gar die Bereichslinie im Medium TP vollkommen überlastet wären. Da Du aber ja explizit recht abgeschlossene Wohneinheiten hast wird der übergreifende Datentransfer da sehr überschaubar bleiben. (Flurlichter / Wetterstation usw.)

Und im Bereich IP langfristig in HW vorzuplanen ist absurd. Die Anforderungen sind so schnelllebig, das man da heute immer gezwungen ist den teuersten Krams zu verbauen nur um dann in 5 Jahren mal eine dann Standard-Funktion zu integrieren wo man dann die notwendige HW für nen Bruchteil leicht nachrüsten könnte. Da bin ich komplett weg davon IT-HW jetzt auf Vorrat für undefinierte inhaltliche Anforderungen zu kaufen.

Wenn man bereits eine IP-Verkabelung zu den Wohneinheiten hat, ist es hardwaremäßig nicht sofort einleuchtend,

Doch weil das eine funktioniert das andere eben nicht, wenn es auf dem LAN den falschen LAN-Router gibt und man keine Ahnung hat wie man ein Netzwerk passend konfiguriert.

Es geht doch nicht darum ich habe schon die Sorte CU in der Wand jetzt muss das auch alles darüber laufen egal wie sinnlos das ist. Kann man machen dann muss man aber da in ggf andere noch teurere HW aber zumindest in viel Wissen investieren.

Ich muss bereits zumindest ein KNX-IP-Interface in jeder Wohneinheit haben, um die KNX-IP-Visu und andere KNX-IP-Teilnehmer einzubinden

Nicht müssen nur können, weil es ggf. die Visu vereinfacht. die könnte auch auf einer übergeordneten Instanz liegen und nur einen Tunnel in die ganze Anlage für alle 4 Wohneinheiten sein. Kommt aber eben auf die Konstruktion der Visu an. Und welche IP-KNX Komponenten sollen es denn sein? Und wenn es die dann gibt haben die sicher alle die gleichen Probleme mit dem Multicast.

(i) KNX-IP und Multicast ein Marketing-Gag der KNX Association ist, der überhaupt nicht funktioniert und deshalb gemieden werden muss oder dass

(ii) KNX-IP sehr kompliziert ist und keiner der Beitragenden bislang eine Antwort gegeben hat, wie man das hinbekommen könnte.

weder noch

IP selbst ist das Problem nicht der KNX dadrinnen. IP segmentieren und die Segmente voneinander abschotten ist halt das Gegenteil zu ich rufe wo rein und alle hören es und jeder kann potentiell antworten. Und das ist aber das was KNX ist. Die bisherige KNX-Protokollogik, so gut sie ist, passt offensichtlich nicht mehr in die aktuelle IP-Welt, zumindest wenn das ganze in segmentierten geschotteten Netzwerken funktionieren soll und dann aber doch darüber ein Datenaustausch erfolgen soll.

Und weil eben IP so dermaßen unsicher ist, ist es nachvollziehbar dass das in Zukunft nicht leichter werden wird Multicast da durchzubringen. Denn alles was Du jetzt baust kann mit dem nächsten Update irgendeiner Netzwerkkomponente schon wieder dahin sein (siehe das Erlebnis von Lars im anderen Thread). Insofern die klare Empfehlung KNX ja aber so wenig wie möglich Kommunikation des KNX selbst auf dem Medium IP. Macht das leben einfach leichter und ist am Ende stabiler wenn man denn so langfristig wie Du da planen will.


Also bau ein VLAN für die Haustechnik und dann könnte das klappen.

[skami]

Nö. Probleme bereitet i.d.R. das reziproke Verhältnis von gewünschter Netzwerkomplexität und den zugehörigen Kompetenzen.

Bester Satz den ich in den letzten Jahren hier gelesen hab : )

[petertau]

Vielen Dank für Eure Lösungsvorschläge zu dem geschilderten Problem, wie Wohneinheiten mit separaten Linien geeignet gekoppelt werden können, um einerseits die gewünschte Integration von IP-Komponenten zu ermöglichen und andererseits Daten von Zentralfunktionen zu empfangen, ohne dass dadurch scheunentorartig alles geöffnet werden muss.

Die Anforderungen in meinem Projekt sind sehr komplex. Nachdem ich von einem Forum definitiv nicht erwarte, dass sich jemand mit einer ellenlangen Anforderungsspezifikation beschäftigt, weist meine zwangsläufig verkürzte Problembeschreibung immer wieder Lücken auf, die leicht zu unzutreffenden Annahmen und dadurch zu Lösungsvorschlägen führen, die mir dennoch nicht gut helfen, weil dadurch etwas anderes herunterfällt. Meine daraus resultierende Zurückhaltung zu den diskutierten Lösungen hat manchen von Euch nicht gefallen:

Insofern vollkommen irrelevant der Gedanke.

Ich hatte hier auch schon was langes runter getippt aber das hätte der TE ja nicht hören wollen.

Dein Ansatz, alles in ein Subnetz pro Wohneinheit zu packen ist falsch, da KNX-IP-Routing eben nicht wie IP-Routing funktioniert!

Die von gbglace und DiMa abgegebenen Klarstellungen sind im Wesentlichen das Ergebnis, dass meine Formulierungen nicht in der Weise verstanden wurden, wie ich das beabsichtigt habe. An Euch beide zur Beruhigung: Keine einzige Eurer Klarstellungen war für mich neu. Ich nehme aber mit, dass ich genauer auf meine Formulierungen achte.

Dass ich gewisse Lösungsvorschläge in Frage stelle, hat also nicht mit einem hartnäckig lernresistenten oder völlig KNX-unerfahrenen TE zutun, sondern mit einer Fülle von Anforderungen, die in Summe noch nicht aufgehen, wenn ich der jeweiligen Lösung folge.

Die Anforderung einer sauberen Separierung der Wohneinheiten ist unter Berücksichtigung aller Randbedingungen in der Tat eine harte Nuss, weil die IP- und KNX-Teilsysteme zu gegenläufigen Lösungen führen. Ich muss aber beide Seiten sinnvoll unter einen Hut bekommen.

Die Diskussion darüber hat sich gelohnt, da ich die eingangs vorgestellte Lösung eines Multicast Relaying verwerfen kann.

Aus IP-Sicht sollen die Wohneinheiten in separaten Subnetzen liegen. Das gilt auch für die KNX-IP-Komponenten. Wenn sich jemand an den KNX-IP-Komponenten in den Wohneinheiten zu schaffen macht und den Datenverkehr am zugehörigen Netzwerkkabel abhört, sollen einfach keine anderen Daten als die der Wohneinheit abgreifbar sein. Gemeinsames Haustechnik-Netz scheidet aus. Diese Anforderung hat Priorität.

Ferner ist es so, dass hier sehr stark auf KNX-IP-Komponenten gesetzt wird. In einer größeren Wohneinheit gibt es beispielsweise gleich 9 Touchpads, die IP-mäßig an die KNX-TP-Linie der Wohneinheit angeschlossen werden müssen. Wir werden hier keinen Mischbetrieb fahren, und in einer Wohneinheit Touchpads über IP-Tunneling anbinden, weil sich das stückmäßig halbwegs mit den verfügnbaren Tunneln ausgeht und in einer anderen Wohneinheit über IP-Routing, weil es einfach zu viele sind. Wenn heute IP-Routing und IP-Tunneling unterstützt wird und die Zahl der anzubindenden KNX-IP-Komponenten laufend steigt, kann ich nicht sehenden Auges IP-Routing für das Integrieren von KNX-IP-Komponenten ausschließen. Der Trend IP-Routing zeichnet sich ab. Von dem her ist für mich klar, dass die Anbindung von KNX-IP-Komponenten über KNX-IP-Router mehr Flexibiität für die Zukunft bietet, da ich damit IP-Routing neben dem ohnehin unterstützten IP-Tunneling ermögliche.

Wir haben also bereits KNX-IP-Router pro Wohneinheit, über die nur IP-Datenverkehr betreffend die jeweilige Wohnung läuft. Diese bleiben in ihren separaten Subnetzen. OpenHAB kann die separaten KNX-IP-Router ohnehin gezielt bedienen, kein Nachteil. Eine zusätzliche Kopplung aller Linien auf TP-Basis geht dadurch nicht mehr, ist aber aus Administrationssicht nicht notwendig.

Was dadurch noch als offenes Problem verbleibt, ist das gezielte Einbringen von Zentraldaten in die Linien. Gibt es dafür Ideen, wie man das machen kann? Grundsätzlich würde es mir reichen, wenn ich Gruppendressen mit den erforderlichen DPTs in der Linie zum Beschreiben hätte. Also eine KNX-Komponente, die nichts anderes als mehrere KO zum Lesen und Schreiben mit einstellbarem DPT bereitstellt, ohne sonst groß etwas zu tun. OpenHAB könnte entsprechende GroupValueWrite senden, und die jeweiligen Komponenten in der Linie der Wohneinheit können mit diesen Gruppenadressen arbeiten.

[gbglace]

gleich 9 Touchpads, die IP-mäßig an die KNX-TP-Linie der Wohneinheit angeschlossen werden müssen.

Welche sollen das denn sein?

Wenn die nativ KNX-sind dann haben die eine ETS Applikation, da fällt mir derzeit so nur das Gira-G1 ein (aber da ich nach sowas nicht suche kann gut sein das da noch mehr existiert) und das ja muss dann an einer IP-Linie hängen. Alle anderen Lösungen sind mehr oder weniger stupide Touchmonitore die eine Webseite abspielen (so kann man auch einen G1 betreiben als Client hinter dem X1). Und da nutzt dann der Webserver genau einen Tunnel und die Pads sprechen gar kein KNX. Andere Lösung sind PEAKNX Panels die haben haben aber eine TP-Schnittstelle und sind schon mehr als nur ein Touchmonitor.

Wenn heute IP-Routing und IP-Tunneling unterstützt wird und die Zahl der anzubindenden KNX-IP-Komponenten laufend steigt, kann ich nicht sehenden Auges IP-Routing für das Integrieren von KNX-IP-Komponenten ausschließen. Der Trend IP-Routing zeichnet sich ab.

Und nochmal die Frage welche IP-KNX-Komponenten siehst Du denn da kommen? Welchen Trend verpasse ich hier gerade?

Hast Du da eine OH Instanz oder 4?

[MUCKNXer]

Wie realisiert man KNX-IP mit Multicast über unterschiedliche Subnetworks?
Was braucht es dafür, um die damit verbundenen Probleme zu lösen?

petertau schau' Dir mal bitte https://github.com/boostchicken-dev/...ulticast-relay an. Damit kannst Du ein multicast relay direkt auf der UDM Pro in einem Container laufen lassen. https://github.com/alsmith/multicast-relay

Die Abwägung, welche Lösung in Deinem Fall eine gute ist, liegt ja immer bei Dir

[Tachy]

Hallo zusammen,

ich bin heute fast wahnsinnig geworden bei der Suche nach einem Fehler, den ich zuerst nicht zuordnen konnte.

Bis heute bestand mein Netz aus einer dreammachine pro, einer Fritzbox als DECT-Basisstation und einem Homeserver.

heute kam ich auf die glorreiche Idee, die Fritzbox rauszuwerfen und durch einen simple Snom M300 Basisstation zu ersetzen.

Dann funktionierte "auf einmal" der Homeserver nicht mehr. Warum? Weil die Fritzbox ungeachtet der Dreammachine still und leise das Multicast-Routing übernommen hatte - früher agierte diese Fritzbox als primärer Router, bis die Dreammachine kam.

Das Problem war also, dass das Multicast auf einmal fehlte und ich den Fehler beim Homeserver suchte. Sobald ich die Fritzbox anklemme, funktioniert auf einmal alles wieder.

Leider habe ich die Einstellung bei der Dreammachine noch nicht gefunden. Die Fritzbox hängt so lange als "Dummy" im Netz.

Sorry für das Chaos, aber beim Posten und editieren kommt hier andauernd ein Datenbankfehler.

[Tachy]

doppelt