Ja, ganz einfach ist das nicht. Cisco und Juniper wollen uns das immer in der Firma als Software Defined Network (SDN) verkaufen.
Wobei ich in dem Fall schon einfachere Lösungsansätze sehe. Eine Zentralstelle mit OpenVPNServer (kann der Raspi) und alle Clients (brauchen natürlich alle eigenes Internet, welches ist eigentlich egal) als OpenVPNClient (kann auch der Raspi). Damit hat man dann quasi via VPN ein virtuelles Netzwerk über das Internet gelegt.
Gruss
Bernd
Ich frage mich gneeell wer das administriert.
Bei der Variante musst du ja die Zugangsdaten der “zentrale” überall offenlegen. Wenn das verschiedne Nutzer sind würde ich das nicht machen.
Wenn alle Symcon-Instanzen von einer Person administriert werden würde ich eher zu einer “großen” Symcon-Version tendieren => ein mal unlimited ist ja auch günstiger als 7 mal basic 
Wenn es von mehreren Benutzern verwaltet wird würde ich die Daten einfach in ein JSON packen und mit Webhooks arbeiten. Dann kannst du dir für jede Verbindung einen Token überlegen und hast niergends die Zugangsdaten von denn symcon offen gelegt.
Die verschiedenen Netzwerke sind leicht zu umgehen, indem man die Verbindung direkt übers Internet macht. Hier kann man ja wunderbar den Connect Dienst benutzen.
Auch den Datenschutz sehe ich persönlich nicht kritisch. Jede Wohnung kann ja von sich aus entscheiden, welche Daten sie an den Server schickt, der Server kann im Gegenzug ja nichts abfragen. Diese Daten teile ich dann allerdings mit den anderen Wohnungsparteien, welche ja alle Zugriff auf den Server haben, aber hier kann ja wie schon gesagt jeder seine bevorzugte Stufe von Privatsphäre einstellen.
Aus diesen Grund käme das für mich niemals in Frage. Ich würde ein großes IPS mit verschiedenen WebFronts machen.
Könnte man über individuelle Webhooks sogar ohne RPC lösen und damit ohne die Daten frei zu legen.
Ein großes IPS über mehrere Wohnungen mit verschiedenen physikalischen Netzen stellt mich allerdings vor ein ganz anderes Problem das dann auch erstmal jemand lösen müsste.
Die Daten zum Server wären für alle Integratoren offen. Dies wäre bei einem einzelnen IPS doch genauso der Fall, oder nicht? Beziehungsweise, dort wäre es noch deutlich offener, da so jeder Wohnungsbesitzer Zugriff auf alle anderen Wohnungen hat, unter der Annahme, dass jeder seine eigene Wohnung verwaltet.
Gibt es einen Integrator für alles, dann tun sich beide Varianten meiner Meinung nach nichts bei der Offenheit des Systems.
Mir geht es weniger um die Daten, die dort fließen. Um Daten auszutauschen, muss ich mich am zentralen IPS authentifizieren. Damit würde den Wohnungen quasi auch ein Zugriff per Konsole zur Verfügung stehen. Um das sicher zu gestalten, bleibt nur ein WebHook.
Den Zugriff zum Server haben die Wohnungen allerdings nur, wenn sie Zugriff zur lokalen Installation haben. Ansonsten kommen sie nicht an den Server-Zugang.
Und wenn Sie in der großen gemeinsamen Variante Zugriff zur „lokalen“ Installation und Konfiguration haben, dann haben sie sogar gleichzeitig noch Zugriff auf alle anderen Einheiten. Daher sehe ich nicht den Sicherheitsgewinn bei einer gemeinsamen Installation.
Webhooks halte ich übrigens für eine sehr gute Idee an dieser Stelle. Das ist in der Einrichtung ein wenig aufwendiger, aber insgesamt eine schöne und elegante Lösung.
Noch schöner und viel einfach als Webhooks wäre übrigends MQTT dafür.
Die Zentrale würde einfach bestimmte Daten abonieren und die anderen Instanzen bringen die Daten ein. Damit müsste nichtmal sofortige Verfügbarkeit gegeben sein, bei Verlust der Verbindung würden keine Daten verloren gehen, Sicherheit wäre gegeben und man könnte sogar mehrere Instanzen synchronisieren (wenn z.B. auch die anderen Clients bestimmte Werte wissen sollen).
nur so mal btw
Genau!
Somit müsste nur der Broker erreichbar sein und man hat den Datenfluss in alle Richtungen
… die zentrale Lösung gewählt. 5 Mieter greifen auf 1 zentrales Gerät (in dem Fall ein RPI2) zu.
So bekomme ich alle Daten des Hauses (inkl. Treppenhäusern, Rauchmeldern und Wetterstation) recht problemlos in alle Mieteinheiten. Selbst konfigurieren möchte niemand. Der Zugriff erfolgt mit entsprechendem Passwort für jedes WebFront über ein DynDNS. Läuft seit über 2 Jahren in fast vollem Umfang (1 Mieteinheit ist noch im Ausbau) mit überschaubarem Adminstrationsaufwand klaglos.
Das einzige was ich (aus Kostengründen) nicht verwirklichen konnte war der Wunsch eines Mieters nach einer Steuerung über Alexa. Für mein Büro funzt das (mehr zum testen) recht problemlos mit einem zusätzlichen RPI1, der den Connect-Dienst aktiviert hat. Die paar benötigten Daten ‚schubse‘ ich einfach per rpc zum bzw. vom Server (im lokalen Netzwerk).
Bei einem Mieter würde das (außer der Konfigurationszeit) eine zusätzliche Lizenz (idealerweise auf einer SymBox) zzgl. der jährlichen Gebühren und eine Schnittstelle zum System (in meinem Fall natürlich LCN) erfordern Also insgesamt Kosten, die mind. das 20fache eines Dots „verschlingen“. Das rechnet sich dann nicht wirklich.
Ich bin nicht sicher, ob ich diese Lösung heute noch einmal so aufbauen würde. Bei der Planung der Anlage vor ca. 5 Jahren war das mit seinerzeit verfügbarer Hardware allerdings die kostengünstigste Lösung.
In Zeiten wo man anfängt über SmartCity zu reden sollte ein zentrales eigenes SmartHome-Netzwerk IMHO dafür eigentlich die bessere Lösung sein. Kostet aber auch … und Geiz ist ja (zumindest im Wohnungsbau) immer noch geil 
Grüße, Uwe