Zukunft von HomeMatic

Begonnen von Prof. Dr. Peter Henning, 25 Oktober 2018, 17:01:54

Vorheriges Thema - Nächstes Thema

Neuhier

Es gibt genug Alternativen zu HM, sehe erstmal das Problem nicht.
Ok, die Vielfalt der angebotenen HM-Palette, wird nicht durchgehend von einem (!) einzelnen anderen Anbieter erreicht.

Ich habe mir die Arbeit (?) gemacht und einen Xiaomi2MQTT-Stick gebastelt.
Somit kann ich Osram, Tradfri, Zigbee, Hue etc. einbinden, mit einem einzigen Gateway.
Damit gerate ich nicht in Not, wenn HM nicht mehr im Angebot sein würde.

FHEM ist sehr flexibel, in Bezug auf Protokolle und Komponenten.
( Muß ich euch ja wohl nicht erklären )

MIKE67

#16
Kaufmännisch macht es für EQ3 meiner Meinung nach auch wenig Sinn, von einem Tag zum anderen das HMclassig System zu kippen. Dort findet sich die eine oder andere CashCow. Das ein oder andere Teil hat zwar seine Macken, ist eine Diva oder braucht nach einer Zeit x mal nen Lötkolben (C26 ist ein Kandidat, klebende Relais der andere). Aber halt nix unmögliches.
Streng genommen ist HM ein Bastelsystem.
Durch FHEM lassen sich jedoch auch andere Systeme sinnig mit Homematic (IP) (WIRED) verknüpften. Damit ist die Ausfallwahrscheinlichkeit durch einen Hersteller eingeschränkt.

Bei mir läuft allerdings kein FHEM zuhause, seinerzeit war es neben dem jetzt laufenden der zweite Favorit, letztlich sprach allerding meine vorhandene Javascript Erfahrung und die nicht vorhandene Pearl Erfahrung für das andere System. Ist allerdings eine, wie geschrieben, rein subjektive Entscheidung meinerseits gewesen.

Solange eine Middleware egal welcher couleur zum Einsatz kommt, kann man dem recht entspannt entgegenblicken. Bei IP würde mir im Augenblick ein Lan Gateway fehlen. Trotz einer EMV Technisch vernünftig aufgebauten Raspberrymatik mit einer Groundplane erreiche ich nicht sicher (meistens gehts, aber manchmal auch nicht) meine Komponenten im letzten Anbauraum oder am Gartenende. Mit Stummelantennchen gehts weder mit einer CCU2 noch mit dem Raspi. Wenn ein entsprechendes Gateway mal im Programm ist, blicke ich dem gelassen entgegen, dann wird bei Aufbau oder Austausch dann halt IP eingesetzt, oder wie heute auch schon manchmal lightify. Zigbee kommt demnächst auch mal testweise in mein Spielesystem. Mal schauen ob wir gegenseitig miteienander warm werden

schönen Abend noch, Mike
Die Wahrheit ist ein Chor aus Wind

zap

Ich vermute, dass es Homematic (BidCos, Wired) noch eine lange Zeit geben wird. Nur Innovationen würde ich keine mehr erwarten.

Grund: EQ-3 würde eine große Nutzergemeinde verprellen. Bei einem Bigbang wäre die Gefahr, dass diese Nutzer nicht auf HmIP oder WiredIP wechseln sondern zur Konkurrenz gehen, zu groß.
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

Frank_Huber

solange die Kuh Milch gibt wird sie gemolken...

joachimS

Zitat von: betateilchen am 25 Oktober 2018, 19:32:44
Vie Cloud nicht. Aber per Hardwaredesign, da hat EQ3 schon vorgesorgt. Alle Homematic Komponenten, die als Unterputzaktoren an Netzspannung hängen, sterben irgendwann wegen eines defekten Kondensators im Netzteilbereich der Komponente. U
Also in aktuellen Bausätzen (Rollladen) ist der C26 auf 105 Grad ausgelegt. Ist damit das Problem reduziert oder gar weg?
Ich habe auch keine Posts gefunden ob HomeMatic IP da wirklich besser ist.
Wäre ja ein Grund auf HomeMatic IP zu gehen.
Gruss
Joachim

(fhem auf Synology DS209, CUL, FS20, FHT, EM, HM, Keymatic, Hue, OpenDTU)

alanblack

Zitat von: joachimS am 26 Oktober 2018, 16:06:47
Also in aktuellen Bausätzen (Rollladen) ist der C26 auf 105 Grad ausgelegt. Ist damit das Problem reduziert oder gar weg?
Ich habe vor kurzem in zwei (gebraucht gekauften) HMLANs die Kondis getauscht. Es machte zwar nur einer Mucken, aber ich war gerade dabei. Egal!
Was ich sagen wollte, war, dass in beiden die Kondensatoren bis 105°C spezifiziert waren. Das schützt also nicht.

