Welches System ist besser für mich geeignet - EnOcean - z-Wave oder HomeMatic

Begonnen von teufelchen, 26 September 2017, 13:21:45

Vorheriges Thema - Nächstes Thema

teufelchen

Hallo zusammen,

ich brauche bitte Eure Erfahrung und Hinweise beim Ausbau meiner Heimautomatisierung.
Momentan habe ich einen Raspberry Pi mit CUL und diversen Intertechno Aktoren. Durch angepasste CUL-Firmware kann ich mithören wenn die Handsender betätigt werden. Auch ein zweiter CUL mit 868 MHz ist vorhanden.
Intertechno Schalter sind günstig und das Schalten funktioniert auch zu 98%. Durch den fehlenden Rückkanal zur Bestätigung des Schaltvorgangs kann man sich aber nicht auf den Schaltvorgang verlassen.
Nun möchte ich gerne meine bestehenden elektrischen Rollläden manuell als auch automatisch steuern, wissen ob Fenster und Terrassentüren offen oder geschlossen sind und Teile die Temperatur meiner Heizkörper über FHEM steuern.
Da ich nicht renovieren will kommt nur Funk zur Auswahl.
Folgende Teile werde ich brauchen:
•   6 x Rolladensteuerung, am liebsten den Originaltaster austauschen
•   7 x Fensterkontakte und 4 x Terassentürkontakte, am liebsten über Griff abgreifen
•   1 x Kontakt für die Haustüre
•   5 x Heizkörperventile - die Fußbodenheizung bleibt manuell gesteuert da ich durch die Trägheit kein Vorteil bei einer automatischen Steuerung sehe
•   Evtl. Sensor um manuellen Gaszähler und Stromzähler auszulesen.

Ziel ist immer eine manuelle Steuerung als auch eine automatische Steuerung zu ermöglichen und den manuellen Schaltzustand in FHEM zu sehen. Deshalb kommen nur Systeme mit Rückkanal in Betracht.

Beim lesen und suchen habe ich drei Systeme gefunden (gerne ergänzen):
•   zWave mit Komponenten verschiedener Anbietern, Strombetriebene Aktoren funktionieren als Relais
•   EnOcean mit Komponenten verschiedener Anbietern, Sender ohne Batteriewechsel
•   HomeMatic, ein Anbieter, zukunftssicher?
Momentan schwanke ich zwischen zWave und EnOcean wobei ich zWave wegen der Relaisfunktion minimal bevorzuge.
Homematic hat alle Wunschkomponenten (Funk Schaltaktor für Markenschalter, Funk-Fenster-Drehgriffkontakt, Funk-Heizkörperthermostat) jedoch scheint der Lebenszyklus der Systeme langsam gegen Ende zu gehen und man ist auf einen Produzenten angewiesen.

Sicherlich ist der Vorteil von FHEM, dass ich theoretisch alle Systeme mischen könnte jedoch möchte ich neben der Billiglösung Intertechno nur ein weiteres System verwenden.

Was würdet Ihr verbauen und warum?
Raspberry Pi 3
CUL433: V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUL433 (F-Band: 433MHz)
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
Debmatic mit RPI-RF-MOD

Norbert_G

Hallo Teufelchen,

ich kann deinen Ansatz zwar verstehen, aber ich kann nur aus meiner Erfahrung berichten, dass es ein Fehler wäre kategorisch nur 2 Systeme einzusetzen. Der Geschmack kommt bekanntlich beim Essen. Ich setze viele Homematic Komponenten ein, den bidirektional ist einfach besser. Das hast du ja auch bereits festgestellt. Ich habe auch gute Erfahrungen mit den Homematic-Wandtastern gemacht. Leider musste ich feststellen, dass Gira sehr schöne Enocean-Taster hat. Diese passen auch super zum Rest der Schalter und Steckdosen in unserem Haus. Daher habe ich seit kurzem auch Enocean. Man kann auch mit einfachen Mitteln Dinge schalten und abfragen - daher habe ich auch One-Wire. und dann noch netatmo und Sonos und intertechno und Robonect und Hikvision (IPCAM) und natürlich auch Alexa und ...


Ich kann die nur den Rat geben für die jeweilige Anwendung nach einer optimalen Lösung zu suchen und nicht im Vorfeld bereits Einschränkungen vorzunehmen.

liebe Grüße

Norbert

Cubietruck, HM über HMLAN und HMUSB, 1-wire, IPCAMs, Visualisierung über smartVISU

Beta-User

@Norbert:

Es ist zwar grundsätzlich richtig, dass man mit FHEM alles mögliche mischen kann (mache ich teilweise auch), aber bitte dann auch darauf hinweisen, dass man sich damit von einem funktionierenden FHEM abhängig macht (was in der Regel kein Problem ist, solange man immer alles mit Bedacht tut, ausreichend Backups macht und sich nicht grobe konzeptionelle Fehler leistet, schließlich sind wir im IoT).

Daher: Was zusammen funktionieren soll, solle auch aus einer HW-Familie sein, damit es notfalls (ohne Komfortfunktionen) auch ohne FHEM funktioniert (Stichwort aus der HM-Welt: peering, das Konzept gibt es aber praktisch bei allen "besseren" Systemen).

Zusammengefaßt:
- für Heizungsthermostate gibt es eigentlich nur aus dem Hause eq3 akzeptable HW (jedenfalls ist das mein letzter Stand, kann sein, dass Richtung Jahresende zwave aufholen kann)
- Wenn peering von Tür/Fensterkontakten zu HK-Thermostaten gewollt ist: "Familienintern", ansonsten wäre die Frage, ob man hier auch gut erst mal mit vorhandener 433-er HW (?) weitermacht. Optisch ist HM-"classic" da aber nicht so der Hit; bei den Terassentüren bitte nachsehen, ob die Achse zu dick für Drehkontakte aus dem HM-Sortiment ist (da kann man etwas feilen, aber nicht viel).
- Rolladensteuerung: da ist HM "na ja", da es nur zeitorientiert arbeitet, es gibt da wohl bessere (und auch teurere) Systeme (Rademacher?), und die Haptik der Taster ist auch nicht so toll. Kann wirklich ein anderes System sein, es sei denn, man möchte sich eventuell die Mühe machen, einen Aussperrschutz in Hardware zu realisieren (ehrlich: ich weiß nicht, ob das tatsächlich geht, indem man den Aktor mit einem Drehkontakt peert)

Was HM angeht: Garantien gibt es natürlich keine, aber ich würde davon ausgehen, dass es das auch in 10 Jahren noch gibt; schließlich wird auch FS20 heute noch verkauft... Gas- und Stromzähler finde ich aus dem Hause eq3 überteuert, geht auch viel günstiger und mit etwas Bastelei sehr gut mit Selbstbaulösungen wie Arducounter oder MySensors.

(Wenn man Kabel legen kann, gibt es auch für die Fensterkontakte andere und günstige Lösungen, z.B. 1wir; allerdings nicht für den Drehgriff; obwohl: auch dafür gibt es ein HM-Selbstbau-Projekt ;) ).

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors