Vergleich FHEM - IOBroker - OpenHab

Begonnen von zap, 24 Dezember 2017, 11:19:28

Vorheriges Thema - Nächstes Thema

CoolTux

Da ich nur FHEM kenne und weiß das es damit geht würde ich sagen damit. Was er selber an Konfiguration nicht tanzen kann, kann er ja als KnowHow dazu kaufen, macht er ja mit seiner derzeit magenta farbenen Schlüpper auch schon. Nur das mit FHEM mehr geht und bei Problemen schneller reagiert wird.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

fiedel

Zitat von: marvin78 am 19 Februar 2018, 07:44:31
die auf dem Markt bei weitem die vielfältigsten Möglichkeiten im Vergleich zur Konkurrenz bietet
Schreibe es Auf Papier ?  ;D  :-X
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

marvin78

Könnte man meinen. Aber nein. Die Eigenschaften sind, bis auf den Einsatzzweck, aber ähnlich.

Pitcher90

Tut sich hier noch was? Fand den Vergleich bisher sehr gut. Zumal ich viele Erfahrungen von dir, wie z.B. das Problem mit Tablet-UI und Sonos auch gemacht habe.
Arbeite schon seit drei Jahren mit FHEM. Seit vier Monaten beschäftige ich mich mit ioBroker und habe schon viele Konstellationen durch. Geräte in FHEM, Logik und Visualisierung in ioBroker; ioBroker nur als Visualisierung und FHEM für den Rest.
Zum Schluss bleibt aber doch alles bei FHEM. Allein schon wegen den CUL-Gateways.
Wenn man komplett am Anfang steht ist es mit Sicherheit einfacher sich für ein anderes System als FHEM zu entscheiden, da man sich dann auch nur Geräte aussucht, die mit dem jeweiligen System kompatibel sind. Nach drei Jahren FHEM mit viel Erfahrungen, fällt das ungleich schwerer, da einem am neuen System direkt die Unzulänglichkeiten auffallen, die man bei FHEM nicht hatte.

supernova1963

Auch ich hoffe auf weitere Erfahrungsberichte. Bisher kann ich die Erfahrungen von zap nahezu 1:1 teilen.
Nur alle 3 Systeme wollte ich nicht unter OS X gemeinsam installieren. Hier habe ich 3 identische Ubuntu Server VM unter Parallels angelegt. Hier ist auch die Installation von openHab mit snap wirklich super einfach.
Im laufenden Betrieb meine ich, dass ioBroker die meisten Ressourcen benötigt. Gefolgt von openHab und FHEM. Täuscht der Eindruck, oder könnt ihr das bestätigen?

lg

Gernot

Fonzo

Zitat von: supernova1963 am 04 Mai 2018, 18:51:45
Im laufenden Betrieb meine ich, dass ioBroker die meisten Ressourcen benötigt. Gefolgt von openHab und FHEM. Täuscht der Eindruck, oder könnt ihr das bestätigen?
So ist zumindest auch mein Eindruck, FHEM ist klein und schlank, ioBroker braucht von den drei Systemen am meisten Ressourcen, vor allem Speicher.

Bluefox

Zitat von: Fonzo am 08 Mai 2018, 15:37:07
So ist zumindest auch mein Eindruck, FHEM ist klein und schlank, ioBroker braucht von den drei Systemen am meisten Ressourcen, vor allem Speicher.
God sei dank die Zeiten von Taschenrechnern sind vorbei :)

Per

Ich finde es interessant, dass über die Konfiguration u.a. diskutiert wird, aber die eigentliche Aufgabe bei der Hausautomatisation sind die Prozesse, wie wer wann miteinander und aufeinander reagiert. Und das ist nicht in 5 min zusammengeklickt (außer dem Piepser, dass die Waschmaschine fertig ist). Allein eine Außenbeleuchtung tageszeit-, wochentags-, jahreszeit- und helligkeitsabhängig zu schalten, Anwesenheit, Fremdauslösung, Notfall und anderes kommt noch dazu.
Zu sowas würde mich mal ein Vergleich interessieren. In Fhem mache ich das mit einem (zugegebenermaßen recht großen) DOIF oder einer Handvoll notify, bei HM breche ich mir einen ab, die anderen Systeme kenne ich nicht.

Nemo0815

Ich wollte am Wochenende eigentlich anfangen auf OpenHab umzusteigen - auch aufgrund der vielen positiven Berichte.

Begonnen habe ich damit das Raspberry Pi image runterzuladen, einfach auf ne SD Karte und in den Raspi, ist schonmal alles installiert - super!

