FHEM Forum

Verschiedenes => Off-Topic => Thema gestartet von: zap am 24 Dezember 2017, 11:19:28

Titel: Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 24 Dezember 2017, 11:19:28
Der Plan:

Gegen die Langeweile an Weihnachten und als Kontrast zum öden TV Programm werde ich mal einen ausgedehnten Vergleichstest der drei o.g. Lösungen starten. Dazu habe ich meinen alten MacMini 2010 ausgebuddelt, auf 8 GB Speicher aufgerüstet und MacOS High Sierra installiert.

Die Tests mit Links zu den Beiträgen:
Demnächst:

Zu den Beweggründen:

Ich suche seit langem eine schöne, übersichtliche und leicht zu konfigurierende Oberfläche für meine Smarthome Steuerung. FHEM selbst bietet hier m.E. nur veraltete bzw. komplizierte Lösungen. TabletUI kommt meinen Anforderungen noch am nächsten, ist jedoch sehr aufwändig zu konfigurieren und der Entwickler neigt dazu, durch Änderungen in CSS Definitionen o.ä. bei Updates das mühevolle ausgeklügelte Layout zu zerstören, was dann zu tagelangen Korrekturen beim Anwender führt.

Mögliche Lösungen:
Die erste Idee war, IOBroker als Frontend zu benutzen. Da habe ich mir allerdings die Frage gestellt: warum dann FHEM als "Durchlauferhitzer" und nicht gleich alles auf IOBroker umziehen? Oder eben auf OpenHab. Und genau das werde ich jetzt mal ausgiebig testen.

Im ersten Schritt habe ich nun FHEM, IOBroker und OpenHab parallel auf dem MacMini installiert. Im nächsten Schritt werde ich die für mich wichtigsten Funktionen in alle drei Plattformen einbinden:
Ich werde in lockerer Folge in diesem Thread von meinen Ergebnissen berichten. Ggf. werde ich mir auch noch Indigo und IP-Symcon als kostenpflichtige Lösungen anschauen.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: slor am 24 Dezember 2017, 11:44:14
Super cool! Wollte ich auch schon immer Mal machen, nur nie Zeit gefunden.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 25 Dezember 2017, 10:43:15
Teil 1 - Installation

Die hier beschriebenen Erfahrungen beziehen sich ausschließlich auf die Installation! Sie geben meine subjektive Meinung in meiner Smarthome-Umgebung wieder.

Generell bin ich so vorgegangen, dass ich für FHEM, IOBroker und OpenHab jeweils eigene User angelegt habe. Unter diesen Usern werden die Programme ausgeführt.

FHEM

Die Installation von FHEM ist recht einfach und gut beschrieben. Entsprechend problemlos war es, FHEM unter MacOS zu installieren. Lediglich für den Autostart beim Booten musste ich etwas basteln. Schwieriger für einen Einsteiger ist da schon die Abhängigkeit zu diversen Perl-Modulen. Das kann schnell in Frustration enden, wenn erst mal gar nichts geht und man anhand des FHEM Logfiles herausfinden muss, welche Perl Module fehlen. Die müssen dann erst mal über CPAN oder einen Paketmanager nachinstalliert werden.

Wertung: Für Einsteiger bzw. Leute ohne Linux Erfahrung ist die Hürde bei FHEM recht hoch. Ein "einfach loslegen" ist aufgrund der Abhängigkeiten zu Perl Modulen nicht möglich.

IOBroker

Als Voraussetzung muss zunächst NodeJS installiert werden, was problemlos ablief. Bei der IOBroker Installation zeigte sich dann, dass die Macher von IOBroker vermutlich kein MacOS im Einsatz haben. Die Installation nach der Beschreibung auf der IOBroker-Webseite funktioniert schlichtweg nicht. Erst eine Installation mit npm direkt von Github war schließlich erfolgreich. Die Installation unter Linux dürfte einfacher sein. IOBroker konnte danach erfolgreich gestartet werden und der Zugriff per Webinterface war möglich. Im Admin-Interface werden die integrierbaren Gerätetypen übersichtlich präsentiert (s. Screenshot).

Wertung: Die Dokumentation scheint nicht immer aktuell zu sein. Einmal richtig ausgeführt, ist die Installation problemlos. Positiv ist, dass keine andere Software nachinstalliert werden muss, um IOBroker nutzen zu können. Die Installation der einzelnen Plugins erfolgt transparent für den Nutzer ohne frickelige manuelle Aktionen.

OpenHab

OpenHab wird mit Java entwickelt. Daher muss man zunächst das JDK installieren. Die OpenHab Installation beschränkt sich auf das Auspacken des Zip-Files. Danach kann OpenHab gestartet und über das Webinterface administriert werden. Auch hier fällt wie bei IOBroker die aufgeräumte Oberfläche auf. Eine Installation der AddIns und Bindings für die Einbindung von Geräten ist über das Webinterface sehr einfach möglich. Man muss keine Software manuell nachinstallieren. Ein kleiner Wermutstropfen: Ich habe es bisher nicht geschafft, OpenHab über den launch daemon von MacOS zu starten.

Wertung: OpenHab macht einen sehr reifen Eindruck. Die Dokumentation ist top, gut strukturiert und sehr detailliert.
Eigentlich bin ich kein Freund von Java Anwendungen, OpenHab ist aber ein positives Beispiel. Sehr gut gefällt mir die Suche nach Addins und Bindings. Das ist bei der großen Zahl an Addins/Bindings auch notwendig.

Fazit Teil 1 - Installation

OpenHab hat für mich bei der Installation die Nase vorn. Auspacken, starten und loslegen. Dazu eine sehr gute Doku. Das passt! Dicht dahinter kommt IOBroker. Das hat für mich das meiste Potenzial und nutzt mit NodeJS eine moderne Laufzeitumgebung. Ist halt im Vergleich zu OpenHab ein Newcomer. FHEM sehe ich hier leider nur auf Platz 3 v.a. aufgrund dem leidigen Thema Nachinstallation von Perl Modulen. Schade ist auch, dass FHEM dem Einsteiger erst mal nur eine "leere" Umgebung präsentiert und sich der Nutzer erst mal in der Doku auf die Suche nach verfügbaren Modulen begeben muss.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: C0mmanda am 25 Dezember 2017, 11:57:19
Sehr coole Idee die ich gerne mitverfolge.

Hatte mir für den Weihnachtsurlaub auch vorgenommen mal über den Tellerrand zu schauen und mir Openhab und Konsorten mal näher anzuschauen.
Hauptsächlich aus den selben Gründen.
Eine moderne GUI ohne das ganze Gefrickel (TabletUI) geht mir momentan sehr ab.
Langsam vergeht mir die Lust immer wieder zeitaufwändige Anpassungen vornehmen zu müssen.

Grtz
CmdA
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Fixel2012 am 25 Dezember 2017, 13:01:02
Auch ich finde, dass ist ein sehr Interessantes Thema!

Freue mich über weitere Updates!
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: fiedel am 26 Dezember 2017, 11:19:50
Finde das Vorhaben gut und ambitioniert. Habe mich daher aber auch gewundert, warum du dafür MacOS und nicht Linux einsetzt. Wie du schon selbst bemerkst, ist auf MacOS doch einiges speziell und verzerrt ggf. die Vergleichbarkeit.

Gruß
Frank
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 26 Dezember 2017, 12:10:05
Finde das Vorhaben gut und ambitioniert. Habe mich daher aber auch gewundert, warum du dafür MacOS und nicht Linux einsetzt. Wie du schon selbst bemerkst, ist auf MacOS doch einiges speziell und verzerrt ggf. die Vergleichbarkeit.

Gruß
Frank

Ich hatte sowieso vor, meine Smarthome Installation vom Raspi auf den MacMini umzuziehen, da der Raspi ziemlich am Ende ist (Performance und Speicher). Da läuft neben FHEM noch Alexa, Homematic Virtual Layer, ein Apache Server drauf.
Unter MacOS hatte ich bisher nur kleinere Installationsprobleme bei IOBroker und dazu noch das Thema Autostart bei OpenHab. Das sind aber einmalige Dinge die sich auch fixen lassen. Deshalb werde ich die Tools nicht schlechter bewerten und das wird auch nicht ausschlaggebend für meine finale Entscheidung für die eine oder andere Plattform sein. Wichtig ist mir die Funktionalität, die Einbindung von verschiedenen Gerätetypen und v.a. die Darstellbarkeit in einer Web- bzw. Tablet-Oberfläche.

Niemand sollte hier einen objektiven Vergleich erwarten. Das bezieht sich alles auf meine subjektiven Erfahrungen in meiner Umgebung. Es kann durchaus sein, dass jemand, der z.B. EnOcean oder FS20 nutzt, mit FHEM viel besser fährt. Habe ich aber nicht und kann ich daher auch nicht testen.

Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: krikan am 26 Dezember 2017, 12:33:47
Schade ist auch, dass FHEM dem Einsteiger erst mal nur eine "leere" Umgebung präsentiert und sich der Nutzer erst mal in der Doku auf die Suche nach verfügbaren Modulen begeben muss.
Könntest Du das bitte ein wenig ausführen. Bei den anderen Systemen werden doch auch nicht automatisch Hardwaresysteme eingebunden und die Umgebung ist "leer"; ohne Doku kann ich bspw. in openhab kein ZWave nutzen. Oder geht es dabei nur um die Ermittlung von fehlenden Perl-Paketen bzw. um eine Auflistung von Hardware XY = nutze Modul XY?

Gruß, Christian
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 26 Dezember 2017, 12:48:04
Könntest Du das bitte ein wenig ausführen. Bei den anderen Systemen werden doch auch nicht automatisch Hardwaresysteme eingebunden und die Umgebung ist "leer"; ohne Doku kann ich bspw. in openhab kein ZWave nutzen. Oder geht es dabei nur um die Ermittlung von fehlenden Perl-Paketen bzw. um eine Auflistung von Hardware XY = nutze Modul XY?

Gruß, Christian

Es geht um die Auflistung der unterstützten Geräte und die automatische Installation abhängiger Pakete (sofern welche benötigt werden). Siehe dazu auch die Screenshots von IOBroker und OpenHab in Teil 1 - Installation. Schön ist halt, dass man einfach in ein Suchfeld z.B. Homematic oder Sonos eingeben kann und im nächsten Schritt das entsprechende Plugin installieren kann, inklusive aller Abhängigkeiten. Darauf werde ich in Teil 2, der SONOS Integration noch eingehen.

Dass man je nach Komplexität der Hardware/Addons/Module eine Doku braucht ist unstrittig und hängt auch ein Stück weit davon ab, wie einfach der Modulautor die Integration gestaltet hat. Das ist aber bei allen drei Lösungen so.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 26 Dezember 2017, 15:33:47
Teil 2 - Integration von SONOS

Die hier beschriebenen Erfahrungen beziehen sich ausschließlich auf die Integration von SONOS Komponenten! Sie geben meine subjektive Meinung in meiner Smarthome-Umgebung wieder.

Ich habe folgende SONOS Player im Einsatz: 4 x Play1, 1 x Play5. Bei diesem Test ging es mir um die grundsätzliche Integration von SONOS sowie das Verhalten, wenn ein Player vom Strom getrennt wird.

FHEM

Die SONOS Einbindung in FHEM erfolgt mit dem Modul SONOS. Voraussetzung ist, dass man vorher die notwendigen Perl-Module installiert. Andernfalls schlägt die Defintion der Player fehl. Man definiert einen SONOS Player mit dem für FHEM üblichen define Befehl und erhält als Ergebnis (sehr) viele Devices unterschiedlicher Typen (SONOS, SONOSPLAYER, ReadingGroups usw.) mit (sehr) vielen Readings, von denen man im Normalbetrieb nur einen Bruchteil benötigt. Die vielen Devices sind erforderlich, um in der Standard FHEM Oberfläche eine einigermaßen komfortable Bedienoberfläche bereitzustellen (s. Screenshot FHEM_Sonos_Control).
Dazu kommen Unmengen von Set/Get Befehlen, um die Geräte zu steuern. Weniger wäre hier mehr. Einen neuen Nutzer verwirrt das eher als dass es hilft. Hier wäre eine Wahlmöglichkeit zwischen Basis- und Expertenmodus hilfreich.
Wer seine SONOS Player über ein separates Frontend (z.B. TabletUI) steuern möchte, benötigt eigentlich nur die Player-Devices. Hier wäre es vorteilhaft, wenn man bereits beim ersten Define angeben könnte, ob man nur die Player haben möchte oder die Rundumglücklich-Lösung.

Als Beispiel die defines für einen Player:
define d_sonhome_Kueche SONOSPLAYER RINCON_5CAAFD4224A601400_MR
define d_sonhome_KuecheRG readingsGroup d_sonhome_Kueche:<{SONOS_getCoverTitleRG($DEVICE)}@infoSummarize2>
define d_sonhome_KuecheRG_Favourites readingsGroup d_sonhome_Kueche:<{SONOS_getListRG($DEVICE,"Favourites",1)}@Favourites>
define d_sonhome_KuecheRG_Radios readingsGroup d_sonhome_Kueche:<{SONOS_getListRG($DEVICE,"Radios",1)}@Radios>
define d_sonhome_KuecheRG_Playlists readingsGroup d_sonhome_Kueche:<{SONOS_getListRG($DEVICE,"Playlists")}@Playlists>
define d_sonhome_KuecheRC remotecontrol
define d_sonhome_KuecheRC_Notify notify d_sonhome_KuecheRC set d_sonhome_Kueche $EVENT
define d_sonhome_KuecheRC_Weblink weblink htmlCode {fhem("get d_sonhome_KuecheRC htmlcode", 1)}

