Hallo,
im Forum gibt es bereits Artikel dazu "Fhem als Steuerung der Homematic über Funk LAN-Gateway oder Fhem als Client hinter einer CCU2".
z.B.: https://forum.fhem.de/index.php?topic=74953.0 (ähnliche Frage)
und https://wiki.fhem.de/wiki/HomeMatic (Voraussetzungen)
Da selbst mit einer CCU2 die Konfiguration im FHEM gespiegelt wird + änderbar ist weiß ich nicht ob es Unterschiede in der Praktikabilität gibt.
Daher die bitte, mir die Vorteile/Nachteile aufzuschlüsseln:)
DANKE!
Hi,
Nachteil hast Du selbst gesagt:
CCU2 die Konfiguration im FHEM gespiegelt wird
Vorteil: Funk LAN-Gateway - FHEM ist die Zentrale.
Ansonsten ist die Frage ähnlich wie der Vorteil/Nachteil von Grießbrei gegenüber Milchreis. ;D
-> Je nach dem wem es wie schmeckt.
Es gibt hier fast im Wochenrythmus Threads dazu, lies die durch und bilde Dir selbst für dich eine Meinung. Oder werde bitte konkreter.
Gruß Otto
haferflocken!
Hallo Otto,
danke für dein Feedback.
Worin liegt der Vorteil wenn FHEM die Zentrale ist?
Lassen sich die HM Geräte einfacher verwalten?
Gibt es Probleme wenn man in FHEM die Konfiguration der HM ändert und diese wieder zurückschreiben lässt?
@rendgeor:
Du stellst eine Glaubensfrage, was erwartest du da als Antwort?...
Jedenfalls ich (und vermutlich auch Otto und frank) GLAUBE, dass eine reverse-engineered open-Source Software wie das CUL_HM-Modul (oder HMUARTLGW) gegenüber der vom Hersteller selbst gelieferten Zentrale vorzugswürdig ist. Es gibt Leute, die glaubwürdig behaupten, die Software, die der Hersteller für die CCUx anbietet, hätte einige schwerwiegende Macken.
Andere GLAUBEN, dass es besser ist, den Hersteller machen zu lassen und haben daher eine Lösung programmiert, damit FHEM diese optimal nutzt. Hat den "Vorteil", dass man auch HM-IP einsetzten _kann_.
Da ich GLAUBE, dass HM-IP konzeptionell Mist ist und diesem Hersteller soweiso nicht traue, GLAUBE ich, dass ich zukünftig besser was ganz anderes nutzen werde, wenn ich mal was umrüsten muß... Ich GLAUBE auch, dass es besser ist, serielle Interfaces einzusetzen und jegliche Netzwerktechnik, insbesondere WLAN aus der Hausautomatisierung zu verbannen, deswegen habe ich ein Pi-Modul (PCB) an einen USB-seriell-Wandler geklemmt.
Aber ich GLAUBE auch, dass es keinen optimalen Weg gibt, das muß jeder für sich entscheiden.
Ich weiß aber, dass ich Haferflocken nicht besonders mag und sich meine Begeisterung sowohl für Griesbrei wie Milchreis sehr in Grenzen hält. (Bitte auch kein .... Popcorn)
*Duckundweg*
Wenn FHEM der Unter ist und CCU2 der Ober und Du die Shell8.
Dann willst Du das Licht anmachen, Du fragst den Unter: Mach bitte das Licht an. Der Unter fragt den Ober, der Ober sagt dem Licht: geh an und bekommt die Rückmeldung vom Licht: Es ist an. Dann meldet der Ober dem Unter: so das Licht ist an.
Ist da ein Vorteil?
Zitat von: Otto123 am 20 März 2019, 15:35:29
Wenn FHEM der Unter ist und CCU2 der Ober und Du die Shell8.
Dann willst Du das Licht anmachen, Du fragst den Unter: Mach bitte das Licht an. Der Unter fragt den Ober, der Ober sagt dem Licht: geh an und bekommt die Rückmeldung vom Licht: Es ist an. Dann meldet der Ober dem Unter: so das Licht ist an.
Ist da ein Vorteil?
Na ja, das geht ja noch und ist auch nicht zu unterscheiden von anderen Konstellationen, in denen eine Art "bridge" eingesetzt wird, sei es sowas wie eine Hue- oder Tradfri-Bridge, oder z.B. ein externer MQTT-Broker oder FHEM2FHEM.
Aber: mit der CCUx hast du einen Logikbaustein, der z.B. Zeitprogramme verwalten kann oder bedingungsabhängig schalten (denke ich zumindest). Wer dann noch auf die Idee kommt, diese "Optionen" zusätzlich zu nutzen, hat die helle Freude am Fehlersuchen, wenn er nach ein paar Monaten vergessen hat, was wo steht bzw. stehen kann...
Naja Du hast Recht, ich habe das ein bisschen wie bloß Nachrichten übermitteln erklärt. Es ist aber wahrscheinlich doch eher "Spiegeln" d.h Zustände synchronisieren. Bei MQTT geht es ja darum, das die Nachricht auch übermittelt wird. Beim Spiegeln ist das nachrangig?
Puh, ist irgendwie schwierig. Wäre wieder zu klären, was "Spiegeln" sein soll, und auch die MQTT-Technik an sich kann unterschiedlich genutzt werden (auf die Schnelle nur "last will" und "QoS"). Wenn weitere "Bridges" dazukommen, wird das Bild noch bunter.
Sind aber alles doch eher interessante, aber theoretische Fragen und recht weit weg von der eigentlichen Frage des TE, oder täusche ich mich da?
@TE: wenn deine Frage beantwortet sein sollte, mach doch ein [gelöst] an den Thread-Titel (ersten Beitrag editieren).