Zitat
Wäre ja ein Grund auf HomeMatic IP zu gehen.
Wenn die nicht auch Ihre geplante Obsoleszenz beinhalten...  >:(
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Tom Major

Zitat von: joachimS am 26 Oktober 2018, 16:06:47
Also in aktuellen Bausätzen (Rollladen) ist der C26 auf 105 Grad ausgelegt. Ist damit das Problem reduziert oder gar weg?
Ich habe auch keine Posts gefunden ob HomeMatic IP da wirklich besser ist.
Wäre ja ein Grund auf HomeMatic IP zu gehen.

Nach meinen Beobachtungen der letzten Jahre vermindert sich eher die Qualität und Langlebigkeit von elektronischen Modulen, auch wenn sie von Markenherstellern kommen, egal was außen draufsteht, meistens billigste Teile und Fertigung aus Fernost.
Deshalb würde ich in gar keinem Fall davon ausgehen dass HM IP keine Probleme mit Bauelementen haben wird, eher das Gegenteil. Das kann nur die Zeit zeigen.
Zum Glück kann man ja mit Projekten wie der AskSinPP eine Menge Geräte nachbauen und ist so etwas unabhängiger.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Prof. Dr. Peter Henning

Die logische Konsequenz sollte sein, dass wir in das Wiki für jedes dort beschriebene HM-Gerät ein Kapitel "Defekte" aufnehmen und die mögliche Reparatur beschreiben. Außerdem braucht es eine Bibliothek mit 3D-Druckdateien für den Ersatz von Verschleißteilen.

Weiterhin müsste die sehr fragmentierte Information über die AskSin-Bibliotheken und daraus abgeleitete Geräte besser gebündelt werden. Nicht zentralisiert - aber mit ordentlicher Indizierung und Querverweisen.

LG

pah

joachimS

Gute Idee. Ich wusste vor Kurzem nicht mal dass es Homematic IP gibt. Ditto Kondensator Problem und AskSin. Hatte seither nur FS20 plus Hue wollte aber Keymatic und Rollladen.
Wir bräuchten ein Whitepaper über Smarthome Architektur was die verschiedenen Standards und Protokolle, Marktübersicht, Vor- und Nachteile plus Integration beleuchtet,. Schönes Thema für eine Bachelorarbeit, gibts vielleicht schon. Das Problem bei Homematic ist, dass es nicht vollständig Open Source und proprietär ist. Die Stärken von FHEM sind Open Source, die Community und die Integration


Joachim
Gruss
Joachim

(fhem auf Synology DS209, CUL, FS20, FHT, EM, HM, Keymatic, Hue, OpenDTU)

Prof. Dr. Peter Henning

ZitatWir bräuchten ein Whitepaper über Smarthome Architektur was die verschiedenen Standards und Protokolle, Marktübersicht, Vor- und Nachteile plus Integration beleuchtet
Äh - nö.

Erstens Marktübersicht: Die Systeme ändern sich so schnell, dass dieses "Whitepaper" drei Monate nach Erstellung obsolet wäre.
Zweitens Einbindung in FHEM, Protokolle und Vergleich: Siehe "SmartHome Hacks".
Drittens Architektur: Kaum zu verallgemeinern. Wie ich sowohl bei den SmartHome Hacks, als auch bei meinem derzeit in Arbeit befindlichen Buch immer wieder merke: Nicht die Architektur, sondern die Use cases sind der Treiber.

Na, und betreffend Bachelor: Da habe ich aber andere Ansprüche... In einem anderen Thread hat jemand seine Studienarbeit zu dem Thema vorgestellt, da ist jedoch leider ziemlicher Käse herausgekommen.

LG

pah

joachimS

Zitat von: Prof. Dr. Peter Henning am 27 Oktober 2018, 11:35:04
Äh - nö.

Erstens Marktübersicht: Die Systeme ändern sich so schnell, dass dieses "Whitepaper" drei Monate nach Erstellung obsolet wäre.
So schnell geht es wieder auch nicht. Kommunikations Protokolle und Szenarien haben Bestand. Implementierung ist sekundär.
Die FHEM Community ist wohl die einzige, weitgehend neutrale Smarthome Instanz, die  Plattform übergreifend arbeitet und Open Source Smarthome Elemente entwickelt.
Wir könnten sogar ein Zertifikat herausbringen wie ,,FHEM Smarthome integratable". Stell dir vor, der informierte Häuslebauer kauft eine Heizung und fordert Smarthome Kompatibilität.
Eigentlich müsste die Politik sich um Standardisierung von Smarthome und IOT kümmern und dafür sorgen, dass proprietäre Produkte integrierbar sein müssen. Der Staat müsste auch Dienste wie Wetterbericht und Warnung vor Gefahren aller Art bereitstellen. Gebäude müssten miteinander kommunizieren und den Rettungsdiensten mitteilen wo sich Menschen im Gebäude befinden. Alles nicht neu, nur es ist nicht existent. Ich erhöhe den Level auf Habilitation.


Joachim
Gruss
Joachim

(fhem auf Synology DS209, CUL, FS20, FHT, EM, HM, Keymatic, Hue, OpenDTU)

Christoph Morrison

Zitat von: joachimS am 27 Oktober 2018, 20:17:04
Der Staat müsste auch Dienste wie Wetterbericht und Warnung vor Gefahren aller Art bereitstellen.

DWD und NINA / MoWaS existieren. Für den DWD gibt es sogar ein/mehrere FHEM-Modul(e).

Ansonsten hält sich "der Staat" besser aus sowas raus, sonst hast du am Ende ein IoT-Netz mit lawful interception auf Level der Dorfpolizei oder Projekt"erfolg" wie BER. Ich bin mir sicher dass ich nicht der einzige hier bin, der FHEM einsetzt, weil er eben keine Hersteller-Cloud mit Schnüffelschnittstelle für jeden Geheimdienst der Welt haben möchte.

joachimS

Zitat von: Christoph Morrison am 27 Oktober 2018, 20:42:28
DWD und NINA / MoWaS existieren. Für den DWD gibt es sogar ein/mehrere FHEM-Modul(e).

Im Ernst?
Haben die ein verlässliches API?
Warnt Nina vor Hochwasser, oder auch nur lokale Unwetter?
Es gibt ja nicht mal eine kommerzielle Wetterstation, die weiß ob die Sonne scheint oder ob es regnet, das musste Eugen erst entwickeln.
Ich habe Cloud nicht erwähnt, ich schrieb Kommunikation mit Gebäuden und Rettungsdiensten. Du musst dich ja nicht retten lassen


Joachim
Gruss
Joachim

(fhem auf Synology DS209, CUL, FS20, FHT, EM, HM, Keymatic, Hue, OpenDTU)

Christoph Morrison

Zitat von: joachimS am 27 Oktober 2018, 20:49:34
Im Ernst?
Haben die ein verlässliches API?
Warnt Nina vor Hochwasser, oder auch nur lokale Unwetter?

NINA ist nur ein Frontend von MoWaS und ja, in MoWaS gibt es auch Unwetter- und Hochwasserdaten. Die API ist ziemlich dummeinfach und liefert ein standardisiertes Format, CAP oder so, was als JSON übertragen wird.

Zusätzlich gibt es noch BIWAPP und Katwarn, die weitere Informationen über MoWaS hinaus liefern können, teilweise auf dem Niveau von "In Kleinkleckersdorf ist eine Kuh umgefallen".

ZitatEs gibt ja nicht mal eine kommerzielle Wetterstation, die weiß ob die Sonne scheint oder ob es regnet, das musste Eugen erst entwickeln.

Wunderground als kommerzielles Netzwerk von privaten Wetterstationen.

ZitatIch habe Cloud nicht erwähnt

Ich aber, weil eine Standardisierung für alle darauf hinauslaufen würde.

Zitatich schrieb Kommunikation mit Gebäuden und Rettungsdiensten. Du musst dich ja nicht retten lassen

Das ist ungefähr auf dem Niveau von "Ich hab ja nichts zu verbergen". Ich möchte halt auch nicht in einer Welt leben, in der irgendein Telekom-IoT-Netz existiert und an das alles angekoppelt ist und jederzeit von irgendeinem Dorfschulzen abgefragt werden kann. Ein Gebäude das weiß, wo sich Leute aufhalten (und damit leicht auch welche Leute sich aufhalten) und eine Schnittstelle zu den BOS hat, wird früher oder später zu was anderem verwendet werden als nur für den Zweck "retten" (Mautbrücken anyone?). Inseln haben auch so ihre Vorteile.

joachimS

Bist du sicher, dass es ein API für jedermann gibt?
Siehe
https://forum.fhem.de/index.php?topic=73019.0
Oder auch Modulare Warnsystem (MoWaS)
https://www.bbk.bund.de/DE/NINA/Warnung/Warnung.html erwähnt das nicht.

Abgesehen davon berechnet der DWD Hochwasser Gefahr nicht. Dazu müsste er Radar mit Topographie verbinden, undenkbar.

Wundert mich, dass du Wonderground erwähnst, das ist nämlich eine böse cloud, außerdem kostet das API inzwischen, glaube ich.
Was ist denn für Dich gefährlich daran wenn mich ein Nachbar Gebäude vor Feinstaub oder Einbrechern warnt?
Und re Rettungsdienst, dann erlaube halt Deinem Smarthome die Daten Weitergabe nicht.
Wir reden hier über Probleme, die noch gar nicht existieren, weil wir weder die Infrastruktur, noch die Technik und Standards haben



Joachim
Gruss
Joachim

(fhem auf Synology DS209, CUL, FS20, FHT, EM, HM, Keymatic, Hue, OpenDTU)