Mit HomematicIP weiter machen

Begonnen von ronzo, 15 Oktober 2020, 12:40:30

Vorheriges Thema - Nächstes Thema

ronzo

Bis jetzt habe ich viele klassische Homematic-Sensoren und -Aktoren im Einsatz. Die Zukunft dürfte vermutlich aber HomematicIP gehören. Es macht vermutlich Sinn, neue Sensoren und Aktoren als HomematicIP-Geräte anzuschaffen.

Derzeit habe ich HmLanGws über das RaspberryPi-Aufsteckmodul HM-MOD-RPI-PCB im Einsatz. Soweit ich das verstanden habe, könnte ich das für HomematicIP auch verwenden (mit piVCCU). Ich kann also eines meiner LAN-Gateways abzweigen und es für piVCCU konfigurieren, richtig? Das dann gleich mit der CCU3 firmware (oder spricht was für die CCU2)? Dann hätte ich aber nur eine Instanz. So einfach wie mit den HmLanGws beim herkömmlichen Homematic wird's vermutlich nicht gehen...

Setzt ihr schon im großen Stil HomematicIP ein? Wenn ja, wie macht ihr das?

LG
Ronald

Beta-User

Zitat von: ronzo am 15 Oktober 2020, 12:40:30
Bis jetzt habe ich viele klassische Homematic-Sensoren und -Aktoren im Einsatz. Die Zukunft dürfte vermutlich aber HomematicIP gehören.
Die Zukunft bei eQ-3, ja.

Da aber HM-"Classic" und "HM-IP" sowieso getrennte Welten sind, die über eine CCUx (CCU2 ist dem Vernehmen nach einfach langsam und daher nicht mehr zu empfehlen) auch eigentlich nur indirekt miteinander kommunizieren, stellt sich die Frage, ob es denn ggf. auch andere Alternativen gibt, was den Anbieter angeht....

Von daher ist meine private Entscheidung eher die, künftig eher Z.* einzusetzen: Z-Wave tendenziell für "klassische Aktoren" (Rollläden und Jalousien, on/off-Geräte), ZigBee tendenziell für (dimmbare) Beleuchtung und Sensorik. Da kann ich wenigstens den Hersteller wechseln, wenn er mir auf den Zeiger geht oder kann zwischen mehreren Alternativen wählen...

(Einarbeiten muß man sich m.E. in alle neuen Welten, wenn man bisher CUL_HM genutzt hat).

Just my2ct.
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

ronzo

Zitat von: Beta-User am 15 Oktober 2020, 12:58:09
Die Zukunft bei eQ-3, ja.
...
Von daher ist meine private Entscheidung eher die, künftig eher Z.* einzusetzen: Z-Wave tendenziell für "klassische Aktoren" (Rollläden und Jalousien, on/off-Geräte), ZigBee tendenziell für (dimmbare) Beleuchtung und Sensorik. Da kann ich wenigstens den Hersteller wechseln, wenn er mir auf den Zeiger geht oder kann zwischen mehreren Alternativen wählen...

Danke für deine Antwort! Mir persönlich ist HmIP irgendwie nicht sonderlich sympathisch. Da ich ohnehin schon einen DeConz bei mir im Einsatz habe, werde ich mich hier mal schlau machen. Gibt es empfehlungen zu ZigBee-Dimmaktoren und -Tastern?

Beta-User

Zitat von: ronzo am 15 Oktober 2020, 13:39:59
Danke für deine Antwort! Mir persönlich ist HmIP irgendwie nicht sonderlich sympathisch.
Ich habe mich irgendwann so über die Preispolitik von eQ-3 bei HM geärgert, dass es mir gar nicht mehr speziell auf HmIP ankam. Aber dass da nur einzelne Aktoren Mesh machen, finde ich irgendwie "beschränkt" (es kann gute Gründe geben, Vorgaben für Mesh-Funktionalität zu machen, aber das herstellerseitig vorzugeben finde ich sch... Genauso wie es unverständlich ist, wieso ein Rollladenaktor nicht als Jalousieaktor konfiguriert werden kann. Usw. usf.).

ZitatDa ich ohnehin schon einen DeConz bei mir im Einsatz habe, werde ich mich hier mal schlau machen. Gibt es empfehlungen zu ZigBee-Dimmaktoren und -Tastern?
Kommt darauf an, was du genau suchst:

