Umstieg von MAX! auf Homematic

Begonnen von Thyrador, 29 März 2019, 09:31:04

Vorheriges Thema - Nächstes Thema

Thyrador

Hallo ihr lieben.

Da ich nach meinem Umzug im letzten Jahr (110m²) eher unzufrieden mit der Leistung meines MAX!-Cubes (zum CUL umgeflashed; die originale Firmware war der absolute Mist und musste ja andauernd alles vergessen) war, überlege ich seit geraumer Zeit auf Homematic umzusteigen.

Mit dem Cube an sich bin ich sehr unzufrieden. Zum einen, wegen der bereits angesprochenen schlechten Leistung (immer wieder Funkabbrüche, dann ist der Cube angeblich nicht erreichbar für die Komponenten), die immer wieder auftritt und ziemlich nervt, zum anderen wegen der "dürftigen" Auswahl an entsprechenden Hardwarekomponenten, um die ich das System gern erweitern möchte.
Ursprünglich war nicht mehr als eine Heizungssteuerung mit Fensterkontakten gedacht. War auch kaum anders sinnvoll/notwendig, in meiner alten (deutlich kleineren) Wohnung.

Durch den Umzug aber wollte ich nun auch miteinander vernetzte Rauchmelder, (Haus-)"Türsteuerung", Heizungssteuerung, Fensterkontakte, Einheitliche Funkschalter, Rollladensteuerung, Steckdosenaktoren, Temperatur & Feuchtigkeitssensoren (außen, wie innen), Bewegungsmelder, Alarm in das System mit einbinden.
Da bietet Homematic natürlich wesentlich mehr Auswahl und ich kann hier nach Belieben auch erweitern, sofern notwendig.

Ich habe kein Problem damit, meine bisherige Hardware (MAX!-Cube zum CUL umgeflashed, 3 Heizkörperthermostate +, 2 Fensterkontakte, 2 Wandthermostate +) komplett zu ersetzen, bzw an einen Interessierten (natürlich günstiger) weiterzuverkaufen.

Was mich hierbei am meisten Interessiert, ist: für welche Variante zur Einbindung eurer Homematic-Geräte habt ihr euch entschieden?
Es gibt ja nun einige Ansätze, über verschiedene Module (CCU, HM-Mod, CUL, etc.). Ich möchte gern wissen, welche davon am zuverlässigsten und stabilsten funktioniert, insbesondere beim Gedanken an die Erweiterbarkeit und Funkstabilität.
Wichtig hierbei ist natürlich die Funkleistung, da es zwischen Zentrale und Empfänger auch gut mal ~15-20m + 2 tragende Wände dazwischen haben kann.Der aktuelle MAX!-Cube jedenfalls ist damit ganz gut überfordert.

Als Hardware dient mir aktuell ein RPi 3, bei Bedarf kann ich hier aber auch bessere Hardware, sofern notwendig, beisteuern.

Habt ihr noch Tipps für mich, was ich beachten sollte? Empfehlungen zur Hardware oder Punkte, wo ihr eventuell Probleme seht?
Lasst es mich bitte wissen :)

Vielen Dank im Voraus :)

willib

Ich hatte Probleme mit dem CUL. Bestimmte HM Komponenten ließen sich nicht pairen. Das RPI Modul ist die bessere Wahl wenn du nicht noch 433 Mhz Komponenten steurn willst. Bei 19€ für den Bausatz kannst du nicht viel falsch machen. Zur Reichweiten Verbeserung kannst du ein zweites Modul am LAN-TTL-Wandler betreiben.
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Am besten du richtest gleich eine VCCU ein.
Langfristig würde ich mich mit HM IP befassen da bei HM nicht mehr viel passsiert und ichvermute dass es ein Auslaufmodell ist. Das sollte aber mit obiger Hardware auch gehen.
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

Beta-User

Der CUL ist auch dann nicht die bessere Wahl, wenn man "nebenbei" 433MHz-Zeug steuern will. Zum einen ist das Umschalten nicht optimal (Stichwort: EEPROM), zum anderen die Antennenauslegung.

Aber davon mal ab @Thyrador: Dir ist schon klar, dass es auch ganz andere Anbieter mit ganz anderer Technik gibt?
Ein System ist oft einfacher zu verstehen, und HM-BidCoS ist auch nach meiner Erfahrung ok, aber vermutlich würde ich heute eher in zwave investieren. HM-IP (und eine CCU) kommt mir nicht ins Haus, und die Preispolitik des HM-Herstellers für "Nebengeräte" ist ...

Ist aber Ansichts- und Geschmackssache.
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

Thyrador

#3
Zitat von: willib am 29 März 2019, 10:26:26
Ich hatte Probleme mit dem CUL. Bestimmte HM Komponenten ließen sich nicht pairen.

Ein Grund mehr, den Cube endlich rauszuschmeißen :D

Zitat von: willib am 29 März 2019, 10:26:26
Das RPI Modul ist die bessere Wahl wenn du nicht noch 433 Mhz Komponenten steurn willst.

Das meiste wird zum Glück über die entsprechenden Bridges realisiert. 433 wird ja bei Homematic ja gar nicht bedient, oder?
Im Grunde will ich ja so viel, wie möglich, über dieselbe Schnittstelle/Frequenz/dasselbe Protokoll steuern, damit das ganze harmonisch bleibt.
Was käme denn auf der Frequenz in Frage?

Zitat von: willib am 29 März 2019, 10:26:26
Zur Reichweiten Verbeserung kannst du ein zweites Modul am LAN-TTL-Wandler betreiben.
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi

Ah, super. Da brauche ich dann ja quasi nur einen Lan-Anschluss, wo der "Extender" hin soll, korrekt? Die Steuerung übernimmt dann FHEM von alleine, oder muss ich hier die Geräte, die über den Extender erreicht werden sollen, mit dem Extender pairen? (Oder ist der einfach nur eine Antenne, die das Signal weiterreicht?)

Zitat von: willib am 29 März 2019, 10:26:26
Am besten du richtest gleich eine VCCU ein.

Das klappt direkt innerhalb von FHEM, bzw auf der selben Plattform? Die ist ja nur zum Steuern der IO-Devices gedacht, richtig?

Zitat von: willib am 29 März 2019, 10:26:26
Langfristig würde ich mich mit HM IP befassen da bei HM nicht mehr viel passsiert und ichvermute dass es ein Auslaufmodell ist. Das sollte aber mit obiger Hardware auch gehen.

War mir dabei unsicher, ob das mit FHEM so harmoniert/funktioniert. Hatte mal vor einer Weile gelesen, dass es damit wohl Probleme geben solle.
Und hatte da jetzt auch nicht groß weiter recherchiert, ob das sich inzwischen auf normalem Wege einbinden und nutzen lässt.


Zitat von: Beta-User am 29 März 2019, 11:07:55
Der CUL ist auch dann nicht die bessere Wahl, wenn man "nebenbei" 433MHz-Zeug steuern will. Zum einen ist das Umschalten nicht optimal (Stichwort: EEPROM), zum anderen die Antennenauslegung.

Aber davon mal ab @Thyrador: Dir ist schon klar, dass es auch ganz andere Anbieter mit ganz anderer Technik gibt?
Ein System ist oft einfacher zu verstehen, und HM-BidCoS ist auch nach meiner Erfahrung ok, aber vermutlich würde ich heute eher in zwave investieren. HM-IP (und eine CCU) kommt mir nicht ins Haus, und die Preispolitik des HM-Herstellers für "Nebengeräte" ist ...

Ist aber Ansichts- und Geschmackssache.

Das stimmt schon. Was den Preis angeht, schlackern mir da auch die Ohren. Bin natürlich für jede "bessere" oder vergleichbare Lösung offen, die sich entsprechend in FHEM einbinden und steuern lässt.
Ich hatte nur mit HM geliebäugelt, da das Produktportfolio meinen Bedarf im groben Abdeckt, das ganze eine Produktfamilie ist, die miteinander harmonieren sollte und eben oft genug von HM gesprochen wird, als "die Lösung, wenn es um Smarthome geht".

Eistee

Ich nutze den MapleCUN und betreibe damit MAX und Homematic Komponenten sowie 433MHz Komponenten in einer 130m² Dachgeschosswohnung (Rigips Wände).
Mit einem CUL oder weiteren MapleCUN kann man auch nahezu unendlich große Flächen abdecken falls eine größere Reichweite notwendig wird.

LG Alina

Beta-User

Zitat von: Thyrador am 29 März 2019, 11:17:22
Ich hatte nur mit HM geliebäugelt, da das Produktportfolio meinen Bedarf im groben Abdeckt, das ganze eine Produktfamilie ist, die miteinander harmonieren sollte und eben oft genug von HM gesprochen wird, als "die Lösung, wenn es um Smarthome geht".
...Alles hat seinen Preis. Aber dass HM hier "in aller Munde ist", hat zum einen damit zu tun, dass es hier viele User gibt, die Erfahrungen damit haben (und auch die "Mucken" ganz gut kennen), und zum anderen, weil es eben in Deutschland sehr verbreitet ist.
In anderen Ländern findet man das praktisch gar nicht, der Eindruck, es sei "die Lösung" kann also nicht uneingeschränkt zutreffend sein :P .

