Mit welchen Komponenten soll ich zukünftig weiter machen?

Begonnen von Rocky, 15 Oktober 2019, 16:53:24

Vorheriges Thema - Nächstes Thema

Rocky

Nach über 3 Jahren bin ich wieder soweit mich mit meiner Hausautomation zu beschäftigen und stehe nach vielen Recherchen hier im Forum vor der Frage mit welchen neu anzuschaffenden Komponenten ich weiter machen soll?
Mir macht ein bisschen auch die Politik vom Hersteller die Sorge. Vor einigen Jahren musste ich meine ganzen FS20-UP-Dimmer austauschen da einer defekt war und dieser vom Hersteller abgekündigt wurde. Habe damals deswegen mein Wohnzimmer auf Schalter-Komponenten von Homematic umgestellt.

Jetzt habe ich wieder richtig Lust und auch die Zeit mich mit meinem vorhandenes FHEM zu beschäftigen :) Dazu bin ich jetzt in einem ersten Schritt von einem RasPi 2 auf ein RasPi 4 mit CUL und HM-CFG-USB erfolgreich umgezogen.
Jetzt möchte ich mir weitere Komponenten\Actoren zulegen und stehe vor der Frage, ob ich das neue Homematic-IP nehmen oder besser bei den "alten" Homematic-Komponenten bleiben soll? Ich würde auch gerne zukünftig Schritt für Schritt und Zimmer für Zimmer meine dort verbauten FS20 Komponenten (FHT80B,...) gegen neue Homematic-Komponenten ersetzen.
Wegen der Ausfallsicherheit und besseren Bedienbarkeit hatte ich daran gedacht FHEM und eine Homematic-CCU parallel betreiben zu wollen. Mit der HM-CCU könnte ich alle vorhandenen und zukünftigen Homematic-Komponenten verwalten (paaren und peeren), und mit FHEM wird das ganze gesteuert und mit Logic versorgt.

Frage: Wäre es eine gute und sinnvolle Entscheidung wenn ich bei mir jetzt anstelle eines vorhandenen HM-CFG-USB eine Homematic-CCU3 installiere und zukünftig mit Homatic-IP Komponenten weiter mache, oder reicht eine HM-CCU2 mit Standard-Homatic (also ohne -IP) völlig aus?
Vielleicht hat ja der ein oder andere FHEM-Kollege auch vor dieser Entscheidung gestanden und kann mir seine Entscheidung mit Begründung mitteilen.
Herzliche Grüße Markus
__________________________________
FHEM 5.9 auf Raspberry Pi 4
CUL V1.67 CUL868 und HM-CFG-USB-2
FHT80B, FS20 und Homematic

zap

Die CCU2 unterstützt ebenfalls HmIP. Sie ist jedoch langsam und völlig veraltet. Wenn Du Dich für Homematic (IP) und für eine CCU entscheidest, nimm eine CCU3. Das ist nichts anderes als ein Raspi.

Bei Bedarf kannst Du darauf auch RasperryMatic installieren.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Rocky

Was mir wirklich Sorgen bei einer Konzentration auf ein selbst zusammengebautes System mittels RasPi macht, ist die Bedienbarkeit, falls ich mal als ursprünglicher "Konfigurator" ausfallen sollte. So wie ich das verstanden habe besitzt die CCU2 und auch die CCU3 eine ganz ordentliche Benutzeroberfläche (ähnlich HM-CFG-USB-2) die von jedem "recht einfach" bedient werden kann.

Was ich unbedingt vermeiden möchte ist die 100%ige Abhängigkeit bzw. Bindung an FHEM, da die Konfiguration, auch wenn sie noch so gut dokumentiert ist, m.E. nicht so einfach von nicht IT kundigen Mitbewohner nachvollzogen werden kann. Von daher wäre es mir wichtig, alle Stellantriebe und Schalter/Dimmer sowohl über FHEM als auch über z.B. eine HM-CCU3 steuern zu können.
Was ich in diesem Zusammenhang noch nicht so ganz verstanden habe ist folgendes: Kann ich z.B. eine Homematic Fernbedienung und -UP-Schalter an eine CCU3 pairen und peeren und dann mittels FHEM steuern? Ich habe das bisher immer so verstanden, dass Homematic-Komponenten entweder an eine HM-CCU3 oder an FHEM angemeldet werden können - beides geht nicht. Falls an eine HM-CCU3 gepairt wurde ist eine Steuerung durch FHEM nicht mehr möglich - ist das richtig?
Herzliche Grüße Markus
__________________________________
FHEM 5.9 auf Raspberry Pi 4
CUL V1.67 CUL868 und HM-CFG-USB-2
FHT80B, FS20 und Homematic

