FHEM2FHEM bidirectional?

[Astrofreak85]

Hi,

keine Ahnung ob ich mal wieder zu doof bin...:

Ich hab zwei FHEM instanzen per FHEM2FHEM verbunden, an der einen hängt ein CUC, an dem Aktoren...
Ich sehe auf beiden FHEM Instanzen die Aktoren, die wurden per Autocreate erstellt...ich kann den Aktor aber nur von der Instanz steuern an dem auch der CUC hängt...auf der anderen Intanz sehe ich dann nur die Änderung des State, aber steuern kann ich nix...
wie bekomme ich es hin, das der Aktor auch auf der zweiten Instanz gesteuert werden kann?

Danke!
Astro

[ujaudio]

An dieser Herausforderung hänge ich auch gerade: Ich möchte einen Teil meiner Hausautomation auf einem 2. Raspberry laufen lassen. Das geht vermutlich problemlos, einen 2. HM-LAN-Adapter habe ich. Dank FHEM2FHEM kann ich auch alles schön mittels FLOORPLAN anzeigen, was auf dem 2. Raspberry funktioniert. Aber ich möchte ja nicht nur sehen, ob das Licht an oder aus ist, ich möchte es auch schalten können - also genau dein Problem, oder?

Ich habe bislang noch nichts installiert, weil ich es erst einmal theoretisch durchdringen möchte, bevor ich mich in die Herausforderung stürze. Meine erste Idee: nicht nur FHEM2FHEM von Rasbi1 nach Rasbi2 definieren, sondern ein zweites Mal umgekehrt.
Auf Rasbi2 ist das eigentliche Gerät definiert, auf Rasbi1 ein äquivalentes dummy mit den entsprechenden Readings und Attributen.
über je ein notify werden nun die Werte synchronisiert: Wenn ich das dummy auf Rasbi1verändere, dann dann reagiert das notify auf Rasbi2 und setzt das Gerät genau passend.
Durch diese Änderung reagiert das notify auf Rasbi1 und setzt das dummy nochmals. Da sich aber nichts ändert wird auch kein Event mehr ausgelöst und damit keine Endlosschleife erzeugt.
So stelle ich ir das vor, aber ich bin noch nicht durch, ob das wirklich klappt.
In der comandref habe ich gefunden:

event-on-change-reading
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings". Wenn gesetzt, erzeugen nur Veränderungen der gelisteten "readings" ein Ereignis. Wenn die aktualisierten Werte der gelisteten "readings" identisch sind, wird kein Ereignis generiert.

Es müsste also funktionieren...

Gibt es hier im Forum noch einen Tipp/Hinweis dazu? Wenn nicht: muss ich es halt nach meinem Urlaub ausprobieren "versuch macht kluch" 

Einen lieben Gruß
Jürgen

[RitterSport]

Wäre hierfür nicht RFHEM eine Möglichkeit?
Teile meiner Architektur mit Raspi3/Fhem5.7<->Raspi2/Fhem5.7<->Raspi1/Fhem5.6<->Fritzbox mit Fhem habe ich so gelöst

Beispiel:

Code Auswählen Erweitern

set RemoteSlaveRaspi cmd set Klingel ON

[Ralf9]

welche zwingende Gründe gibt es eigentlich FHEM auf mehrere Rechner aufzuteilen?

Das FHEM auf dem Banana Pi ist bei mir nur eine Übergangslösung. Der SIGNALduino und der HMUARTLGW ist auch über wlan oder lan machbar.
Ich finde alles auf einer FHEM Instanz zu haben, macht einiges einfacher.

Gruß Ralf

[Hollo]

welche zwingende Gründe gibt es eigentlich FHEM auf mehrere Rechner aufzuteilen? ...

Zwingend ist vielleicht der falsche Ausdruck.
Unter bestimmten gegebenen Bedingungen (Reichweitenproblem, räumlich, Schnittstellen, Performance, ?) kann es schon interessant oder sinnvol sein, die FHEM-Installation bzw. das System auf mehrere Geräte zu veteilen.
Beispielsweise ist ein 433MHz-Sender für die Funksteckdosen über GPIO an einem Raspi oder ähnlichem schnell realisierbar, während ein sowieso laufender kleiner Homeserver meist viel mehr (und teilweise ungenutzte) Performance für die Erstellung von Plots etc. hat.

Nicht zu vergessen, dass "man" vieles ja auch macht weil es geht oder interessant ist, und nicht weil man es zwingend bräuchte.

[marvin78]

Ich habe ein FHEM2FHEM für möglicherweise blockierende Aufgaben. Die beiden FHEMs laufen aber auf der selben Maschine. Reichweitenprobleme sollte man ggf. anders lösen. Die Hausautomation an sich auf verschiedene Maschinen aufzuteilen ist für Basteleien sicher ok (auch zur Entwicklung) aber eine Produktivumgebung muss auch leicht wartbar und dokumentierbar sein. Da eignet sich ein solches Vorgehen sicher nur bedingt.

[ujaudio]

Ich möchte auf 2 Raspberries aufteilen, weil auf einem die ganz wichtigen Funktionen ungestört und sicher ablaufen sollen (z.B. Heizung), während auf dem anderen die nice-to-have-Dinge wie z.B. buntes Licht im Garten laufen sollen, wo man gerne auch mal ein wenig herumspielt und dazu programmiert. Das mit dem blockierend ist dann ein weiteres Argument, das steht glaube ich auch schon im Wiki dazu.