Leider funktioniert die SONOS-Integration seit einigen Monaten nur noch schlecht bzw. läuft instabil, insbesondere wenn man Player zeitweise vom Strom trennt. Dann wird das FHEM-Logfile permanent mit Fehlern vollgeschrieben und irgendwann funktioniert die Steuerung der noch aktiven Player gar nicht mehr. Dann hilft nur noch ein Neustart von FHEM.

Wertung: Das SONOS-Modul in FHEM lässt was Konfigurierbarkeit und Funktionsumfang angeht keine Wünsche offen. Wenn man Player nur steuern möchte, gilt eher: Nicht alles was machbar ist, macht auch Sinn. Aufgrund der vielen Probleme insbesondere bei temporärerem Ausschalten von Playern ist das SONOS Modul in FHEM für mich nur noch (sehr) eingeschränkt nutzbar. Da die Probleme schon seit Monaten bekannt sind, erscheint es mir unwahrscheinlich, dass sie zeitnah behoben werden.

IOBroker

Die Installation des SONOS-Adapters aus der Weboberfläche heraus gestaltet sich einfach. Man gibt im Suchfeld Sonos ein und klickt auf den Install Button. Während der Installation wird ein Fenster geöffnet, in dem die Ausgabe der ausgeführten npm Befehle angezeigt wird. Nach Abschluss der Installation öffnet sich ein Fenster, in dem einige Einstellungen des Adapters festgelegt werden können (s. Screenshot IOBroker_Sonos_Adapter). Hier gibt es auch einen Button, über den man eine Suche nach Playern starten kann.

Leider erkennt der Adapter Player nicht automatisch, d.h. man muss immer explizit danach suchen lassen. Die Suche arbeitet unzuverlässig. Wenn 2 Player zu einem Stereopaar verbunden sind, wird nur einer der Player gefunden. Außerdem wurde bei meinen Tests immer ein Player mit der IP Adresse 0.0.0.0 gefunden, der jedoch über keinerlei Funktion verfügte. Unschön ist auch, dass gefundene Player nur mit ihrer IP-Adresse angezeigt werden. Den Namen und den Raum muss man manuell eintragen. Wenn ein Player nicht gefunden wird, kann man ihn manuell durch Eingabe der IP-Adresse hinzufügen. Man sollte also wissen, welche IP welchem Player gehört.

Nach dem Abspeichern der Adapter-Konfiguration symbolisiert ein grüner Kreis vor dem Adapternamen, dass der Adapter funktioniert. Die Player und ihre Attribute findet man im Reiter "Objekte" (s. Screenshot IOBroker_Sonos_Objekte). Die Werte bzw. Zustände der Attribute findet man im Reiter "Zustände".

Der SONOS Adapter bringt eine Weboberfläche zur Steuerung der Player mit (s. Screenshot IOBroker_Sonos_Control). Diese ist weitgehend identisch mit der Oberfläche der SONOS-App. Man muss also nicht erst ein Dashboard in IOBroker definieren, um die Basisfunktionen eines Players nutzen zu können.

Das Ausschalten eines Players wird vom Adapter nicht erkannt, d.h. der Player steht weiterhin auf active = true. Bei einem Druck auf den Play Button passiert erwartungsgemäß nichts, es wird auch keine Fehlermeldung angezeigt. Nach dem Einschalten kann der Player jedoch ohne weitere Maßnahme wieder genutzt werden.

Wertung: Wie vieles bei IOBroker scheint auch der SONOS Adapter sich noch in einem Beta Stadium zu befinden. Insbesondere die fehlende Erkennung von Player-Name und Raum macht die Einrichtung sehr umständlich. Der Adapter erkennt nicht, wenn ein Player vom Strom genommen wird. Dies ist noch schlechter gelöst als in FHEM, wo zumindest der Player als "disappeared" angezeigt wird.

OpenHab

Die Integration von SONOS Playern in OpenHab erfolgt über die Weboberfläche PaperUI. Sobald man das SONOS-Bindung aktiviert hat, erscheinen die gefundenen Player in der Inbox von OpenHab. Von dort können sie in die aktive Konfiguration übernommen werden und finden sich dann unter der Rubrik "Things" (s. Screenshot OpenHab_Sonos_Things). OpenHab findet alle Player, auch gruppierte oder Stereopaare. Die Player werden mit Name und IP-Adresse erkannt.

Mit einem Klick auf einen Player unter "Things) wird die Liste der verfügbaren Channels angezeigt (s. Screenshot OpenHab_Sonos_Channels). Der Channel "Control" dient der Steuerung eines Players, während andere Channels wie Current Artist mit Readings in FHEM vergleichbar sind. Zu jedem benötigten Channel erzeugt man ein Item und verbindet es mit dem Channel (s. Screenshot OpenHab_Sonos_Link). Das ist mit ein paar Mausklicks erledigt. Ich habe ein Item für die Steuerung und ein weiteres für die Anzeige des aktuellen Titels angelegt. Danach konnte ich den Player in der Weboberfläche steuern (s. Screenshots OpenHab_Sonos_Control). Leider sind in der Weboberfläche PaperUI nicht alle Parameter eines Players auswählbar. Fehlende Parameter müssen über Konfigurationsdateien eingebunden werden.

Eine Trennung vom Stromnetz hat problemlos funkioniert. Der entsprechend Player wird dann einfach als "offline" angezeigt. Nach dem Einschalten erkennt OpenHab den Player wieder als "online".

Wertung: Die Einbindung eines SONOS-Players in OpenHab ist sehr einfach über das Webinterface möglich. Mit ein paar Mausklicks hat man eine funktionale, auf die persönlichen Bedürfnisse zugeschnittene Steuerung ohne Overhead implementiert. Schade ist, dass einige Parameter nicht über das Webfrontend eingebunden werden können.

Fazit Teil 2 - SONOS Integration

Am besten gefällt mir die SONOS-Integration in OpenHab. Hier kommt man am schnellsten ans Ziel. Die Player werden inklusive Raum und Name gefunden und alle wichtigen Attribute stehen zur Verfügung. Allerdings ist je nach benötigtem Parameter manuelle Nacharbeit notwendig. Der SONOS-Adapter in IOBroker muss noch etwas reifen und bietet keine Verbesserung gegenüber FHEM. Negativ fällt v.a. die manuelle Konfiguration der Playernamen auf. Das SONOS Modul in FHEM ist für mich aufgrund der aktuellen oben beschriebenen Probleme eigentlich nicht mehr nutzbar. Daher würde ich, selbst wenn ich bei FHEM bleiben sollte, für die SONOS-Integration eine andere Lösung verwenden (z.B. IOBroker mit FHEM Adapter oder Homematic Virtual Layer).

P.S. Teil 3 - Homematic dürfte etwas aufwändiger werden, daher bitte etwas Geduld.

Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: krikan am 26 Dezember 2017, 15:53:04
Leider funktioniert die SONOS-Integration seit einigen Monaten nur noch schlecht bzw. läuft instabil, insbesondere wenn man Player zeitweise vom Strom trennt. Dann wird das FHEM-Logfile permanent mit Fehlern vollgeschrieben und irgendwann funktioniert die Steuerung der noch aktiven Player gar nicht mehr. Dann hilft nur noch ein Neustart von FHEM.
Hast Du das mit der aktuellen Version der SONOS-Module getestet (im update seit 24.12.) oder sind das Vergangenheitserfahrungen?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: herrmannj am 26 Dezember 2017, 16:02:21
ich finde den Vergleich (hier im FHEM forum) auf der einen Seite schon in gewisser Weise "mutig" (neutraler Boden sieht anders as ;)) aber auch sehr gut !!!

(Sonos scheint, den logs nach die ich so sehe) auch nicht die.... stabilste... Möglichkeit zu sein FHEM zu betreiben ;)


Mach weiter, bin gespannt !
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: krikan am 26 Dezember 2017, 16:11:58
(Sonos scheint, den logs nach die ich so sehe) auch nicht die.... stabilste... Möglichkeit zu sein FHEM zu betreiben ;)
Scheint systemabhaengig zu sein. Hier laeuft die nicht gerade kleine SONOS-Installation seit Jahren problemlos; auch mit Aus- und Einschalten, Sprachausgaben usw.
Lese im Forum aber auch, dass teilweise Probleme existier(t?)en.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 26 Dezember 2017, 16:33:54
@krikan, herrmanj

Die Sonos vom 24.12. habe ich nicht installiert. Das letzte Update habe ich so um den 20.12. gemacht. Ich hole das aber nach und werde den Testbericht korrigieren, wenn das Problem damit behoben ist. Der Fehler tritt sowohl bei meiner produktiven Umgebung unter Raspbian Stretch auf als auch in der neu aufgesetzten Testumgebung unter MacOS.

Generell zu dem Vergleichstest: habe mir ja extra den Off Topic Bereich ausgesucht. Wenn ihr als Moderatoren aber der Meinung seid, dass das hier nichts verlorenen hat, werde ich die Beiträge löschen bzw. durch einen Link auf eine Wordpress Seite ersetzen. Die könnte ich kurzfristig einrichten.

Allerdings weiß ich, dass es vielen Usern hier so geht wie mir und sie mit dem Gesanken spielen, zumindest für die Darstellung IOBroker Vis einzusetzen.

Ich kann nur nochmal darauf hinweisen, dass das hier meine persönliche Meinung und Erfahrung in meiner Smarthome Umgebung ist. Für,andere User mögen ganz andere Dinge für die Wahl der Plattform ausschlaggebend sein. Trotzdem ist es sicher mal interessant zu sehen, wie das andere Plattformen umsetzen. Und vielleicht holt soch der eine oder andere FHEM Entwickler die eine oder andere Anregung ;-)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: krikan am 26 Dezember 2017, 16:48:59
Also von meiner Seite gilt genauso wie von Joerg: Mach hier weiter! Interessiert mich.  :)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Amenophis86 am 26 Dezember 2017, 18:49:28
Mich interessiert es auch, daher hoffe ich, dass du weiter machst. Und im besten Fall kann man aus der ein oder anderen Sache noch etwas für FHEM lernen oder dran verbessern :)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: ext23 am 26 Dezember 2017, 19:07:42
Es wäre ganz gut noch etwas mehr Augenmerk auf die mögliche Flexibilität zu legen. FHEM ist nun wirklich keine Augenweide, auch wenn ich die Schlichtheit mag. Aber im Prinzip lässt FHEM auch alles zu was geht. Wie sieht es denn bei den anderen Systemen aus, kann man da leicht komplexe Funktionen einbauen oder ist es aller CCU2, "Wenn das tue das", sprich nur simple Sachen ...

Wie sieht es mit Modulen aus, gibt es hier bei den anderen Systemen saubere Anleitungen? Oder ist es ähnlich "schlecht" wie bei FHEM, hier ist ja Copy und Paste Standard ...

Weil Installation etc. finde ich persönlich eher langweilig. Das macht man in der Regel genau ein mal, ob das nun kompliziert ist oder leicht, am Ende eher Nebensache.

/Daniel
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 26 Dezember 2017, 22:14:01
Die Installation war ja nur Teil 1. Die Einbindung von Sonos, Homematic usw. ist mir sehr wichtig, da das die Grundlage meines Smarthomes ist. Homematic muss einwandfrei funktionieren, sonst geht bei mir gar nichts.

Zur Flexibilität werde ich noch was schreiben. IOBroker hat zB ein Javascript Interface. Das ist sehr flexibel. Hab ich mir schon mal kurz angeschaut.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: DerBodo am 27 Dezember 2017, 20:45:27
Da du ja ohnehin auf Homematic unterwegs bist, kannst du mal schauen ob es dort ähnlich zur VCCU bei FHEM etwas gibt um mehrere IO Devices nutzen zu können ?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Mathea am 02 Januar 2018, 14:18:09
Da du ja ohnehin auf Homematic unterwegs bist, kannst du mal schauen ob es dort ähnlich zur VCCU bei FHEM etwas gibt um mehrere IO Devices nutzen zu können ?

Das interessiert mich auch sehr stark. Habe schon öfters mit dem Gedanken gespielt, auf eine andere Plattform umzusteigen (z.B. Aufgrund der Bedienerfreundlichkeit, User Interface, ...), aber am Ende kam ich immer zu dem Entschluss, dass FHEM die beste Homematic Implementierung bietet. Neben der schon genannten vccu auch insbesondere die Unabhängigkeit von der CCU. Das Raspberry PI Homematic UART Interface z.B. funktioniert meines Wissens bisher nur in FHEM.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 03 Januar 2018, 18:24:10
Ich fürchte, da werdet ihr bei FHEM bleiben müssen / dürfen ;-)

Mittlerweile habe ich Homematic mit IOBroker getestet. IOBroker sieht sich als Middleware, d.h. es gibt keine direkte Homematic Integration per CUL o.ä. Es wird ein CCU (als Gerät oder als Software auf einem Raspi) benötigt. Das Verfahren entspricht dem, was mein Modul HMCCU in FHEM macht. Dafür unterstützt IOBroker auch HM-IP.