MadMax-FHEM

#3
Du kannst alle Homematic (mit und ohne IP) an einer CCU2/CCU3 betreiben.
Dort auch Logik machen (Scripte etc.)...

Du kannst aber NICHT Homematic (ohne IP/bidCos) mit Homematic IP Geräten PEEREN!

Die "Verknüpfung" geht nur über die CCU oder fhem (oder ioBroker oder ...).

In fhem kannst du alle in einer CCU angelernten Homematic Geräte (IP und nicht IP) mittels HMCCU-Modul "integrieren" und dort auch Logik etc. haben...

D.h. die CCU ist dann sozusagen das IO...

Homematic OHNE IP (bidCos) kannst du auch direkt per Funkmodul in fhem integrieren...

Allerdings würde ich nicht mischen (auch wenn es mit fhem geht)...
...also alles an eine CCU und dann per HMCCU nach fhem, das macht die Logik in fhem "einfacher", weil alle Geräte "gleich angesprochen" werden...

Bzgl. Logik würde ich mich auch entscheiden.
Entweder in der CCU oder in fhem...
...bei einer Vermischung ist es nicht so einfach herauszufinden wo es hakt, wenn es hakt... ;)

EDIT: allerdings gibt es ja neben Homematic (mit und ohne IP) auch noch ZWave und EnOcean und Zigbee... Alles nicht an einen einzigen Hersteller gebunden... Bei ZWave gibt es vergleichbare Geräte. Bei/an Enocean gefallen mir die Schalter, die ohne Stromversorgung auskommen, da ich nicht überall einen Neutralleiter habe und manchmal sogar gerne einen Schalter wo habe (in der Vergangenheit: gerne gehabt hätte) wo gar keine Leitungen/Dose etc. ist... :) Zigbee gefällt mir bzgl. Beleuchtung sehr gut. Aber sonst hab ich da noch nicht viel gefunden, leider nicht mal Schalter für "hinter" einen vorhandenen Schalter bzw. passend für mein Schalterprogramm (da hatte ich mit EnOcean Glück ;)  )...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

zap

Zitat von: Rocky am 15 Oktober 2019, 19:19:09
Was mir wirklich Sorgen bei einer Konzentration auf ein selbst zusammengebautes System mittels RasPi macht, ist die Bedienbarkeit, falls ich mal als ursprünglicher "Konfigurator" ausfallen sollte. So wie ich das verstanden habe besitzt die CCU2 und auch die CCU3 eine ganz ordentliche Benutzeroberfläche (ähnlich HM-CFG-USB-2) die von jedem "recht einfach" bedient werden kann.

Im Gehäuse der CCU3 steckt ein Raspberry (falls das in meiner ersten Antwort nicht klar war)
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Rocky

Zitat von: zap am 15 Oktober 2019, 19:46:15
Im Gehäuse der CCU3 steckt ein Raspberry (falls das in meiner ersten Antwort nicht klar war)

Ja, das war mir klar und hab das auch so verstanden. Was mir jedoch bei einer CCU3 viel einfacher erscheint ist das GUI fürs pairen und peeren. Das traue ich in meiner Familie im Notfall auch noch anderen zu. Mir ist eine Unabhängigkeit sehr wichtig!
Herzliche Grüße Markus
__________________________________
FHEM 5.9 auf Raspberry Pi 4
CUL V1.67 CUL868 und HM-CFG-USB-2
FHT80B, FS20 und Homematic

Rocky

Zitat von: MadMax-FHEM am 15 Oktober 2019, 19:30:47

In fhem kannst du alle in einer CCU angelernten Homematic Geräte (IP und nicht IP) mittels HMCCU-Modul "integrieren" und dort auch Logik etc. haben...


Hi Joachim, das geht aber nicht mit einem HM-CFG-USB-2, da er ja keine vollwertige CCU darstellt - richtig?


Zitat von: MadMax-FHEM am 15 Oktober 2019, 19:30:47
Bei/an Enocean gefallen mir die Schalter, die ohne Stromversorgung auskommen, da ich nicht überall einen Neutralleiter habe und manchmal sogar gerne einen Schalter wo habe (in der Vergangenheit: gerne gehabt hätte) wo gar keine Leitungen/Dose etc. ist... :)

