Hauptmenü

Erfahrungen HM-MOD-RPI-PCB

Begonnen von NewMatic, 11 Dezember 2017, 13:28:26

Vorheriges Thema - Nächstes Thema

NewMatic

Hallo,

hat von euch jemand das in diesem Wiki-Thread beschriebene HM Funkmodul im Einsatz?
Wie sind eure Erfahrungen dazu? Gab es Probleme beim Einbinden im Betrieb?
Bin um jegliches Feedback dankbar :)

LG Tobi

Beta-User

Bitte bemühe doch die Forumssuche und beachte die Hinweise in dem in der Signatur verlinkten Thread.

Kurzfassung trotzdem als "besonderer Service": Es ist _das_ interface für HM...
Ich selbst hatte es erst im PI2 problemlos im Einsatz und betreibe es jetzt seit Monaten an einem USB-Seriell-Wandler (Bild dazu hier, das ganz im Vordergrund rechts unten gehört dazu...).

Btw.: es gibt auch andere funktionierende Funktechnik, nicht nur HM ;) .

Gruß, Beta-User
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

NewMatic

#2
Hi Beta-User,

danke für deine Antwort.

Warum HM-> weil dass das einzige Hardware-System ist, welches adapter zu gängigen Schalterprogrammen/Abdeckungen bietet (Gira,Becker.etc) Dazu habe ich keine anderen Systeme gefunden? Kennst du welche?

LG Tobi

Beta-User

Zitat von: NewMatic am 11 Dezember 2017, 14:39:33
Kennst du welche?
Leider nein, aber:

z.B. die Fibaro-Aktoren (und vom Eindruck her auch die von andere zwave-Herstellern) sind recht klein und sollten sich mit etwas Gequetsche (dass es für HM-Schalterprogramm-Geräte auch braucht) hinter die Schalter in den Dosen versenken lassen.
Damit benötigt man gar keine Adapter und kann die bisherige Installation optisch belassen.

Auch der "Druckpunkt" bei den HM-Geräten ist sehr weich. Doppelschalter gibt es nicht, zudem benötigt man für Doppel-UP-Geräte Taster  (kann man - nach meinem bisherigen Kenntnisstand - mindestens bei einem Teil der zwave's wohl umdefinieren und dann als Schalter belassen).

Im Ergebnis würde ich zwischenzeitlich sagen: Wenn du keine Heizkörper ansteuern willst, nimm nicht HM, die Geräteauswahl ist woanders besser. (Aber bitte: HM funktioniert auch, und anderswo sind die Dinge auch nicht perfekt, ich weiß es (nur) noch nicht...

Just my2ct ;)
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

herrmannj

Zitat von: NewMatic am 11 Dezember 2017, 13:28:26
Hallo,

hat von euch jemand das in diesem Wiki-Thread beschriebene HM Funkmodul im Einsatz?
Wie sind eure Erfahrungen dazu? Gab es Probleme beim Einbinden im Betrieb?
Bin um jegliches Feedback dankbar :)

LG Tobi
Funktioniert stabil

NewMatic

danke für eure antworten :)

@Beta-User:
Vorrangig geht es mir in erster Linie um eine gute Jalousiensteuerung.
Hattest du negative Erfahrungen mit HM, bzw. was sind deine Contras?....

Zitat von: Beta-User am 11 Dezember 2017, 14:51:19

Im Ergebnis würde ich zwischenzeitlich sagen: Wenn du keine Heizkörper ansteuern willst, nimm nicht HM, die Geräteauswahl ist woanders besser. (Aber bitte: HM funktioniert auch, und anderswo sind die Dinge auch nicht perfekt, ich weiß es (nur) noch nicht...


Beta-User

Hard-Facts:
- Es gibt immer wieder Berichte über zweitklassige Kondensatoren, die von eQ-3 verbaut wurden (HM-Lan und diverse UP-Aktoren).
- Sicher ist HM BidCoS nur mit eingeschaltetem AES (ansonsten kann jeder Sender an alle Aktoren Anweisungen verteilen, der sich mit einer für die Installation geltenden ID als Zentrale ausgibt). Wie stark das Einschalten von AES das Funkbudget beeinträchtigt, weiß ich nicht (1%-Regel). Gefühlt laufen die meisten Installationen jedenfalls im wesentlichen ohne AES...
- Softwareupdates sind bei einzelnen Aktortypen ein Vabanquespiel (auch mit CCU, such mal im Homematicforum nach dem Rolladenaktor...)
- Manche Geräte müssen erst nachgearbeitet werden (konnte neulich erst nachlesen, wie man laute HK-Thermostate richtig schmiert),
(- bei HK-Thermostaten gibt es Leute, die sich über abgebrochene Kunststoffteile im Inneren ärgern)
(- keine Ahnung, ob das nur bei mir so ist, aber die Dreh-Fensterkontakte scheinen vergesslich zu werden, wenn die Batterien leer werden und man das nicht rechtzeitig merkt)

Soft-Facts:
- Die Preispolitik bei eQ-3 ist jedenfalls in den Randbereichen happig, die Qualität nicht immer der Preisklasse angemessen (Wetterstation mit Batterien?!? Warum kein Solarmodul + Supercap?)
- ich mag es nicht, von nur einem Hersteller abhängig zu sein (SuFu: Investitionsschutz)
- Geräteauswahl ist anderswo breiter (aber auch noch nicht vollständig), angefangen damit, dass ich einzelne Schalter ggf. Taster +2-Fachmodul getauscht habe, um Doppelschalter zu ersetzen.

Pro-HM:
- AskSin++
- Es tut im Wesentlichen schon wie es soll...
(- Der Umsatz wird im Inland gemacht)
(- Es gibt wenigstens Reparaturanleitungen für den meisten Murks)

Hoffe, das ist soweit nachvollziehbar,

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

NewMatic

wow danke für die ausführlichen pro und contras :)

was meinst mit (SuFu: Investitionsschutz) genau?

und was ist AskSkin? Ich hoffe ich blamiere mich jetzt nicht mit der Frage :D

Bzgl. Wetterstation... mit FHEM kann ich ja verschiedene System einbinden? Also kann ich ja die Wetterstation, die mir bei HM auch komplett überteuert vorkommt, mit einem anderen System einbinden und in FHEM sollte ich ja mit der Wetterstation von XY die Aktoren von HM arbeiten lassen?


Beta-User

#8
Ja, manches an +/- kann ich mir merken...

SuFu=Suchfunktion ;)

https://forum.fhem.de/index.php/topic,78109.msg712539.html
https://forum.fhem.de/index.php/topic,57486.msg718564.html

Das mit der Wetterstation stimmt, aber wenn es z.B. darum geht, die Jalousien oder eine Markise bei Sturm unabhängig von FHEM hochzufahren, ist ein direktes peering (HM-Sprech) besser. Bei sowas arbeite ich gerne mit teilautonomen Systemen, aber soviel drücke ich an ELV - FHEM sei Dank - nicht ab. Außerdem sind Dinge wie Böenwarner bei vielen gängigen Systemen nicht eingebaut (?).

Allerdings weiß ich auch nicht, ob es da z.B. heute schon bessere zwave-Geräte gibt.
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

NewMatic

Wow deine Links regen zum nachdenken an. Danke dafür.

Ja mit der teilautonomen Wetterstation, geb ich dir komplett recht.

Sollte jetzt wirklich HM "Classic" sterben, kann ich dann mit dem Raspberry und dem oben genannten Funkmodul auch HM IP ansprechen?
Hab im Forum schon gesucht, fand aber nur Artikel mit dem Lan adapter oder dem CUL Stick:
https://forum.fhem.de/index.php/topic,68796.0.html

Wenn das geht, kann man ja dank FHEM alt und neu zumindest über die Zentrale kommunizieren lassen.

NewMatic

Hier im Forum wird immer wieder die HM CCU2 genannt.
Das Funkmodul kann man dann auch als eine Art CCu2 sehen? Ist das richtig?

Beta-User

Also: Das Funkmodul ist "eigentich" dafür gedacht, eine Variante der CCU2 zu bauen, also Pi+Funkmodul+Software=CCU2-Variante.

Das geht auch auf dem selben Pi, Stichwort für die SuFu: YAHM (gibt wohl noch weitere Varianten). Wenn du eine (ggf. virtualisierte) CCU2 hast, kannst du auch HM-IP damit betreiben.

FHEM-perl-Modul zur Anbindung der HM-(IP)-Komponenten wäre dann nicht CUL_HM, sondern HMCCU.
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

NewMatic

also mit einer VCCU(2) kann ich dann sowohl HM-IP als auch HM "basic" betreiben?
Über den Begriff YAHM bin ich vorher schon mal gestolpert. Muss mich mal einlesen, danke für den Tip :)

Beta-User

Achtung, die Begriffe VCCU und CCU2 kommen aus völlig unterschiedlichen Welten:
VCCU ist ein CUL_HM-Begriff zu HM-BidCoS, CCU2 ist eQ-3 (und kann - anders als die alte Version 1 der CCU (die ein Fertiggerät war) - in der Tat alle Varianten von HM, auch wired). Die CCU2 gibt es als Fertiggerät oder eben nach der bereits beschriebenen Formel im Selberbau...
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

NewMatic