Hi!
Ich suche nach einer eleganten Lösung, den Zustand eines identen "Schalters" zwischen zwei FHEM Servern synchron zu halten.
Wenn man z.B. am FHEM Server_A den Schalter "Lüftung" einschaltet, soll sich der Zustand des Schalters "Lüftung" am FHEM Server_B ebenfalls ändern.
Was das ganze jedoch erschwert ist, dass die Netzwerkverbindung zwischen den beiden Servern unzuverlässig ist!
Bin gespannt ob sowas einfach zu lösen ist :)
Zitat von: chunter1 am 06 Februar 2019, 12:42:24
Hi!
Ich suche nach einer eleganten Lösung, den Zustand eines identen "Schalters" zwischen zwei FHEM Servern synchron zu halten.
Wenn man z.B. am FHEM Server_A den Schalter "Lüftung" einschaltet, soll sich der Zustand des Schalters "Lüftung" am FHEM Server_B ebenfalls ändern.
Was das ganze jedoch erschwert ist, dass die Netzwerkverbindung zwischen den beiden Servern unzuverlässig ist!
Bin gespannt ob sowas einfach zu lösen ist :)
Schau dir mal FHEM2FHEM an . Ich weiss aber gerade nicht wie sich das bei fehlender Verbindung beim schalten und anschließenden reconnecr verhält. Musst du nachlesen .
Wenn bei reconnecr keine Synchronisierung stattfindet ... ich glaube das tut es nicht .... wirst du dir da vermutlich noch was bauen müssen .
Gruss Byte09
Gesendet von meinem SM-G900F mit Tapatalk
Ungeprüft: Müßte auch mit dem MQTT-Protokoll gehen (und entspechender Einstellung bei qos/retain). Das ist für Verbindungsabbrüche (mind. theoretisch) vorbereitet.
Wenn es mehrere Devices betrifft, die von einer Instanz an eine andere übertragen werden sollen: MQTT_GENERIC_BRIDGE (hexenmeister hat im MQTT-Bereich auch entsprechende Anwendungsszenarien dargestellt).
In beide Richtungen aber aufpassen: Man kann mit MQTT recht leicht unbeabsichtigte loops bauen...
Gruß, Beta-User
MQTT möchte ich ehrlich gesagt vermeiden. ;)
FHEM2FHEM hab ich bereits am Laufen - auch bidirektional (mit entsprechenden Filtern gegen Loops).
Momentan denke ich an folgende Lösung:
SERVER_A ("Master"):
*) DUMMY namens "Lüftung" den man normal toggeln kann (on/off)
*) DOIF sendet via FHEM2FHEM bei Zustandsänderung sowie periodisch alle 60s den DUMMY Zustand an Server_B
SERVER_B ("Slave"):
*) DUMMY namens "Lüftung" den man NICHT schalten kann sondern der ausschließlich via FHEM2FHEM vom DOIF des Server_A upgedatet wird.
*) .....?
Und dann steh ich an. :)
Ich würde gerne genu den DUMMY am Server_B als Taster nutzen um ein toggle am Server_A auszulösen - der Zustand des DUMMIES soll sich aber nicht ändern sondern nur vom Master Server via FHEM2FHEM bestimmt werden.
Klingt kompliziert... ist es auch ;D
Zitat von: chunter1 am 06 Februar 2019, 13:41:50
MQTT möchte ich ehrlich gesagt vermeiden. ;)
Deine Entscheidung, obwohl mich der Grund interessieren würde :D .
Ich hatte übrigens früher auch "eigentlich" keine Lust auf MQTT, das klang kompliziert und war mit einem gefühlt hohen overhead verbunden (@mosquitto); mit MQTT2-SERVER (bzw. MQTT2_CLIENT auf dem 2. FHEM) braucht man eigentlich keine "FHEM-externe" Infrastruktur mehr (nur ggf. für die Gen-Bridge ein (!) zusätzliches Perl-Modul, das aber mit apt-get zu installieren sein sollte). Und hexenmeister hat auch irgendeinen Mechanismus vorgesehen, um loops zu verhindern.
Klingt für mich einfacher wie ein selbergestrickter polling-Mechanismus ;) .
Zitat von: Beta-User am 06 Februar 2019, 14:06:30
Deine Entscheidung, obwohl mich der Grund interessieren würde :D .
1. Möchte ich jede unnötige zusätzliche Fehlerquelle/Wartung/Komplexität im ohnehin schon großen System vermeiden
2. Möchte ich alle Parameter und Algorithmen selber bestimmen können :)
Darum hat MQTT bei mir keine Chance ;)
Für alle die vor dem gleichen Problem stehen... ich habs jetzt so gelöst:
FHEM_A ("Master")
*) FHEM2FHEM Richtung FHEM_B ("Slave") eingerichtet.
*) DUMMY mit dem Namen "Lueftung"
*) DOIF das alle 60 Sekunden ein fake-event des Dummies generiert um via FHEM2FHEM den Zustand am FHEM_B server synchron zu halten. Dies ist auf Grund der unzuverlässigen Netzwerkverbindung nötig.
FHEM_B ("Slave")
*) FHEM2FHEM Richtung FHEM_A ("Master") eingerichtet.
*) READINGSPROXY mit dem gleichen Namen wie bei FHEM_A angelegt (="Lueftung"). Mittels "setFn" wird dann bei Betätigung der Zustand an FHEM_A ("Master") übermittelt (lokal jedoch nicht upgedatet!!) und der tatsächliche Zustand dann von FHEM_A via event an FHEM_B zurückübermittelt/bestätigt.
Ist wahrscheinlich nicht die eleganteste Lösung, aber sie funktioniert und gibt eine gewisse Sicherheit der Synchronität. ;)
Zitat*) DOIF das alle 60 Sekunden ein fake-event des Dummies generiert um via FHEM2FHEM den Zustand am FHEM_B server synchron zu halten. Dies ist auf Grund der unzuverlässigen Netzwerkverbindung nötig.
Warum DOIF, wenn es auch mit einem at geht?
Zitat von: Wernieman am 07 Februar 2019, 13:44:22
Warum DOIF, wenn es auch mit einem at geht?
Kann man natürlich auch mit einem "at" machen :)
Zitat von: Wernieman am 07 Februar 2019, 13:44:22
Warum DOIF, wenn es auch mit einem at geht?
[Ironie ein]
a) es steht im Anfängerbereich; at ist nur was für Fortgeschrittene ;D b) Der TE bevorzugt überschaubare und selbstgestrickte Lösungen, da ist ein sehr einfach zu konfigurierendes FHEM-Modul genau auf der Linie
[Ironie aus]
@Wernieman: Ich glaube, wir können uns solche Fragen sparen, die Leute haben einfach Spaß an eierlegenden Wollmilchsäuen...
Das Schlachtfeld für DOIF Hasser und Befürworter gibts doch schon in einem anderen thread.
Ich denke konstruktiven Beiträge zum Thema haben mehr Wert ;)
Das Thema ist also [gelöst]?
Bei nur einem Device mag das egal sein, wie man es löst aber ansonsten bleibe ich für eventuelle Nachahmer bei der These, dass sich schlaue Leute MQTT ausgedacht haben, um gerade für unzuverlässige Netzwerkverbindungen und verteiltes Gerät eine recht einfach zu handhabende Lösung zu haben (ganz unabhängig davon, ob man jetzt mosquitto oder sonst einen Broker einsetzt).
Jeder wie er kann und mag...
Angenommen die Netzwerkverbindung fällt für 3 Tage aus.
Synchronisiert dann MQTT den Zustand immer noch irgendwie irgendwann irgendwo oder muss nicht doch die Quelle nochmal aktiv die Daten senden?
Was ist wenn sich in der Zwischenzeit der Zustand geändert hat?
Kommen dann die gequeuten Pakete in kuzem Abstand hintereinander an?
Damit nicht wie üblich gleich wieder ein shitstorm losgeht oder sich wer in der Ehre verletzt fühlt... MQTT ist sicher nciht schlecht - aber aus weiter oben genannten Gründen vermeide ich es bei all meinen Projekten. ;)
Soweit ich das verstanden habe, kann man schlicht (im Prinzip pro message) definieren, ob das Gerät (und/oder der Server) unbedingt versuchen soll, das zuzustellen, ob sich der Server das auch noch merken soll, wenn er es weitergeleitet hat usw.... Erfordert dementsprechend Einarbeitung, aber dafür kann man z.B. auch einstellen, was der Server tun soll, wenn er eine bestimmte Zeit keine Messages mehr erhält (last will).
So kann man z.B. auch ein nachhaltige Netzwerkstörungen entdecken, und versucht nicht zwanghaft, einfach nur weiter Daten zu senden. Aber letztlich bin ich da auch nicht der Experte und nutze MQTT auch nur oberflächlich - als solches ist es ein sehr einfach gestricktes, universelles Textprotokoll...