Am Wochenende werde ich mir noch Homematic in OpenHab anschauen. Ich befürchte aber, dass die Integration dort genauso aussieht. Macht ja eigentlich auch wenig Sinn, das Rad neu zu erfinden und alles manuell zu integrieren wie das in FHEM passiert ist. Man benötigt dann zwar keine CCU, dafür aber eben ein CUL oder HMLAN oder ... Den Sinn dahinter habe ich nie verstanden.

Den ganzen Testbericht gibt es dann zeitnah.

Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: marvin78 am 03 Januar 2018, 20:13:12
Den Sinn dahinter habe ich nie verstanden.

Dabei hat man es dir oft genug erklärt  ;) Ein Teil steht sogar in diesem Thread. Es kommt auf die Perspektive an. Es gibt sehr gute Gründe für den FHEM Ansatz. In dem man immer wiederholt, dass man diese nicht sieht oder versteht, zeigt man deutlich, dass einem das Verständnis oder die Fähigkeit zum Verständnis einer andere Sichtweise fehlt. Ob man dann einen Vergleichstest starten sollte, lasse ich mal dahingestellt.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 04 Januar 2018, 12:13:36
Die Erklärung in diesem Thread muss ich überlesen haben.
Aber du hast Glück: du musst diesen Thread nicht weiter verfolgen, wenn dir der Inhalt nicht zusagt  ;)
U.a. deshalb steht das im Off Topic Bereich.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: marvin78 am 04 Januar 2018, 20:01:27
Ich habe nicht von diesem Thread geredet. Deine Antwort zeigt mir aber einmal mehr, dass du gar nicht daran interessiert bist. Ich bin nicht der Typ, der sich oder andere wiederholt. Du weißt schon, wo du nachlesen kannst. Was ich verfolge, überlasse bitte mir und interpretiere meine Worte nicht. Es gibt nichts zwischen den Zeilen.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 04 Januar 2018, 20:51:52
Teil 3 - Integration von Homematic

Die hier beschriebenen Erfahrungen beziehen sich ausschließlich auf die Integration von Homematic Komponenten! Sie geben meine subjektive Meinung in meiner Smarthome-Umgebung wieder.

Ich habe ca. 80 Homematic Komponenten im Einsatz (BidCos und HM-IP). Die Geräte sind an einer CCU2 angelernt. Zur Reichweitenverlängerung kommt ein LAN-Gateway zum Einsatz. Zusätzlich nutze ich virtuelle Geräte auf der CCU (CUxD).

FHEM

In FHEM unterscheidet man zwei Arten der Homematic Integration:
- Direkte, Hardware basierte Integration (z.B. mit CUL-Stick oder HMLAN-Adapter)
- Indirekte Integration über CCU (Software oder Hardware)
Beide Verfahren sind sehr gut im FHEM Wiki und der Commandref dokumentiert.

Die Hardware basierte Integration ist sehr umfangreich und vollständig in FHEM abgebildet. Sämtliche Funktionen der Homematic Geräte werden unterstützt. Es stehen sowohl allgemeine als auch Gerätetyp spezifische Befehle zur Steuerung zur Verfügung. Nach der Definition des IO Device werden Geräte automatisch erkannt und per Autocreate Instanzen in FHEM angelegt. Homematic IP wird nicht unterstützt. Vorteile dieser Variante sind die Unterstützung virtueller Geräte sowie einer virtuellen CCU (z.B. für Ausfallsicherheit). Das Anlernen sowie die Verknüpfung von Geräten erfolgt über das FHEM Webinterface bzw. die Kommandozeile.

Bei der indirekten Integration wird eine CCU2 (als Hardware oder Software) in FHEM eingebunden. Die Geräte werden nicht in FHEM angelernt sondern an der CCU2. Diese Art der Integration ist generisch gehalten, d.h. es stehen mit wenigen Ausnahmen keine Gerätetyp spezifischen Befehle zur Verfügung. Diese können jedoch über Attribute definiert werden. Bei dieser Lösung wird auch Homematic IP unterstützt sowie andere von der CCU2 bereitgestellte Erweiterungen wie z.B. CUxD oder Homegear. Das Anlernen neuer Geräte an der CCU2 sowie die Verknüpfung von Geräten untereinander erfolgt in der CCU2 über eine Weboberfläche.

Wertung:

Die Integration von Homematic in FHEM lässt keine Wünsche offen. Gerade Einsteiger haben zwar gelegentlich Probleme mit Peering und Pairing. Das wird jedoch von der sehr guten Dokumentation im FHEM Wiki sowie der guten Unterstützung im FHEM-Forum kompensiert.

IOBroker

IOBroker ist als Middleware konzipiert. Daher gibt es keine direkte, Hardware basierte Integration von Homematic Komponenten (z.B. via CUL). Lediglich die indirekte Einbindung per CCU2 wird unterstützt.

Eine Suche nach "Homematic" in der Adapterliste liefert 3 Treffer (s. Screenshot IOBroker_HM_Adapter). Zunächst benötigt man den ReGaHSS Adapter. Mit diesem werden CCU Informationen wie z.B. Systemvariablen und Räume in IOBroker übernommen. In den Adaptereinstellungen legt man u.a. die IP-Adresse der CCU und die zu synchronisierenden Informationen fest (s. Screenshot IOBroker_HM_Rega). Um Statusänderungen von Geräten der CCU automatisch an IOBroker zu übertragen, muss für jede Schnittstelle ein RPC-Adapter konfiguriert werden. IOBroker unterstützt die CCU Schnittstellen Wired, BidCos, HM-IP, CUxD und Homegear. Leider werden virtuelle Gerätegruppen (Heizung) nicht unterstützt. Für meine Tests habe ich je einen RPC-Adapter für BidCos und für HM-IP angelegt. Die Einstellungen eines RPC-Adapters sind dokumentiert (s. Screenshot IOBroker_HM_RPC). Der Screenshot IOBroker_HM_Instanz zeigt die 3 definierten Homematic-Adapter.

Leider musste ich IOBroker nach der Definition der Adapter komplett neu starten, damit die Adapter korrekt funktionierten und Informationen aus der CCU übertragen wurden. Wenn alle Adapter laufen, werden unter dem Reiter "Objekte" die erkannten Homematic Komponenten angezeigt (s. Screenshot IOBroker_HM_Objekte). Im Reiter "Zustände" findet man die Kanäle mit den Datenpunkten und den aktuellen Werten (s. Screenshot IOBroker_HM_Zustand).

IOBroker bietet keine eingebaute Oberfläche, um die Geräte zumindest rudimentär zu steuern. Dazu muss die CCU verwendet werden. Auch eine Interpretation bzw. Konvertierung von Werten findet nicht statt (z.B. Skalierung von 0-1 auf 0-100 bei Dimmern oder Rollläden).

Die Geräte können aus IOBroker mit JavaScript oder über die Definition von Szenen gesteuert werden. Mehr dazu in einem der folgenden Teile, der sich mit der Steuerungslogik der getesteten Smarthome Lösungen befasst.

IOBroker unterstützt keine virtuelle CCU oder virtuellen Geräte. Allerdings können mehrere CCUs eingebunden werden. Damit kann jedoch keine ausfallsichere Umgebung realisiert werden.

Wertung:

Die Homematic-Integration in IOBroker ist nicht sehr komfortabel. Es wird eine Schnittstelle zur CCU bereitgestellt, über die Daten im Rohformat synchronisiert werden. Die Implementierung einer Steuerung ist Aufgabe des Anwenders.

OpenHab

Wie schon IOBroker integriert OpenHab Homematic Komponenten via CCU. Im ersten Schritt wird das Homematic Binding installiert (Screenshot OpenHab_HM_Binding). Direkt danach definiert man als erstes eine Homematic Bridge, die die Verbindung zwischen CCU und OpenHab herstellt (Screenshot OpenHab_HM_CCU). Einige wenige Angaben genügen und OpenHab bindet automatisch alle auf der CCU verfügbaren Schnittstellen ein. In meinem Fall sind das BidCos, HM-IP, Gruppen und CUxD.

Nach einigen Sekunden Wartezeit tauchen dann nach und nach meine >80 Geräte der CCU in der OpenHab Inbox auf (Screenshot OpenHab_HM_Inbox). Diese müssen nun einzeln per Klick auf das OK-Symbol übernommen werden. Eine Möglichkeit zur Übernahme aller Komponenten auf einmal habe ich nicht gefunden. Ggf. muss man dazu die OpenHab Kommandozeile bemühen.

Für den Test habe ich einen Rollladen-Aktor und eine Heizungsgruppe übernommen. Mit einem Klick auf ein "Thing" öffnet sich das Konfigurationsfenster der Komponente. Hier werden automatisch alle Kanäle und Datenpunkte angezeigt (Screenshots OpenHab_HM_ConfGruppe und OpenHab_HM_ConfRollladen). Jeden Datenpunkt, den man für Steuerung oder Anzeige benötigt, wird mit einem Item verlinkt. Dabei schlägt OpenHab den passenden Item-Typ vor (Zahl, Rolladensteuerung, ...). Nach der Verlinkung der Items stehen in der Oberfläche PaperUI rudimentäre Steuerelemente zur Verfügung (Screenshots OpenHab_HM_Heizung, OpenHab_HM_Rollladen).

Wenn man auch auf CCU Variablen und Programme zugreifen möchte, muss man zusätzlich noch das Thing "Gateway Extras" übernehmen (Screenshots OpenHab_HM_Extras, OpenHab_HM_Variablen, OpenHab_HM_Programme).

Wie schon bei IOBroker gibt es in OpenHab keine virtuellen CCUs. Aber auch hier können problemlos mehrere CCUs eingebunden werden.

Wertung:

Die Homematic Integration in OpenHab ist sehr einfach umzusetzen. Wenn man das Prinzip von OpenHab verstanden hat, reduziert sich die Konfiguration auf ein paar Mausklicks. Ein Blick in die Doku ist nicht erforderlich. Mit den automatisch generierten Steuerelementen lassen sich die Komponenten sofort nach der Konfiguration in der PaperUI Oberfläche nutzen.

Fazit Teil 3 - Homematic Integration

Sowohl bei FHEM als auch bei OpenHab macht die Homematic Integration einen sehr reifen Eindruck. Bei OpenHab kommt man durch die gut geführte Konfiguration in der Weboberfläche schneller zum Ziel als bei FHEM. Auch die zwar einfache, aber funktionale Steuerung der Geräte in der Weboberfläche steht in OpenHab mit ein paar Mausklicks zur Verfügung. In FHEM muss man für das gleiche Resultat mit einigen Attributen jonglieren.
Bei IOBroker macht die Homematic Integration noch einen unfertigen Eindruck. Hier ist ziemlich viel Handarbeit erforderlich, um zu einer nutzbaren Steuerung zu kommen.

FHEM stellt mit der VCCU als einzige Lösung eine Ausfallsicherung zur Verfügung, allerdings nicht für HM-IP. Inwieweit dieses Feature ausschlaggebend ist, muss jder für sich entscheiden. Für mich macht es wenig Sinn, da man für eine vollständige Ausfallsicherheit auch den Rechner, die Netzkomponenten usw. redundant auslegen müsste.

Mein Fazit: FHEM und OpenHab teilen sich Platz 1. IOBroker folgt mit einigem Abstand.

In einem späteren Teil dieses Vergleichstests werde ich auf die alternativen Oberflächen zur Steuerung sowie Steuerungslogiken eingehen.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: ext23 am 04 Januar 2018, 21:19:51
Den Sinn dahinter habe ich nie verstanden.

Ich hab das ja jetzt mit der CCU2 auch am Start wegen HmIP, ist natürlich auch ganz nett, vor allem weil man die Geräte einfacher konfigurieren kann als über FHEM und den Registern. Man sieht eben auf einem Blick was geht und was nicht. Die GUI der CCU2 ist aber nicht viel besser als die von FHEM.

Dennoch fällt mir persönlich das zum Sinn der Direkt-Integration in FHEM ein (und stirbt natürlich eventuell mit HmIP):
- VCCU
- HomeBrew
- Nicht zwei Geräte an denen man schrauben muss (FHEM+CCU)
- Einfachere Einbindung in FHEM dank autocreate
- nicht zuletzte den Spaß an der Frickelei, nen System out of the box kaufen aller CCU kann sich jeder der ein paar Taler auf dem Konto hat ...


Aber mal was anderes, wir sind ja hier eh Off, FHEM ist ja eigentlich eine "Hausautomatisierung". Klar ich finde eine schöne GUI auf dem Tab auch geil, das will ich nicht abstreiten. Aber ist der Sinn einer Hausautomatisierung nicht eigentlich, dass alles automatisch und Intelligent funktioniert? Braucht man da überhaupt eine GUI zu?!?

/Daniel
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 04 Januar 2018, 21:42:22
Die CCU Einstellungen sind ja eine einmalige Geschichte: Geräte anlernen, ein paar Einstellungen machen, ggf. noch miteinander verknüpfen. Danach fasst man das normalerweise nicht mehr an.

Das mit dem Spaß an der Frickelei ist natürlich für viele ein Argument. Allerdings hat nicht jeder die Zeit dafür. Ich z.B. nicht. Ich hock den ganzen Tag an der Kiste, da brauch ich das in der Freizeit nicht auch noch. Die Sache muss einfach funktionieren.