Super, das schaue ich mir mal an! Kann ich an manchen Örtlichkeiten auch gebrauchen.
Herzliche Grüße Markus
__________________________________
FHEM 5.9 auf Raspberry Pi 4
CUL V1.67 CUL868 und HM-CFG-USB-2
FHT80B, FS20 und Homematic

MadMax-FHEM

Nein, weder CUL noch der HM-CFG-USB...

Die gehen nur als Funkmodul an fhem über CUL_HM...

Für Homematic IP muss es schon eine "echte" CCU sein.

Da ginge das HMOD-PCB oder das neue Aufsteckmodul (das wäre dann Bausatz "Charly") und evtl. auch der neue USB-Stick...

Es ist auch möglich fhem und eine CCU auf EINEM PI laufen zu lassen (Stichworte: piVCCU, debmatic, raspberrymatic / mal im Forum suchen)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Rocky

#8
Zitat von: MadMax-FHEM am 15 Oktober 2019, 20:46:35

Da ginge das HMOD-PCB oder das neue Aufsteckmodul (das wäre dann Bausatz "Charly") und evtl. auch der neue USB-Stick...


Diese Info ist mir auch schon in diversen Beiträgen aufgefallen. Ist aber nur für RasPi3 freigegeben, ich habe den RasPi4!
Kann ich denn bei Verwendung eines HM-MOD-RPI-PCB HomeMatic Funkmodul auch die orig. Konfigurationssoftware (GUI) nutzen? Falls das geht, könnte ich mir diese Konstellation gut vorstellen.
Beim Hersteller lese ich: "Für den Betrieb des Funkmoduls steht ein angepasstes Softwarepaket zum Download bereit"!
Herzliche Grüße Markus
__________________________________
FHEM 5.9 auf Raspberry Pi 4
CUL V1.67 CUL868 und HM-CFG-USB-2
FHT80B, FS20 und Homematic

MadMax-FHEM

#9
Entweder das angepasste SW-Paket, da aber fraglich, ob das für PI4 geht...

Was wohl geschafft wurde ist debmatic mit dem HMOD-PCB ("altes" Aufsteckmodul) auf einem PI4 bzw. zumindest unter Buster...

Mal im Forum nach "debmatic ccu auf debian" suchen...

Debmatic ist halt dann quasi eine CCU mit CCU-Oberfläche wenn du das meinst...

Vorteil (gegenüber SW-Paket ELV): es ist ein Debian-System drunter, fhem kann also leicht zusätzlich installiert werden...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Rocky

Ich danke dir!
Ich gehe deinem Hinweis zu "debmatic ccu auf debian" mal nach...
Herzliche Grüße Markus
__________________________________
FHEM 5.9 auf Raspberry Pi 4
CUL V1.67 CUL868 und HM-CFG-USB-2
FHT80B, FS20 und Homematic

Damu

ZitatBei/an Enocean gefallen mir die Schalter, die ohne Stromversorgung auskommen, da ich nicht überall einen Neutralleiter habe und manchmal sogar gerne einen Schalter wo habe (in der Vergangenheit: gerne gehabt hätte) wo gar keine Leitungen/Dose etc. ist... :)

Ohne Strom geht das natürlich nicht.
Das muss dann über die Lampe gehen, der Aktor bezieht den Nullleiter-Strom über die Leuchte.
Das hab ich beim neuen Minidimmer von Qubino (Zwave) gesehen.

So wie Du das aber beschreibst geht das eher nach Homematic und dann bist du hier aber im falschen Forum.

MadMax-FHEM

#12
Die EnOcean Lichtschalter gehen sehr wohl komplett OHNE JEGLICHE SPANNUNGSVERSORGUNG!

Erst nachforschen/-lesen dann schlau schreiben ;)

Die holen sich die Energie zum Funken des Schaltvorganges zum Aktor aus der mechanischen Bewegung beim Schalten.

Klar die Aktoren brauchen nat. Strom aber da kann man ja die vorhandenen Schalter überbrücken und den Aktor dann an/in die Lampe oder was auch immer einbauen...

Und ich habe eben von den Schaltern und NICHT den Aktoren geschrieben... ;)

