KNX/EIB 2 EIB/KNX Netze verbinden über WLAN oder Funk?

[viceversa]

Wir hatten das Thema schon mal, aber ich kann es leider nicht mehr finden. Wie ist es möglich, 2 unabhängig voneinander arbeitende, räumlich getrenne EIB-Installationen miteinander zu verbinden? In beiden Installationen gibt es eine ABB RS232-Schnittstelle EA/S 232.5 , die der Programmierung der Anlagen dient.
Ich habe noch 2 Funkmodems rumliegen, also Modems die eine RS232-Schnittstelle z.B. über Freenet-Frequenzen übertragen können. Ist sowas denkbar?
Welche Möglichkeiten gäbe es über WLAN? Welche Schnittstellen KNX / Ethernet könnten hierfür verwendet werden? Hat jemand von euch schon mal sowas realisiert?

Danke!

[GLT]

Wie ist es möglich, 2 unabhängig voneinander arbeitende, räumlich getrenne EIB-Installationen miteinander zu verbinden?

Stellt sich die Frage für welchen Zweck - willst Du Weltenkopplung betreiben, gemeinsame Visu oder zum Programmieren?
Welche Voraussetzungen/Gegebenheiten gibt es an den Standorten bzw. zueinander?
Gibt es evtl. schon Netzwerkverbindungen untereinander?

Einfachste Lösung wären IP-Router in Verbindung mit vorhandener Standortvernetzung oder VPN-Router-Verbindung/DSL; danach die Varianten mit ISDN, Analogtel., Funk.

[vento66]

Oder wenns etwas teurer sein darf, auch mit LWL

[viceversa]

Es geht darum, die "zweite" EIB Installation auf der vorhandenen Installation zu visualisieren. Es gibt kein Kabel. Von der Reichweite dürfte WLAN machbar sein, oder natürlich auch Funk über die vorhandenen RS232-Modems.

[makki]

wenns nur um die Visu geht, ein eibd an einem entfernten Ende (oder beiden) sollte es tun, solange die Adressen nicht kollidieren.

Makki

P.S.: Funk ist IMHO immer eine Gülle-Notlösung, zwei DSL-Flatrates und ein VPN-Router könnten das evtl. besser lösen auch wenn die Packerl dann ggfs. 1000km weiter reisen müssten

[PeterPan]

Hoi..

gehen wir mal systematisch vor:

Frage 1: WLAN: Was verstehst Du unter "nicht weit entfernt" und
Frage 2: Um welche Art von Gebäude/Projekte handelt es sich (Einfamilienhaus oder Privatbank)

Und ja, so ein Projekt haben wir schon einmal realisiert: Mobile Hafenkräne via WLAN-Client an Hafengebäude via WLAN-Acces-Point (Simatic SCALANCE-Produkte) und zwei KNX/IP-Router N146. Wetterfest, Roamingfähig und Unterbrechungsfrei. Heute würde ich Xirrus "Ufos" empfehlen: 4 bis 16 integrierte Access-Points, riesige Abdeckung, optionales wetterfestes Gehäuse, Controller und Firewall integriert, Roaming, PoE (Power over Ethernet).

Gruss Peter

PS: Funk ist wie Multimedia ein weit gefasster Ausdruck. Professionelle WiFi-Lösungen finden schon länger ihren Einsatzbereich in Krankenhäusern, Schulen, Universitäten, Kommunalen Einrichtungen, Flughäfen, Bahnhöfen, Einkaufszentren und in der industriellen Fertigungssteuerung.

[viceversa]

Danke für die Antworten:

zu Frage 1: etwa 500m Luftlinie, schwach bebaut, keine direkte Sichtverbindung.

zu Frage 2: eher eine Gartenlaube als ein Eigenheim. Dennoch kann hier durchaus professionelle Technik zum Einsatz kommen.

Welche Komponenten bräuchte ich? Wenn ich es richtig verstanden habe 2 Stück N146 und dazwischen eine WLAN-Infrastruktur. Richtig?

Zum Funk: ich hatte folgende Idee. Auf beiden Seiten ist die genannte RS232-Schnittstelle installiert und wenn ich die Schaltschränke anschaue, sehe ich auf 2 RS232-Buchsen. In meinen Händen halte ich 2 professionelle Datenfunkmodems von Satel, die eine RS232 Schnittstelle locker auf diese Entfernung durch die Luft übertragen können, auf einer konventionellen Analogfrequenz im 2m-Band. (Frequenz programmierbar)

