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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Vergleich FHEM - IOBroker - OpenHab
« 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:
  • Teil 4 - Hue Integration
  • Teil 5 - Eigene Dashboards / Webinterfaces
  • Teil 6 - Sprachsteuerung mit Alexa

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:
  • IOBroker: Leichtgewichtige Lösung mit schnell zu konfigurierendem Frontend. Unterstützung aller für mich wichtigen Gerätetypen. Kleine Community. Neue Entwicklungen dauern etwas.
  • OpenHab: Seit Version 2.0 gut konfigurierbare Plattform mit einem enormen Umfang an unterstützten Gerätetypen. Sehr große, internationale Community. Sehr kurze Innovationszyklen
  • Indigo: Mac Only. Keine Homematic Integration out of the box. Stelle ich erst mal zurück.
  • IP-Symcon: Kostet Geld, ansonsten umfangreicher Gerätezoo, schicke, leicht zu konfigurierende Oberfläche
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:
  • Homematic CCU2 mit 80 Geräten
  • SONOS mit 5 Lautsprechern (seit einem größeren Update des Moduls im Sommer in FHEM kaum noch benutzbar)
  • Hue Lampen
  • Alexa
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.
« Letzte Änderung: 04 Januar 2018, 21:00:58 von zap »
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)
Gefällt mir Gefällt mir x 5 Liste anzeigen

Offline slor

  • Full Member
  • ***
  • Beiträge: 423
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #1 am: 24 Dezember 2017, 11:44:14 »
Super cool! Wollte ich auch schon immer Mal machen, nur nie Zeit gefunden.
FHEM auf Cubietruck mit Igor Image (weezy)
FS20, Homematic, MQTT, Telegram, Sonoff mit Tasmota Firmware, Bluetooth Anwesenheitserkennung mit Handys

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #2 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.
« Letzte Änderung: 25 Dezember 2017, 11:23:20 von zap »
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)
Gefällt mir Gefällt mir x 2 Informativ Informativ x 2 Liste anzeigen

Offline C0mmanda

  • Full Member
  • ***
  • Beiträge: 290
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #3 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

Offline Fixel2012

  • Hero Member
  • *****
  • Beiträge: 1215
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #4 am: 25 Dezember 2017, 13:01:02 »
Auch ich finde, dass ist ein sehr Interessantes Thema!

Freue mich über weitere Updates!
Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

Offline fiedel

  • Hero Member
  • *****
  • Beiträge: 1626
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #5 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
FHEM 5.7 FeatureLevel: 5.7 auf Dreamplug/Deb. 7; Perl: v5.14.2
HM: HM-CFG-USB-2 + hmland | SlowRF: CUNO V2.1/CULFW V 1.43 868
OWServer:LinkUSBi | OWDevice:DS18S20|DS2401|DS2406|DS2423

Offline zap

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

CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5908
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #7 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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #8 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.
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline zap

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

« Letzte Änderung: 26 Dezember 2017, 15:46:33 von zap »
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5908
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #10 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?

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4652
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #11 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 !
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5908
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #12 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.
Zustimmung Zustimmung x 1 Liste anzeigen

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #13 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 ;-)
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5908
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #14 am: 26 Dezember 2017, 16:48:59 »
Also von meiner Seite gilt genauso wie von Joerg: Mach hier weiter! Interessiert mich.  :)
« Letzte Änderung: 26 Dezember 2017, 16:52:47 von krikan »
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Amenophis86

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

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 2683
    • Homepage
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #16 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
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #17 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.
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline DerBodo

  • Full Member
  • ***
  • Beiträge: 222
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #18 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 ?
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Mathea

  • Full Member
  • ***
  • Beiträge: 132
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #19 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.

Offline zap

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

CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Online marvin78

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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #22 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.
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Online marvin78

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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #24 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.
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)
Gefällt mir Gefällt mir x 1 Informativ Informativ x 1 Liste anzeigen

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 2683
    • Homepage
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #25 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
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #26 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.
« Letzte Änderung: 04 Januar 2018, 21:45:11 von zap »
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 2683
    • Homepage
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #27 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
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 754
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #28 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. ;-)

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 2683
    • Homepage
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #29 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
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2394
  • Anti-Statement befreite Zone ;)
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #30 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 :)
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System
Gefällt mir Gefällt mir x 1 Liste anzeigen

Online marvin78

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

Offline Amenophis86

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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #33 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  : ;)
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Online marvin78

  • Hero Member
  • *****
  • Beiträge: 5131
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #34 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.
Zustimmung Zustimmung x 5 Liste anzeigen

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #35 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 ;-)
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Online marvin78

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

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 2683
    • Homepage
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #37 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
HM, FS20, 1-Wire, PanStamp, AVR-NET-IO, SIS-PM, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #38 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.
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline raimundl

  • Full Member
  • ***
  • Beiträge: 319
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #39 am: 02 Februar 2018, 16:47:35 »
@zap

Gibt es bald neue Erkenntnisse?
Homematic: Licht, Heizung, Alarm,...  auf zwei RaspberryPi3 mit OS "Stretch" und HM-MOD-RPI-PCB, alexa, MobileAlerts, Hue Ledstripes, ....

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #40 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.
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline JackWolfskind

  • New Member
  • *
  • Beiträge: 18
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #41 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!  :)
« Letzte Änderung: 05 Februar 2018, 18:55:55 von JackWolfskind »
HW Entwickler mit diversen Raspi Projekten z.B. FHEM, OpenHab, IOBroker, NodeRed, Airconnect,Waermepumpen und Lunos Lueftungssteuerung...
Gefällt mir Gefällt mir x 12 Liste anzeigen

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #42 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.
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5908
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #43 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

