Kaufberatung miniCUL V2 oder nanoCUL

[rbptn]

Hallo,

da im Forum beide Geräte verkauft werden, stelle Ich mein Frage hier hoffentlich im richtigen Forum. Geplant ist meine Homematic Wired und Wireless Komponenten von der CCU2 auf eine offenere Lösung zu migrieren. Ich will mir deshalb für meine Wireless Komponenten einen CUL besorgen. Softwareseitig habe Ich mich noch nicht zwischen FHEM und Openhab 2+Homegear entschieden. Deshalb ist es mir wichtig, dass mein Komponentenkauf meine Softwarewahl nicht einschränkt. Der CUL von Busware ist mir für dieses Experiment zu teuer. Wichtig ist für mich auch, dass die Funkreichweite nicht geringer ist, als die der CCU2, da diese meine Haus gerade noch abdeckt. Der Hauptunterschied zwischen den beiden Geräten scheint für mich zu sein, dass man den miniCUL auch im WLAN, also mit USB nur als Stromversorgung betreiben kann. Wenn ich die Dokumentation von Esp-Link aber richtig verstanden habe, dann ist der Zugriff auf das angehängte Modul nur per Telnet, aber nicht wie ich es benötigen würde per emulierter Serieller Schnittstelle an einem PC, also über /dev/ttyS0 möglich. Welchen Stick würdet Ihr für mein Anwendungsgebiet empfehlen?

[MadMax-FHEM]

Weder noch!

Für Homematic würde ich ein "Original-IODev" empfehlen!

Beispielsweise: https://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html

Mit CUL, nanoCUL, etc. gibt es immer wieder Timingprobleme bzgl. Homematic...
...Abhilfe schafft hier nur eine spezielle FW und spezielle fhem-Module...

Aber das Aufsteckmodul kostet eigentlich (fast) weniger als ein Selbstbau-CUL und deutlich weniger als ein fertiger...
...und es gibt keine Probleme bzgl. Timing etc.

Er lässt sich auch per USB oder mittels ESP per WLAN oder oder oder anbinden (zumidest in fhem).
Passt aber auch über Homegear (soweit ich gelesen habe)...

Achja: Homematic IP geht NICHT mit fhem, also nicht direkt! Sondern nur an einer CCU2 und dann per HMCCU-Modul in fhem...

Gruß, Joachim

[rbptn]

