Vergleich FHEM - IOBroker - OpenHab

Begonnen von zap, 24 Dezember 2017, 11:19:28

Vorheriges Thema - Nächstes Thema

slor

Angeblich soll das gehen, wenn du die gleiche hmid ID nutzt.
Einfach dann an der ccu anlernen und das Gerät "wechselt" mit allen Einstellungen rüber. So die Theorie  :)
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

raimundl

Zitat von: slor am 02 Oktober 2018, 20:00:22
Angeblich soll das gehen, wenn du die gleiche hmid ID nutzt.
Einfach dann an der ccu anlernen und das Gerät "wechselt" mit allen Einstellungen rüber. So die Theorie  :)

Danke, muss ich mir anschauen - vorerst muss ich mich aber überhaupt in die CCU3 einlernen.
LG
Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....

zap

Zitat von: raimundl am 02 Oktober 2018, 19:52:55
Hallo zap!
Danke, genauso habe ich es mir gedacht. Jetzt muss ich mich entscheiden, ob ich ca. 30 HM Geräte auf eine original CCU3 portiere oder meine erworbene RPI-RF-MOD mit einem Raspi verwende.
Wenn ich nun wirklich übersiedle, tendiere ich zu einer originalen CCU3 aus Zukunftssicherheit.
Stelle mir vor, dass das Übersiedeln nur mit neu Anlernen jedes Gerätes funktioniert?

LG

Wenn Du nicht unbedingt die Mediola Lizenz benötigst, nimm das Charly Set von ELV. Das entspricht Hardware technisch 1:1 der CCU3, ist aber billiger.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Nemo0815

Zitat von: zap am 02 Oktober 2018, 09:04:29Weiteres Kriterium derzeit: Weder der Homematic Adapter von IOBroker noch der von OpenHab kann das, was mein FHEM Modul HMCCU kann. Da müsste ich vermutlich Abstriche machen.

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

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

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

Zitat@Nemo0815: Im Zweifel würde ich bei Problemen mit OpenHab so vorgehen, wie Du es auch bei FHEM machen würdest. Frag die Community! Du bekommst mindestens genauso schnell Hilfe wie im FHEM Forum.

Ich habe gesucht, bei FHEM findet man fast immer eine Antwort durch einfaches googlen, davon ist OpenHab noch weit entfernt, sobald es mal nicht um "Standardprobleme" geht (z.B. bei MiLight und UDP Ports), einfach weil es zu wenige Leute gibt die diese Probleme schon gehabt haben.
Das macht es nicht einfacher...

Wernieman

Lohnt es sich eigentlich, von der ccu2 auf die 3 zu gehen?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

zap

m.E. definitiv. Ist ein Geschwindigkeits Boost.
Von der Funktionalität her ist es mit der CCU2 identisch, es sei denn, man installiert RasperryMatic. Das hat ein paar zusätzliche Features.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Per

Zitat von: zap am 04 Oktober 2018, 16:32:51Ist ein Geschwindigkeits Boost.
Nur in der Weboberfläche? Oder auch anderswo spürbar?

zap

Zitat von: Per am 04 Oktober 2018, 17:47:00
Nur in der Weboberfläche? Oder auch anderswo spürbar?

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

Klar, ein Raspi ist auch keine Rakete. Aber immer noch deutlich schneller als die in die Jahre gekommene ARM Plattform der CCU2. Der zusätzliche Speicher trägt hier sicher auch bei.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Wernieman

Wie sieht es mit der Funkverbindung aus? Besser oder gleichgeblieben?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

zap

Ich würde sagen gleich geblieben. Ich habe nicht mehr oder weniger unreachables als mit der CCU2.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Simon74

ich habe auch ein wenig mit anderen Systemen rumgespielt, ich habe mich 2 Tage mit Symcon beschäftigt, 1 Tag mit openhab, ein wenig iobroker

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

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

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

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

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

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

zap,
ich weiss das sehr viel Mühe in der HMCCU stecken muss, ich frage mich jedoch warum eigentlich die Werte der CCU nicht "einfach" 1:1 übernommen werden,
ich empfinde die Homematic Anbindung bei iobroker,symcon logischer ?

zap

