Autor Thema: Vergleich FHEM - IOBroker - OpenHab  (Gelesen 22613 mal)

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16043
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #60 am: 19 Februar 2018, 17:19:20 »
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.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline fiedel

  • Hero Member
  • *****
  • Beiträge: 1683
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #61 am: 20 Februar 2018, 04:39:23 »
die auf dem Markt bei weitem die vielfältigsten Möglichkeiten im Vergleich zur Konkurrenz bietet
Schreibe es Auf Papier ?  ;D  :-X
FHEM 5.7 FeatureLevel: 5.7 auf Dreamplug/Deb. 7; Perl: v5.14.2
HM: HM-CFG-USB-2 + hmland | SlowRF: CUNO V2.1/CULFW V 1.43 868
OWServer:LinkUSBi | OWDevice:DS18S20|DS2401|DS2406|DS2423

Offline marvin78

  • Hero Member
  • *****
  • Beiträge: 5199
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #62 am: 20 Februar 2018, 07:09:31 »
Könnte man meinen. Aber nein. Die Eigenschaften sind, bis auf den Einsatzzweck, aber ähnlich.

Offline Pitcher90

  • Jr. Member
  • **
  • Beiträge: 51
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #63 am: 23 April 2018, 13:36:52 »
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.

Offline supernova1963

  • Full Member
  • ***
  • Beiträge: 324
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #64 am: 04 Mai 2018, 18:51:45 »
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
Fhemserver: Mac Mini - Parallels Desktop mit Ubuntu Server 18.04,
Module: Harmony, fakeRoku, FBAHA, Fritzbox, MQTT + espBridge + TASMOTA_DEVICE, HMCCU, Nmap, ...

Offline Fonzo

  • New Member
  • *
  • Beiträge: 5
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #65 am: 08 Mai 2018, 15:37:07 »
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.

Offline Bluefox

  • New Member
  • *
  • Beiträge: 14
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #66 am: 21 August 2018, 16:37:09 »
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 :)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Per

  • Hero Member
  • *****
  • Beiträge: 1338
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #67 am: 31 August 2018, 15:34:25 »
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.

Online Nemo0815

  • Full Member
  • ***
  • Beiträge: 103
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #68 am: 01 Oktober 2018, 08:54:26 »
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.





Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16043
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #69 am: 01 Oktober 2018, 09:47:31 »
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.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2282
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #70 am: 02 Oktober 2018, 09:04:29 »
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.
CCU3 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
IOBroker VIS
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU2 - FHEM = best of both worlds approach)

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2463
  • Anti-Statement befreite Zone ;)
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #71 am: 02 Oktober 2018, 10:01:45 »
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?
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline raimundl

  • Full Member
  • ***
  • Beiträge: 333
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #72 am: 02 Oktober 2018, 10:03:50 »
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
« Letzte Änderung: 02 Oktober 2018, 10:13:14 von raimundl »
Homematic: Licht, Heizung, Alarm,... auf einen RaspberryPi3 mit OS "Stretch" und HM-MOD-RPI-PCB, ca. 30 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes, ....

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2282
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #73 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.

Ü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
« Letzte Änderung: 02 Oktober 2018, 15:12:48 von zap »
CCU3 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
IOBroker VIS
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU2 - FHEM = best of both worlds approach)

Offline raimundl

  • Full Member
  • ***
  • Beiträge: 333
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #74 am: 02 Oktober 2018, 19:52:55 »
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,... auf einen RaspberryPi3 mit OS "Stretch" und HM-MOD-RPI-PCB, ca. 30 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes, ....