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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2380
    • 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 5 - Steuerung / Automatisierung
  • Teil 6 - Hue Integration
  • Teil 7 - Eigene Dashboards / Webinterfaces

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: 15 Oktober 2018, 14:31:08 von zap »
CCU3 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
IOBroker VIS
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU2 - FHEM = best of both worlds approach)
Gefällt mir Gefällt mir x 8 Liste anzeigen

Offline slor

  • Full Member
  • ***
  • Beiträge: 466
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 Debian Stretch
CCU3 mit RaspberryMatic im Testbetrieb
FS20, Homematic, MQTT, Telegram, Sonoff mit Tasmota, Bluetooth Anwesenheitserkennung mit Handys

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2380
    • 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 »
CCU3 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
IOBroker VIS
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU2 - FHEM = best of both worlds approach)
Gefällt mir Gefällt mir x 2 Informativ Informativ x 2 Liste anzeigen

Offline C0mmanda

  • Full Member
  • ***
  • Beiträge: 347
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: 1218
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: 1688
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: 2380
    • 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.

CCU3 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
IOBroker VIS
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU2 - FHEM = best of both worlds approach)

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6111
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: 2380
    • 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.
CCU3 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
IOBroker VIS
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU2 - FHEM = best of both worlds approach)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2380
    • 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 »
CCU3 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
IOBroker VIS
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU2 - FHEM = best of both worlds approach)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6111
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: 4685
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: 6111
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: 2380
    • 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 ;-)
CCU3 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
IOBroker VIS
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU2 - FHEM = best of both worlds approach)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6111
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