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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3026
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #90 am: 17 Oktober 2018, 15:40:30 »
Komplex bezog sich auf die Alexa Integration von justme. Das ist auch nicht die Schuld von FHeM sondern von Amazon, die ständig den Konfigurationsprozess ändern. Und bei dieser Lösung ist ja auch ne Cloud im Spiel (AWS).

Eine einfache Integration ist für mich:
- keine Konfiguration irgndwelcher Amazon Backend Funktionen
- einfache Angabe der Geräte, die ich mit Alexa steuern möchte, und zwar ohne Dummy, Readingproxy oder sonstige Workarounds
Einfach „einfach“ funktionieren  :)
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline Nemo0815

  • Full Member
  • ***
  • Beiträge: 132
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #91 am: 17 Oktober 2018, 16:49:05 »
Komplex bezog sich auf die Alexa Integration von justme. Das ist auch nicht die Schuld von FHeM sondern von Amazon, die ständig den Konfigurationsprozess ändern. Und bei dieser Lösung ist ja auch ne Cloud im Spiel (AWS).


Das stimmt, deswegen nutze ich das Modul auch nicht, sondern ausschliesslich 37_amazecho, eine HA-Bridge und der Rest geht direkt in der Alexa App über Routinen bzw. Dummies in FHEM (falls nötig für komplexe Schaltvorgänge oder um Rückantworten an Alexa zu geben, z.B. den aktuellen Status aller geöffneten Fenster als Sprachantwort zurückzugeben).

Offline Maui

  • Sr. Member
  • ****
  • Beiträge: 559
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #92 am: 22 Oktober 2018, 09:24:53 »
Moin,

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

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

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

Bloß mein Ketchup.... :)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3026
    • HMCCU
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #93 am: 23 Oktober 2018, 07:42:27 »
Ich denke nicht, dass ich irgendwo das FHEM Forum kritisiert habe. Das Forum ist mit das beste, was es im Smarthome Bereich gibt.

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

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

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

Ich vergleiche das gerne mit dem PC. Früher war das für mich mein Hobby. Programmieren, Basteln und Dinge ausprobieren. Dann wurde das Hobby zum Beruf und man wurde älter. Nun ist der PC zuhause ein reines Arbeitsmittel für Bildbearbeitung, Abrechnungen usw. Früher habe ich Tools für Bildbearbeitung selbst entwickelt, heute nutze ich Lightroom, Photoshop und co.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline Maui

  • Sr. Member
  • ****
  • Beiträge: 559
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #94 am: 23 Oktober 2018, 08:11:46 »
Ich verstehe ja deinen Ansatz, aber ich bezweifele, dass meine bessere Hälfte mal ernsthaft was am Smart Home fixxt, vor allem spätestens, wenn es Richtung Heizungssteuerung etc. geht. Und da würde auch Blockly zb. nicht helfen.
Meistens sind es auch eklige Sachen (bei mir) wenn irgendwas in die Brüche geht.

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

Offline wkarl

  • Sr. Member
  • ****
  • Beiträge: 851
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #95 am: 16 Dezember 2018, 18:08:32 »
Hallo an alle,

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

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

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

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

Meine 'two cents' zu diesem Thema.

Caio Walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Maui

  • Sr. Member
  • ****
  • Beiträge: 559
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #96 am: 17 Dezember 2018, 07:33:28 »
Ich hab mich in den letzten Wochen auch mal ein wenig mit ioBroker befasst. Ich konnte im Vergleich mit FHEM eigentlich nur 2 Vorteile erkennen:
-leichterer Einstieg
-non blocking, zumindest wenn ein Adapter sich ausklinkt, läuft der Rest weiter

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

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

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

Offline Simon74

  • Full Member
  • ***
  • Beiträge: 371
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #97 am: 13 Oktober 2019, 16:29:12 »
Ich habe mir die letzten Tage wieder mal Symcon, iobroker, homeassistant ein wenig angesehen.
Bei Symcon: sehe ich das Problem das zuwenig vorgefertigte Module bestehen, dürfte non opensouce geschuldet sein, (zu wenig freiwillige Entwickler?).
Bei iobroker: Übersichtlichkeit über die "Objekte" besser macht das denke ich keine andere Lösung, VIS ist mir jedoch zu hoher Aufwand, und andere (habpanel, lovelace,smartvisu..) sind nicht fertig eingebunden.
HomeAssistant: Lovelace sieht schick aus, aber kompakt viele Dinge ohne scrollen auf einer Seite ist damit auch nicht möglich. Verwende zwar ansible, aber yaml im Smarthome.. ich weiss nicht. Dockerzwang mag ich ebenso wenig. (Nach ausschalten der VM) kam der Docker-Container nicht mehr hoch und home assistant startete nicht mehr.