Sowas: SATEL Oy - Radio Modems

Die Investitionskosten in diesem Fall wären also fast Null. (Obwohl der Kostenfaktor keine Priorität hat) Mir drängen sich bei dieser Lösung jedoch folgende Fragen auf:

Kommt an der der RS232-KNX-Schnittstelle alles an, was auf dem Bus passiert, oder dienen diese Schnittstellen nur zum Programmieren des KNX?

Die entscheidende Frage: Könnten die Schnittstellen überhaupt miteinander kommunizieren wenn sie beispielsweise über ein Kabel miteinander verbunden wären??? Wenn ja,

Was ist mit dem Timing? Bei dieser Funkübertragung vergeht Zeit bis zum Auftasten des Senders im Funkmodem usw. Ist das kritisch für die Kommunikation der RS232 Schnittstellen untereinander?

[PeterPan]

Hoi Kollege..

Über die Programmierschnittstellen geht es definitiv nicht.

500 Meter ohne direkte Sichtverbindung sieht auch nicht gut aus.

Ohne Ausmessen vor Ort sehe ich keine Möglichkeiten für WLAN oder Richtfunk.

Gruss Peter

[mkoegler]

wenns nur um die Visu geht, ein eibd an einem entfernten Ende (oder beiden) sollte es tun, solange die Adressen nicht kollidieren.

Über EIBnet/IP Routing vom EIBD EIBnet/IP Server sollte auch eine Kopplung möglich sein. Damit sollte man ein Art Bridge für alle Gruppenaddressen aufbauen können. Jeder der 2 EIBDs kann über ein beliebiges, unterstützes Interface auf den Bus zugreifen. Ist mit 2 Rechnern einfach auszuprobieren.

PS:
Ich würde extrem auf die Netzwerk Security schauen. Sobald man im IP Netzwerk ist (dh. auf einen EIBnet/IP Server zugreifen kann), hat man TOTALE Kontrolle über das EIB Netzwerk dahinter.

[Andreas2006]

zu WLAN:

Ich betreibe privat eine W-LAN-Strecke (ohne KNX-Kopplung) mit einer Entfernung von 388 m. Da ist eine Baumkrone halb dazwischen, sonst Sicht und 1,5 m über dem First der dazwischenliegenden Häuser. Ich verwende 2,4 GHz und Richtantennen mit Routergehäuse auf den Antennenmasten der beiden Häuser.

Die Berechnungen der Strecke im Vorfeld haben eine "wacklige" Strecke vorhergesagt, aber die Tests verliefen recht positiv.

Nach der Installtion im Sommer 2008 lief das wirklich super. Im Sommer 2009 war das nicht mehr so unproblamtisch: Es gibt jetzt deutlich mehr WLANs in dem Wohngebiet und ich glaube auch, dass der Baum gewachsen ist. Nunja, ich habe noch keine 100%ige Ursachenforschung betrieben und werde im Herbst die Anlage komplett durchchecken müssen. Ich hoffe mal, das die Qualität der Verbindung dann wieder zunimmt. Ansonsten: Ist ja nur privat, dann überlege ich mir was anderes.


Das Summary meiner Erfahrung: WLAN für "geschäftskritische Anwendungen" geht, wenn die Vorraussetzungen samt Ausstattung stimmt.

WLAN-Funkstrecken ohne direkte Sichtverbindung und Außenantennen bei der Entfernung von 400 m werte ich als unischer und damit als nicht geeignet, um eine Anwendung stabil verfügbar zu machen.

Praxis: Erste Hinweise auf die Qualität ergibt die Berechnung der Signalstärke auf der Strecke und nachfolgend ein Feldversuch am Bauort.

Schöne Grüße,
Andreas W.

[makki]

Fehlende Sichtverbindung ist ganz schlecht aber evtl. möglich könnte es sein - mit dem richtigen Eqipment. Das kann man aber nur vor Ort beurteilen (oder eben ausprobieren) ..
Ich würde eher Richtung 5GHz gehen und mir auf jeden Fall was überlegen, die Wlan-Verbindung für den EIB mit TCP zu "überbrücken" (wiederum: eibd, socat-Tunnel, whatever) weil dem KNX IP-seitig jegliche Sicherungsschicht fehlt (UDP) und bei so nem Wlan nach meiner Erfahrung immer Paketverluste auftreten..

Makki

[PeterPan]

Hoi Makki..

Nur mal so nebenbei...

ich weiss ja nicht was Du bezweckst, aber nun schon die zweite negative Aussage über KNX und WIFI. Nochmals; wenn WIFI in der industriellen Automatisierung und in prof. KNX-Grossprojekten eingesetzt wird, sind die Anforderung in jedem Fall für private Anwendungen im Bereich KNX geeignet.

Speziell um mal "einfach" so wie hier in diesem Beispiel ein "Gartenhäuschen" anzubinden. "Verlorene Pakete"? Was stellst Du Dir darunter vor? Aber eine Diskussion darüber "Wie hoch ist die Wahrscheinlichkeit im Fall xyz, dass Datenpakete bei UDP bei den Rahmenbedingungen (unbekannt) im Grenzfall?" sprengt den Rahmen dieses Threads. Und ist in meinen Augen auch unrelevant. (Weil es sich um ein Gartenhäuschen handelt und mir nicht einleuchtet, was verlorene Pakete da zu suchen haben).

Aber das Wichtigste für mich: Keep it Simple! Kommt von der Vorstellung weg, dass jeder Anfragende ein Technik-Freak sein muss! Bewerft die Leute nicht mit Abkürzungen, Fachkauderwelsch, Worthülsen und Anglizismen! Anforderung abfragen, Rahmenbedingungen eingrenzen, Lösung vorschlagen, Umsetzungsvorschlag unterbreiten. Und das mit einfachen unkomplizierten nachvollziehbaren Produkten und Systemen.

wie einleitend erwähnt "Nur mal so nebenbei".. als Anmerkung.. nix für ungut und
Greez Peter

[Chris M.]

Zum Thema Richtfunk: Da muss man sehr aufpassen, wenn man nicht genau weis, was man macht, überschreitet man ganz leicht die erlaubten Grenzwerte!

Von einem normalen WLAN-Router die (Rundum-)Antenne abschrauben und durch eine Richtantenne zu ersetzen wird sehr schnell illegal - da muss die Sendeleistung oft noch deutlich runtergesetzt werden.

Da die Datenraten ja nicht extrem sein müssen, wäre ggf. Packet Radio über CB-Funkt noch eine Möglichkeit...

Und mit kompakterer Technik fällt mir das normale Handy-Netz ein. Mit Festnetz-Flatrate oder Volumen-Basierter Abrechnung ist das heutzutage durchaus finanziell attraktiv (und da ist's egal ob's 500 Meter oder die eigene Berghütte ist...)

[makki]

ich weiss ja nicht was Du bezweckst, aber nun schon die zweite negative Aussage über KNX und WIFI.

Ich bezwecke bisher nur Aufklärung, für konkrete Lösungsvorschläge reichen die Eckdaten nicht..

Nun, das hat zwei Gründe:
1. gibt es in jedem Wlan, und sei es noch so perfekt per se eben Paketverluste.
Die bewegen sich im Rahmen von sagen wir mal mindestens 0,1%, für normale Applikationen ist das natürlich vernachlässigbar.
2. basiert KNXnet/IP Routing aber auf UDP und es existieren erstmal keine höherliegenden Sicherungsschichten, die sich z.B. um Wiederholungen bei Paketverlusten auf dem Medium kümmern. (man korrigiere mich gerne..)

Das bedeutet im Klartext, zurück zum EIB, dass dabei *bestenfalls* 1 von 1000 Telegrammen schlicht nicht ankommen - bei wirklich optimistisch angenommen 0,1% in einer "perfekten Installation" & bei Sonnenschein.
Hier, mit vermutlich nicht ganz perfekten Bedingugen dürften wir eher von 1-5% sprechen, also wenn einem das nicht egal ist, ob hin und wieder mal ein Telegramm auf der anderen Seite fehlt, reichen Wlan-AP + 2x KNX-IP-Router aus dem Regal halt nicht.

Wenn man das alles eh schon weiss und berücksichtigt, gut, Haken dran.


Ich halte das aber für ein Problem, worüber man sich deutlich im klaren sein sollte, weil wenn jenes Telegramm grade den Sprinkler ausschalten oder die Tür verriegeln sollte, ist das blöd (auch das kann man natürlich zusätzlich mit Logik, Statusobjekten usw. absichern, aber das ist eben nichts "aus der Box" mit einstecken und gut ists).

Nochmals; wenn WIFI in der industriellen Automatisierung und in prof. KNX-Grossprojekten eingesetzt wird, sind die Anforderung in jedem Fall für private Anwendungen im Bereich KNX.