[Ralf9]

Ich möchte auf 2 Raspberries aufteilen, weil auf einem die ganz wichtigen Funktionen ungestört und sicher ablaufen sollen (z.B. Heizung)

Die ganz wichtigen Funktionen sollten auch ohne Fhem funktionieren. Was machst Du z.B. wenn nach einem Stromausfall Dein Raspi nicht mehr läuft?
Oder wenn fhem nach einem update nicht mehr läuft?

Das mit dem blockierend ist dann ein weiteres Argument, das steht glaube ich auch schon im Wiki dazu.

Ja, dies ist ein Argument, wenn Du Module verwendest die vom Entwickler noch nicht auf nicht blockierend umgestellt wurden.

Gruß Ralf

[ujaudio]

Die ganz wichtigen Funktionen sollten auch ohne Fhem funktionieren. Was machst Du z.B. wenn nach einem Stromausfall Dein Raspi nicht mehr läuft?
Oder wenn fhem nach einem update nicht mehr läuft?

Ja, so ist es, deshalb (und weil ich vielleicht übervorsichtig bin) läuft noch ganz viel ohne echte Automatisierung. Aber die Dunstabzugshaube wird über FHEM gesteuert. Wenn die nicht läuft, weil ich mich mal wieder verprogrogrammiert habe, bekomme ich Stress von meiner lieben Frau. Die Heizung ist auch nur insofern halb-automatisiert, dass ich per Sprachausgabe Hinweise gebe, was getan werden sollte. Stromausfall lässt sich via Akku ja in den Griff bekommen, da denke ich schon darüber nach, weil ich noch einen 12V Akku habe, der den Raspberry recht lange am Laufen halten kann und ihn sicher abschalten kann. Hochlauf ist dann kein Problem. Was aber wenn der Raspberry selbst ausfällt??!? Hat schon jemand mal ein Doppelsystem angedacht, ein Teil als Standby, welches übernimmt, wenn das andere ausfällt?

Raspi1 mit FHEM1 und Raspi2 mit FHEM2. beide mit FHEM2FHEM gekoppelt. Wenn der regelmäßige Impuls von FHEM1 ausbleibt übernimmt FHEM2 die Kontrolle. Aber wie macht man das mit dem/den HM-LAN-Adapter/n?

Naja, ich mach erst einmal die (hoffentlich) einfacheren Dinge.

[Billy]

Ich habe mit MQTT gute Erfahrungen gemacht!

FHEM2FHEM vs ECMD vs MQTT

https://forum.fhem.de/index.php/topic,36228.0.html
Vielleicht hilfts!
Billy

[Garbsen]

...... Was aber wenn der Raspberry selbst ausfällt??!? Hat schon jemand mal ein Doppelsystem angedacht, ein Teil als Standby, welches übernimmt, wenn das andere ausfällt?

Raspi1 mit FHEM1 und Raspi2 mit FHEM2. beide mit FHEM2FHEM gekoppelt. Wenn der regelmäßige Impuls von FHEM1 ausbleibt übernimmt FHEM2 die Kontrolle. Aber wie macht man das mit dem/den HM-LAN-Adapter/n?

Naja, ich mach erst einmal die (hoffentlich) einfacheren Dinge.

An einer solchen Lösung wäre ich interessiert. Redundanz ist immer gut, auch wenn es sich nicht um lebenswichtige Dinge handelt. Es reicht ja schon, wenn das System ausfällt und man z.B. Im Urlaub ist (Rolläden bleiben unten, Gartenbewässerung streikt, etc. alles blöd) oder man einfach keine Zeit hat, das System zu reparieren (z.B. Raspberry stirbt).
Super wäre es, wenn man dann ein Backup hat, das automatisch startet und auch immer auf dem aktuellem Stand ist. (z.B. Tägliche Spiegelung oder ähnlich )
Das ganze dann noch einfach installierbar (bin ganz brauchbar im copy/Paste aber nicht so im tatsächliche, programmieren  )

[Tedious]

Ein bidirektionales FHEM2FHEM wäre durchaus interessant - ich hätte, mal abgesehen von den üblichen Reichweitenproblemen durchaus Anwendungsgebiete..

• Jedes Stockwerk könnte autark gesteuert werden, das wäre bei mir recht spannend
• Jedes Stockwerk könnte entsprechend die Fußbodenheizung regeln
• Sicherheitskritische Dinge (Alarm, Fensterkontakte, Rauchmelder etc.) separiert auf einer eigenen Instanz in einem Subnetz, getrennt von Wlan o.ä.

könnte beliebig erweitert werden Ideen hätte ich durchaus genug Sicher, das alles lässt sich prinzipiell auch auf einer Instanz abbilden, ich bin aber ein Freund von "Trennen, was getrennt werden sollte/könnte"

[Billy]

MQTT ist bidirektional und kann mE das was ihr wollt!

Vergleich mit FHEM2FHEM hier beschrieben.
https://forum.fhem.de/index.php/topic,36228.msg285198.html#msg285198
billy

[marvin78]

Was ist denn falsch an dem hier schon erwähnten RFHEM?

[Billy]

Falsch ist nichts. Aus meiner Sicht vereint das Modul MQTT - Bridge zwischen mqtt und fhem
die Eigenschaften von RFHEM und FHEM2FHEM.
Siehe auch
https://forum.fhem.de/index.php?topic=27532.0

Aber vielleicht sehe ich das auch falsch?

Billy