Homematic IP Geräte Erweiterung

[zap]

Das ist doch alles total unbefriedigend. Die neuen Geräte sind nicht schlecht, aber ich werde sie nicht kaufen solange dieser irre Aufwand erforderlich ist.

Wie kommen denn Alexander Reinert und Jens Maus (debmatic / raspberrymatic) an das HMIP- Protokoll?
Kann denn der FHEM- Verein da nichts machen? Prof. Redeker (EQ3/ELV) müsste doch Interesse daran haben, dass jede gößere Smart Home- Plattform dieses Protokoll direkt hat.
Um so beliebter wären die Komponenten.

Gruß
Frank

Außer EQ-3 kommt niemand an das HmIP-Protokoll. Im GIT Repository (https://github.com/eq-3/occu) liegen entsprechend nur die Binärfiles vom HMServer. Die werden dann z.B. von Rasperrymatic übernommen.

Ich denke auch nicht, dass EQ-3 ein Interesse daran hat, das Protokoll offenzulegen. Schließlich sind die CCU Schnittstellen gut dokumentiert und werden auch von verschiedenen Smarthome Plattformen genutzt (ioBroker, OpenHab, ...). Keine Ahnung, warum man bei FHEM auf Reverse Engineering gesetzt und das Rad neu erfunden hat. War vor meiner FHEM Zeit. FHEM ging hier bisher also einen anderen Weg als die anderen großen Smarthome Plattformen.

Wenn man etwas reverse engineered bzw. nicht die dokumentierten Schnittstellen nutzt, läuft man halt in Gefahr, dass bei jeder Änderung seitens des Anbieters die eigene Lösung nicht mehr funktioniert.

[Beta-User]

Wie auch immer diese Dinge mal entstanden sind...

Jedenfalls stimmt m.E. die These nicht, dass ein "irrer Aufwand" erforderlich wäre, weder in finanzieller noch in "software-administrativer" Hinsicht.

Für mich waren (bereits schon vor dem Erscheinen von HM-IP) andere Gründe maßgebend, warum ich mich mit Alternativen beschäftigt habe - auch, wenn das im Ergebnis erst mal deutlich höherer Aufwand war wie nur die Installation einer (ggf. virtualisierten) CCU.

[frank]

Keine Ahnung, warum man bei FHEM auf Reverse Engineering gesetzt und das Rad neu erfunden hat.

eventuell hätte eq3 nie das occu projekt begonnen, wenn es nicht zuvor reverse engeneering gegeben hätte.
ebenso hätte es die grandiose homebrew/asksin community nie gegeben.

[marvin78]

Ich denke auch nicht, dass EQ-3 ein Interesse daran hat, das Protokoll offenzulegen. Schließlich sind die CCU Schnittstellen gut dokumentiert und werden auch von verschiedenen Smarthome Plattformen genutzt (ioBroker, OpenHab, ...). Keine Ahnung, warum man bei FHEM auf Reverse Engineering gesetzt und das Rad neu erfunden hat. War vor meiner FHEM Zeit. FHEM ging hier bisher also einen anderen Weg als die anderen großen Smarthome Plattformen.

Weil FHEM HM konnte, bevor überhaupt jemand daran gedacht hat, dass EQ-3 mal etwas offenlegen könnte. Und tatsächlich ist es in dem Rahmen auch sinnvoll. Es war vergleichsweise leicht, es zu machen und der Vorteil ist riesig. Man benötigt keinen "Zwischenwirt" (nur eine Zentrale), kann so viele IODevs verwenden, wie einem beliebt (bzw. ist der Rahmen nur schwer zu sprengen) und muss sich nicht mit der gräuseligen HM-CCU Software rumquälen (ok, das ist nun rein subjektiv aber es ist einfach vieles zu rudimentär). Für HM nutze ich noch immer NUR FHEM. Die Idee HM (ohne IP) auch auf eine CCU zu ziehen käme mir nie. Mit all den kleinen Zusatztools, die es mittlerweile gibt, schlägt FHEM die CCU um Längen.

[fiedel]

Eigentlich kann EQ3 von der Offenlegung des Protokolls nur profitieren:
Wenn es gut ist, ist es auch offen sicher - wie z.B. Veracrypt.
Mehr Leute können HMIP einfacher einsetzen und die Nachfrage steigt - nicht zuletzt wegen der besseren Zukunftssicherheit bei offenem Protokoll.
AskSin ist keine Konkurrenz, sondern ein Segen für EQ3: Eine kostenlose Quelle für neue Ideen und man könnte sich gegenseitig unterstützen.
Aber vermutlich denke ich zu blauäugig... 

[Burny4600]

Mit all den kleinen Zusatztools, die es mittlerweile gibt, schlägt FHEM die CCU um Längen.

Aus diesem Grund hatte ich mich damals für FHEM entschieden.

Anders wäre mein Projekt viel zu teuer geworden, und möglicherweise auch mit sonstiger SmartHome Lösungen bis heute nicht weiter als vor 7 Jahren.
FHEM ist für mich das Maß aller Dinge geworden, mit all dem, was ich schon alles implementiert habe.
Die Haustechnik bestand damals nur aus Stand alone Komponenten, die nicht miteinander kommunizieren konnten.

Erst als alles verknüpft wurde, konnte ich vieles erreichen, um viel an Energieaufwand einzusparen.
Gerade was das Zusammenspiel der Solaranlage mit der Heizung im Haus, Nebengebäude und dem Pool auf der einen Seite betrifft, als auch die PV-Anlage (derzeit noch ohne Batteriespeicher) für das Haus, das Nebengebäude, dem Pool und den gesamten Außenbereich.
Kleiner Projekte folgen noch, und dann folgen noch passende Visualisierungen.
Hierfür werde ich nun nicht mehr Homematic verwenden können, denn Homematic IP passt hier nicht mehr mit derzeitigem Stand der Technik in mein System.

[zap]

Weil FHEM HM konnte, bevor überhaupt jemand daran gedacht hat, dass EQ-3 mal etwas offenlegen könnte. Und tatsächlich ist es in dem Rahmen auch sinnvoll. Es war vergleichsweise leicht, es zu machen und der Vorteil ist riesig. Man benötigt keinen "Zwischenwirt" (nur eine Zentrale), kann so viele IODevs verwenden, wie einem beliebt (bzw. ist der Rahmen nur schwer zu sprengen) und muss sich nicht mit der gräuseligen HM-CCU Software rumquälen (ok, das ist nun rein subjektiv aber es ist einfach vieles zu rudimentär). Für HM nutze ich noch immer NUR FHEM. Die Idee HM (ohne IP) auch auf eine CCU zu ziehen käme mir nie. Mit all den kleinen Zusatztools, die es mittlerweile gibt, schlägt FHEM die CCU um Längen.

Nun, die Schnittstellen waren schon zu Zeiten der CCU1 offengelegt. Ich wusste nicht, dass FHEM bereits BidCos unterstützt hat, bevor EQ-3 Homematic auf den Markt brachte.

[frank]

Eigentlich kann EQ3 von der Offenlegung des Protokolls nur profitieren:

das protokoll wird vermutlich ähnlich zu bidcos sein, empfangen lässt sich ja auch scheinbar alles.
das aktuelle problem ist doch wahrscheinlich "nur" der unbekannte default key zur entschlüsselung.

[marvin78]

Nun, die Schnittstellen waren schon zu Zeiten der CCU1 offengelegt. Ich wusste nicht, dass FHEM bereits BidCos unterstützt hat, bevor EQ-3 Homematic auf den Markt brachte.

Die CCU1 gab es sehr lange. Soweit ich das im Kopf habe, waren die Schnittstellen zu Beginn nicht offengelegt und ich war ziemlich früh dabei. Selbst wenn es so war, schlägt das nicht die vielen guten Argumente für eine direkte Implementierung.

[zap]

Die CCU1 gab es sehr lange. Soweit ich das im Kopf habe, waren die Schnittstellen zu Beginn nicht offengelegt und ich war ziemlich früh dabei. Selbst wenn es so war, schlägt das nicht die vielen guten Argumente für eine direkte Implementierung.

Als Software Entwickler bekomme ich bei solchen "Lösungen" Schnappatmung und schlimmen Ausschlag 

Schnittstellen sind dazu da, genutzt zu werden. Aber gut, Zeitverschwendung, über Entscheidungen der Vergangenheit zu diskutieren.

[marvin78]

Hier wird aber ein Element als Zwischenwirt ausgespart und nicht einfach nur eine Schnittstelle nicht genutzt. Als ebenfalls ursprünglich mal Entwickler halte ich das für einen guten Weg, da es die genannten Vorteile bringt. Deine Argumentation passt nur dann, wenn du die CCU nicht weg lassen könntest. Es entfällt ein Teil, der gewartet und am Leben gehalten werden muss. Das ist durchaus sehr wünschenswert.

[Prof. Dr. Peter Henning]

Ich denke, dass man trotzdem mal ein Blueprint für die Zukunft machen sollte: Wie kann man sein HM-System in die Zukunft retten, wenn eQ3 irgendwann HM komplett abverkauft hat?

LG

pah