Dann der erste Start ins Paper UI und erstmal ein Binding für meine WifiLEDs erstellt. Es werden dann auch tatsächlich automatisch die 5 Geräte (sogar LD686) gefunden und angezeigt. Sieht alles top modern aus.

Dann habe ich mal auf "On" geklickt und es passierte - nichts. Ich konnte keine der Lampen steuern. Erst nach mehrmaligem löschen und nochmal erstellen (und dazwischen mit der Magic Light App am Handy spielen) hat es dann irgendwann geklappt, keine Ahnung wieso.

Also nächstes dann kamen meine 4 MiLights die über nen ESP MiLight Hub verunden sind. Binding installiert, und sofort werden auch die 4 konfigurierten Lampen angezeigt, allerdings nur eine wird als "Online" angezeigt, alle restlichen bleiben in "Initializing" hängen. Dazu gibt es eine nichtssagende Warnmeldung im Log. Auch Google brachte keine Hilfe zu dem Problem. Anscheinend liegt es aber daran dass ich unterschiedliche Ports verwende um mehrere Lampen getrennt ansprechen zu können. Die funktionierende Lampe hatte den default Port verwendet und wurde deswegen gefunden, die anderen 3 hatten unterschiedliche Ports konfiguriert, was dem Binding anscheinend nicht geschmeckt hat. Man kann zwar in den Settings einen Custom Port eintragen, allerdings brachte auch das keine Lösung des Problems.

Ich bin also gezwungen hier entweder komplett auf MQTT umzustellen oder mir eine andere Lösung zu suchen.