- Dimmer
Unterputz gibt es - afaik - was von Dresden Elektronik selbst, und diverse Baumarkt- (Paulmann?)-Varianten und tint. Ich habe bisher nur diverse "klassische" Leuchtmittel für E27 usw.. Aber generell einfach in die Kompabilitätsliste schauen oder eben "auf Risiko" kaufen - die ZigBee-Profile sind ja generisch und meistens dauert es nicht lange, bis neue/bisher noch nicht bekannte Hardware integriert ist.

- Taster
Es gibt zum einen auch Dimmereinsätze von Gira (?, u.a.?) mit passenden "Aufsteckern", ansonsten ist es mit Tasterintegration relativ mau. Am ehesten noch die "opple". Zu dem 6-er gibt es einen Thread, da sind weitere Links zu den Abmessungen usw. drin. Die originalen von Jung (und wohl noch einer "klassischen" Schalterserien-Fa.) sind dagegen technisch überholt und jedenfalls in der vorliegenden Version nicht gut (aber hübsch).
(Da fällt mir grade ein, dass man uU. die "kleinen mit den runden Ecken" vom gelben Möbelhaus vielleicht recht einfach als Basis für Bastellösungen hernehmen könnte...? Die sind jedenfalls recht klein).
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

bmaehr

Ich stehe greda vor einer ähnlichen Entscheidung... Für eine zweites Haus wollte ich anfangen Komponenten zu kaufen und bin überall nur noch über HomematicIP statt Homematic gestolpert.
Auch mir ist HomematicIP nicht sonderlich symphatisch.

- Die Auswahl bei Homematic / HomematicIP an Geräten ist schon gut - würde ich ungern vermissen.
- Die Preise sollte eher niedriger als höher sein.

So wie ich es verstanden habe gibt es also noch keine gute Alternative?

Beta-User

Zitat von: bmaehr am 02 November 2020, 22:41:35
So wie ich es verstanden habe gibt es also noch keine gute Alternative?

Was ist eine "gute Alternative"?

Meiner persönlichen Meinung nach ist HM-IP keine gute Alternative, aber kurz zusammengefaßt ist es halt schlicht und ergreifend so: DAS perfekte System gibt es nicht...
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

Sailor

Ein herzerfrischendes "Moin" vom achtern Diek.

Zitat von: Beta-User am 03 November 2020, 08:08:30
Was ist eine "gute Alternative"?

Eine gute Alternative ist aus meiner Sicht:
- eine robuste Hardware die nicht nach 12 bis 24 Monaten auseinander fällt bzw. den Geist aufgibt
- auf einem offenen Kommunikations-Standard (MQTT)
- einen Funkstandard ohne Begrenzung (1%-Regel bei 884MHz) beruht.
- halbwegs gut aussieht. (Wenn ich da an manche Rauchmelder denke fühlt man sich an Raumschiff Orion erinnert)

Aber ich fürchte, da kann mann lange suchen...


Zur Zeit habe ich ein homogenes Homematic System im Haus am Laufen.

Der Heizkörper-Stellaktor ist alles andere als ein mechanisch robustes Gerät.
Kurz dagegen kommen, fliegt der runde Stell-Deckel ab und der R6 wartet auch nur darauf, einen leichten mechanischen Stoß zu bekommen um das gesamte Gerät mit einem F12 ins Nirvana zu verabschieden.
https://forum.fhem.de/index.php?topic=64446.0

Die Unterputz - Aktoren halten sich nicht an die Norm und füllen die gesamte Standard - UP-Dose aus.
Das hat zur Folge, dass man keine zusätzlichen WAKO-Klemmen hinter den Aktor untergebracht bekommt.

Nebenbei: Die Preise steigen und steigen.
Irgendwann ist meine Schmerzgrenze erreicht und ich werde wechseln müssen.

Gruss
    Sailor

PS: Tut gut mal seinen Frust los zu schreiben...
******************************
Man wird immer besser...

ronzo

Würde HomematicIP mit einem Konzept wie den LAN-Gateways für Homematic funktionieren, hätte ich vermutlich schon einige IP-Komponenten. So finde ich das neue System aber einfach unattraktiv.

Zumindest habe ich durch Homematic löten gelernt. Etwas, was ich sonst vermutlich nie gemacht hätte... (nicht jeder SmartHome-interessierte Mensch ist Elektriker oder Elektrotechniker...)

Habe mittlerweile einige Steckdosen-Adapter und Beleuchtung mit Zigbee.

Christoph Morrison

#8
Zitat von: ronzo am 03 November 2020, 09:21:22
Würde HomematicIP mit einem Konzept wie den LAN-Gateways für Homematic funktionieren, hätte ich vermutlich schon einige IP-Komponenten. So finde ich das neue System aber einfach unattraktiv.

Was für ein Konzept meinst du? Die HmIP-HAP haben kürzlich ein Firmware-Update bekommen, mit dem man sie wie ein HMLANGW einsetzen kann. Ich hab mir gleich mal ein paar Silvercrest-gelabelte für etwa 15-20€ pro Stück besorgt, unschlagbar gegenüber den HMLANGW.

https://www.homematic-inside.de/blog/homematic-ip-access-point-hmip-hap-als-lan-router-auf-ccu3-installieren-und-anlernen

frank

Zitat von: Sailor am 03 November 2020, 09:10:03
Eine gute Alternative ist aus meiner Sicht:
- eine robuste Hardware die nicht nach 12 bis 24 Monaten auseinander fällt bzw. den Geist aufgibt
- auf einem offenen Kommunikations-Standard (MQTT)
- einen Funkstandard ohne Begrenzung (1%-Regel bei 884MHz) beruht.
- halbwegs gut aussieht. (Wenn ich da an manche Rauchmelder denke fühlt man sich an Raumschiff Orion erinnert)
im "normalen" betrieb sollte die 1%-regel keine probleme bereiten, denke ich.

mehr probleme gibt es, wenn es hier keine regeln gibt.
siehe wlan.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

ronzo

Zitat von: Christoph Morrison am 03 November 2020, 10:12:07
Was für ein Konzept meinst du? Die HmIP-HAP haben kürzlich ein Firmware-Update bekommen, mit dem man sie wie ein HMLANGW einsetzen kann. Ich hab mir gleich mal ein paar Silvercrest-gelabelte für etwa 15-20€ pro Stück besorgt, unschlagbar gegenüber den HMLANGW.

Ich hätte es gerne so simpel wie jetzt. Einfach ein HM-MOD-RPI-PCB zusammenlöten und unter Raspbian per Socat freigeben. Das Gefrickel für HmIP ist schon deutlich mehr Aufwand.

MadMax-FHEM

Zitat von: ronzo am 03 November 2020, 10:23:28
Ich hätte es gerne so simpel wie jetzt. Einfach ein HM-MOD-RPI-PCB zusammenlöten und unter Raspbian per Socat freigeben. Das Gefrickel für HmIP ist schon deutlich mehr Aufwand.

Warum so "teuer" und nicht einen ESP mit serial-Bridge (oder hinge der PI dann per LAN dran?)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

ronzo

Zitat von: MadMax-FHEM am 03 November 2020, 10:25:14
Warum so "teuer" und nicht einen ESP mit serial-Bridge (oder hinge der PI dann per LAN dran?)...

Gruß, Joachim

Raspberrys liegen hier rum wie Sand am Meer.... (Habe mir testweise so ein USR TCP232-Teil bestellt, liegt aber ungenutzt herum, da ich keine Ahnung habe was ich da abgesehen vom PCB noch alles zusätzlich benötige...) Habe 3 LAN-GWs auf dieser Basis, die alle per LAN angebunden sind.

frank

fang bloss nicht mit esp/wlan an.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MadMax-FHEM

#14
Naja, ob nun ein PI per WLAN oder ein ESP per WLAN ist wohl egal... ;)

Wie geschrieben, wenn per LAN, dann ein PI...

Und es sind ja nicht nur die Anschaffungskosten sondern auch der Betrieb...
...ein ESP ist schon deutlich genügsamer...

Aber: deine Stromrechnung... ;)

Zitat
USR TCP232
Wichtig ist halt, dass max. 3,3V kommen sowohl bei Versorgung als auch bei den Pegeln!
Ansonsten: Pegelwandler! (oder Widerstandsteiler)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)