Verbinden Sie mehrere IP-Symcon Standorte (z. B. Ferienhaus, Büro, Hauptwohnsitz) effizient, sicher und mit Rückkanal.
Hallo zusammen,
bevor ich ins Detail gehe, ein wichtiger Hinweis vorab: Dieses Modul, die gesamte Code-Logik sowie dieser Beitrag wurden unter intensiver Nutzung von Gemini 3.5 Pro entwickelt. Wer KI-generierte Inhalte oder mit KI entwickelte Module ablehnt, braucht an dieser Stelle nicht weiterzulesen.
RemoteSync spiegelt Variablen-Strukturen zwischen entfernten Systemen, ohne die Internetverbindung unnötig zu belasten. Es arbeitet nach dem „Push“-Verfahren: Die Quelle sendet aktiv Daten, sobald sich etwas ändert.
Wie es funktioniert (Technik)
Das Modul agiert als intelligentes Gateway:
Empfänger-Skript: Bei der Einrichtung installiert das Modul vollautomatisch ein Empfänger-Skript auf dem entfernten Zielsystem.
Effizienz durch Blöcke: Um den Overhead zu minimieren, werden Variablen-Änderungen nicht einzeln pro Event gesendet. Stattdessen werden Änderungen dynamisch gesammelt und in optimierten Datenblöcken (Batches) an das Empfänger-Skript geschickt.
Verarbeitung: Das Remote-Skript entpackt diese Blöcke und aktualisiert das Zielsystem in einem Rutsch.
Die 5 Grundfunktionen
Das Modul deckt den gesamten Lebenszyklus einer gespiegelten Variable ab:
Automatische Anlage (Replikation):
Wählen Sie eine lokale Variable zur Synchronisation aus, wird diese auf dem entfernten System automatisch angelegt. Dabei werden Wert, Profil, Icon und Einheiten 1:1 repliziert. Manuelles Anlegen entfällt.
Spiegeln (Standard / Last-Value-Wins):
Im Standardmodus wird zur Schonung der Bandbreite nur der jeweils aktuellste Wert übertragen. Ändert sich eine Variable 10x pro Sekunde, wird nur der letzte Stand im nächsten Datenblock gesendet. Das ist extrem schnell und effizient.
Lückenlose Historie (Full History):
Für Variablen, bei denen jeder Zwischenwert wichtig ist (z. B. für Graphen/Charts), kann optional die „Full History“ aktiviert werden.
Vorteil: Jeder einzelne Wert wird chronologisch korrekt übertragen und archiviert.
Nachteil: Dies erhöht die Datenmenge signifikant und verringert die Übertragungsgeschwindigkeit im Vergleich zum Standard-Modus („auf Kosten der Performance“).
Symmetrisches Spiegeln (Mit Rückkanal):
Aktiviert man die Option „Remote Action“, wird die Variable auf dem Zielsystem bedienbar. Schalten Sie am entfernten System (z. B. im Dashboard des Ferienhauses), wird der Befehl zurück zur Quelle geleitet und dort ausgeführt. Die Statusänderung fließt anschließend wieder zum Ziel zurück.
Remote Löschen:
Entfernen Sie eine Variable aus der Liste im Modul, wird diese (optional) auch automatisch auf dem entfernten System gelöscht, um Datenmüll zu vermeiden.
Das aktuelle Update sorgt für maximale Stabilität bei schlechten Internetverbindungen:
Multi-Lane Architektur: Parallele Kanäle verhindern Staus bei vielen gleichzeitigen Änderungen.
Safety Circuit Breaker: Ein Puffer-Limit schützt den RAM bei langen Ausfällen.
Chronologische Recovery: Bei Verbindungsabbruch werden Daten zwischengespeichert und später in korrekter Reihenfolge nachgesendet.
Einrichtung
Zugangsdaten sicher im lokalen Symcon Password Vault (SEC-Modul) hinterlegen.
Hier werden „nur“ Variablen synchronisert. Sync Remote bildet einen ganzen IPS-Baum eines Remote Systems ab - mit Variaben, Scripten usw. Und Mirroring Symcon geht in Richtung Redundanz zweier Systeme.
@kronos Das nur variablen synchronisiert werden ist der Hauptunterschied. Meine ursprüngliche Motivation das Modul zu schreiben lag in IPSVIEW. Ich habe eine Lizenz und eine Oberfläche über die ich insgesamt 4 IP Symcon Installationen (inkl. Test System) abbilde und steuere. Hier ist ein Auszug aus der Dokumentation der die Unterschiede nochmals beschreibt :
RemoteSync dient der Vernetzung (Daten-Austausch), während Mirroring der Ausfallsicherheit (Redundanz) dient.
Vergleich: RemoteSync vs. IP-Symcon Mirroring
Oft stellt sich die Frage, wann man das kostenlose RemoteSync Modul und wann die kostenpflichtige Mirroring-Funktion von IP-Symcon nutzen sollte. Beide Lösungen haben völlig unterschiedliche Zielsetzungen:
RemoteSync ist ein Connector: Es verbindet unabhängige Systeme (z.B. Ferienhaus mit Hauptwohnsitz), um Daten auszutauschen und zentral zu visualisieren.
Mirroring ist ein Redundanz-System: Es erstellt eine 1:1 Schattenkopie eines Servers, um bei Hardware-Ausfall sofort den Betrieb zu übernehmen.
Detaillierter Vergleich
Merkmal
RemoteSync (Modul)
IP-Symcon Mirroring (Nativ)
Hauptzweck
Vernetzung & Aggregation(z. B. „Büro“-Daten im „Haupthaus“ anzeigen)
Hochverfügbarkeit (HA)(Ausfallsicherheit bei Server-Crash)
Umfang
Selektiv: Nur ausgewählte Variablen/Zweige werden übertragen.
Total: Das gesamte System (Skripte, Instanzen, Hardware-Konfig) wird 1:1 kopiert.
Richtung
Bidirektional: Werte fließen zum Ziel, Schaltbefehle (Aktionen) zurück zur Quelle.
Einseitig: Master überschreibt Slave. Änderungen auf dem Mirror gehen verloren (werden nicht auf das Quell System zurueckgespiegelt).
Verbindung
Push (Event-basiert): Sendet nur bei Änderung (datensparsam). Die Konfiguration erlaubt eine “1 to many” Konfiguration.
Sync/Replikation: Hält Konfigurationsdateien und Zustände permanent synchron.
Kosten
Kostenlos (Community Modul).
Kostenpflichtig (Lizenz-Erweiterung). 1 Installation frei für Privat Zwecke
Hardware-Hardware
Funktioniert auch zwischen völlig unterschiedlichen Systemen (z. B. RasPi ↔ Windows Server).
Vermutung : Sollte identisch sein, da Hardware-Instanzen (z. B. Serial Ports) mitsynchronisiert werden.
Internet-Verbindung
Optimiert für WAN: Pufferung bei Ausfall, Traffic-Reduktion durch Batches.
Optimiert für LAN: Benötigt stabile, schnelle Verbindung für die Replikation.
Unabhängigkeit
Zielsystem bleibt eigenständig und kann eigene Skripte/Hardware haben.
Zielsystem ist ein „Sklave“ und darf quasi keine eigene Konfiguration haben (sonst wird sie überschrieben).
RemoteSync stellt bei Bedarf eine detaillierte Performance Statistik zur Verfuegung : Echtzeit-Metriken zu Round-Trip-Time (RTT), Verzögerung (Lag), Datenmenge (Payload) und Fehlerraten zur Überwachung der Verbindungsqualität.
Fazit: Wann nutze ich was?
Nutze RemoteSync, wenn zwei lebende Systeme verbunden werden (z. B. Daten vom Gartenhaus ins Haus holen, um sie dort im WebFront anzuzeigen oder darauf zu reagieren).
Nutze Mirroring, wenn ein kritisches Produktionssystem existiert, das bei einem Hardwaredefekt ohne manuellen Eingriff sofort auf einem Zweitgerät weiterlaufen muss (Failover).
Ah, Danke für die Erklärung. Das ist RemoteSync (Modul) also gar nicht vergleichbar mit Mirroring, sondern mit dem nativen SyncRemote (mit einigen Unterschieden). Richtig?
Erweiterter Funktions-Vergleich: RemoteSync vs. IP-Symcon „Sync Remote“
Während die native Funktion darauf ausgelegt ist, ganze Systembäume administrativ einzubinden, fokussiert sich RemoteSync auf die operative Vernetzung von Variablen mit maximaler Kontrolle über Datenfluss und Bandbreite.
Detaillierte Gegenüberstellung
Feature
IP-Symcon „Sync Remote“ (Nativ)
RemoteSync (Modul v1.12.0)
Architektur
Pull (Intervall): Der Server fragt zyklisch Daten ab (Polling).
Push (Event): Die Quelle sendet aktiv bei Änderung.
Daten-Granularität
Alles: Der gesamte Objektbaum des Clients wird integriert.
Selektiv: Nur definierte Variablen/Zweige werden übertragen.
Historie & Daten
Snapshot: Überträgt den Zustand zum Zeitpunkt des Pollings. Schnelle Zwischenwerte können verloren gehen (Aliasing).
Wählbar: 1. Last-Value (Standard): Nur der letzte Wert (spart Traffic). 2. Full History: Lückenlose Übertragung aller Zwischenwerte.
Netzwerk-Effizienz
Konstante Last: Erzeugt Traffic durch Polling, auch wenn nichts passiert (Delta-Berechnung kostet CPU).
On-Demand: Traffic entsteht nur bei echten Events. „Idle“-Last ist gleich Null.
Symmetrie (Rückkanal)
Implizit: Der Server hat Vollzugriff und kann Variablen am Client schalten.
Explizit (Remote Action): Eine RequestAction auf die gespiegelte Variable am Ziel führt die Aktion nahtlos auf der Quelle aus.
Performance-Sichtbarkeit
Versteckt: Wenig Einblick in Latenz oder Paketverluste.
Transparent: Echtzeit-Sensoren für RTT, Lag, Payload und Fehlerraten.
RemoteSync ermöglicht eine echte Interaktion. Wenn die Option „Remote Action“ aktiviert ist, verhält sich die gespiegelte Variable auf dem Zielsystem wie das Original.
Beispiel: Sie haben einen Lichtschalter im Ferienhaus (Quelle). Dieser wird ins Büro (Ziel) gespiegelt.
Aktion: Sie drücken im Büro im WebFront auf „An“.
Prozess: RemoteSync fängt diesen Befehl ab, leitet ihn sofort an das Ferienhaus zurück und führt dort das Schalten aus. Die Bestätigung (Status „An“) fließt anschließend automatisch zurück ins Büro. Das fühlt sich für den Nutzer an, als wäre der Schalter lokal.
2. Historie: „Last-Value-Wins“ vs. „Full History“
Szenario A (Temperatur): Ein Sensor sendet alle 2 Sekunden. Für die Visualisierung reicht der aktuelle Wert. RemoteSync (Standard) verwirft im Puffer veraltete Werte und sendet nur den allerletzten im nächsten Datenblock. Ergebnis: Massive Bandbreitenersparnis.
Szenario B (Windböen/Stromspitzen): Sie wollen wissen, ob kurzzeitig ein Grenzwert überschritten wurde. Die native „Sync Remote“ könnte diesen Peak zwischen zwei Abfrage-Intervallen verpassen. RemoteSync mit „Full History“ garantiert, dass jeder einzelne Messwert übertragen und im Ziel-Archiv gespeichert wird, auch wenn 10 Werte pro Sekunde eintreffen.
3. Performance-Messung (Monitoring)
RemoteSync liefert harte Zahlen zur Verbindungsqualität direkt als Variablen:
RTT (Round Trip Time): Wie lange dauert der Weg hin und zurück?
Lag: Wie viel Zeit vergeht zwischen dem Ereignis an der Quelle und dem Eintreffen am Ziel?
Payload: Wie viele Daten werden tatsächlich verbraucht (wichtig bei LTE-Volumentarifen)?
Hat das Modul schon mal jemand ausprobiert? Funktioniert das wirklich?
Habe nur mal den Code überflogen, aber dachte das da paar Sachen drin sind die in einem Modul nicht funktionieren, aber vielleicht täusche ich mich auch (z.B. Klassenvariablen)!
Sowas habe ich auch noch nie gesehen …
$this->rpcClient->IPS_SetIdent($cID, $ident);
Werde weiter aufmerksam den Thread verfolgen - interessante Sache
Und wer prüft jetzt, ob die Aussagen der KI stimmen? Selten so viel KI generierten Content (Hier stand vorher “Schwachsinn”. Mal schauen, ob es so ist.) gelesen.
Das Modul habe ich seit ca. 2 Wochen auf 4 Systemen im produktiven Einsatz. Im Moment ist mir kein Problem bewusst. Ich spiegele zur Zeit 230 Variable aus Florida nach Berlin.
Dieses Statement führt einen Befehl auf einem entfernten IP-Symcon System aus.
Hier ist die genaue Aufschlüsselung des Codes:
$this->rpcClient->IPS_SetIdent($cID, $ident);
1. Die Bestandteile
$this->rpcClient:
Dies ist das Verbindungsobjekt (der „Client“), das die Kommunikation zum entfernten Server hält. Es fungiert als Tunnel. Alles, was danach aufgerufen wird, passiert nicht lokal, sondern auf dem Zielsystem.
->IPS_SetIdent(…):
Dies ist der eigentliche IP-Symcon-Befehl. Er weist einem Objekt einen Identifikator (Ident) zu.
Der Ident ist ein interner String-Name für ein Objekt (z. B. „STATE“, „TEMPERATURE“), der unsichtbar im Hintergrund existiert.
Er unterscheidet sich vom „Namen“ des Objekts (der im Baum sichtbar ist und vom User geändert werden kann).
$cID:
Das ist die ID des Objekts auf dem entfernten Server. Das Modul hat dort wahrscheinlich gerade eine Variable oder Kategorie angelegt und deren ID in dieser Variable gespeichert.
$ident:
Das ist der String (Text), der als Ident gesetzt werden soll.
2. Was passiert technisch?
Das Skript sagt dem entfernten Server:
„Nimm das Objekt mit der ID $cID (das ich gerade bei dir angelegt oder gefunden habe) und setze seinen internen Identifikator auf den Wert $ident.“
3. Warum macht man das? (Der Sinn)
Das Setzen eines Idents ist für die Programmierung extrem wichtig, um Objekte wiederzufinden:
Stabilität: IDs (Zahlen) können sich ändern, wenn man Objekte löscht und neu anlegt. Namen (Text) können vom Benutzer geändert werden („Wohnzimmer“ → „Living Room“).
Zuordnung: Der Ident ist fest. Das RemoteSync-Modul nutzt dies wahrscheinlich, um zu wissen: „Diese Variable hier auf dem Remote-Server gehört zu jener Variable auf dem Quell-Server.“
Unabhängigkeit: So kann das Skript später sagen: „Gib mir das Objekt unterhalb von Kategorie X mit dem Ident ‚MyVariable‘“, anstatt eine harte ID zu raten.
Zusammengefasst:
Es markiert ein Objekt auf dem entfernten Server mit einem festen internen „Codenamen“, damit das Modul es später eindeutig identifizieren und aktualisieren kann.
@DerStandart Leider werden nicht alle meine Antworten immer 100% korrekt sein.
Ich generiere die Antworten mit KI und überprüfe sie aber versuche gleichzeitig den Zeitaufwand gering zu halten.
Im übrigen bin ich nur ein durchschnittlich (wenn überhaupt) guter Hobby Programmierer mit viel Phantasie. Die meisten Ideen die Daten Übertragung effizient zu gestalten (z.b. Remote Script, Blockbildung mit Hilfe von Sempahoren, Nutzer definierte Anzahl paralleler Verbindungen) kommen von mir. Ich konzentriere mich darauf optimale Methoden zu finden mit der KI umzugehen. Im Ergebnis muss die Software bei mir funktionieren, wie ist mir dabei nicht so wichtig.
Alle fertigen Module werden von der KI daraufhin über prüft das die von Paresy veröffentlichten Best Praxis Richtlinien für Module eingehalten wurden.
Wollte nochmal nachfragen ob jemand das Modul schon genutzt hat, also außer BestEx slight_smile: ?
Leider bin ich ein kleiner Schisser und habe Angst mein System kaputt zu machen. Normalerweise verstehe ich den Code, aber hier ist mir zuviel Magic(KI) am Start!
@pitti Die erste Hürde wird wahrscheinlich mein Passwort Modul sein. Ich habe schon überlegt diese Abhängigkeit optional zu machen aber die Verbindungsdaten sind in einem Array abgelegt und die stehen im Password Modul so das eine Erweiterung nicht trivial ist und teilweise das Password Modul duplizieren würde. Du kannst mir gerne PM´s schicken und ich helfe Dir das ganze aufzusetzen.