Danke  für die schnelle Antwort. Den HM-MOD-RPI-PCB hatte Ich bisher als Option nicht auf dem Schirm. Von Raspberrymatic(https://homematic-forum.de/forum/viewtopic.php?t=34497) wird aber bemängelt, dass die Funkreichweite geringfügig schlechter ist, als die der CCU2. Auch habe Ich mich bezüglich meines Homeservers schon auf einen stromfressenden Dell T20 als Host für meine verschiedenen VMs festgelegt. Ich habe zwar noch einen Pi hier rumliegen, der ist aber noch aus der ersten Generation und damit sowieso inkompatibel. Deshalb bleiben mir nur Lösungen auf Basis von USB oder dem seriellen Port übrig. Man könnte zwar eventuell mit dem seriellen Port den FTDI USB Chip einsparen, mir mangelt es leider an der Zeit, um sowas selber zu basteln. Deshalb ist meine aktueller Ansatz einen USB CUL zu kaufen und darauf zu hoffen, dass beim durchreichen des USB Ports an meine VM mit der Heimsteuerung keine zusätzlichen Probleme bezüglich des Timings auftreten. Was ist für dieses Anwendungsgebiet am empfehlenswertesten?

[MadMax-FHEM]

Tja ich kann nur noch mal im Zusammenhang Homematic von einem CUL abraten und durch das Durchreichen in eine VM wird es bestimmt nicht besser...

Ab und an wird auch im Forum ein USB-HM-MOD fertig angeboten bzw. auch ein WLAN-HM-MOD (per ESP8266)...
...dadurch brauchst du noch nicht einmal einen USB/Seriell-Anschluss (verschwenden) und kannst zusammen mit einer vccu sogar einige verteilen und so eine bessere Funkabdeckung zu haben (falls überhaupt nötig).

Evtl. kannst du ja auch im Forum eine Kaufen-Anfrage starten...

Evtl. kommt die (gefühlt) geringere Reichweite gegenüber einer CCU2 von der/einer nicht optimal verlegten Antenne.
Wenn das PI-Modul aufgesteckt ist (wie beschrieben) und die Antenne entsprechend verlegt wurde wie beschrieben, dann ist das sicher nicht optimal.

Wenn Platz im Gehäuse etc. dann kann das auch besser gemacht werden und dann ist die Reichweite bestimmt ähnlich...
...denn ich denke, dass in der CCU2 dasselbe Funkmodul sitzt

Ansonsten, wenn du wirklich einen CUL willst und nicht selber "basteln" willst, dann wohl einen "Original-CUL" von Busware...
...ist aber nicht wirklich "billig" und wie gesagt für Homematic würde ich den nicht nehmen...

Gruß, Joachim

[Ralf9]

Ein CUL hat gegenüber dem HM-MOD-RPI-PCB nur Nachteile und keine wirklichen Vorteile.
Siehe
https://forum.fhem.de/index.php/topic,68145.msg595998.html#msg595998
und
https://forum.fhem.de/index.php/topic,56606.msg620356.html#msg620356

Für eine USB-Version des HM-MOD-RPI-PCB sind nur 4 Drähte erforderlich.
Ich habe es hier zusammengefasst:
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241

Gruß Ralf

[rbptn]

Ich hab zwar noch nicht ganz verstanden, welches Problem beim Timing des Homematic Protokolls auftritt, verlasse mich aber mal auf die Empfehlungen ein HM-MOD-RPI-PCB dem CUL vorzuziehen. Wenn ich mir folgende Zeichnung zum Anschluss eines USB Controllers anschaue(https://forum.fhem.de/index.php?action=dlattach;topic=69042.0;attach=74300;image), dann sollte doch auch ein RS232 auf TTL Wandler(http://www.pollin.de/shop/dt/MTQ2OTgxOTk-/Bauelemente_Bauteile/Entwicklerboards/Sonstige_Boards/RS232_TTL_Wandler_mit_MAX3232.html) die gleiche Funktion übernehmen können. Passt das bezüglich der Spannungsversorgung, da auf dem Bild 3,3V verwendet wird, beim Adapter aber ein Bereich von 3-5V angegeben ist? Wenn das funktionieren würde wäre das die einfachste Lösung, da Ich mir somit die Suche nach einem originalen USB UART Interface und die mit USB verbundene Latenz spare.

[supernova1963]

Hallo rbptn,
damit du FHEM testen kannst, benötigst du meiner Ansicht nach nicht unbedingt neue Hardware.
Mit dem Modul HMCCU kannst du alle Geräte der CCU2 in FHEM integrieren (s.a. https://wiki.fhem.de/wiki/HMCCU

Code Auswählen Erweitern


define d_ccu HMCCU [IP der CCU2]
attr d_ccu ccuflags extrpc
attr d_ccu room 91 Systeme
attr d_ccu rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr d_ccu rpcinterval 2
attr d_ccu rpcport 2001,2010,9292
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state

define d_ccu_rpc HMCCURPC [IP der CCU2]
attr d_ccu_rpc room 91 Systeme
attr d_ccu_rpc stateFormat rpcstate/state
attr d_ccu_rpc verbose 2


Anschließend legst du die gewünschten Geräte und/oder Kanäle mit:

Code Auswählen Erweitern


get d_ccu devicelist create [Geräte-/Kanalname der CCU2] t=[dev/chn]


an. Danach empfehle ich die "defaults" des jeweiligen Gerätes in den erstellten FHEM Devices zu laden.

Code Auswählen Erweitern


set [FHEM Device] defaults


Hinweis: Teilweise werden das Gerät und der Kanal der CCU2 benötigt (bei mir der Dimmer)

lg

Gernot

[supernova1963]

Nochmal ich:

Zur Vervollständigung von:

damit du FHEM testen kannst, benötigst du meiner Ansicht nach nicht unbedingt neue Hardware.

Anstelle des RPi habe ich mir zunächst jeweils eine virtuelle Maschine mit Ubuntu Server für FHEM und OpenHab auf meinem PC angelegt und getestet.
2 GB RAM, 32 GB HD, 32 MB Grafik, Netzwerk=Bridge war ausreichend und performanter als ein RPi.

lg

Gernot

[chris1284]

Geplant ist meine Homematic Wired und Wireless Komponenten von der CCU2 auf eine offenere Lösung zu migrieren.

homematic ist nicht offen und wird nicht offener wenn du homematic an fhem betreibst.

Ich will mir deshalb für meine Wireless Komponenten einen CUL besorgen.
Welchen Stick würdet Ihr für mein Anwendungsgebiet empfehlen?

garkeinen wie schon gesagt. sind culs nicht zu empfehlen.
die wireless komponenten von der ccu "abzuziehen" ist unsinn. nutze hmccu als verbidner zwischen fhem und der ccu2 und nutze so alle vorteile der ccu2 und fhem (und lasse dir dabei die möglichkeit auf auch noch andere systeme anzusehen). so kann deine ccu weiter zuverlässig werkeln und du erweiterst nur die funktionalität mit fhem oder anderen systemen (bist aber nicht darauf angewiesen). das ist der beste weg hm zu betreiben meiner meinung nach (und ich habe lange hm erst mit cul-derivaten betrieben, dann mit hm-iOS wie dem hmlan und hmusb und bin nun quasie am ende beim besten aus beidem gelandet mit der ccu). das händling von hm-geräten (verknüpfen, konfigurieren usw) ist in der ccu auch einfacher (effektiver will ich mal sagen weil man schnell erfolgreich ist ohne ewig befehle zusammenzufrickeln und register, kanäle usw zu suchen und zu schreiben. und was auch nicht zu vergessen ist: du sparst dir die migration der ganzen hm-geräte da du sie wie gernot schon schrieb einfach importierst und in fhem nutz.

Auch habe Ich mich bezüglich meines Homeservers schon auf einen stromfressenden Dell T20 als Host für meine verschiedenen VMs festgelegt.

was den weg oben noch mal unterstreicht da du so vm-seitig keine probleme mit dem durchschleifen von den hm-ios bekommst weil du die ccu über lan ansprichst. du könntest zwar auf ein langateway wechseln aber das wäre dumm weil es genau so viel wie die ccu kostet und weniger kann. wenn du später dennoch culs einbindne willst (für zb günstige wetterstationen) sollte das in der vm auch gehen (und es gibt auch culs auf lan basis -> cun(o), max cube mit culfw,....)