Ok, Problem erstmal beiseite gelegt und als nächstes mal die FS20 Komponenten einbinden, also das FS20 Binding anklicken und schon installiert es sich.
Das wars aber auch mit der schönen GUI. Denn das FS20 binding basiert noch auf openHAB 1 und muss daher komplett unter der Console/Kommandozeile auf dem Raspi konfiguriert werden. Dabei gibt es keinen zentrale Konfig, sondern man muss sich manuell - von Hand - verschiedene Files erstellen, welche noch dazu in verschiedenen Ordnern auf dem Raspi liegen.
Wo sie liegen steht nicht in der Hilfe, und auch was man eintragen muss bekommt man nur per Google aus Forenbeiträgen zusammen. Also alles nach irgendwelchen Beispielen eingetragen, dann noch openHab erlauben überhaupt auf USB devices zuzugreifen (hier muss wiederum ein Konfigfile geändert werden, wobei in der Hilfe zwar steht was geändert werden soll, aber nicht wo sich die Konfig befindet, also wieder googeln.

Es sollte jetzt eigentlich alles soweit funktionieren, zumindest hab ich es genauso gemacht wie in diversen Forenbeiträgen zu lesen ist, schalten kann ich aber trotzdem nicht. Auch sieht man im normalem Log keine Empfangenen Geräte (HMS o.Ä., nachdem das HMS Binding installiert wurde!), weder in Karaf noch in der GUI.

Dann dasselbe Spiel mit den IT Steckdosen. Auch hier gibt es ein Binding, auch hier nur ein openHab 1.x. Also alles von Hand zusammenschreiben.

Ich bin jetzt erstmal wieder bei FHEM. Hier muss ich zwar das meiste von Hand anlegen, aber zumindest weiss man was gerade nicht stimmt und wo die entsprechenden Geräte konfiguriert werden (und kann diese Konfig jederzeit ändern ohne sich auf den Rechner einloggen zu müssen).

Evtl. weiss ich noch zu wenig über openHAB, aber dass selbst die einfachsten "Things" (Lampen) solche Probleme bereiten und die Doku hier auch nicht sehr hilfreich ist, schreckt mich schon sehr stark davon ab jetzt noch umzusteigen.





CoolTux

Zitat von: Nemo0815 am 01 Oktober 2018, 08:54:26
Evtl. weiss ich noch zu wenig über openHAB, aber dass selbst die einfachsten "Things" (Lampen) solche Probleme bereiten und die Doku hier auch nicht sehr hilfreich ist, schreckt mich schon sehr stark davon ab jetzt noch umzusteigen.

<ironie on>
Aber Du musst zugeben, es sieht schick und modern aus  ;D
<ironie off>
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

zap

Mal zum aktuellen Stand meines Umzugsprojektes, das mangels Zeit noch nicht abgeschlossen ist:

Auf meinem MacMini läuft seit geraumer Zeit IOBroker mit dem FHEM Adapter. Nach wie vor ist ein Großteil meiner Smarthome Umgebung in FHEM integriert. Insbesondere die zahlreichen Homematic Geräte der CCU3 sind nach wie vor per HMCCU an FHEM angebunden. IOBroker nutze ich für die Oberfläche. Vis ist m.E. derzeit die beste Oberfläche für Smarthome. Außerdem habe ich SONOS von FHEM auf IOBroker migriert, da das SONOS Modul unter FHEM immer mehr Probleme machte.

Mein Fernziel ist nach wie vor, alles in IOBroker oder OpenHab zu migrieren. Da ich keinen BigBang machen kann und will, fehlt mir in OpenHab derzeit der FHEM Adapter. Den müsste ich selbst entwickeln, wobei ich Java noch mehr hasse als Python. Aber vielleicht ergibt sich mit MQTT eine Möglichkeit. Weiteres Kriterium derzeit: Weder der Homematic Adapter von IOBroker noch der von OpenHab kann das, was mein FHEM Modul HMCCU kann. Da müsste ich vermutlich Abstriche machen.

Demnächst steht jetzt erst mal die Alexa Migration auf IOBroker an. Mit der neuen IOBroker Version bieten sich gerade bei Alexa enorme Möglichkeiten, die ich bei der Alexa FHEM Integration schon lange vermisse. Danach kommen die Hue und OSRAM Lampen dran und dann ... mal sehen.

@Nemo0815: Im Zweifel würde ich bei Problemen mit OpenHab so vorgehen, wie Du es auch bei FHEM machen würdest. Frag die Community! Du bekommst mindestens genauso schnell Hilfe wie im FHEM Forum.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Amenophis86

Zitat von: zap am 02 Oktober 2018, 09:04:29
Demnächst steht jetzt erst mal die Alexa Migration auf IOBroker an. Mit der neuen IOBroker Version bieten sich gerade bei Alexa enorme Möglichkeiten, die ich bei der Alexa FHEM Integration schon lange vermisse. Danach kommen die Hue und OSRAM Lampen dran und dann ... mal sehen.

Zum Beispiel?
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

raimundl

#72
Zitat von: zap am 02 Oktober 2018, 09:04:29
Mal zum aktuellen Stand meines Umzugsprojektes, das mangels Zeit noch nicht abgeschlossen ist:

Ich verfolge dein "Umzugsprojekt" sehr interessiert und bin aufgrund der Diskussionen unt Entwicklungen (HMIP) zu folgender Ansicht gekommen:
Das beste wäre eigentlich alle "Homematic-Geräte" in einer CCU3 ("nativ") zu betreiben und nur wo notwendig eine Verbindung (HMCCU) mit Fhem oder vielleicht einmal einen anderen Paket herzustellen.
Siehe auch: https://forum.fhem.de/index.php/topic,80170.msg839618.html#msg839618
Geringerer Wartungsaufwand mehr Flexibilität - Übersiedlung von ca. 30 Homematic-Geräten (von fhem nach CCU3) sehr grosser Aufwand!

LG
Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....

zap

#73
Genauso mache ich es ja jetzt schon. Alles Homematic interne läuft in der CCU3 bzw per direkt verknüpfter Sensoren/Aktoren. In FHEM bzw HMCCU erfolgt die Verknüpfung mit der Nicht-Homematic Welt, sofern notwendig.

Übrigens spricht seit Einführung der CCU3 und der damit deutlich gesteigerten Performance nichts dagegen, sowohl von HMCCU als auch IOBroker aus parallel die CCU3 per RPC Server einzubinden. Bei mir sieht das derzeit so aus:

FHEM/HMCCU <--> CCU3 <--> IOBroker/HM-Adapter

FHEM <--> IOBroker/FHEM-Adapter <--> IOBroker/VIS
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

raimundl

Zitat von: zap am 02 Oktober 2018, 15:02:34
Genauso mache ich es ja jetzt schon. Alles Homematic interne läuft in der CCU3 bzw per direkt verknüpfter Sensoren/Aktoren. In FHEM bzw HMCCU erfolgt die Verknüpfung mit der Nicht-Homematic Welt, sofern notwendig.

Hallo zap!
Danke, genauso habe ich es mir gedacht. Jetzt muss ich mich entscheiden, ob ich ca. 30 HM Geräte auf eine original CCU3 portiere oder meine erworbene RPI-RF-MOD mit einem Raspi verwende.
Wenn ich nun wirklich übersiedle, tendiere ich zu einer originalen CCU3 aus Zukunftssicherheit.
Stelle mir vor, dass das Übersiedeln nur mit neu Anlernen jedes Gerätes funktioniert?

LG
Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....