Neue Hardware für zuverlässige Aussenlichtsteuerung

Begonnen von Fredi69, 04 Mai 2020, 16:30:52

Vorheriges Thema - Nächstes Thema

Fredi69

Die bisherige Aussenlichtsteuerung basiert hauptsächlich auf FS20 Komponenten, die nicht mehr zuverlässig funktionieren.
Zwei Bewegungsmelder und ein Aktor wurden bereits durch Homematic (classic) Komponenten ersetzt.
Jetzt möchte ich die verbliebenen zwei Bewegungsmelder und den 4-fach Aktor ersetzen.
Zuerst dachte ich auch wieder an Homematic (classic) Komponenten.
Da ich aber immer wieder gelesen habe, das System wird nicht weiter entwickelt, habe ich mich mit Homematic IP beschäftigt.
Hierzu würde ich dann einen zweiten Raspi mit RPI-RF-MOD und externer Stabantenne, sowie mit piVCCU austatten. Das Ganze dann über HMCCU verbinden, so der Plan.

Jetzt habe ich aber wieder gelesen, das gerade man eine Aussenlichtsteuerung (wo es auf schnelle Reaktion ankommt) nicht auf diesem Konstrukt aufbauen sollte, da es gerade die Kommunikation über HMCCU nicht zuverlässig schnell funktioniert.
Was würdet ihr raten, welche Komponenten würdet ihr empfehlen?

Vielen Dank für Eure Unterstützung
fhem auf Raspberry Pi 3
FRITZ!Box7490, Fritz!Box 3270 AP, 3xHMLAN, CUL868, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere Homematic, Intertechno, Shelly und LaCrosse Komponenten

Beta-User

Wäre mir neu, dass HMCCU.* irgendwie langsam oder unzuverlässig sein soll.

Die "Krux" bei der Mischung verschiedener Systeme (auch HM-Classic und HM-IP sind verschiedene Systeme, selbst wenn alles über die CCUx eingebunden ist!) ist halt, dass das nicht mehr läuft, wenn die Zentrale (FHEM oder CCU) oder das IO (CCU) weg sind.

Was spricht denn dagegen, alles in HM-Classic zu machen und dann direkte Peerings zu verwenden?
Dass HM-Classic entwicklungstechnisch irgendwo in der Nähe von "end of live ist", ist mMn. kein Argument, das nicht zu nehmen (wenn man schon ein paar Komponenten hat). Es läuft ja, und die Schwachstellen sind bekannt; notfalls kann man sogar Eigenbauten einbinden (AskSinn++), wenn's gar nicht mehr anders ginge...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Christoph Morrison

Zitat von: Fredi69 am 04 Mai 2020, 16:30:52
Jetzt habe ich aber wieder gelesen, das gerade man eine Aussenlichtsteuerung (wo es auf schnelle Reaktion ankommt) nicht auf diesem Konstrukt aufbauen sollte, da es gerade die Kommunikation über HMCCU nicht zuverlässig schnell funktioniert.
Was würdet ihr raten, welche Komponenten würdet ihr empfehlen?

Kann ich nicht nachvollziehen. Ich hab einen HM(Ip)-Betrieb über drei Wege: HM direkt über CUL_HM, HmIP und Asksin-PP über die CCU3 mit HMCCU. Die CCU3 ist nur ein Gateway, die Logiken laufen alle über FHEM. Ich kann da null merkbare Latenzen feststellen.

Ich sehe das übrigens so, dass HM (classic) sogar das zukunftssicherere System ist, denn alles was man für ein eigenes HM-Gerät braucht ist ein Arduino, ein Funkmodul (und Glück kein rip off aus China zu bekommen) und ein Sketch. Einen 8fach-Temperatursensor bekommt man von eQ-3 auch nicht, von Asksin++ schon.