Ohne Oberfläche wäre ein Traum. Das geht vielleicht mal, wenn es eine wirklich intelligente Sprachsteuerung gibt. Bis dahin brauche ich eine "Mensch-Schnittstelle", um Temperaturen einzustellen, Heizkurven zu programmieren, usw.
Und eine übersichtliche Darstellung diverser Haus-Zustände hat auch was.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: ext23 am 05 Januar 2018, 09:53:11
Das mit dem Spaß an der Frickelei ist natürlich für viele ein Argument. Allerdings hat nicht jeder die Zeit dafür. Ich z.B. nicht. Ich hock den ganzen Tag an der Kiste, da brauch ich das in der Freizeit nicht auch noch. Die Sache muss einfach funktionieren.
Kenn ich, dann sind aber alle genannten Systeme die falschen. Vielleicht noch IP-Symcon aber wenn man auspacken und einschalten will muss man sich für ein System entscheiden und es so nehmen wie es ist mit allen Vor- und Nachteilen einer Wolke und was auch immer.

Ohne Oberfläche wäre ein Traum. Das geht vielleicht mal, wenn es eine wirklich intelligente Sprachsteuerung gibt. Bis dahin brauche ich eine "Mensch-Schnittstelle", um Temperaturen einzustellen, Heizkurven zu programmieren, usw.
Und eine übersichtliche Darstellung diverser Haus-Zustände hat auch was.
Naja aber da nimmt man doch die normalen Schalter, das ist doch gerade der Sinn das man von der Automatisierung nichts mitbekommt. Es soll doch alles so bleiben wir vorher. Ich will mein Thermostat an der Wand haben und mein Schalter. Jetzt ein Tablet als Bedienung zu nehmen wäre mir alles zu langsam. Ein Handy muss man erst einschalten, App starten und was nicht alles. Dann ist der Akku leer und und und. Bis dahin bin ich 5 mal zum Schalter gerannt. Und beim Tablet genauso. OK ich habe auch "eins" an der Wand im Flur, aber das nutze ich wirklich selten weil zu langsam, man muss erst die richtige Seite "aufklappen" dann einstellen, dann hängt es zig mal... also ja, wie gesagt sieht schön aus, aber im Prinzip total überflüssig und mehr oder weniger nur zum Zeigen da wenn Besuch kommt. Und die Temperatur stellt sich doch alleine ein, weil intelligent ;-) Ich will doch gerade nichts mehr einstellen, das soll das System doch alles selber machen ;-)

Aber ich habe da vermutlich eine andere Ansicht. Wie gesagt, geile GUI etc. alles schön aber zu 99% die Kategorie Frickelei und Spielerei. Und Sprachsteuerung, nunja, da reagiere ich immer irgendwie allergisch, also wenn jemand Alexa oder ähnliche Dienste in der Cloud benutzt um sein Haus zu steuern, dann ist was anderes nicht in Ordnung. Generell solche Dinger zu benutzen finde ich sehr gefährlich. Bis ich sowas nutzen würde muss es Systeme geben die ohne Cloud arbeiten bzw. ohne jegliche Verbindung nach außen. Das Risiko dieser "Wanzen" wird von vielen unterschätzt. Da meine ich nicht den FHEM Skill, da geht es alleine nur um die Tatsache, dass nahezu alle Gespräche in der Cloud gespeichert werden. Aber das ist ein anderes Thema, da kann man ja Bücher drüber schreiben ^^ Das nutzen heute die Leute die morgen eine Partei wählen die gegen Datensammlung ist, das geht in meine kleine Birne leider immer irgendwie nicht rein. Aber vermutlich ist es nur die Angst der Menschen etwas vorgeschrieben zu bekommen, selber machen sie es dann freiwillig ^^.

Achso noch kurz wegen der CCU und nicht mehr anfassen. Das stimmt, aber ich finde es schon praktisch wenn man den Knopf an der Funksteckdose im Sommer eine andere default on-till zeit hinterlegen kann als im Winter. Gut das geht vielleicht auch über dein HMCCU Modul aber unter FHEM direkt ist es einfach (Register Änderung). Also ich würde schon sagen das man durchaus für bestimmt Sachen auf die CCU GUI muss. Aber das ist jetzt auch ne Ausnahme glaube ich.

So ich warte jetzt auch Teil 5 ;-)

/Daniel
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: chunter1 am 05 Januar 2018, 17:13:14
...also wenn jemand Alexa oder ähnliche Dienste in der Cloud benutzt um sein Haus zu steuern, dann ist was anderes nicht in Ordnung. Generell solche Dinger zu benutzen finde ich sehr gefährlich. Bis ich sowas nutzen würde muss es Systeme geben die ohne Cloud arbeiten bzw. ohne jegliche Verbindung nach außen. Das Risiko dieser "Wanzen" wird von vielen unterschätzt. Da meine ich nicht den FHEM Skill, da geht es alleine nur um die Tatsache, dass nahezu alle Gespräche in der Cloud gespeichert werden. Aber das ist ein anderes Thema, da kann man ja Bücher drüber schreiben ^^ Das nutzen heute die Leute die morgen eine Partei wählen die gegen Datensammlung ist, das geht in meine kleine Birne leider immer irgendwie nicht rein. Aber vermutlich ist es nur die Angst der Menschen etwas vorgeschrieben zu bekommen, selber machen sie es dann freiwillig ^^.
Du besitzt hoffentlich kein Handy and nutzt Internet nur via Tor aus einem Internetcafe?!
Ich frag nur, weil ich abschätzen möchte, ob bei dir alles in Ordnung ist. ;-)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: ext23 am 06 Januar 2018, 09:00:24
Du besitzt hoffentlich kein Handy and nutzt Internet nur via Tor aus einem Internetcafe?!
Ich frag nur, weil ich abschätzen möchte, ob bei dir alles in Ordnung ist. ;-)

Überall außerhalb meiner Wohnung nutze ich WLAN nur via VPN, logisch. Da braucht es nicht gleich Tor zu was im übrigen keinerlei Sicherheit der Anonymität bietet. Mit dem Handy musste mir mal erklären, aber technisch bitte, falls du auf das Mikro anspielst ;-)

/Daniel
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Amenophis86 am 06 Januar 2018, 10:31:40
Ich frage mich, ob ihr das Thema des TE wirklich soweit ausschlachten müsst um diese (schon mehrfach im Forum geführte Diskussion) hier zu führen. Daher bitte ich euch wieder zurück zum Thema zu kommen, auch, wenn es im Off-Topic Bereich ist :)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: marvin78 am 07 Januar 2018, 08:04:56
Ich bin sicher, dass es zum Thema gehört, wenn der Ausdruck "Hausautomation" im eigentlichen Sinne bei diesem Vergleich nicht oder kaum berücksichtigt wird bzw. man den Eindruck gewinnt, dass der Einsatzbereich der hier getesteten Software ggf. nicht richtig verstanden wurde. Es ist nämlich nicht falsch, dass ein Frontend bei einer richtigen Hausautomation eher zweitrangig ist, ein Backend aber nicht. Und dazu gehören eben auch die anderen Argumente. Der TE hat das sehr sehr große Fass so weit auf gemacht. Alle anderen Diskussionen gehören dann eben dazu.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Amenophis86 am 07 Januar 2018, 14:45:10
Hätte mich präziser ausdrücken sollen. Ich meinte nicht die Diskussion über Front und Backend, sondern über Sicherheit mit Handy / Alexa / Wir werden alle abgehört, oder auch nicht.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 07 Januar 2018, 16:29:22
Ich werde mir auch das Thema Steuerung im Hintergrund noch genauer anschauen und davon berichten.
Das Thema Frontend war ja eigentlich nur der Anstoss, mich überhaupt nach anderen Lösungen umzuschauen. Und dann habe ich mich eben gefragt ob es Sinn macht, nur für das Frontend eine separate Lösung einzusetzen oder nicht besser gleich komplett zu wechseln.

Bisher war das kein Thema. FHEM war konkurrenzlos was die Vielzahl der unterstützten Gerätetypen angeht. Aber nun gibt es eben IoBroker und openhab ist seit Version 2.0 endlich vernünftig nutzbar.

Für mich ist eine Oberfläche sehr wichtig. Da hängt auch der WAF dran. Und wenn dann nach einem Tablet UI Update wieder mal gar nichts mehr geht und ich erst wieder 1 Woche basteln muss, ist das für mich keine stabile Lösung. Ich habe mein Smarthome nicht zum Rumbasteln, sondern um es nutzbringend einzusetzen. Das muss „einfach“ funktionieren, auch wenn ich mal nicht da bin, um es wieder zu richten.

P.S. Ich habe keine Angst vor großen Fässern, ich arbeite täglich damit  : ;)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: marvin78 am 07 Januar 2018, 16:44:44
Unser Frontend sind haptische Schalter. Für alles andere wird kein (oder eher selten ein) Frontend benötigt, da die Dinge automatisiert sind. Ich behaupte: JEDES Frontend ist nicht gut für den sogenannten WAF (den ich nicht sehe und den es aus meiner Sicht auch in der Form nicht geben sollte, es geht eher um die allgemeine Zufriedenheit mit dem System. das ist völlig unabhängig vom Geschlecht). Eine Hausautomation sollte ein Frontend kaum benötigen, nur dann kann man davon sprechen. Und nein, bei uns läuft sehr wenig über Sprachsteuerung, viel jedoch über Abhängigkeiten. Wer denkt, ein Licht über ein Tablet, statt über einen Schalter zu schalten (bewusst überspitzt), sei Hausautomation, hat sie nicht verstanden. Die Möglichkeit, einen hohen Automationsgrad zu erreichen sind in einem solchen "Test" aus meiner Sicht um etwa den Faktor 10 höher zu bewerten, als ein (subjektiv) tolles Frontend. Das sehe ich ganz unabhängig von FHEM. Wenn alles toll ist, auch gut.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 08 Januar 2018, 19:05:24
Ich schaue mir beides an: Fontend und Automatisierung.

Ich denke, DOIF und notify sind jetzt nicht so schwer zu toppen ;-)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: marvin78 am 08 Januar 2018, 20:19:06
Ich denke, DOIF und notify sind jetzt nicht so schwer zu toppen ;-)

Und ich behaupte, dass sie in Kombination mit den vielen anderen Möglichkeiten, die FHEM mit der Perl Einbindung bietet, sehr schwer zu toppen sind. Aber auch hier kommt, es, wie immer, auf die Sichtweise an.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: ext23 am 09 Januar 2018, 10:08:24
Für mich ist eine Oberfläche sehr wichtig. Da hängt auch der WAF dran. Und wenn dann nach einem Tablet UI Update wieder mal gar nichts mehr geht und ich erst wieder 1 Woche basteln muss, ist das für mich keine stabile Lösung. Ich habe mein Smarthome nicht zum Rumbasteln, sondern um es nutzbringend einzusetzen. Das muss „einfach“ funktionieren, auch wenn ich mal nicht da bin, um es wieder zu richten.

Dann mach doch nicht jedes Update mit, wenn alles einmal läuft friert man den Stand doch normalerweise ein. Updates macht man doch nur WENN etwas NICHT mehr funktioniert.

Aber in Zeiten wo man Geräte wie Smartphones, Tablets etc. benutzt wird es immer schwer sein, dass es auf lange Sicht funktioniert. Dafür ist es eben besser auf Nextion oder so zurückzugreifen, also spezielle Hardware nur für den Zweck. Ansonsten ist es nahezu unmöglich so ein System dauerhaft zu betreiben.

Professionelle Gebäudeleittechnik geht ja genau diesen weg. Das wird einmal installiert und muss Jahre laufen ohne dass es jemand anfässt.

Diesen schmalen Grad muss man natürlich gehen ja. Gerade bei FHEM ist das durch die Stündliche Weiterentwicklung wirklich sehr schwer. Aber wie gesagt, läuft alles ein mal, dann finger weg. Und wer geil auf täglich neue features ist oder einfach nur vorne dabei sein will, der muss eben frickeln. Und je mehr Funktionen man hat und nutzt siehe AMAD etc. desto mehr muss man eben nach jedem Update/Tablet tausch frickeln.

Aber ich muss schmunzeln wegen der GUI und WAF ;-) Meine cheffin hat das tablet im Flur gesehen und mein "Wasn das für scheiss... muss ich damit jetzt Licht anschalten?!?...." Also man sieht, die Meinungen gehen da stark auseinander ;-)

/Daniel
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 09 Januar 2018, 20:45:32
Und ich behaupte, dass sie in Kombination mit den vielen anderen Möglichkeiten, die FHEM mit der Perl Einbindung bietet, sehr schwer zu toppen sind. Aber auch hier kommt, es, wie immer, auf die Sichtweise an.

Zumindest IOBroker wird da mithalten. Alles was in FHEM mit Perl geht, macht man in IOBroker mit Javascript. Aber mal sehen, ich will mich ja auch nicht verschlechtern. So ein Wechsel will gut überlegt sein. Da steckt man ja einiges an Zeit rein.
Falls IOBroker und OpenHab nicht die Lösung sind, wird es vielleicht IPSymcon. Hat eine sehr mächtige PHP basierte Scriptengine. Auch sicher nicht schlechter als Perl.

@ext23: wir nutzen das Tablet für Anzeige von Wetterdaten, Kalender, Rollladensteuerung, Heizungssteuerung, Radiosteuerung usw. und da keine FHEM Oberfläche fehlerfrei ist, muss ich Updates installieren. Wäre halt schön, wenn die abwärtskompatibel wären.