EDIT:
ZitatDas muss dann über die Lampe gehen, der Aktor bezieht den Nullleiter-Strom über die Leuchte.
Das hab ich beim neuen Minidimmer von Qubino (Zwave) gesehen.
solche hatte ich auch, allerdings von InterTechno (und kompatible). Aber für die braucht man ja mindestens eine Dose wo zumindest mal ein (Licht)Schalter war (auch ohne Neutralleiter)... Die EnOcean kann man einfach "überall" an die Wand kleben, schrauben, was auch immer... Aber die IT-Dinger sind jetzt (fast) alle rausgeflogen, da die OHNE Rückkanal waren und somit den Zustand nicht gemeldet haben. Also schalten am Schalter und nix stimmt mehr... ;)  Beim EnOcean Schalter sieht man sogar den Schaltbefehl in fhem (anstehend). D.h. man kann sogar eine Logik machen (wofür andere immer Dummy etc. "brauchen"/nehmen) wo man prüfen kann, ob das Licht beispielsweise automatisch eingeschaltet wurde oder eben durch einen Lichtschalter manuell (und auch wann)... Aber das nur am Rande...

Ja hier geht es um Homematic, ich hab das schon gelesen/verstanden...
...aber auch um was soll/könnte ich nach Homematic "Classic" (bidCos) nutzen...

Und da gibt es halt mehr als nur Homematic IP...

Äh, falsches Forum?
Nein, nein schon richtig und genau passend zur Frage(stellung)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: Rocky am 15 Oktober 2019, 19:19:09
Was mir wirklich Sorgen bei einer Konzentration auf ein selbst zusammengebautes System mittels RasPi macht, ist die Bedienbarkeit, falls ich mal als ursprünglicher "Konfigurator" ausfallen sollte. So wie ich das verstanden habe besitzt die CCU2 und auch die CCU3 eine ganz ordentliche Benutzeroberfläche (ähnlich HM-CFG-USB-2) die von jedem "recht einfach" bedient werden kann.

Was ich unbedingt vermeiden möchte ist die 100%ige Abhängigkeit bzw. Bindung an FHEM, [...]
Meine Meinung dazu:
Wenn du unterschiedliche Ebenen der Steuerungslogik hast, wird sich so oder so schwerlich jemand finden, der da durchblickt bzw. das wird unbezahlbar, ob jetzt mit oder ohne FHEM, ist da fast egal. Die Frage wird sein: Was funktioniert ohne weitere Pflege (wie lange)?

Ohne den "Königsweg" wirklich zu kennen: Dazu sollte man vermutlich sicherstellen, dass die wesentlichen Funktionen in der Hardware vorhanden sind (HM-Sprech: Peering). Sowas können aber afaik praktisch alle größeren Hardwaresysteme, es lohnt sich also ggf., den Blick auch mal weg von eQ-3 zu anderen Herstellern/Technologien zu lenken.
Die Zentrale (welche auch immer das sind bzw. aus welchen Teillogiken auch immer die besteht), darf dann nur "Komfortfunktionen" machen.

Ziemlich theoretisch..., in der Praxis gelingt das erfahrungsgemäß nur sehr bedingt. Daher versuche ich, nur FHEM als Zentrale zu verwenden, und direkte Bedienerinterfaces ("Schalter", mit einer Art "peering") überall da vorzusehen, wo man es in einer "klassischen" Installation auch tun würde. Abhängigkeiten von Systemen untereinander mag ich gar nicht, also sowas wie eine CCUx auf einer eigenen Plattform iVm. FHEM käme mir nicht ins Haus - da muß dann nämlich auch ein Router laufen, damit die sich finden, die Netzwerkkonfiguration muß passen usw.. Sowas ist für die Lichtfarbe akzeptabel, aber sonst...?
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

willib

Wenn du dir Sorgen wegen der Politik von ELV/EQ3 machst solltest du über einen herstellerunabhängigen Standard nachdenken. Ich bin derzeit noch voll mit HM Komponenten ausgerüstet werde aber zukünftig auf zwave setzen. Rückblickend habe ich mich damals zu schnell für HM entschieden, aufgrund der starken Verbreitung hier im Forum.
Ich habe allerdings noch keine Alternative zu den HM Unterputz Schaltaktoren für Markenschalter gefunden. Bei Zwave braucht man im prinzip immer eine Tiefe Unterputzdose um die Aktoren noch mit rein zu bekommen. 
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD