[Gelöst] Empfehlung für robuste Unterputz Funk-Aktoren, welches System?

[Tom Major]

@chris1284 und Beta-User
Danke für Eure Infos. Damit und nachdem ich jetzt über die einzelnen Module und HW etwas mehr gelesen habe sind die diversen Möglichkeiten etwas klarer.

Ich schwanke jetzt zwischen der ccu2 oder HM-MOD-RPI-PCB + RPi3.

Bei ccu2 hätte ich "echte" HM hardware, eine FHEM Anbindung über HMCCU sowie sogar ein alternatives SmartHome System zu FHEM (mit WebUI), wobei das nicht mein ursprüngliches Ziel war.

Bei HM-MOD-RPI-PCB + RPi3 würde mich reizen, das ich kein extra Gerät, Netzteil etc. unterbringen muss und das es für meine erste Ausbaustufe (die UP Aktoren) und wohl auch später voll reichen würde - falls ich es stabil am RPi3 seriell hinbekomme. Es ist aber ein reverse engineering Projekt welches bzgl. Unterstützung der devices dem Original naturgemäß immer etwas nachlaufen wird.

@chris1284, was ich noch nicht verstehe ist folgende Variante:

du kannst aber auch eine ccu2 für um die 50€ haben wenn du sie auf dem pi (ca 30€) mit dem HM-MOD-RPI-PCB(ca 23€) installierst.

Das wäre dann keine HMUART / CUL_HM Anbindung sondern auch mittels Modul HMCCU oder wie? Wird da irgendwie die originale ccu2 firmware auf dem RPi emuliert oder wie ist das Konzept?
Wäre das eine vollwertige ccu2, d.h. auch die Original HM firmware mit WebUI läuft darauf?

@Beta-User, für Deine ~60 HM Geräte, die problemlos laufen, nutzt Du was genau, ein SIGNALduino + CC1101 und dann HMUART / CUL_HM, das wars ?

Danke,

[Beta-User]

@Beta-User, für Deine ~60 HM Geräte, die problemlos laufen, nutzt Du was genau, ein SIGNALduino + CC1101 und dann HMUART / CUL_HM, das wars ?

Ich hatte mehr als 2 Jahre nur einen Busware-CUL, habe dann den PI mit einem HMUART-PCB...-Modul aufgerüstet (mit VCCU) und im Moment arbeitet seit letzter Woche wieder nur der CUL (seitdem habe ich eine TV-Box als Server im Einsatz, die hat keinen 3,3V-UART-Anschluß). Das Modul werde ich entweder via USB wieder in Betrieb nehmen, oder zusammen mit einem ESP. Hier finden sich dazu weitere Links mit Bauanletungen usw..

Das HMUART-Modul ist ein natives HM-Gerät, das ist für die Kommunikation mit den HM Geräten das Optimum und findet auch in der CCU2 Verwendung. Anders ist dann nur die Ansteuerungssoftware, wie chris1284 ja schon zutreffend beschrieben hat. Einmal CUL_HM (reverse-engineering), einmal eben die CCU2-Software, sei es im Orginal oder als OCCU (oder wie das Ding dann heiß, halt PI+Modul+Software von e3Q...).
Als Interface ist es nicht nur billiger als ein Busware-CUL, sondern auch besser (Funkreichweite, schneller), daher jedenfalls für CUL_HM zu empfehlen.
Wie chris1284 beschrieben hat, dauert es manchmal, bis alle Funktionalitäten spezieller HM-Hardware unterstützt wird, in der Basis gibt es m.E. keine wesentlichen Unterschiede. Dafür entfallen Verzögerungen aus der Netzwerkecke.

Allerdings dürfte ein Wechsel von CUL_HM nach HMCCU praktisch mit so großem Aufwand verbunden sein, dass ich das nur als theoretische Option ansehen würde; die Readings usw. heißen anders, also muß man die komplette Steuerung überarbeiten...

Grundsätzlich sehe ich als Vorteil an, alles auf einem Gerät zu haben, dann entfallen Fehlerquellen wg. Nezwerk usw. chris1284 hat - wie ich das verstanden habe - alles auf einer Maschine, aber virtualisiert. Dazu exisitert keine mir bekannte Anleitung, es hört sich aber interessant (aber kompliziert) an.

Hoffe, das halbwegs verständlich erklärt zu haben,

Gruß, Beta-User

[chris1284]

Das wäre dann keine HMUART / CUL_HM Anbindung sondern auch mittels Modul HMCCU oder wie? Wird da irgendwie die originale ccu2 firmware auf dem RPi emuliert oder wie ist das Konzept?
Wäre das eine vollwertige ccu2, d.h. auch die Original HM firmware mit WebUI läuft darauf?

jawohl. du hättest den pi mit dem HM-MOD-RPI-PCB. auf dem pi würdest du YAHM installieren welches quasie eine virtuelle CCU2 ist. auf dem pi kannst du dann wie gewohnt fhem installieren und per fhem auf die virtuelle CUU2 zugreifen die deine Homematic Geräte verwaltet (wie die reale CCU2 ohne Abstriche)

@beta-user: die anleitung wäre

1.rasbian auf pi installier (sd-card image drauf)
2. HM-MOD-RPI-PCB installiern eund wie im fhem wiki beschrieben freischalten
3- YAHM installieren https://homematic-forum.de/forum/viewtopic.php?t=31033
4. fhem installieren und aktualisieren
5. hmccu in fhem einrichten

ich habe so für meinen schrebergarten nur 1 device für fhem, ccu2. ggf, werde ich noch einen umts-stick verbauen und per wlan einen ap aufreißen. so hätte ich alles auf dem pi welcher bei fehler einfach wieder herzustellen ist (clone der sd-card)

in der Basis gibt es m.E. keine wesentlichen Unterschiede.

was aber für evtl später eingestiegene nur so scheint weil eq3 im bereicht bidcos ehr sehr wenig neues bringt, die basics von hm bereits zusammen gesucht wurden und hmip keine rolle spielt da es nicht geht. ich hatte zb mal den rgw controller bausatz. diesen kannte fhem noch nciht bzw nur zu gefühlt 10%. ich habe ihn dann verkauft und später wieder gekauft als ich die ccu2 hatte (mit vollem support). in fhem hat sich in der zeit (3/4jahr) nichts getan. erts mit sniffen per cul und ccu2 konnte dann irgendwann mal der rgbw controller zu 100% in fhem genutzt werden. es gibt halt keine doku die martin nutzen könnte somit muss er alles selbst erarbeiten

[Beta-User]

@chris1284:
Danke für die Erläuterung. YAHM kannte ich bisher nicht, gefällt mir aber vom Ansatz her gut, da man nicht 2xPC/PI-Hardware braucht!

Eher interessehalber und evtl., weil es für Tom Major wichtig sein könnte: YAHM kann vermutlich auch mit mehreren IO's umgehen und kann dementsprechend auch auf einen HMUART@USB-Wandler uä. konfiguriert werden?

Ansonsten sollte man das m.E. für Einsteiger etwas prominenter plazieren; es scheint mir (wie diese Bau- und Lötanleitung für den HMUART@USB etc.) doch eher nur für Intensiv-Sucher auffindbar zu sein...

Gruß und Danke für die Diskussion,

Beta-User

[chris1284]

soweit ich weiss kann alles was auf der hm-occu-sdk aufbaut nur das pcb auf gpio als direkt angebundenes ioDev. andere ioDevs müsste man in der CCU selbst einbinden (die ccu kann zb das hmlan-gateway nutzen). mehrer ioDev wie vccu zur redundanten absicherung kennt die ccu nicht.

[Tom Major]

Hoffe, das halbwegs verständlich erklärt zu haben,

Definitiv, alles verstanden, vielen Dank an Beta-User und chris1284 für Eure ausführlichen Infos. Das hat mir echt weitergeholfen und ich denke einigen anderen die jetzt oder später vor diesen Fragen stehen ebenso.

@Beta-User
Hier habe ich noch eine Anleitung "aus der Praxis" für YAHM gefunden:
http://blog.its-webtime.de/2017/02/04/homematic-modul-hm-mod-rpi-pcb-und-yahm-auf-einem-raspberry-pi-3/

Obwohl mir das Konzept der virtuellen ccu mit YAHM gefällt werde ich für meine gegenwärtige Aufgabe das erstmal nicht weiter verfolgen, das lenkt mich zu sehr vom Ziel ab (und wenn das nicht auf Anhieb funktioniert kann das schnell zeitmässig ausufern, das kennt man ja). Ich möchte ja vorerst "nur" ein paar UP Aktoren in Betrieb nehmen.
Dafür schwanke ich immer noch zwischen HM-MOD-RPI-PCB / CUL_HM oder halt CCU2 / HMCCU - mittlerweile habe ich ein viel besserers Verständnis dieser beiden Varianten.

Wie Beta-User schreibt sehe ich auch Vorteile in nur einem Gerät, das würde mir an HM-MOD-RPI-PCB / CUL_HM gefallen, und diese Lösung wäre ja für meine Aktoren völlig ausreichend und schnell eingerichtet.

Die CCU2 / HMCCU hätte als Nachteil für mich das extra Gerät + Netzteil. Wenn ich aber später mit HM auf den Geschmack komme und vielleicht mit Heizungsthermostaten etc. mehr machen will, wäre das WebUI in der ccu2 schon sehr verlockend als paralleles System zu FHEM, um solche Sachen eleganter erledigen zu können - zumindest habe ich das bei einigen Leuten hier gelesen dass die bestimmte Sachen lieber im WebUI erledigen.

Ich könnte natürlich jetzt HM-MOD-RPI-PCB / CUL_HM machen und später wenn mal mehr Zeit wäre mit der gleichen HW die YAHM Lösung mit virtueller ccu testen, aber Beta-User schreibt das ein Wechsel später nicht mehr so einfach ist.

Nun ja, ich werde noch einige Tage überlegen ehe ich bestelle. Vielleicht ergeben sich noch ein paar neue Aspekte.

Vielen Dank für die aufschlussreiche Diskussion hier.
Grüße Tom

[Tom Major]

Nachtrag:
Bin gerade beim Studium von Heimautomatisierung-mit-fhem.pdf über den KeepAlive Abschnitt gestolpert:

KeepAlive: Die Geräte prüfen durch einen keep-alive Mechanismus das bestehen der Verbindung zur
Zentrale. Das Gerät wird die Verbindung trennen und neu aufsetzen sollte für 30sec kein ,,keep-
alive" gekommen sein. FHEM macht dies automatisch alle 25sec.

Da ich das für eine Menge Funkverkehr im idle Betrieb bei vielen HM Geräten halte, habe ich dazu noch mal eine Grundsatzfrage im HM Bereich des Forums gestellt:
https://forum.fhem.de/index.php/topic,72102.0.html

Grüße Tom

[KernSani]

Ist dieses Thema dann damit gelöst. Dann bitte das Subject des ersten Post anpassen...

[Tom Major]

Meine keep-alive Anfrage ist beantwortet.
Der von mir zitierte Text aus dem Einsteiger pdf bezieht sich nur auf den Netzwerk (Ethernet/Wlan) Verkehr zum IO Device, nicht auf den Funkverkehr.

Thread subject auf [Gelöst] geändert.