in der Firma haben wir eine professionelle Gebäudetechnik. Die wird regelmäßig aktualisiert (Bugfixing, neue Features, neue Komponenten usw.) die Zeiten, als man sowas einmal installiert und nie mehr angefasst hat, sind lange vorbei.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: raimundl am 02 Februar 2018, 16:47:35
@zap

Gibt es bald neue Erkenntnisse?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 03 Februar 2018, 18:21:35
Ich hoffe. War die letzten 2-3 Wochen mit der neuen Version meines HMCCU Moduls beschäftigt. Da stehen jetzt noch ein paar kleinere Bugfixes an. Dann habe ich wieder Zeit für dieses Thema hier.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: JackWolfskind am 05 Februar 2018, 16:02:09
Interessantes Vergleich - sowas hatte ich vor einem Jahr gesucht, bin aber leider mit den bisherigen Vergleichen nicht einverstanden gewesen und habe dann notgedrungen einen eigenen gemacht :-) 

Am meisten habe ich mich dabei auch mit F,O,I=FHEM,OpenHab2 und IOBroker beschäftigt, aber auch mit IPSymcon,Loxone, HASS, Domotics und bOS habe ich schon ein paar Monate verbracht.
Was ich dabei festgestellt habe ist, dass je mehr man sich in eine Plattform einarbeitet desto mehr lernt  man die entsprechenden Vorzüge zu schätzen, als auch manche Abneigungen zu bestärken.
Während man anfangs geneigt ist die liste der unterstützten Protokolle zu vergleichen, stellt man in der Realität bald fest  das die Stabilität der Adapter/Bindings ... mit jeder Version stark variiert und andere Dinge im Alltag wichtiger werden.
Das kann durch die vorherrschende Foren LandesUmgangssprache (je nach geografischer Verbreitung)  oder die vewendeten Programmiersprachen und Tools sein (der eine liebt es zu tippen der andere zu klicken)

Installation
Was das angeht würde ich gerade Beginnern niemals mehr was anderes empfehlen als mit fertigen Images für Raspi oder andere SBCs zu beginnen. Gründe dafür sind viel einfacherer Support, Backup/Restore, Stromverbrauch  ...
Mit fertigen Images ist man bei egal ob F ,O, I sehr schnell bei einem lauffähigen System!

Unterstütze Geräte
Hier macht sich das Alter - die Reife der Plattformen bemerkbar. Rein von der Anzahl unterscheiden die sich nicht mehr so stark auch wenn FHEM sicher noch die Nase vorn haben dürfte.
Was imho wichtiger ist, bei FHEM ist der Reifegrad für "legacy" Geräte wie 433MHz, FS20, Homematic ... höher, bei IOBroker und OpenHab ist dafür oft alles  mit TCP/IP besser unterstützt.

Regeln/Logging Diagramme
In FHEM geht (fast) alles, aber der Weg ist meistens entweder ein Holzweg oder brutal steinig.
In Openhab gehen Regeln mit dem grafischen Regeleditor sehr einfach, daür selbst einfachste Dinge wie Logging und Diagramme ähnlich übel aufwändig wie in FHEM.
In IOBroker sind Regeln in Blockly auch recht einfach, und zumindest primitives Logging  und Histogramme sind mit dem History+Flot Adaptern auch relativ einfach machbar.

Sonstige Dinge wie Stabilität/Maintanance
FHEM Wer nicht dran rumspielt und nach jahren das Logging völlig verstanden hat, erhält  ein performantes, stabiles System das sogar einfach zu backupen und restoren wäre, falls man das jemals brauchen würde!
OpenHab: Seit 2.0 ein Groß-Projekt das zumindest bei mir aufgrund dem permanenten Beta Status einiger Bindings nie dauerhaft, völlig stabil läuft.Backup und restore ist bei jedem Mini-Update dringend empfohlen wenn auch kaum einem Nicht-Entwickler klar sein dürfte was denn wo gespeichert und wie wiederhergestellt  sein sollte.
IOBroker: Aufgrund des jugendlichen Alters einiger Adapter ist absolute Stabilität sicher noch zu viel erwartet, andererseits gibts dafür bereits eingebaute automatische Cron Restarts für Binding  ;) Backup und restore geht auch leicht von der Hand, für den Fall das man mal wieder die Meldungen über die vielen neu verfügbaren Adapter-Updates nicht ignorieren konnte, die man hier im Gegensatz zu OpenHab auch problemlos erfährt!

Hilfe/Foren
Hier macht sich imho auch wieder das Alter der Plattform und damit einhergehend der Forenteilnehmer bemerkbar.
Es bildeten sich auf den Plattformen unterschiedliche Schwerpunkte heraus was man dann auch daran merkt das in den betreffenden Foren, Youtube etc. ein deutlich anderer Umgangton herrscht, was ich nicht ganz ernst wie folgt zusammen fassen würde:

FHEM: Doku gibts massig, liest, bzw. versteht aber kaum jemand.  Man spricht deutsch, hat eine gewisse "Reife"/Erfahrung und Newbies sollten sich dementsprechend schon eine gewisse Zeit (>Monate ... besser x Jahre) mit der Plattform beschäfftigt haben und wenigstens nebenberuflich Datenbank Admin mit Löterfahrung sein um sich würdig zu erweisen. Dafür kriegt ein echter FHEMler mit ein paar Zeilen Code auch Opas Rasenmäher eingebunden, wenn auch niemals per Alexa gesteuert, denn die Cloud ist eine ganz böse Wolke über dem Eigenheim.WAF juckt niemand und in Youtube sind die textlasitigen FHEM Videos faszinierend aber auch ein bischen öde  :-\
OpenHab: Gute Doku gibts vor allem über die generelle Architektur, für den Rest erst wenn die SW mal fertig ist, sprich nie. Die ITLer sprechen nur englisch, freuen sich aber über jeden neuen OHler, bis sie festestellen das der OH 2 Newbie unter Openhab lediglich die wenigen PaperUI kompatiblen Bindings versteht und auch nicht flüssig SQL und Java parliert . Das behindert dann natürlich, so das nicht   viel  mehr als eine simple Kacheloberfläche für die neue Ikea/Hue LED-Lampen rauskommt, aber  mit hohem WAF Faktor  :-*
IOBroker: Hier finden sich neben jungen Hipstern auch viele alte FHEM Veteranen + Tabellen Nerds , die nach Hochzeit und Nachwuchs noch auf die Schnelle fürs Eigenheim ein WAF kompatibles GUI machen müssen. Je nach Gusto zimmert man sich entweder ein paar Zeilen JavaScript oder noch besser NodeRed Flows um per Alexa den China Staubsauger tanzen zu lassen, was man dann der ganzen Welt in Youtube zeigen muss  :P

Kurzum wer maximale Freiheit will, oder Geld für immatrielle Dinge wie SW für Betrug hält muss sich bei diesen Plattformen auf viele Kompromisse, extrem harte Arbeit aber auch viel Spaß einstellen.
Wer etwas flexibler ist , sollte aber ggf. auch über den Tellerrand hinausschauen, denn es gibt noch soviele andere Plattformen irgendwo da draussen ... 8)

P.S:
Danke an alle Programmierer und Supporter die bisher unendlich viel Freizeit in diese Projekte gesteckt haben!  :)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 09 Februar 2018, 20:58:08
Danke für diese Zusammenfassung. Vielleicht habe ich es überlesen, aber bei welcher Plattform bist du letztlich hängen geblieben?

Deine Bewertungen zu den Tools würde ich nach den wenigen Erfahrungen, die ich bis jetzt während meiner Tests sammeln durfte, unterschreiben. Nur was die Doku von Openhab angeht nicht. Die finde ich nämlich im Vergleich zu FHEM verständlich und recht vollständig.

Mal sehen, was bei mir am Ende rauskommt. Ich liebäugle ja auch schon länger mit IPSymcon. Habe auch kein Problem, für gute Software Geld auszugeben.
Openhab ist momentan mein Favorit, zumal der Entwickler ein Arbeitskollege ist und ich nachempfinden kann, wie schwer es ist, neben dem Job noch ein so großes Opensource Projekt zu betreuen.

Aber ich habe es nicht eilig. Kann auch sein, dass ich IoBroker oder OpenHab erst mal nur als GUI für FHEM verwende und später erst auf eine andere Plattform wechsle.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: krikan am 10 Februar 2018, 08:23:20
Nur was die Doku von Openhab angeht nicht. Die finde ich nämlich im Vergleich zu FHEM verständlich und recht vollständig.
Könntest Du bitte genauer ausführen, wo die FHEM-Doku nicht verstaendlich bzw. unvollstaendig ist, damit ich die Aussage verstehe. Danke.
Gruß, Christian
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: JackWolfskind am 10 Februar 2018, 22:30:11
Danke für diese Zusammenfassung. Vielleicht habe ich es überlesen, aber bei welcher Plattform bist du letztlich hängen geblieben?
Ehrlich gesagt noch bei keiner  :-\ FHEM, OpenHAB und IOBroker laufen aktuell so semi-produktiv, dazu noch ein paar andere mehr oder weniger spielerisch z.b. Domoticz - man das hat einige Feature die würde ich mir bei den 3 großen Plattformen dringend wünschen  ::)

Deine Bewertungen zu den Tools würde ich nach den wenigen Erfahrungen, die ich bis jetzt während meiner Tests sammeln durfte, unterschreiben.
Eigentlich wollte ich ja nur aufzeigen das man je nach Herkunft oder Anforderungen beim Vergleichen auch zu gänzlich anderen Ergebnissen kommen kann  ;D

Nur was die Doku von Openhab angeht nicht. Die finde ich nämlich im Vergleich zu FHEM verständlich und recht vollständig.
Ähm, ich sagte ja, das variiert je nach Version - z.B. habe ich jetzt festgestellt das mit OpenHAB 2.2 die Doku auch schon wieder viel vollständiger wurde (ok das praktisch essentielle Habmin fehlt halt seit Jahren) ! Man muß hier aber immer noch des Englischen mächtig und sollte Informatiker sein, aber dann findet man sie echt ziemlich verständlich - also gegenüber FHEM  ;)

Ich finde es z.B. bei OH sehr gut wie zunächst das Konzept dahinter erklärt wird, samt paar Bespiele damit man in wenigen Minuten eine PaperUI GUI hinbekommt. Allerdings wird am Ende z.B. mehr über Dinge wie die Karaf-Console und verschiedene IDEs geschrieben, als wozu die ganzen Admin Oberflächen und Visualisierungen überhaupt gut sein sollen - wo doch am liebsten alle nur sowas (vermeintlich) einfaches wie PaperUI wollen :-) Da wird imho aktuell noch eine Menge Potential verschenkt... aber das wird in ein paar Monaten sicher was  :)

Bei FHEM hingegen finde ich die Doku extrem vollständig - also eigentlich schon fast viel zu üppig! Ich schaue mir da sogar sehr  häufig z.B. Protokoll Details, oder was zum Z-Wave Adapter zum Verständnis für andere Plattformen ab - quasi als HomeAutomation Wiki  :P Und dann gibts ja auch nach DAS Forum !

Leider muss ich zugeben - selbst als alter Informatiker habe ich das Konzept hinter FHEM bisher nicht mal im Ansatz verstanden  >:( ich glaube dafür bin ich trotz meines hohen Alters zu spät zur HomeAutomation gekommen und verstehe vlt. einige FHEM Ursprünge nicht die evtl. aus der Homematic, FritzBox Zeit oder sonstigen historischen Altlasten kommen... 

Und trotzdem im Ernst: Der FHEM-Einsteiger Guide ist wirklich superklasse, sowas sollte es für alle Programme geben! Bloss wenn ich den alle paar Monate nochmal vorholen und halb durchlesen muss, weil man als Hobbynutzer in FHEM sonst schier gar nix hinkriegt, dann ist FHEM ... zumindest nicht vollständig selbsterklärend   ;D

Mal sehen, was bei mir am Ende rauskommt. Ich liebäugle ja auch schon länger mit IPSymcon. Habe auch kein Problem, für gute Software Geld auszugeben.
Openhab ist momentan mein Favorit, zumal der Entwickler ein Arbeitskollege ist und ich nachempfinden kann, wie schwer es ist, neben dem Job noch ein so großes Opensource Projekt zu betreuen.

Aber ich habe es nicht eilig. Kann auch sein, dass ich IoBroker oder OpenHab erst mal nur als GUI für FHEM verwende und später erst auf eine andere Plattform wechsle.
Ja, als Entwickler habe ich absolute Hochachtung vor den ganzen Freizeit Entwickler an diesen Projekten.
Wobei ich auch immer wieder denke - Opensource schön und gut. Aber was werden da andauernd zig Mannjahre an Entwicklungszeit verschwendet  :'(
Für jede Plattform werden immer und immer wieder die gleichen Adapter programmiert und Protokolle reverse engineered.
Da werden zig alternative Visualisierungen geschrieben bevor eine auch nur halbwegs fertig ist usw.
Die Liste an "yet another"- Dingens bei FHEM  ::) .... kann man natürlich auch als tolle Menge an Möglichkeiten bewundernswert finden  :o

Ich habe es aber auch nicht eillig mit der Entscheidungsfindung:
FHEM läuft  - wenn auch häßlich und völlig unverstanden - trotzdem super stabil!