Offline JackWolfskind

  • New Member
  • *
  • Beiträge: 18
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #44 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? ;)
HW Entwickler mit diversen Raspi Projekten z.B. FHEM, OpenHab, IOBroker, NodeRed, Airconnect,Waermepumpen und Lunos Lueftungssteuerung...

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4652
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #45 am: 10 Februar 2018, 22:52:33 »
das FHEM smartVisu kann ist bekannt ?
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline JackWolfskind

  • New Member
  • *
  • Beiträge: 18
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #46 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  :'(
HW Entwickler mit diversen Raspi Projekten z.B. FHEM, OpenHab, IOBroker, NodeRed, Airconnect,Waermepumpen und Lunos Lueftungssteuerung...

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #47 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
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Online the ratman

  • Hero Member
  • *****
  • Beiträge: 1482
  • cosmoprolet & intelligenzdiabetiker
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #48 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?
« Letzte Änderung: 11 Februar 2018, 12:11:38 von the ratman »
→do↑p!dnʇs↓shit←

Offline JackWolfskind

  • New Member
  • *
  • Beiträge: 18
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #49 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... :-)
HW Entwickler mit diversen Raspi Projekten z.B. FHEM, OpenHab, IOBroker, NodeRed, Airconnect,Waermepumpen und Lunos Lueftungssteuerung...

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #50 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
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline JackWolfskind

  • New Member
  • *
  • Beiträge: 18
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #51 am: 16 Februar 2018, 23:48:32 »
HW Entwickler mit diversen Raspi Projekten z.B. FHEM, OpenHab, IOBroker, NodeRed, Airconnect,Waermepumpen und Lunos Lueftungssteuerung...

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #52 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.
« Letzte Änderung: 17 Februar 2018, 08:23:54 von zap »
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Online marvin78

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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2110
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #54 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.
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Online marvin78

  • Hero Member
  • *****
  • Beiträge: 5131
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #55 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.
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline JackWolfskind

  • New Member
  • *
  • Beiträge: 18
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #56 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  :'(
HW Entwickler mit diversen Raspi Projekten z.B. FHEM, OpenHab, IOBroker, NodeRed, Airconnect,Waermepumpen und Lunos Lueftungssteuerung...

Online marvin78

  • Hero Member
  • *****
  • Beiträge: 5131
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #57 am: 19 Februar 2018, 15:34:19 »
Wer lesen kann... ;)


Kann ich. Man darf eben nicht nur Teilzitate verwenden. Selektives Lesen sollte man vermeiden.

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14997
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #58 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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer
Gefällt mir Gefällt mir x 3 Zustimmung Zustimmung x 4 Liste anzeigen

Offline JackWolfskind

  • New Member
  • *
  • Beiträge: 18
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #59 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?
HW Entwickler mit diversen Raspi Projekten z.B. FHEM, OpenHab, IOBroker, NodeRed, Airconnect,Waermepumpen und Lunos Lueftungssteuerung...

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14997
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #60 am: 19 Februar 2018, 17:19:20 »
Da ich nur FHEM kenne und weiß das es damit geht würde ich sagen damit. Was er selber an Konfiguration nicht tanzen kann, kann er ja als KnowHow dazu kaufen, macht er ja mit seiner derzeit magenta farbenen Schlüpper auch schon. Nur das mit FHEM mehr geht und bei Problemen schneller reagiert wird.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline fiedel

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

Online marvin78

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

Offline Pitcher90

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

Offline supernova1963

  • Full Member
  • ***
  • Beiträge: 314
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #64 am: 04 Mai 2018, 18:51:45 »
Auch ich hoffe auf weitere Erfahrungsberichte. Bisher kann ich die Erfahrungen von zap nahezu 1:1 teilen.
Nur alle 3 Systeme wollte ich nicht unter OS X gemeinsam installieren. Hier habe ich 3 identische Ubuntu Server VM unter Parallels angelegt. Hier ist auch die Installation von openHab mit snap wirklich super einfach.
Im laufenden Betrieb meine ich, dass ioBroker die meisten Ressourcen benötigt. Gefolgt von openHab und FHEM. Täuscht der Eindruck, oder könnt ihr das bestätigen?

lg

Gernot
Fhemserver: Mac Mini - Parallels Desktop mit Ubuntu Server 18.04,
Module: Harmony, fakeRoku, FBAHA, Fritzbox, MQTT + espBridge + TASMOTA_DEVICE, HMCCU, Nmap, ...

Offline Fonzo

  • New Member
  • *
  • Beiträge: 5
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #65 am: 08 Mai 2018, 15:37:07 »
Im laufenden Betrieb meine ich, dass ioBroker die meisten Ressourcen benötigt. Gefolgt von openHab und FHEM. Täuscht der Eindruck, oder könnt ihr das bestätigen?
So ist zumindest auch mein Eindruck, FHEM ist klein und schlank, ioBroker braucht von den drei Systemen am meisten Ressourcen, vor allem Speicher.