Hätte nicht gedacht das ich diese Erkenntnis erreiche, jedoch ist für mich ein Grund bei FHEM zu bleiben, die Oberfläche mit Floorplan und f18, und natürlich die Anzahl der Themen für die es schon fertige Module gibt.
Floorplan: so einfach und kompakt viele Dinge fürs Tablet über eine Seite ( klickbare Icons) zu steuern bekomme ich bis dato bei keiner anderen Lösung hin, ausserdem habe ich mit f18 so gut wie eine fertige mobile Ansicht ohne viel Aufwand. Mit etwas CSS sieht das ganze auch noch ansehlich aus  :)
Obwohl mir manche Dinge in FHEM zu komplex oder komisch erscheinen, habe ich bis dato erreicht was ich eigentlich wollte, stabilität war sowieso nie ein Thema.

Nie gefallen wird mir jedoch das PERL Klammernzeugs {["()"]}  :D
Und die Unverständniss warum nicht die Energie von TabletUI in den Floorplan geflossen ist.
« Letzte Änderung: 13 Oktober 2019, 16:31:55 von Simon74 »
INTEL Nuc: KVM,FHEM,Bluetooth,RfxTRX-E | Raspberrys: Bluetooth,Presence,SmsGateway
Homematic: CCU3, LAN Adapter, Türkontakte, Keymatic, Schalter/Dimmer/Taster, Steckdosen, Bewegungsmelder usw.
Sonstiges: Somfy, Logitech Hub, Squeezebox, Alexa

Offline sz_wolfi

  • New Member
  • *
  • Beiträge: 31
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #98 am: 13 Oktober 2019, 23:59:30 »
Könntest Du bitte genauer ausführen, wo die FHEM-Doku nicht verstaendlich bzw. unvollstaendig ist, damit ich die Aussage verstehe. Danke.
Gruß, Christian

na ja - z.B. die commandref ist sicher vollständig, nur überfordert sie Newbies ganz sicher.
Fuer mich, war sie am Anfang viel zu abstrakt ... und ohne Beispiel-Snippets quasi wertlos.
Mittlerweile - ist sie meine 'Lieblingswebseite' im FHEM-Universum - neben der DevelopmentModuleAPI.
 
die vielen einfachen Beispiel-Snippets aus dem Forum und Wiki - das war der Anfang.
Und auch wenn nicht alle Snippets immer funktionieren, ich konnte immer was draus lernen.
Mittlerweile schätze ich den Perl-Mode sehr - extrem praktisch!
(z.B. userReadings zu erstellen, um z.B. div. Z-Wave-Geräten die Marotten auszutreiben)

Ja - FHEM hat kein "schönes" GUI - und ich bin Web-künstlerisch ziemlich unbegabt - und anspruchslos ;-)
Aber wie schon viele vorher schreiben - ich will von FHEM eigentlich gar nichts sehen.
(bzw. wenn ich was sehen will - sind es fast immer zuerst die Log-Files ... )

Ich habe diverse Z-Wave Fernbedienungen, Schalter, Thermostate etc. - das ist mein primäres 'GUI'.
Automatisierte Entscheidungen 'unsichtbar' im Hintergrund - das soll FHEM machen.
Dafür braucht man 'Input' - auch z.B. via Unifi,Enigma2,FritzBox etc.
Und ja, die "Lernkurve" - ist am anfang extrem steinig ... aber ich bereue es nicht.

Zustimmung Zustimmung x 1 Liste anzeigen

Online Thyraz

  • Sr. Member
  • ****
  • Beiträge: 997
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #99 am: 14 Oktober 2019, 09:58:38 »
Ich habe aufgrund der teils schöneren Frontends zuerst mehrere Lösungen der Mitbewerber ausprobiert.
Wenn man aber einen wild gemischten Hardwarepark hat, aufwändigere Automatisierungen umsetzen will, sowie bei vielen neuen Geräten frühzeitig Unterstützung sucht, landet man irgendwann doch bei FHEM.

Ich halte es für keinen Nachteil, dass man hier etwas Programmieren lernen muss.
Klar gibt es bei anderen Systemen grafische Konzepte wie z.B. Blockly die zu Beginn verführerisch wirken.
Doch wenn die Automatisierungen komplexer werden, muss man hier meist auch auf eine Skriptsprache ausweichen, welche erlernt werden will.
Der Vorteil der schnelleren Einarbeitung ist also eher von kurzer Natur.

Wenn man sich erst einmal in eine Skriptsprache eingearbeitet hat, halte ich es für sinnvoller diese immer zu verwenden,
anstatt innerhalb des SmartHome Systems zweigleisig zu fahren.
Allein schon deshalb, weil auch zu Beginn einfach wirkende Automatisierungsaufgaben dazu tendieren, mit der Zeit durch Feinjustage komplexer zu werden.