OH2 läuft bei mir mit vielen (2.x Beta-)Adaptern leider alles andere als stabil - also gar kein Vergleich zu FHEM  ::) und bei IOBroker tut sich gerade in einigen Bereichen auch noch viel zuviel, als das ich das als alleiniges Produktiv-Setup laufen lassen wollte. Aber z.B. die Portierung von Smartvisu lässt mich schon mit der Zunge schnalzen, da steckt ne Menge Potential drin...

Vielleicht ist dann nächstes Jahr was "finales" für mich dabei. Sowas in der Art: Stabilität und Vielfalt wie FHEM, dazu noch bischen  Domoticzs und die OpenHab PaperUI Oberfläche für Einsteiger, bzw. IOBroker für Cloud plus SMartvisu für Visu Profis  8)
Oder doch gleich statt dem ganzen "Gefrickel" was aus einem Guss wie Luxone bzw. IPSymcon? ;)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: herrmannj am 10 Februar 2018, 22:52:33
das FHEM smartVisu kann ist bekannt ?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: JackWolfskind am 11 Februar 2018, 00:11:13
das FHEM smartVisu kann ist bekannt ?
Klar, daher kenne ich Smartvisu ja. Aber das ist vom Aufwand ganz und gar nicht mit meinem restlichen Arbeits+Freizeitsverhalten kompatibel  - sonst hätte ich mich da bestimmt reingehängt  :'(
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 11 Februar 2018, 11:57:37
Könntest Du bitte genauer ausführen, wo die FHEM-Doku nicht verstaendlich bzw. unvollstaendig ist, damit ich die Aussage verstehe. Danke.
Gruß, Christian
die Einsteigerhilfe ist sehr gut für ein Grundverständnis von FHEM, für eine wirkliche „Nutzung“ der vielfältigen Funktionen und vor allem der Module aber nicht ausreichend.

die Commandref ist (Überraschung ;-) eine Referenz. Hier kann man nachsehen, wenn man wissen möchte, welche Funktion eines Moduls sich hinter einem Befehl oder einem Attribut verbirgt. Wenn man hier nachschaut, hat man das Modul aber meist schon im Einsatz oder zumindest ansatzweise verstanden. Für einen Einstieg in die Verwendung eines bestimmten Moduls sind 90% der Commandref aber nicht geeignet. Eben eine Referenz, kein Users Guide oder ein „Modul XY for dummies“

bleibt das Wiki. An und für sich ein guter Ansatz (der Homematic Teil ist wirklich gut) hat jedoch einige Unzulänglichkeiten:
- viele Artikel sind nur kurz bzw verweisen auf das Forum. Und hey mal ehrlich: soll ich wirklich Threads mit mehr als 1000 Einträgen lesen, um ein Modul zu verstehen?
- viele Artikel sind eher eine Commandref (s.o.) oder so schwer verständlich, dass sich zumindest mir auch nach mehrmaligem Lesen der Inhalt nicht erschließt (readingsgroup zB). Vielleicht bin ich aber auch zu doof dafür oder als altgedienter Informatiker/Softwareentwickler betriebsblind
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: the ratman am 11 Februar 2018, 12:09:49
zur veranschaulichung mancher texte in fhem und zur commandref, weil man die ja im zweifelsfalle blind glauben soll ...

weil ich grad drüber gestolpert bin und eben nicht verstehe, was nun wie, wenn überhaupt passiert (man beachte die hervorgehobenen texte). dies nur als bspl. nicht als beschwerde!
auszug aus der commandref zum text2speech modul
Zitat
TTS_CacheFileDir
Optional: Die per Google geladenen Sprachbausteine werden in diesem Verzeichnis zur Wiedeverwendung abgelegt. Es findet zurZEit keine automatisierte Löschung statt.
Default: cache/
Achtung: Nur bei einem lokal definierter Text2Speech Instanz möglich!
Zitat
TTS_noStatisticsLog
1, verhindert das Loggen von Statistikdaten in DbLog Geräten, default ist 0
Bitte zur Beachtung: Das Logging ist wichtig um alte, lang nicht genutzte Cachedateien automatisiert zu loeschen. Wenn dieses hier dektiviert wird muss sich der User selbst darum kuemmern.
ich glaub, das blickt dann auch kein linux-supernerd-programmierer-gott, oder?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: JackWolfskind am 16 Februar 2018, 13:05:53
Neben den bekannten großen 3 OpenSource Lösungen FHEM, OpenHab und IOBroker habe ich mir auch noch einige andere angeschaut.
Besonders 3 möchte ich hier erwähnen, die allesamt als besondere Stärke einen deutlich leichteren Einsteig bieten - Home Assistant, Pimatic sowie Domoticz. Wobei ich besonders das letzte aktuell am fortgeschrittensten empfinde:
Domoticz
Ist verglichen mit FHEM extrem einsteigerfreundlich ;-)
Fertiges modernes GUI (noch einfacher als PaperUI) das man ggf. um Floorplan und Dashboards ergänzen kann
Viele Aufgaben wie SW Updaten, Backup/Restore , System Restart gehen bequem aus dem GUI.
Auch Gruppen, Regeln und Floorplans, Logging oder Graphen macht man bequem mit ein paar Mausclicks - da ist alles OutOfTheBox was man bei den anderen, besonders FHEM entweder erst nachinstallieren und dann teils mühsam 3rd Party oder Plugins, bzw. per Kommandozeile erledigen müsste.
Am stärksten finde ich den Z-Wave Support, der teils besser als in kommerziellen Produkten ist und m.E. besonders von der Config sogar deutlich Fhem,OpenHab und IOBroker überlegen ist!
https://www.domoticz.com/wiki/Zwave

Allerdings gibts auch ein paar gravierende Nachteile:
Es gibt deutlich weniger Plugins, auch wenn man noch viel per Python Scripte nachrüsten kann.
Kommt wohl aus den Niederlanden, Doku in englisch!  und ist es nicht ganz so verbreitet wie F,O,I...
Vor allem fehlen daher auch viele "deutsche" Eigenheiten/Produkte wie z.B. Homematic - was sicher für viele ein NoGO ist, mir fehlt z.b. noch eine Modbus TCP Unterstützung.

Wer also auf Dinge wie Homematic verzichten kann findet mit Domoticz eine recht komplette Lösung, bei der man ohne viel Anleitung wälzen komfortabel zu einer schicken Heimautomatisierung kommen kann. Das erhöht den WAF und kann wenn es mal nötig sein sollte (und man ein kleines bischen dokumentiert) sogar von anderen mal übernommen/weitergeführt werden.
Ich werde es jednfalls auch mal im Auge behalten... :-)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 16 Februar 2018, 21:14:38
Sieht wirklich gut aus. Leider wird mqtt nicht untertützt, sonst hätte man darüber Homematic integrieren können
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: JackWolfskind am 16 Februar 2018, 23:48:32
Doch, MQTT geht schon:
https://www.domoticz.com/wiki/MQTT
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 17 Februar 2018, 08:19:56
Hatte ich übersehen. Dann kann man sogar FHeM anbinden und die CCU. Für diese gibt es mW ein mqtt Addon.

Was übrigens auch recht nett ist: Indigo Pro. Gibt es allerdings nur für den Mac und kostet Geld.

Man sieht: mitlerweile gibt es einige Alternativen, die Dank offener Bussysteme wie mqtt auch einfach miteinander verheiratet werden können. So muss man nicht zwingend nur auf eine Lösung setzen sondern kann sich die Rosinen rauspicken, zB Gerätevielfalt mit FHEM, Darstellung und Bedienung über was anderes.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: marvin78 am 17 Februar 2018, 08:38:48
Und so kann man es mit fhem schon seit Jahren machen. Was der Punkt ist, ist mir nicht klar. Einerseits wird fhem dafür kritisiert, dass  es so kompliziert ist, andererseits will man Dinge kompliziert miteinander verknüpfen (und ja, wenn man eine echte Automation haben möchte, ist das komplex) obwohl man fhem, wenn es denn sein muss recht einfach mit ansprechenden Oberflächen ausstatten kann. Was das Ziel ist, ist im Nebel. 
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 18 Februar 2018, 21:08:14
da sind wir uns einig: mein Ziel war, FHEM mit einer ansprechenden Oberfläche auszustatten. Da es diese direkt bei FHEM nicht gibt (meine völlig voreingenommene subjektive Meinung) hab ich mich nach Alternativen umgeschaut und bin so bei IOBroker und OpenHab gelandet.
Aber da ich ungern mehrere Plattformen betreiben möchte, ist der nächste logische Schritt zu prüfen, ob ich nicht alles mit IOBroker oder OpenHab abbilden kann.
Ich seh da keinen Nebel.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: marvin78 am 19 Februar 2018, 07:44:31
Da du oben was anderes geschrieben hast, ist da viel Nebel.

Dein letzter Beitrag bestätigt also, dass es dir um die Oberfläche geht und der Punkt, der bei der Art der Software, die hier getestet wird, natürlich im Mittelpunkt stehen muss, die Automation, eher ein Nebenthema ist. Dieser "Test" ist nicht im Bereich Hausautomation, sondern eher unter "Oberflächentest" anzusiedeln. Das ist ok, wenn du es auch klar so darstellst.

Ich bin beruflich in der Beratung zu einer Software zu Hause, die auf dem Markt bei weitem die vielfältigsten Möglichkeiten im Vergleich zur Konkurrenz bietet (nein es geht nicht um Hausautomation), bestehende Prozesse abzubilden. Diese Software kommt bei der Oberfläche teilweise eher altbacken daher. Das ändert nichts daran, dass die Möglichkeiten für die Kunden damit deutlich größer sind, als bei jeder anderen vergleichbaren Software auf dem Markt (und das sehe ich weitgehend objektiv, weil ich keine Verbindungen zum Hersteller habe und auch die Beratung für die Konkurrenzsoftware anbiete). Ich komme immer wieder zu Kunden, die sich aufgrund von tollen, "modernen" Oberflächen für eine andere Software entschieden haben und das dann bitter bereuen, weil es alle Prozesse in den Büros massiv einschränkt. Am Ende schafft man dann zweimal an und merkt, dass die Oberfläche zweitrangig ist, weil sie durch mich in der Lage sind, mit Hilfe der Software ihre Prozesse so weit zu automatisieren, dass die Oberfläche gar nicht so oft ins Auge fällt.

Das ist nicht 1:1 auf FHEM übertragbar. Ich kenne alle guten Argumente für andere Tools und vieles davon ist auch völlig korrekt. Ich bin auch nicht mit FHEM verheiratet, ich bin aber der Meinung, dass dieser "Test" hier richtig gelesen werden muss. Er führt die Leute auf die falsche Fährte. Es muss ganz klar sein, dass eine gute Hausautomation in der Regel und die meiste Zeit ohne Oberfläche auskommt und diese eine Nebenrolle spielt. Ich habe mir auch mal Tablets an die Wand geschraubt und ärgere mich nun, dass sie da hängen, weil eines zur Anzeige gereicht hätte.

Zudem kommt mir das Thema zu kurz, dass es durchaus ansprechende (das ist immer subjektiv) Oberflächen für FHEM gibt. Klar, es ist ein wenig Arbeit, diese einzurichten, aber wie das immer so ist, bekommt man danach auch genau das, was man für sich selbst haben möchte. Man kann sich auch eine eigene Oberfläche basteln, da ist sehr viel möglich. FHEM ist ein Tool für Leute, die die volle Kontrolle möchten und auch die Lust habe, sich in all die Themen rein zudenken. Sie wollen Schnittstellen nutzen, individuell gestalten und sehen genau das als ihr Hobby an. Hier gibt es mittlerweile viele Leute, die ich niemals in die Zielgruppe von FHEM einordnen würde, da sie die falschen Kriterien für die Software anlegen. Es gibt für alles einen Markt. Das stellst du hier gar nicht mal so schlecht heraus und man muss sicher auch sagen, dass die Leute, die Hausautomation nicht verstanden haben, auch ihre Software haben sollen. Das ist gut und richtig. Die Bewertung ist aber zu subjektiv, um noch als "Test" (ein Begriff, der immer etwas objektives suggeriert, auch wenn es das selten ist) durchzugehen. Dass man unterschiedliche Software testet, finde ich gut, ich halte das hier aber immer mehr für fehl am Platz, da nicht die Hausautomation im Vordergrund steht.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: JackWolfskind am 19 Februar 2018, 15:31:50
Zitat

Da du oben was anderes geschrieben hast, ist da viel Nebel.

Dein letzter Beitrag bestätigt also, dass es dir um die Oberfläche geht und der Punkt, der bei der Art der Software, die hier getestet wird, natürlich im Mittelpunkt stehen muss, die Automation, eher ein Nebenthema ist. Dieser "Test" ist nicht im Bereich Hausautomation, sondern eher unter "Oberflächentest" anzusiedeln. Das ist ok, wenn du es auch klar so darstellst.
Wer lesen kann... ;)
Der Plan:
Ich suche seit langem eine schöne, übersichtliche und leicht zu konfigurierende Oberfläche für meine Smarthome Steuerung.


Aber mal im Ernst: Wir reden hier, verglichen mit aktuellen SW Projekten, über eine simple SW zur HeimAutomatisierung, mit der man die Weihnachtsbeleuchtung zeitgesteuert einschaltet, oder die Rollläden in Abhängigkeit vom Sonnenstand hochfährt und vielleicht die Heizung taktet, aber keiner Profi SW zur Abbildung von IndustrieProzessen von der Menschenleben abhängen oder mit der Millionen verdient werden.
Das OpenSource SW hier aufgrund ihrer offenen Art flexibler ist und deutlich mehr Geräte als die (hübscheren) kommerziellen Alternativen unterstützt, finde ich selbstverständlich und ist kein Alleinstellungsmerkmal von FHEM, sondern lediglich ein Argument unter vielen. 