Wir sprechen über Wlan nach IEEE-802.11a/b/g/n ?
Ich kenne mich in industrieller Automatisierrung kaum aus, dort wird man aber auch kaum UDP-Pakete übers Wlan blasen und hoffen dass sie schon ankommen werden, eine zusätzliche wie auch immer geartete Sicherungsschicht auf übergelagertem Protokoll oder Applikationseben die ggfs. eine erneute Übertragung veranlasst wird da vermutlich auch obligatorisch sein.

"Verlorene Pakete"? Was stellst Du Dir darunter vor?

Naja, darunter stelle ich mir gesendete Pakete vor die nicht dort ankommen wo sie hinsollten In diesem Kontext vor allem solche bei denen der Empfänger nicht weiss, ob sie abgesendet wurden und der Absender nicht weiss ob oder wo sie angekommen sind (*merken könnte es der Empfänger schon aber das hilft ja auch nichts). KNXnet/IP Routing eben.

Vorschlag: nehme eine Wlan-Verbindung Deiner Wahl und mache "ping a.b.c.d -t", drücke nach 4h Strg+Pause. Wenn da gesendet=empfangen dann steckt sicher noch das Ethernetkabel im Notebook
ICMP (ping) verhält sich hierbei exakt wie UDP, weg ist weg. Der Unterschied ist: man sieht es wenigstens im Nachhinein.
(Nein, ich messe und teste Netzwerke nicht nur mit ping aber das ist am einfachsten; ganzes Ausmass kann man ermitteln, wenn man mit iperf die Bandbreite simuliert)

Wenn das bei KNX-Grossprojekten so gehandhabt wird, toleriert man halt dass das ein oder andere Telegramm - im Regelbetrieb wohlgemerkt - verloren geht.
Fände ich komisch aber kann sein, meinen Anforderungen würde das nicht genügen, weil ich dann gleich nen FS20-Schalter hinmachen kann. Das wäre dann wirklich KISS

Finally, nur so nebenbei Das Thema "madige" Verbindungen wie Wlan/WAN sind AFAIK im KNXnet/IP-Standard halt - ebenso wie jedwede Authentisierung o.ä. - weder nachhaltig berücksichtigt noch speziell erwähnt. Leider.
Dass die Industrie hier keine Lösung anbietet, z.B. eine (wie auch immer geartete) Verbindungsvariante für IP-Router über unzuverlässige Medien und daher IMHO "basteln" notwendig ist, dafür kann ich nichts

Das dieses Thema im Standard keine Rolle spielt und in der Praxis vielleicht auch gerne so praktiziert wird ändert aber nichts an dessen Existenz. Dem Netzwerkmenschen mit dem Anspruch an eine HA auf die man sich auch wirklich 100,1% verlassen kann grummelts da halt im Magen.. Sonst wäre ich wohl im FS20 Forum..

Makki

Edit/P.S.: Peter, ohne Deine Webseite und dieses Forum gäbe es meine Installation so nicht, aber das was ich vorher schon über IP wusste und in den letzten 2 Jahren über EIB dazugelernt habe legt halt gewisse Dinge offen, die nunmal gesagt werden müssen

[PeterPan]

Hoi Makki..

merci vielmals! Nur noch eine Anmerkung:

Die WLAN-Strecke ist "nur" ein anderes Übertragungsmedium, als z.B. TP. Bei TP funktioniert der Telegrammverkehr auf "Broadcast" - alle Teilnehmer hören mit - auch nicht anders als UDP via Ethernet. Auch hier kann es vorkommen, dass ein Telegramm "verlorengeht". Macht aber nix, weil der Sender auf ein ACK wartet. Kommt dies nicht, so wiederholt der Sender bis zu drei Mal das Telegramm.
Jetzt schneiden wir ein Stück aus der Leitung und überbrücken mit WLAN-Access-Point und -Client. Kommt ein Telgramm nicht bei einem TP-Teilnehmer auf der Clientseite an, so sendet er kein ACK. Somit wiederholt der Sender, wie oben angesprochen bis zu 3x.
Somit ist die "Übertragungssicherheit" via KNX-Spezifiktion gesichert - unabhängig vom Übertragungsmedium.

Aber richtig: In diesem Thread wurde eine "Nichtsichtverbindung mit 500 Meter Distanz" angesprochen. Und wie ich schon ausführte, sehe ich hier wenig Chancen dies mit WLAN zu lösen.

Alternativ könnte man GSM einsetzen. Hier bin ich noch an der Klärung.

Gruss Peter