Und wie schon öfters erwähnt: Das Ziel sollte normal sein, dass die Bewohner das Konfigurationsinterface des SmartHome Systems nie zu Gesicht bekommen.
Taster / Sensoren in der Wohnung sollten die Bedienung ohne Smartphone / Tablets ermöglichen,
da dies an sich immer unkomfortabler bzw. langsamer und somit gar nicht smart ist. ;)
Selbst Sprachsteuerung ist da oft vorzuziehen.

Ausgaben des Systems halte ich auch sinnvoller mit Sprachausgabe, Sounds, Lampeneffekten, Textanzeigen (bei uns z.B. Lametric Time) oder Push Notifications aufs Handy umzusetzen.
Popups/Anzeigen in der SmartHome Oberfläche oder eine Notification Queue in der selbigen sind auch eher wieder schwer zu erreichen oder im entscheidenden Moment nicht sichtbar.

Es ist natürlich trotzdem gut Lichter / Geräte übers Handy steuern zu können wenn man mal will, Szenen zu starten und z.B. eine Übersicht über die Sensorik wie z.B. Temperatur und Luftfeuchtigkeit von allen Räumen zu sehen.
Dafür ist aber eine vereinfachte Ansicht von Vorteil, da man weder Konfigurationsdialoge, noch die unzähligen zur Bedienung unnötigen Geräte präsentieren will.

Hier gibt es ja z.B. mit TabletUI eine schöne Lösung.
Bei mir kommt hingegen zur Zeit einfach Homekit zur Anwendung. Damit kommen alle in der Familie gut zurecht.
Die Möglichkeit Favoriten direkt vom Sperrbildschirm/Control Center der Geräte zu bedienen ohne erst eine App öffnen zu müssen,
trägt sehr dazu bei, dass der Nervfaktor bei Handynutzung nicht zu hoch ist.

Aktuell spiele ich auch noch ein wenig damit ausgewählte Geräte per MQTT freizugeben und diese in einer nur als Frontend zweckentfremdeten Installation von HomeAssistant zu präsentieren.
Funktioniert auch einwandfrei und man kann HomeAssistant von der UI schlank halten, da nicht alle Geräte aus Fhem dort landen müssen.
Als Hauptsystem wäre mir HomeAssistant aber nicht flexibel genug.
Auch die Tatsache, dass man einzelne Räume (Views) nicht komplett vor einzelnen Usern verstecken kann, stellt einen wieder vor das Problem, dass die Familienmitglieder keine schlanke Oberfläche haben.
Wird bei mir wahrscheinlich eher wieder rausfliegen, da ich das eher aus Interesse mal testen wollte.
Aber kann durchaus eine schöne Lösung als Frontend für FHEM sein.

Der letzte Punkt der auf einem Handy / Tablet /Computer dann interessant ist, wären noch Langzeitauswertungen.
Also Charts, Kurven, ...
Da kommt von der Flexibilität und der einfachen Bedienung was die Wahl des Zeitraum u.Ä. angeht aber kein SmartHome System an speziell dafür optimierte Software heran.
Ich verwende hier Grafana (bei FHEM z.B. mit DBLog und dem Grafana MySQL Adapter nutzbar) und einzelne Auswertungen werden sogar recht gerne von meiner Frau angeschaut.
z.B. Temperaturverläufe in der Wohnung, Übersicht wann es geregnet hat, Außentemperatur in der Jahresübersicht jeweils mit Min/Max/Mittelwert pro Tag und andersfarbig hinterlegt mit den selben Kuven aus dem Vorjahr zum Vergleich.

Als "Poweruser" ist FHEM für mich immer noch recht alternativlos.
Mag für Leute die nur ein paar Geräte auf einfache Weise automatisieren wollen natürlich ganz anders aussehen...
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Lacrosse, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, ...
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Simon74

  • Full Member
  • ***
  • Beiträge: 371
Antw:Vergleich FHEM - IOBroker - OpenHab
« Antwort #100 am: 27 November 2019, 18:19:54 »
Ich muss mich "outen".
Mein Weihnachtsgeschenk dieses Jahr war eine Symcon umlimited Lizenz  :)

Ich möchte mich bei allen Entwicklern von FHEM für Ihre tolle Arbeit, Zeit und Hilfe bedanken !
DOIF, ich vermisse dich  :)
INTEL Nuc: KVM,FHEM,Bluetooth,RfxTRX-E | Raspberrys: Bluetooth,Presence,SmsGateway
Homematic: CCU3, LAN Adapter, Türkontakte, Keymatic, Schalter/Dimmer/Taster, Steckdosen, Bewegungsmelder usw.
Sonstiges: Somfy, Logitech Hub, Squeezebox, Alexa

 

decade-submarginal