Im Endeffekt sollte es nicht um die Frage gehen ob, sondern wie schnell und frustfrei/vergnüglich ich damit meinem Ziel der Hausautomatisierung näher komme.
So schreibe ich meine Briefe schliesslich heutzutage mit MS Office statt vi, da ersteres ja nunmal ein besseres GUI hat, auch wenn ich letzteres lernen durfte :-)

M.E. gilt es die verschiedenen HA Lösungen über ihre Lebenszeit miteinander zu vergleichen, egal ob FHEM, OpenHab, IOBroker... und dann sollte jeder sich das raussuchen mit dem er glaubt eher an sein Ziel zu kommen.
Und eine gute Hausautomation ist natürlich nicht nur stabil, zuverlässig, vielseitig und läuft möglichst ohne Eingriffe, sondern kann auch von anderen Haushaltsmitgliedern genutzt und ggf. mal geändert und erweitert werden, ohne das ich die zu einer längeren Schulung schicken muss   ::)

Ich finde (auch das subjektive) Vergleichen der HA SW Alternativen als sehr wertvoll.
Ob es nun für FHEM überhaupt ansprechende Oberflächen gibt, ist wie alles was Design angeht sehr subjektiv. Bei den netten FHEM Alternativ GUIs von "klein wenig Arbeit" zu reden, empfinde ich nachdem ich bereits einige andere gesehen habe, aber als sehr arg optimistisch ;D

Da ich mittlerweile genug meiner Lebenszeit in FHEM investiert/verschwendet habe, mag ich es irgendwie und werde es bis auf weiteres auch noch einsetzen.
Ich muss aber auch zugeben das ich heutzutage sehr wenige Argumente wüsste, warum ich es jemand anderes als Neueinstieg empfehlen sollte, das hat mir mein bisheriger Vergleich gezeigt  :'(
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: marvin78 am 19 Februar 2018, 15:34:19
Wer lesen kann... ;)


Kann ich. Man darf eben nicht nur Teilzitate verwenden. Selektives Lesen sollte man vermeiden.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: CoolTux am 19 Februar 2018, 15:49:41
Das Problem in der heutigen Zeit ist, das alle denken sie wüssten dank des Marketings wie Hausautomatisierung aus sieht.
Schöne bunte Knöpfe im Bus drücken weil die Kaffeemaschine an geblieben ist. Das hat sie aber nur gemerkt weil sie nach gesehen hat. Die Rolläden runter fahren und das licht an machen draußen im Garten mit dem Handy. Wahrscheinlich sperrt der Vollpfosten sich dabei auch noch aus. Das alles ist für die da draußen Smarthome. Gruselig

Das die Kaffeemaschine automatisch aus schaltet wenn der letzte das Haus verlässt, das die Rolladen je nach Sonnenstand und Lichtintensität runterfahren und das Licht auf gleiche Weise an geht und das geprüft wird ob beim runter fahren die Terrassentür auf ist und das Rollo nicht fährt, sowas ist erst gar nicht in den Gedanken der Marketinggeistesverseuchten Leute von heute im Kopf.

Hauptsache der Knopf der App vibriert so lustig wenn man drüber fährt mit den Daumen. Und alles ist so schön magenta farbend. Ich könnt kotzen
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: JackWolfskind am 19 Februar 2018, 16:39:10
Das Problem in der heutigen Zeit ist, das alle denken sie wüssten dank des Marketings wie Hausautomatisierung aus sieht.
Schöne bunte Knöpfe im Bus drücken weil die Kaffeemaschine an geblieben ist. Das hat sie aber nur gemerkt weil sie nach gesehen hat. Die Rolläden runter fahren und das licht an machen draußen im Garten mit dem Handy. Wahrscheinlich sperrt der Vollpfosten sich dabei auch noch aus. Das alles ist für die da draußen Smarthome. Gruselig

Das die Kaffeemaschine automatisch aus schaltet wenn der letzte das Haus verlässt, das die Rolladen je nach Sonnenstand und Lichtintensität runterfahren und das Licht auf gleiche Weise an geht und das geprüft wird ob beim runter fahren die Terrassentür auf ist und das Rollo nicht fährt, sowas ist erst gar nicht in den Gedanken der Marketinggeistesverseuchten Leute von heute im Kopf.

Hauptsache der Knopf der App vibriert so lustig wenn man drüber fährt mit den Daumen. Und alles ist so schön magenta farbend. Ich könnt kotzen
Das Problem an der heutigen Zeit ist, das unsere Kinder sie als die gute alte Zeit glorifizieren werden ... hat schon mein Opa gesagt  ;D

Wird aber jetzt ein bischen Offtopic - interessanter wäre mit welcher HA SW bekommt denn zur Not auch ein farbenblinder "Vollpfosten" diese genannten Regel-Beispiele am zuverlässigsten umgesetzt?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: CoolTux 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.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: fiedel 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
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: marvin78 am 20 Februar 2018, 07:09:31
Könnte man meinen. Aber nein. Die Eigenschaften sind, bis auf den Einsatzzweck, aber ähnlich.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Pitcher90 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.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: supernova1963 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
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Fonzo 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.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Bluefox 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 :)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Per 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.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Nemo0815 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.




Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: CoolTux 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>
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap 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.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Amenophis86 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?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: raimundl 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
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag 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.

Ü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
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: raimundl 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
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: slor am 02 Oktober 2018, 20:00:22
Angeblich soll das gehen, wenn du die gleiche hmid ID nutzt.
Einfach dann an der ccu anlernen und das Gerät "wechselt" mit allen Einstellungen rüber. So die Theorie  :)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: raimundl am 02 Oktober 2018, 20:06:21
Angeblich soll das gehen, wenn du die gleiche hmid ID nutzt.
Einfach dann an der ccu anlernen und das Gerät "wechselt" mit allen Einstellungen rüber. So die Theorie  :)

Danke, muss ich mir anschauen - vorerst muss ich mich aber überhaupt in die CCU3 einlernen.
LG
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 03 Oktober 2018, 14:03:49
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

Wenn Du nicht unbedingt die Mediola Lizenz benötigst, nimm das Charly Set von ELV. Das entspricht Hardware technisch 1:1 der CCU3, ist aber billiger.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Nemo0815 am 04 Oktober 2018, 13:15:37
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.

... so wie's aussieht müsste man noch sehr viel mehr Abstriche machen bei openHab, gerade was so spezialisierte HW wie einen CUL (mit a-culfw) angeht und das einbinden verschiedener "noname" Produkte (IT) klappt bei FHEM einfach viel besser. Auch ist der Funktionsumfang vieler Bindings deutlich geringer als das entsprechende FHEM Equivalent (z.B. FS20, HMS...).

Openhab ist gut wenn man "neuere" HW hat, alles was irgendwie Cloud basiert ist oder per WiFi angesprochen werden will, also mit einfachen "Standardinterfaces" verbunden ist. Sobald es nur ein bischen spezieller und komplexer wird, ist selber programmieren/ändern angesagt - und darauf habe ich keine Lust und keine Zeit.

Und ein weitere Punkt der mich stört: Schnell mal was ändern ist nicht bei OpenHab, weil es keinen integrierten Editor gibt. Bei FHEM habe ich schon Sachen im Urlaub per Handy geändert, weil das interface das ohne Probleme zulässt.

Zitat
@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.

Ich habe gesucht, bei FHEM findet man fast immer eine Antwort durch einfaches googlen, davon ist OpenHab noch weit entfernt, sobald es mal nicht um "Standardprobleme" geht (z.B. bei MiLight und UDP Ports), einfach weil es zu wenige Leute gibt die diese Probleme schon gehabt haben.
Das macht es nicht einfacher...
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Wernieman am 04 Oktober 2018, 16:24:32
Lohnt es sich eigentlich, von der ccu2 auf die 3 zu gehen?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 04 Oktober 2018, 16:32:51
m.E. definitiv. Ist ein Geschwindigkeits Boost.
Von der Funktionalität her ist es mit der CCU2 identisch, es sei denn, man installiert RasperryMatic. Das hat ein paar zusätzliche Features.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Per am 04 Oktober 2018, 17:47:00
Ist ein Geschwindigkeits Boost.
Nur in der Weboberfläche? Oder auch anderswo spürbar?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 05 Oktober 2018, 08:13:13
Nur in der Weboberfläche? Oder auch anderswo spürbar?

Macht sich auch bemerkbar, wenn man mehrere RPC Anwendungen hat. Bei mir derzeit FHEM, ioBroker und PocketHM. Das führte bei der alten CCU schon zu einer gewissen Verzögerung bei der Benachrichtigung von Statusänderungen.

Klar, ein Raspi ist auch keine Rakete. Aber immer noch deutlich schneller als die in die Jahre gekommene ARM Plattform der CCU2. Der zusätzliche Speicher trägt hier sicher auch bei.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Wernieman am 05 Oktober 2018, 08:20:45
Wie sieht es mit der Funkverbindung aus? Besser oder gleichgeblieben?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 07 Oktober 2018, 18:23:01
Ich würde sagen gleich geblieben. Ich habe nicht mehr oder weniger unreachables als mit der CCU2.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Simon74 am 13 Oktober 2018, 23:55:45
ich habe auch ein wenig mit anderen Systemen rumgespielt, ich habe mich 2 Tage mit Symcon beschäftigt, 1 Tag mit openhab, ein wenig iobroker

symcon: Von der Geschwindigkeit der Systeme ist Symcon vorne, auch sonst finde ich es nach kurzer Eingewöhnung noch am nächsten zu fhem (klein, schlank, am einfachsten zu installieren, php kann nicht falsch sein)

openhab: Die Idee des Konfigurationsverzeichnisses und Configfile-Syntax von openhab gefällt mir im Grunde gut, die rein englische Doku zum lesen jedoch (für mich) "mühsam", das Java werkelt macht mir "Angst" ? Das Backup, kurz nach erstellen der openhab-sitemap hatte über 200mb [kopfkratz]

iobroker: Eigentlich selbst erklärend wie es einzurichten ist, mir fehlt es jedoch noch an Modulen, Visu ist ja schön, aber die Smartphone Ansicht auch so erstellen zu müssen, weiss nicht

Was bei openhab und symcon sehr gut gefällt, die gut funktionierenten Smartphone-Apps.

Nach dem ansehen dieser 2 Lösungen wird mir klarer was an fhem gut ist: Schnell, schlank, sehr sehr vielseitig, schön isses halt nicht :-)

Christkind bring mir bitte:   ;D
1. Weiterentwickelten Floorplan (dann bräuchte es mM. keine FTUI/smartvisu Aufsätze)
2. Eine schöne Smartphone App
3. Eine FHEM Admin-Gui deren Ansicht etwa so aufgebaut ist wie zb. das Adminpanel von Wordpress (mit der kann anscheinend jeder Internetwebmaster :)

zap,
ich weiss das sehr viel Mühe in der HMCCU stecken muss, ich frage mich jedoch warum eigentlich die Werte der CCU nicht "einfach" 1:1 übernommen werden,
ich empfinde die Homematic Anbindung bei iobroker,symcon logischer ?
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 14 Oktober 2018, 14:00:51
was meinst du mit Werte der CCU 1:1 übernehmen? Soll es nur ein Device für die CCU geben, in dem die Readings aller CCU Geräte abgelegt sind? Das wäre doch ziemlich unübersichtlich, da FHEM keine Baumansicht analog zur Objektansicht in IOBroker ermöglicht.

Ansonsten entspricht die Architektur von HMCCU der von IOBroker. Es gibt ein Geräte für die CCU und je eines für jede CCU Schnittstelle. In FHEM kommt dann eben nochmal ein Device je Aktor oder Sensor hinzu. Aber so ist eben die Vorgabe von FHEM.

Zu OpenHab: die offizielle Doku ist zwar in Englisch, jedoch lässt sie inhaltlich keine Wünsche offen. Es gibt auch deutsche Doku (einfach mal googeln). Persönlich/beruflich arbeite ich sowieso nur möit englischer Doku, da es für viele Dinge keine deutsche gibt oder die Übersetzung unbrauchbar ist. Aber auch bei FHEM gibt es für viele Module nur noch englische Doku.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 15 Oktober 2018, 14:28:48
Teil 4 - Sprachfunktionen / Alexa Integration

Die hier beschriebenen Erfahrungen geben meine subjektive Meinung in meiner Smarthome-Umgebung wieder.

Die funktionalen Unterschiede zwischen FHEM, IOBroker und OpenHab bei der Alexa SmartHome Integration sind marginal. Alle drei Systeme bieten einen Smarthome Skill an. Der Funktionsumfang dieses Skills ist durch Amazon genau festgelegt, von daher gibt es wenig Möglichkeiten der Abgrenzung. Zusätzlich bieten FHEM und IOBroker sogenannte Custom Skills mit deutlich größerem Funktionsumfang und mehr Konfigurationsmöglichkeiten an. Abstriche muss man hier lediglich bei OpenHab machen, das keinen Custom Skill anbietet.
 
Die Installation der Alexa Integration erfolgt bei allen drei Plattformen über ein separates Stück Software (Modul / Adapter / o.ä.). Möchte man Funktionen wie z.B. die Sprachausgabe über einen Echo nutzen, muss in FHEM zusätzlich das Modul "Amazon Echo Device" installiert werden.
 
