Hallo zusammen,
ich möchte mein FHEM System so erweitern, das einige Lampen für die Außen-/Gartenbeleuchtung (ca. 6 bis 10 Stück) damit gesteuert werden. Ich möchte dafür Unterputz Funk-Aktoren nutzen. Ich habe bisher noch kein RF System im Einsatz, bin also frei in der Wahl.
Gibt es Empfehlungen für robuste und langlebige Aktoren? Das wäre mir das wichtigste Kriterium, danach der Preis und Standby Verbrauch.
Der Markt ist ja voll davon, ein Standard hier scheint u.a. Homematic zu sein, z.B. mit diesem
Homematic 076793
https://www.elv.de/homematic-hm-lc-sw1-fm-unterputzschalter-1fach.html
Aber es gibt ja auch FS20, Eltako, RSL, Intertechno usw. usw.
https://www.voelkner.de/products/675450/Eltako-Funk-Schaltaktor-Stromstoss-Schalter-1-Kanal-Unterputz-Schaltleistung-max.-2000-W-Reichwei.html#tech-data
https://www.conrad.de/de/rsl-funk-dimmer-unterputz-1-kanal-schaltleistung-max-300-w-reichweite-max-im-freifeld-70-m-640465.html?sc.ref=Product%20Details
https://www.amazon.de/Intertechno-CMR-1000-Funk-Einbauschalter/dp/B000W3XGBU/ref=sr_1_1?ie=UTF8&qid=1494351352&sr=8-1&keywords=funk+aktor
Der Preis vom Homematic 076793 wäre ok (gibts in anderen Läden auch noch etwas günstiger als in meinem link), kann aber gern auch noch günstiger sein. Der Eltako wäre vom Preis die Obergrenze, ist der in irgend einer Hinsicht besser als der Homematic 076793 ?
Standby lese ich oft um die 0,5W, gibt es da Aktoren die deutlich weniger verbrauchen?
Was habe ich vom bidirektionalen Betrieb bei Homematic? Falls der Kanal belegt ist und der Aktor kein Acknowledge sendet, wird dann die Zentrale immer wieder versuchen, den Aktor zu erreichen? Wie lange macht sie das bis sie aufgibt?
Neben Empfehlungen für bestimmte Aktoren würden mich natürlich auch negative Erfahrungen mit bestimmten Typen interessieren.
Schon mal vielen Dank an Euch,
Grüße Tom
Hi Tom Major!
ZitatFHEM auf BeagleBone Black
Ich habe hier auch noch einen BBB rumliegen und will FHEM darauf installieren. Welches BS kannst du empfehlen?
Gruss Franz
@FranzB94: Kannst du zu deiner Frage einen neuen Thread aufmachen, oder das per PN klären
@Tom Major: Durch den Rückkanal bei Homematic weisst du vor allem ob wirklich geschaltet wurde, was natürlich gerade bei Lampen die du nicht siehst interessant ist. Grundsätzlich ist Homematic auch was Reichweite etc... betrifft durchaus zu empfehlen, aber die anderen tun's auch - evtl. mit weniger Komfort.
Hi Tom Major,
zu HM (andere ernstzunehmenede Kaufsysteme habe ich nicht): Habe einiges von HM am laufen (~60 Geräte), die UP-Schalter (3 oder 4, davon die meisten 2-kanalig) seit ca. 3 Jahren und bin soweit zufrieden, hatte HM-technisch bisher nur einen Ausfall von einem Fensterkontakt, das war kurz nach dem Kauf.
Ist der Aktor nicht zu erreichen, kommt nach ca. 30 sec. (kann auch eine Minute sein) wiederholter Sendeversuche ein NACK, mit einer VCCU und vernetzten IOs ist es aber recht einfach, solche Funkprobleme zu beseitigen.
Meine UP-Aktoren haben in der Regel trotzdem einen bzw. mehrere Taster, mit denen man an- und ausschalten kann (idR. mit einer Treppenhausschaltung, sie gehen also nach einer gewissen Zeit auch wieder aus). Der Vorteil des Rückkanals liegt dann nicht nur darin, dass man die Dinger ziemlich zuverlässig geschaltet bekommt, sondern auch darin, dass man Tasteraktionen ebenfalls steuerungsseitig mitbekommt.
Für Deinen Aufbau wäre zu überlegen, ob statt der 1-fach-Aktoren die zweikanaligen in Frage kommen.
Gruß, Beta-User
Beta-User & KernSani, Danke für Eure Infos. Der Tipp mit den zweikanaligen Aktoren ist gut, ich werde das prüfen.
ZitatIst der Aktor nicht zu erreichen, kommt nach ca. 30 sec. (kann auch eine Minute sein) wiederholter Sendeversuche ein NACK
Das heißt nach 30sec oder 1min gibt die Zentrale auf? Kann man diese Zeit irgendwo einstellen oder ist die in der Firmware des Interface fest vorgegeben?
Und welches FHEM Interface würdet ihr mir eigentlich empfehlen (LAN bevorzugt), HM-LGW-O-TW-W-EU oder CUNX?
Habe schon vermutet dass es irgendwie auf HM hinauslaufen wird, Qualität eines HM 076793 sollte schon besser sein als z.B. ein Intertechno CMR-1000, oder?
Die Zahl von einem HM Ausfall bei 60 Geräten in 3 Jahren ist ja schon mal eine Aussage, die nicht schlecht klingt. Beim Amazon und dem CMR-1000 z.B. liesst man ja von einigen Ausfällen.
@FranzB94
kurz zur OT Frage, als ich vor 2 Jahren FHEM aufgesetzt habe habe ich bone-debian-7.8-console-armhf-2015-01-19-2gb verwendet und das läuft immer noch. Keine Probleme. Ich werde aber demnächst auf RPi3 umsteigen, wenn meine 1-Wire Adapterplatine fertig ist, um etwas mehr Performance zu haben.
Hallo Tom Major,
ja, wenn ein NACK kommt, ist es vorbei, keine Ahnung, ob man das irgendwo einstellen kann, denn:
Man kann die Qualität der Funkverbindung sehen (RSSI) und entsprechend für eine ordentliche Funkabdeckung sorgen. Damit ist das Problem nach meiner Erfahrung erledigt. (Mehrere Interfaces => VCCU).
Als Interface würde ich das HM-UART-Modul empfehlen. Muß man zwar löten, das ist aber einfach. Da Du sowieso einen PI einsetzt, umso mehr. Die Dinger sind von der Reichweite her auch ok. Wenn das dann nicht reicht: "Eigentlich" sind das nur serielle Geräte, man kann die also netzwerkfähig machen (ser2net oder mit etwas mehr gebastle und Microcontroller-Hardware: ESP8266 oder STM32; beide aber "nur" für den Zweck, die serielle Schnittstelle im Netz durchzureichen). Empfehlenswert ist in jedem Fall für HM eine "echte" HM-Schnittstelle (im Wiki-Bereich gibt es dazu einen Thread von UliM).
Gruß, Beta-User
Würde auch entweder zu HM oder Zwave (um mal noch eine Alternative zu nennen) raten,
da beide ein breites Spektrum an Geräten bieten und sehr zuverlässig arbeiten.
An sich geben sich beide Systeme nicht viel.
ZWave hat als recht nettes Feature, dass alle aktiven (nicht batteriebetriebenen) Aktoren Signale an andere Aktoren weiterleiten können, falls die Zentrale diese nicht direkt erreicht.
Durch dieses Schneeballsystem erreicht man ggf. eine Reichweite die bei anderen Systemen nur mit einem zweiten Controller möglich wäre.
Notfalls auf halber Strecke einfach eine schaltbare Zwave Steckdose einstecken um den eigentlich nicht erreichbaren Teilnehmer doch wieder ins Netz zu bekommen.
HM hat dafür ein paar nette Devices die es für Zwave nicht gibt (was aber sicher auch umgekehrt gilt).
Weiterer Unterschied ist, dass bei HM alles aus einem Haus kommt. Zwave Geräte gibt es hingegen von vielen verschiedenen Herstellern.
Ob das nun Vor- oder Nachteil ist muss jeder selbst entscheiden. ;)
@Thyraz
Danke für die Infos bzgl. Zwave. Ich habe mal nach UP Aktoren dafür gesucht und oft findet man dann Fibaro, aber die Zuverlässigkeit z.B. beim Typ 222 klingt nicht wirklich gut:
https://www.amazon.de/Fibaro-Relais-Unterputzeinsatz-Schalter-FIBEFGS-222/dp/B00WH0S8F0/ref=cm_cr_arp_d_product_top?ie=UTF8
Ich glaube ich werde mich erstmal auf HM konzentrieren.
@Beta-User
Löten wäre kein Problem, aber UART und RPi3 möchte ich nicht, wegen schlechten Erfahrungen. Habe vor einiger Zeit versucht, 1-Wire chip DS2480 am RPi3 anzubinden, ging zwar nach einigen Verrenkungen und Deaktivierung von bluetooth, allerdings nicht stabil, nach reboot gab es immer mal wieder Probleme. Bin dann auf DS2482 über I2C gewechselt, viel stabiler.
Möchte deshalb für HM eher eine Anbindung mittels LAN haben.
Gibt es Einschränkungen, wenn ich an FHEM das Homematic 104029 Funk-LAN Gateway für 79 Euro anbinde anstatt das CCU2 für 99 Euro?
Und könnte ich das ebenso ohne Einschränkungen nehmen:
http://busware.de/tiki-index.php?page=CUNX
Kostet allerdings auch 79 Euro.
ZitatEmpfehlenswert ist in jedem Fall für HM eine "echte" HM-Schnittstelle
Das verstehe ich nicht. Was ist eine echte bzw. eine unechte HM Schnittstelle?
Danke & Grüße,
Tom
Kann die HMs auch nur empfehlen. Ich meine die 2-kanaligen haben aber mal Probleme gemacht. Musst Du mal die Suchfunktion verwenden. Irgendwas war damit nicht so optimal.
Schöne Grüße
Jo
Hi Tom,
unter einem echten HM-IO verstehe ich solche, die "von selbst" das HM Protokoll können, also im wesentlichen die HW, die ELV etc. selbst liefern.
"Unecht" sind CUL, CUNO etc., die haben uU. Probleme mit dem Timing usw. (Ich selbst habe aber ganz gute Erfahrungen mit einem CUL).
Von PI-GPIO rate ich tendenziell auch ab, wobei mein HMUART auf einem PI2 sehr gut funktioniert hat (mußte nur für die RTC die I2C-PINs eben am Modul abgreifen). PI3 soll diesbezüglich hakeliger sein, aber es gibt da eine ganz gute Anleitung von Otto123.
Das HMUART ist aber eigentlich nur an irgendeine serielle Schnittstelle gebunden, die kann man auch z.B. mit einem ESP8266 im serial-Bridge-mode (https://forum.fhem.de/index.php/topic,54511.0.html) bereitstellen, dann hat man ein "echtes" HM-WLAN-Modul für ca. 23 Euro. Oder man nimmt einen simplen USB-serial-Adapter (am besten FTDI-basiert), stellt den auf 3,3V und bindet das Teil darüber an; die kosten in China grade mal 2 Euro. Oder über einen STM32 mit W5500 als Netzwerk-Maple-CUL (https://forum.fhem.de/index.php/topic,60458.0.html), der kann auch eine Netzwerk-serial-Bridge, dann sind es eben knapp 30 Euro, man kann gegen geringen Aufpreis noch weitere CC1101-Module anbinden (433MHz und slow-RF).
Bitte suche die nicht verlinkten Stichworte selbst, wenn Du boards brauchst/willst: weitere User dahinter sind PeMue, Telekatz und Ranseyer.
Gruß, Beta-User
Zitat von: Tom Major am 11 Mai 2017, 20:31:14
Gibt es Einschränkungen, wenn ich an FHEM das Homematic 104029 Funk-LAN Gateway für 79 Euro anbinde anstatt das CCU2 für 99 Euro?
Und könnte ich das ebenso ohne Einschränkungen nehmen:
http://busware.de/tiki-index.php?page=CUNX
Kostet allerdings auch 79 Euro.
das langateway würde ich nicht nehmen da es genau so viel wie der ccu2 bausatz (nur stecken und 4 schrauben )kostet und die CCU2 mehr kann (und du so nicht auf HMUART und CUL_HM angewiesen bist).
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. entgegen der aussage von Beta-User läuft das modul auf dem pi3 mit zb YAHM (ccu im lxc container) sehr stabil und du hast auch die HMip anbindung (was mit HMUART / CUL_HM nicht der fall ist). anderer vorteil: du hast nur ein gerät pi = fhemserver und ccu2. vom cul für hm wird in der regel abgeraten.
Zitat von: chris1284 am 12 Mai 2017, 08:41:33
entgegen der aussage von Beta-User läuft das modul auf dem pi3
...meine Aussage sollte so zu verstehen sein, dass ich a) eigene positive Erfahrungen mit dem PI2+HMUART gemacht habe und b) vom Hörensagen nur berichten kann, dass es auch mit dem PI3 geht.
Was die Anbindung von HM Komponenten angeht, hat man 2 Wege, die nicht kompatibel sind: CUL_HM oder HMCCU.
Ich nutze nur CUL_HM (aber auch mit dem HMUART-Modul, also einem "echten" HM-IO), das läuft auch problemlos (mit mehreren IO-s über die "Zwischeninstanz" VCCU). Ob es besser ist, mit HMCCU zu arbeiten, kann ich nicht beurteilen, man sollte dazu wissen, dass die CCU2 eben dafür gemacht ist, eigene Logiken zur Steuerung der HM-Komponenten abzubilden, also ähnlich wie FHEM zu steuern (und nicht nur Befehle durchzureichen). Dadurch kann es theoretisch zu Konflikten zwischen den Logik-Ebenen kommen (je nachdem, wie man was löst).
Gruß, Beta-User
vorteil der ccu (sei es real oder yham) ist halt ganz klar (für mich) die einfache bedienung (kein befehle tippen / registerschupsen, viele vereinfachungen wie gruppen bilden), das breite angebot an artikeln (da ich hm wired,hmip und bidcos nutzen kann) und der fakt da sich alle hm-produkte ohne einschränkung nutzen kann (in cul_hm erfolg die implementierunf oft später und hin und wieder erts sehr spät zu 100%).
und nicht vergessen: mit pi und hmuart modul bist du flexibel. passt dir die ccu nicht wechselst du einfach zu cul_hm oder anderst herum
Hey Leute,
danke für Eure Infos, bin jetzt aber angesichts der ganzen HM Abkürzungen eigentlich noch mehr verwirrt, das ist aber nicht Eure Schuld, sondern ich wollte ja wie im Topic geschrieben erstmal Empfehlungen für ein RF System bzw. für UP Aktoren haben, mit den Details der Konfiguration wollte ich mich erst befassen wenn die Sachen installiert sind, aber wahrscheinlich ist das zu spät.
@chris1284
Danke für Hinweis mit dem ccu2 Bausatz. Das wäre der hier, korrekt?
https://www.elv.de/homematic-zentrale-ccu2-arr-bausatz.html
Ich habe kein Problem mit den vorgeschlagenen Elektronikprojekten (Netzwerk-Maple-CUL, ESP8266 im serial-Bridge-mode etc.) nur momentan ist eher die Zeit als das Geld der begrenzende Faktor. Deswegen würde ich eher ein fertiges und stabiles Interface zwischen HM und FHEM bevorzugen.
Zitatund du so nicht auf HMUART und CUL_HM angewiesen bist
ZitatWas die Anbindung von HM Komponenten angeht, hat man 2 Wege, die nicht kompatibel sind: CUL_HM oder HMCCU.
Kann ich das so verstehen das HMCCU besser/stabiler/whatever? als CUL_HM ist?
Und ich nehme den ccu2 Bausatz und habe damit eine gute und stabile Anbindung der Aktoren an FHEM und alles ist gut?
Zitat von: Tom Major am 12 Mai 2017, 20:09:35
Das wäre der hier, korrekt?
ja
Zitat von: Tom Major am 12 Mai 2017, 20:09:35
Kann ich das so verstehen das HMCCU besser/stabiler/whatever? als CUL_HM ist?
nein, cul_hm ist auch stabil aber ich will es mal als reverse engineering bezeichnen. martin muss halt immer frickeln/probieren/lange testen wenn es was neues gibt. bei der ccu gibts nen firmwareupdate und gut ist. bestes beispiel aktuell ist das batterie reading des wettersensors (den es seit jahren gibt) und das erst jetzt wieder in fhem verfügbar ist oder der rgbw-controller der erst nach langer, langer zeit in fhem verfügbar ist (in der ccu seit release)
Zitat von: Tom Major am 12 Mai 2017, 20:09:35
Und ich nehme den ccu2 Bausatz und habe damit eine gute und stabile Anbindung der Aktoren an FHEM und alles ist gut?
ja, so ist das (wobei cul_hm nicht instabiler ist) und du kannst hmip nutzen was ein reiner fhemuser nicht kann. dir entstehen keine nachteil meiner meinung nach (außer das es teuere als pi + hmuart modul ist). man vccu und hminfo als einziges pro cul_hm feature anführen meiner meinung nach. mit der ccu stehen dir außerdem auch noch andere system automatisierungssysteme zur verfügung falls fhem nichts für dich ist
@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:
Zitatdu 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,
Zitat von: Tom Major am 13 Mai 2017, 12:35:59
@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 (https://forum.fhem.de/index.php/topic,71791.msg634267.html#msg634267) 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
Zitat von: Tom Major am 13 Mai 2017, 12:35:59
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)
Zitat von: Beta-User am 13 Mai 2017, 17:44:39
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
@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
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.
Zitat von: Beta-User am 13 Mai 2017, 17:44:39
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
Nachtrag:
Bin gerade beim Studium von Heimautomatisierung-mit-fhem.pdf über den KeepAlive Abschnitt gestolpert:
ZitatKeepAlive: 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
Ist dieses Thema dann damit gelöst. Dann bitte das Subject des ersten Post anpassen...
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.