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

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2484
  • 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: 2769
    • 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: 2381
    • 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.
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 DerBodo

  • Full Member
  • ***
  • Beiträge: 232
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: 138
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: 2381
    • 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.

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 marvin78

  • Hero Member
  • *****
  • Beiträge: 5226
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: 2381
    • 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.
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 marvin78

  • Hero Member
  • *****
  • Beiträge: 5226
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: 2381
    • 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.
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 Informativ Informativ x 1 Liste anzeigen

Offline ext23

  • Hero Member
  • *****
  • Beiträge: 2769
    • 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: 2381
    • 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 »
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 ext23

  • Hero Member
  • *****
  • Beiträge: 2769
    • 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)
Zustimmung Zustimmung x 1 Liste anzeigen

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 767
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: 2769
    • 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)