Die Konfiguration bzw. Einrichtung der Skills unterscheidet sich hingegen deutlich, v.a. was den zeitlichen Aufwand betrifft.

FHEM

In FHEM ist die Einrichtung der Alexa Integration sehr komplex, da neben der lokalen Installation im Heimnetz auch ein Cloud-Service (AWS) eingerichtet werden muss. Es existieren zwar diverse Anleitungen, diese sind jedoch nur eingeschränkt nutzbar, da Amazon häufig die Konfigurationsseiten ändert und die Anleitungen dadurch schnell veralten. Außerdem ist für die Nutzung von Alexa unter FHEM eine Port-Freischaltung bzw. -Weiterleitung im Internet Router erforderlich. Diese ist zwar abgesichert, hinterlässt aber zumindest bei mir ein ungutes Gefühl. Für einen Einsteiger in die Alexa-Welt dürfte die FHEM Integration mindestens 1-2 Stunden in Anspruch nehmen, je nachdem, wie aktuell die Dokumentation gerade ist.

IOBroker und OpenHab

Bei IOBroker und OpenHab erfolgt die Alexa Integration über (kostenlose) Cloud-Dienste. Es genügt, einen Account unter iobroker.net oder myopenhab.org anzulegen. Im lokalen Adpater in IOBroker oder in OpenHab müssen lediglich noch die Credentials und die zu steuernden Geräte eingetragen werden. Danach ist der Dienst sofort nutzbar. Dauer der Aktion ca. 10 Minuten. Für OpenHab gibt es auch einen Lambda-Service, den man analog zur Alexa-Integration in FHEM auf Basis der AWS einrichten kann. Macht m.E. aber keinen Sinn, da man nur einen Cloud-Dienst durch einen anderen ersetzt, der außerdem nach 12 Monaten kostenpflichtig wird.
 
Bei IOBroker gibt es noch eine Besonderheit: Man kann auch einen kostenpflichtigen Cloud-Dienst buchen. Funktional gibt es keinen Unterschied zum kostenlosen. Jedoch ist die Performance der Cloud-Server angeblich besser. Meine persönliche Erfahrung: Momentan genügt der kostenlose Dienst. Er reagiert spürbar schneller als in FHEM. Das könnte sich mit zunehmder Nutzung von IOBroker natürlich ändern.
 
Fazit Teil 4 - Sprachintegration

Seit 2 Wochen habe ich Alexa von FHEM nach IOBroker migriert. Den Schritt habe ich nicht bereut. Bei OpenHab fehlt der Custom Skill. Das bestätigt meinen Entschluss, mit OpenHab noch zu warten, bis es einen solchen gibt oder Amazon die Smarthome Skills funktional aufwertet. Für Nutzer eines der Smarthome Skills ist es im Prinzip egal, welche der drei Plattformen man nutzt. Der Einrichtungsaufwand bei FHEM ist zwar groß, aber das ist Einmalaufwand und insofern kein Drama. Kostet halt Nerven.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: raimundl am 15 Oktober 2018, 16:08:16
@zap:
Ich verfolge interessiert deine Ausführungen und bin aufgrund dieser dabei einige Veränderungen für die Zukunft zu beginnen:

Vorher möchte ich jedoch betonen, dass ich mit FHEM zur Hausautomatisierung gekommen bin, sehr sehr viel dabei gelernt habe und sehr wohl die Leistungen der vielen Beteiligten zu schätzen weiß!

Anstoß für angedachte und teilweise auch getestete Veränderungen sind:

Der Homematic-Bereich endet derzeit mit Homematic ohne IP - Änderung des Status glaube ich ist schwer möglich.
Mein Vorhaben daher, sämtliche  Homematicgeräte auf eine CCU3 Plattform zu übertragen, die programmtechnischen Möglichkeiten dort direkt zu nutzen und über HMCCU die vielfältigeren Möglichkeiten von FHEM weiter zu nutzen.

Die Alexa Funktion von "justme" ist ein essentieller Bestandteil meiner Automation geworden. Sie läuft ausgezeichnet (mir genügt der "SmartHomeSkill vollauf) - jedoch wurde auch ein weiterer Skill angekündigt (über Cloud), wo seit Monaten keine Kommunikation mehr stattfindet. Der Autor dieser beiden Funktionen war auch seit Ende Juli nicht mehr im Forum. Das ist sein gutes Recht und ich bin dankbar für das bisher Geschaffene!
Die Alexa Anbindung bei Amazon ist aber sehr komplex und wird auch laufend geändert - daher meine Bedenken.
Hier möchte ich mir die Option schaffen, jederzeit rasch auf eine andere Plattform (ioBroker, openHab, ..) zu wechseln. Das geht natürlich m.E. auch leichter wenn die Geräte nativ auf einer Plattform (CCU3 Basis) sind.

Bin für Ratschläge dazu dankbar!

LG

PS.: Hat schon jemand Erfahrung mit ioBroker auf einer Synology?

Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Nemo0815 am 17 Oktober 2018, 14:45:17
In FHEM ist die Einrichtung der Alexa Integration sehr komplex...

Das wiederum kommt sehr darauf an was man machen will. MMn kann man sich den Alexa FHEM Skill komplett und damit die komplizierte Einrichtung sparen, denn wenn man der Empfehlung des Wikis folgt:

"Für kompliziertere Aktionen, etwa das Übermitteln eines spezifischen Schaltbefehls an FHEM, ist die Einrichtung eines Dummies zu empfehlen."

Dann lässt sich damit und einer HA-Bridge bzw. mittlerweile sehr flexiblen Routinen in Alexa fast alles umsetzen, bei minimalem Aufwand und - und das ist ein sehr großer Vorteil von FHEM - ohne einen Cloud Zugang zu benötigen.

Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 17 Oktober 2018, 15:40:30
Komplex bezog sich auf die Alexa Integration von justme. Das ist auch nicht die Schuld von FHeM sondern von Amazon, die ständig den Konfigurationsprozess ändern. Und bei dieser Lösung ist ja auch ne Cloud im Spiel (AWS).

Eine einfache Integration ist für mich:
- keine Konfiguration irgndwelcher Amazon Backend Funktionen
- einfache Angabe der Geräte, die ich mit Alexa steuern möchte, und zwar ohne Dummy, Readingproxy oder sonstige Workarounds
Einfach „einfach“ funktionieren  :)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Nemo0815 am 17 Oktober 2018, 16:49:05
Komplex bezog sich auf die Alexa Integration von justme. Das ist auch nicht die Schuld von FHeM sondern von Amazon, die ständig den Konfigurationsprozess ändern. Und bei dieser Lösung ist ja auch ne Cloud im Spiel (AWS).


Das stimmt, deswegen nutze ich das Modul auch nicht, sondern ausschliesslich 37_amazecho, eine HA-Bridge und der Rest geht direkt in der Alexa App über Routinen bzw. Dummies in FHEM (falls nötig für komplexe Schaltvorgänge oder um Rückantworten an Alexa zu geben, z.B. den aktuellen Status aller geöffneten Fenster als Sprachantwort zurückzugeben).
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Maui am 22 Oktober 2018, 09:24:53
Moin,

hab den Thread mal gelesen (leider ohne Popcorn) und musste an paar Ecken schmunzeln.
Ich hab mich natürlich auch schon über das Frontend von FHEM geärgert und die bekannten Ansätze dort (smartVisu,TabletUI, floorplan) haben mich alle nicht komplett überzeugt.
Am Ende bin ich bei Floorplan hängen geblieben, aber nutze effektiv doch immer f18 und das normale Menü.
@zap: Bzgl. Alexa, AWS und Kosten muss man mal die Kirche im Dorf lassen. Ja in der Theorie kostet es etwas, aber in der Realität nicht. Es sei denn, du liest Alexa nachts immer Gute-Nacht Geschichten vor :)
Prinzipiell finde ich es gut, wenn mal jemand über den (FHEM) Tellerrand guckt und schaut, was die große weite Welt so bietet.
Allerdings wirkst du schon sehr negativ (vor)belastet, was FHEM angeht. Auch was den Support im Forum angeht, übertreibt ihr beide, finde ich.

Ja, komplett Ahnungslose, die zu faul sind, sich einzulesen, werden vielleicht nicht immer in den Mund gefüttert. Aber jeder hier ist auch privat und in seiner Freizeit unterwegs.
Und ich muss auch mal eine Lanze für FHEM und das Forum brechen. Es gibt kein Problem, was ich nicht mit FHEM lösen konnte. Und das Forum ist denke ich das größte deutschsprachige SmartHome Forum seiner Art (ja mag auch an der Historie liegen).

Aber aus dem Thread werde ich mitnehmen, mal ioBroker anzuschauen, vor allem in Kombi mit FHEM Adapter.

Bloß mein Ketchup.... :)
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: zap am 23 Oktober 2018, 07:42:27
Ich denke nicht, dass ich irgendwo das FHEM Forum kritisiert habe. Das Forum ist mit das beste, was es im Smarthome Bereich gibt.

Auch die Kosten bei Aws sind für mich zweitrangig. Wie beim Rest von FHEM geht es mir bei Alexa um die Komplexität der Konfiguration und die Höhe der Hürde für Einsteiger und auch Nutzer.

Ich möchte, dass mein Smarthome auch von Familienmitgliedern einfach bedient werden kann. Auch wenn ich mal nicht da bin, sollte es jedem möglich sein, kleinere Fehler zu beheben.

Und schließlich möchte ich nicht bei jeder kleinen Erweiterung um eine Steckdose in die Tiefen der HTML und CSS Programmierung abtauchen, um das Gerät für alle nutzbar zu machen. Nicht weil ich es nicht kann, sondern weil mir einfach die Zeit dafür zu Schade ist.

Ich vergleiche das gerne mit dem PC. Früher war das für mich mein Hobby. Programmieren, Basteln und Dinge ausprobieren. Dann wurde das Hobby zum Beruf und man wurde älter. Nun ist der PC zuhause ein reines Arbeitsmittel für Bildbearbeitung, Abrechnungen usw. Früher habe ich Tools für Bildbearbeitung selbst entwickelt, heute nutze ich Lightroom, Photoshop und co.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Maui am 23 Oktober 2018, 08:11:46
Ich verstehe ja deinen Ansatz, aber ich bezweifele, dass meine bessere Hälfte mal ernsthaft was am Smart Home fixxt, vor allem spätestens, wenn es Richtung Heizungssteuerung etc. geht. Und da würde auch Blockly zb. nicht helfen.
Meistens sind es auch eklige Sachen (bei mir) wenn irgendwas in die Brüche geht.

Und ich sehe es auch bei mir schon, dass ich teilweise echt grübeln muss (zB. bei komplexen DOIFs) was ich eigentlich will und am Ende muss ich doch noch 1-2 Iterationen drehen, um ans Ziel zu kommen.
Was das Anlegen in FHEM angeht, geb ich dir total Recht. Ich muss immer in die Ref oder in meine alten defines gucken, weil ich zu gemütlich bin, mir den Kram zu merken. Da wären andere wie ioBroker sicher angenehmer. Aber die Logik im DOIF muss man eben doch immer im Kopf stricken.
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: wkarl am 16 Dezember 2018, 18:08:32
Hallo an alle,

unabhängig von diesem thread habe ich diese Woche mir io.Broker und OpenHab angesehen.

io.Broker: schnell mal CCU2 und io.Broker als Docker container geladen - das mit den Ports war ein bisschen frickelig, da ich noch nie eine CCU in den Händen hatte. Kurz zusammengefasst - die devices in der CCU erfassen und verwalten (z.B peeren) und in io.Broker vis darstellen war mir am Ende zu umständlich. Der Aufwand für Tablet UI und io.Broker vis ist so ziemlich der selbe. Nach zwei Tagen habe ich das Projekt eingestellt.

OpenHab: OpenHab container geladen und versucht mit der CCU2 zu binden (Paper UI) ... Ich habs nicht hinbekommen und den Versuch nach wenigen Stunden eingestellt.

Jetzt bin ich wieder bei fhem und Tablet UI mit der Erkenntnis, dass es für mich das bessere Packet ist.

Meine 'two cents' zu diesem Thema.

Caio Walter
Titel: Antw:Vergleich FHEM - IOBroker - OpenHab
Beitrag von: Maui am 17 Dezember 2018, 07:33:28
Ich hab mich in den letzten Wochen auch mal ein wenig mit ioBroker befasst. Ich konnte im Vergleich mit FHEM eigentlich nur 2 Vorteile erkennen:
-leichterer Einstieg
-non blocking, zumindest wenn ein Adapter sich ausklinkt, läuft der Rest weiter

Als ich dann allerdings mal versucht habe, eine Test-Nachricht mit telegram abzusetzen, kreiert man mit Blockly oder JS schnell ein Monster. In FHEM reicht ein DOIF als one-Liner oder direkt mit set ...

Gerade Blockly mag bei komplexen Abfragen schöner zu lesen zu sein, allerdings macht es das auch unnötig kompliziert.

Ich würde also grob sagen, ioBroker ist die Hausfrauen-Variante von fhem. Möchte man so ein bisschen Smart-Home machen und ist noch nicht ewig in FHEM unterwegs und ist bereit für Kompromisse, dann ist das sicherlich eine gute Alternative. Ich werd auf jeden Fall (erstmal) bei FHEM bleiben.