Ob man eine "one-for-all" Lösung braucht, ist Ansichtssache und zum Teil auch davon abhängig, wie die baulichen Gegebenheiten sind. Z.B. würde ich mir überlegen, ob es nicht in einem sehr gut isolierten Haus überhaupt Sinn macht, HK-Thermostate einzubauen...
Und wenn: ich fand den Gedanken, die dann direkt mit den Fensterkontakten zu koppeln ganz gut, zwischenzeitlich habe ich eine ganze Anzahl aber entkoppelt und mache das "virtuell" über FHEM (mit Verzögerung). Aber dazu mußte ich erst das "Vertrauen" in meinen Server aufbauen, dass das wirklich zuverlässig klappt (und ich nicht dauernd irgendwo nachbessern muß). Da FHEM aber wie eine 1 läuft, ist das kein Problem mehr...

Jeder wie er mag ;) .

@Eistee:
Wenn du die ZWave-Integration via MapleCUN hinbekommst, kannst du vielleicht deinen Kundenkreis erweitern...
Für HM ist ein MapleCUN ggf. v.a. dazu gut, das alte Pi-PCB daran zu betreiben. Aber ansonsten gelten eben für einen MaleCUN m.E. hinsichtlich HM-BidCoS dieselben Einschränkungen wie für einen "normalen" CUL, und es ist m.E. sehr unfair, hier einen anderen Eindruck zu erwecken!
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

Thyrador

Zitat von: Beta-User am 29 März 2019, 11:31:34
...Alles hat seinen Preis. Aber dass HM hier "in aller Munde ist", hat zum einen damit zu tun, dass es hier viele User gibt, die Erfahrungen damit haben (und auch die "Mucken" ganz gut kennen), und zum anderen, weil es eben in Deutschland sehr verbreitet ist.
In anderen Ländern findet man das praktisch gar nicht, der Eindruck, es sei "die Lösung" kann also nicht uneingeschränkt zutreffend sein :P .

Gut, wie es in anderen Ländern ausschaut, kann ich so nicht beurteilen. Ich stütze mich da tatsächlich eher auf die Erfahrungen/Empfehlungen aus dem deutschen Raum :D

Zitat von: Beta-User am 29 März 2019, 11:31:34
Ob man eine "one-for-all" Lösung braucht, ist Ansichtssache und zum Teil auch davon abhängig, wie die baulichen Gegebenheiten sind. Z.B. würde ich mir überlegen, ob es nicht in einem sehr gut isolierten Haus überhaupt Sinn macht, HK-Thermostate einzubauen...

Dachgeschoss, Altbau, Oberlichter. Im Winter merkt man ganz deutlich, wie hier die Wärme abzieht. Auch habe ich über Profile die Steuerung der Heizung je nach Anwesenheit/Urlaub/etc. handlen lassen, sodass ich meine Temperatur am Tag auf eine bestimmte Zahl konstant halten kann, trotz Lüften, etc, und nachts dann entsprechend abkühle.

Beta-User

OK, dann sind die bauligen Gegebenheiten schon so, dass regeln Sinn macht (wir hatten hier schon Neubauten mit FBH, da wollten die TE's minutengenaue Regelungen haben...).

Ansonsten scheint z.B. das hier eine Alternative in ZWave zu sein (in HM gibt es aktuell auch nur einen Typen...):
https://forum.fhem.de/index.php/topic,77598.0.html

Kann sein, dass es zwischenzeitlich noch mehr gibt, und sowas wie burst (beißt da FLIRS, glaube ich) nicht bei allen bekannt ist. Da das aber sowieso auf die Batterie geht und eine Heizung auch immer träge ist, wäre das ggf. m.E. verschmerzbar. Aber Profile usw. sollten eigentlich alle modernen Thermostate kennen.
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

Thyrador

Welche Vorteile von Z-Wave habe ich den gegenüber Homematic? (Außer der Verwendung von Hardware verschiedener Hersteller).
War die Vielfalt an Geräten bei HM nicht größer?

Klar, ich könnte dann auch zweigleisig fahren, aber mir wäre eine einheitliche Produktlinie da etwas lieber. Zumal mir die Thermostate von MAX! (optisch und Display) sehr zugesagt hatten, bei HM da sehr ähnlich sind.

Beta-User

Das war nur als Anregung gedacht, mach's wie du denkst...
Ich habe keine komplette Marktübersicht, bin mir aber ziemlich sicher, dass die Auswahl schon alleine wegen der sehr viel höheren Zahl der Anbieter größer ist.

ZWave bildet ein mesh-Netzwerk => idR. keine verteilten IO's notwendig.

Rudi scheint auch ZWave zu nutzen, krikan sowieso (Boris glaube ich auch), du wärst also auch nicht "allein"...
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

Thyrador

Da muss ich mich wohl doch nochmal schlauer machen. Aber erstmal danke für die Infos :)