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

Begonnen von Tom Major, 09 Mai 2017, 19:57:48

Vorheriges Thema - Nächstes Thema

Tom Major

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
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

FranzB94

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

KernSani

@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.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Beta-User

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
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

Tom Major


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.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Beta-User

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
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

Thyraz

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. ;)
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Tom Major


@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
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Jojo11

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

Beta-User

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 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, 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
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

chris1284

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.

Beta-User

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
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

chris1284

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

Tom Major

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?

Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

chris1284

#14
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