#86
was meinst du mit Werte der CCU 1:1 übernehmen? Soll es nur ein Device für die CCU geben, in dem die Readings aller CCU Geräte abgelegt sind? Das wäre doch ziemlich unübersichtlich, da FHEM keine Baumansicht analog zur Objektansicht in IOBroker ermöglicht.

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

Zu OpenHab: die offizielle Doku ist zwar in Englisch, jedoch lässt sie inhaltlich keine Wünsche offen. Es gibt auch deutsche Doku (einfach mal googeln). Persönlich/beruflich arbeite ich sowieso nur möit englischer Doku, da es für viele Dinge keine deutsche gibt oder die Übersetzung unbrauchbar ist. Aber auch bei FHEM gibt es für viele Module nur noch englische Doku.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

zap

#87
Teil 4 - Sprachfunktionen / Alexa Integration

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

Die funktionalen Unterschiede zwischen FHEM, IOBroker und OpenHab bei der Alexa SmartHome Integration sind marginal. Alle drei Systeme bieten einen Smarthome Skill an. Der Funktionsumfang dieses Skills ist durch Amazon genau festgelegt, von daher gibt es wenig Möglichkeiten der Abgrenzung. Zusätzlich bieten FHEM und IOBroker sogenannte Custom Skills mit deutlich größerem Funktionsumfang und mehr Konfigurationsmöglichkeiten an. Abstriche muss man hier lediglich bei OpenHab machen, das keinen Custom Skill anbietet.

Die Installation der Alexa Integration erfolgt bei allen drei Plattformen über ein separates Stück Software (Modul / Adapter / o.ä.). Möchte man Funktionen wie z.B. die Sprachausgabe über einen Echo nutzen, muss in FHEM zusätzlich das Modul "Amazon Echo Device" installiert werden.

Die Konfiguration bzw. Einrichtung der Skills unterscheidet sich hingegen deutlich, v.a. was den zeitlichen Aufwand betrifft.

FHEM

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

IOBroker und OpenHab

Bei IOBroker und OpenHab erfolgt die Alexa Integration über (kostenlose) Cloud-Dienste. Es genügt, einen Account unter iobroker.net oder myopenhab.org anzulegen. Im lokalen Adpater in IOBroker oder in OpenHab müssen lediglich noch die Credentials und die zu steuernden Geräte eingetragen werden. Danach ist der Dienst sofort nutzbar. Dauer der Aktion ca. 10 Minuten. Für OpenHab gibt es auch einen Lambda-Service, den man analog zur Alexa-Integration in FHEM auf Basis der AWS einrichten kann. Macht m.E. aber keinen Sinn, da man nur einen Cloud-Dienst durch einen anderen ersetzt, der außerdem nach 12 Monaten kostenpflichtig wird.

Bei IOBroker gibt es noch eine Besonderheit: Man kann auch einen kostenpflichtigen Cloud-Dienst buchen. Funktional gibt es keinen Unterschied zum kostenlosen. Jedoch ist die Performance der Cloud-Server angeblich besser. Meine persönliche Erfahrung: Momentan genügt der kostenlose Dienst. Er reagiert spürbar schneller als in FHEM. Das könnte sich mit zunehmder Nutzung von IOBroker natürlich ändern.

Fazit Teil 4 - Sprachintegration

Seit 2 Wochen habe ich Alexa von FHEM nach IOBroker migriert. Den Schritt habe ich nicht bereut. Bei OpenHab fehlt der Custom Skill. Das bestätigt meinen Entschluss, mit OpenHab noch zu warten, bis es einen solchen gibt oder Amazon die Smarthome Skills funktional aufwertet. Für Nutzer eines der Smarthome Skills ist es im Prinzip egal, welche der drei Plattformen man nutzt. Der Einrichtungsaufwand bei FHEM ist zwar groß, aber das ist Einmalaufwand und insofern kein Drama. Kostet halt Nerven.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

raimundl

@zap:
Ich verfolge interessiert deine Ausführungen und bin aufgrund dieser dabei einige Veränderungen für die Zukunft zu beginnen:

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

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

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

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

Bin für Ratschläge dazu dankbar!

LG

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

Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....

Nemo0815

Zitat von: zap am 15 Oktober 2018, 14:28:48
In FHEM ist die Einrichtung der Alexa Integration sehr komplex...

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

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

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