Verständnisfrage HomematicIP

[JudgeDredd]

Hallo Zusammen,

ich habe mit FHEm schon durchaus das Eine oder Andere bewerkstelligt und auch Lösungen gefunden.
Allerdings fehlt mir zur Zeit noch der "Durchblick" im Homematic-Universum. Speziell die IP Variante.

Da ich mittelfristig gerne meine HomematicRF Komponenten durch HomematicIP ersetzen möchte.

Gelesen habe ich viel (vielleicht zuviel) und auch schon eine Menge Begriffe aufgeschnappt (CCU(1)(2)(3); RaspberryMatic; VCCU; piVCCU; debMatic; hmIP-WLAN-HAP und was weiß ich noch nicht alles).
Mein größtes Problem ist aber (glaube ich), zu Verstehen, was ist Hardware und was ist Software. Das geht aus den meisten Beiträgen für mich nicht ganz klar hervor.

Eine kleine Übersicht meiner HomematicRF-Welt habe ich mal als Diagramm angehängt.

Vielleicht ist ja Jemand (oder gleich mehrere  ) so freundlich und kann mir helfen meine Gedanken zu sortieren.

Wie man auf dem Diagramm sieht, setze ich zur Zeit 3 x HM-UART-LGW ein um alle meine Sensoren/Aktoren zu erreichen.

Das Zielbild sollte im großen und ganzen ähnlich sein. Evtl. kann ich noch ein Zugangspunkt durch bessere Positionierung einsparen, aber 2 müssten es mindestens sein.
Da FHEM in einer VM auf einem Host im Metall-Serverschrank läuft, scheiden dort angeschlossene Funkmodule wohl leider aus.

• Was für Software (Module) sind in FHEM erforderlich ?
  
• Welche Software ist auf der VM notwendig ?
• Welche Hardware/Software muss ich an den Sende-/Empfangspunkten einsetzen ?

um erfolgreich Homematic einzusetzen.

Ebenso bin ich mir noch nicht ganz sicher, was mit wem und wie gepairt werden muss.
Allerdings wird diese Frage erst akut, wenn ich Eure (hoffentlich zahlreichen) Vorschläge/Antworten verstanden und umgesetzt habe.

Gruß,
JudgeDredd

[Beta-User]

Was fehlt dir in https://forum.fhem.de/index.php/topic,116424.0.html (angepinnt)?

Du brauchst für HM-IP also eine (ggf. virtualisierte) CCUx mit (mindestens) einem (!) passenden Funkmodul, wobei dem Vernehmen nach dafür zwischenzeitlich auch ein IP-USB-Stick in Frage kommt, um "alte" (BidCoS-) Komponenten anzusteuern. Die bindest du dann mit den HMCCU.*-Modulen in FHEM ein. Der AP ist afaik nicht geeignet, und einfach nur "ein dummes Interface" abzusetzen, wie es bei BidCoS (oder ZWave,...) geht (an ESP8266 etc.), funktioniert mit HM-IP nicht, da das extremst timing-kritisch ist.

HM-IP arbeitet dabei nicht mit "abgesetzten Interfaces", sondern ein Teil der dauerbestromten Komponenten kann als Repeater genutzt werden. Ob mehrere Interfaces (für IP) möglich sind, kann ich aber auf die Schnelle auch nicht sagen.

[tndx]

HM-IP arbeitet dabei nicht mit "abgesetzten Interfaces", sondern ein Teil der dauerbestromten Komponenten kann als Repeater genutzt werden. Ob mehrere Interfaces (für IP) möglich sind, kann ich aber auf die Schnelle auch nicht sagen.

Naja, der HmIP-RFUSB an einer USB-Verlängerung ist ja auch schon abgesetzt. Daneben gibt es noch weitere Möglichkeiten, die GPIO-Funkmodule per USB oder LAN abzusetzen (WLAN kommt bei HmIP wg. strenger Timing-Vorgaben nicht in Frage). Steht aber auch im verlinkten Beitrag oder ist zumindest verlinkt, meine ich.

Parallel dazu können für BidCos wie gehabt die Funk-LAN-Gateways, für HmIP die HmIP Access Point als Reichweitenverlängerung eingesetzt werden.

[JudgeDredd]

Du brauchst für HM-IP also eine (ggf. virtualisierte) CCUx mit (mindestens) einem (!) passenden Funkmodul ...

Wenn ich den Satz mal etwas reduziere, würde es also bedeuten, bei den CCUx sind keine Funkmodule enthalten ?

Der AP ist afaik nicht geeignet, und einfach nur "ein dummes Interface" abzusetzen, wie es bei BidCoS (oder ZWave,...) geht (an ESP8266 etc.), funktioniert mit HM-IP nicht, da das extremst timing-kritisch ist.

Ja, gelesen hatte ich, das der AP nur in einem HomaticIP-only Szenario sinnvoll ist.

HM-IP arbeitet dabei nicht mit "abgesetzten Interfaces", sondern ein Teil der dauerbestromten Komponenten kann als Repeater genutzt werden.

OK, das ist natürlich ein gravierender Nachteil (bei mir), da ich keinerlei HomematicIP dauerbestromte Devices einsetze.
Bei mir beschränkt es sich ausschließlich auf Tür-/Fensterkontakte. Die ich gerade wegen der Stromunabhängigkeit verwende.

Ob mehrere Interfaces (für IP) möglich sind, kann ich aber auf die Schnelle auch nicht sagen.

Du bist Dir also nicht sicher, ob ich theoretisch mehrere CCUx + Funkmodule parallel betreiben kann ?
Schade, ich hatte mir genau diesen Weg als Möglichkeit auserkoren.

Vielleicht gibt es ja doch Jemand, der HomematicIP mit mehreren Funkmodulen im Einsatz hat.

[Beta-User]

Wenn ich den Satz mal etwas reduziere, würde es also bedeuten, bei den CCUx sind keine Funkmodule enthalten ?

Nope. Eine CCU3 ist nichts anderes als ein teuerer Pi mit einem darauf aufgesteckten Funkmodul mit eigenem OS, mit dem man sonst nichts anfangen kann...

Man kann genausogut die Hardware-Anteile separat kaufen und ein "normales" Linux draufpacken, und dann eine virtualisierte CCU und z.B. FHEM darauf betreiben.

Steht doch genau so in dem anderen Thread...

Ja, gelesen hatte ich, das der AP nur in einem HomaticIP-only Szenario sinnvoll ist.

Wieder Nope. Das Ding taugt ggf. zur Reichweitenverlängerung für HM-IP, als standalone-Lösung ist er für FHEM mehr oder weniger unbrauchbar, ganz gleich, ob wir über BidCoS oder HM-IP reden.

OK, das ist natürlich ein gravierender Nachteil (bei mir), da ich keinerlei HomematicIP dauerbestromte Devices einsetze.
Bei mir beschränkt es sich ausschließlich auf Tür-/Fensterkontakte. Die ich gerade wegen der Stromunabhängigkeit verwende.
Du bist Dir also nicht sicher, ob ich theoretisch mehrere CCUx + Funkmodule parallel betreiben kann ?
Schade, ich hatte mir genau diesen Weg als Möglichkeit auserkoren.

Zu "abgesetztes IO" siehe die Anmerkung zu dem AP, und selbstredend kann man mehrere CCU parallel betreiben. Ob das jeweils sinnvoll ist, steht auf einem anderen Blatt...

Vielleicht gibt es ja doch Jemand, der HomematicIP mit mehreren Funkmodulen im Einsatz hat.

Siehe die Anmerkung von tndx...

[JudgeDredd]

Danke erstmal für die Antworten, aber so wahnsinnig viel deutlicher als vorher ist es leider noch immer nicht geworden (liegt aber bestimtm an mir).

Eine CCU3 ist nichts anderes als ein teuerer Pi mit einem darauf aufgesteckten Funkmodul mit eigenem OS, mit dem man sonst nichts anfangen kann...
Zu "abgesetztes IO" siehe die Anmerkung zu dem AP, und selbstredend kann man mehrere CCU parallel betreiben. Ob das jeweils sinnvoll ist, steht auf einem anderen Blatt...

Dies würde also bedeuten, das ich meine 3 HM-UART-LGW ersetzen könnte durch:

• 3 x CCUx
• 3 x RPI + Funkmodul

Dann müsste ich aber alle Homematic-Devices mit einem Zugangspunkt fest pairen und es würde nicht automatisch bei Ausfall oder schlechtem Empfang der nächste Zugangspunkt gewählt (wie es bisher der Fall ist) ?

Wo allerdings dieser hmIP-WLAN-HAP da irgendwie ins Spiel kommen könnte, verstehe ich überhaupt nicht.
Wie wird dieser angeschlossen und wer kommuniziert da mit wem und was ?

Um mal ein kleinen Blick aufs monitäre zu werfen:
- Die CCU3 wird aktuell zu ~150 EUR angeboten und würde keine weiteren Funkmodule benötigen
- Ein RPI3b+ (sofern verfügbar) ~50 EUR + HM-MOD-RPI-PCB ~20 EUR + Gehäuse, Netzteil, SD-Card ~50 EUR == ~120 EUR (Summe)

Da ich meine LAN-Dosen direkt in die weiße Decke integriert habe, würde sich die CCU3 optisch dort am besten einfügen, bei "nur" ~30 EUR Preisvorteil
würde ich das für den Schönheitfaktor in Kauf nehmen.

Sicherlich "könnte" man auf einem Raspberry noch mehr machen, aber da meine IT sowieso komplett im Keller wohnt, würde ich das aber sowieso nicht nutzen.
Der einzigste Vorteil eines RPI ggü. der CCUx wäre (für mich) das der RPI mittels WLAN mit FHEM (HMCCU) kommunizieren könnte, aber davon wird ja aus zeitkritischen Gründen dringen abgeraten.

Sehe ich das nun richtig, oder sind da schon wieder ein paar "Nope" dabei ?

[MadMax-FHEM]

Dann müsste ich aber alle Homematic-Devices mit einem Zugangspunkt fest pairen und es würde nicht automatisch bei Ausfall oder schlechtem Empfang der nächste Zugangspunkt gewählt (wie es bisher der Fall ist) ?

Genau.
Ein Gerät kann nur mit EINER Zentralen verbunden werden.

Bei CUL_HM sorgt die Imlementierung seitens fhem (vccu) dafür, dass mehrere Funkmodule unter derselben HMID (=Zentralenkennung) funken.

EDIT: für das Gerät ist quasi jedes (verteilte) Funkmodul die EINE Zentrale

Der einzigste Vorteil eines RPI ggü. der CCUx wäre (für mich) das der RPI mittels WLAN mit FHEM (HMCCU) kommunizieren könnte, aber davon wird ja aus zeitkritischen Gründen dringen abgeraten.

Es gibt bzgl. fhem keinen Unterschied zwischen einer "echten" CCUx und einem PI mit Funkmodul und CCU-Software (debMatic, piVCCU, ...).
Beides wird mittels HMCCU eingebunden...

EDIT: kann die CCUx kein WLAN? Gut, dann wäre das ein/der Unterschied... Und aufpassen bzw. nicht verwechseln: abgesetztes Funkmodul (und zwar NUR Funkmodul) also beipielsweise HMOD-PCB an ESP32/ESP8266 per WLAN ist schlecht, da ja der Telegrammverkehr (zum Großteil) "durch fhem" muss und damit auch über den WLAN-Kanal -> Timing zwischen Zentrale und Gerät. Eine CCUx per WLAN ist nicht so kritisch, da ja die CCUx direkt per eigenem Funkmodul mit dem/den Geräten kommuniziert und nur die "Ergebnisse" bzw. der aktuelle "Zustand" der Geräte etc. an fhem übermittelt wird bzw. die "Wünsche" (neue Einstellungen etc.) von fhem an die CCUx gehen (und nicht direkt ans Gerät). Dort mag es auch Verzögerungen geben aber die sind bzgl. der Gerätekommunikation unkritisch, evtl. nur für Automtisierungen merklich/relevant.

Gruß, Joachim

[Beta-User]

Dies würde also bedeuten, das ich meine 3 HM-UART-LGW ersetzen könnte durch:

   
• 3 x CCUx
• 3 x RPI + Funkmodul

Dann müsste ich aber alle Homematic-Devices mit einem Zugangspunkt fest pairen und es würde nicht automatisch bei Ausfall oder schlechtem Empfang der nächste Zugangspunkt gewählt (wie es bisher der Fall ist) ?

Falls das als "oder" zu deuten wäre: Prinzipiell ja, aber wie du selbst schreibst: Das ist nicht die optimale Lösung...

Wo allerdings dieser hmIP-WLAN-HAP da irgendwie ins Spiel kommen könnte, verstehe ich überhaupt nicht.
Wie wird dieser angeschlossen und wer kommuniziert da mit wem und was ?

Nochmal: Wenn du ein (ausfallsichereres) System aufbauen willst, mit nur einer Zentrale (CCUx), kannst du den HM-IP-WLAN-HAP vielleicht als Routergerät einsetzen, um damit die FUNK-Reichweite deiner Zentrale zu verbessern. Du könntest dasselbe Ergebnis erreichen, wenn du an zwei passenden Punkten ein ANDERES Router-fähiges HM-IP-Gerät (afaik ginge das mind. mit Zwischensteckdosen) einbaust. Die können aber afaik NUR HM-IP, so dass du ggf. überlegen müßtest, wann du wo was gegen HM-IP tauschen willst, um nicht zusätzlich auch noch die bisherigen HM-UART-LGW zu benötigen...

Der einzigste Vorteil eines RPI ggü. der CCUx wäre (für mich) das der RPI mittels WLAN mit FHEM (HMCCU) kommunizieren könnte, aber davon wird ja aus zeitkritischen Gründen dringen abgeraten.

Na ja, zu WLAN allgemein kann man stehen wie man will, aber falls damit gemeint sein sollte, dass es ein Problem darstellen könnte, ein INTELIGENTES IO-Modul irgendwo abzusetzen: eher nicht (wenn das WLAN nicht allgemein wackelig ist). Denn der zeitkritische Teil läuft da AUF dem Gerät...

Sehe ich das nun richtig, oder sind da schon wieder ein paar "Nope" dabei ?

Mach dir selbst einen Reim darauf.

Genau.
Ein Gerät kann nur mit EINER Zentralen verbunden werden.

Bei CUL_HM sorgt die Imlementierung seitens fhem (vccu) dafür, dass mehrere Funkmodule unter derselben HMID (=Zentralenkennung) funken.

EDIT: für das Gerät ist quasi jedes (verteilte) Funkmodul die EINE Zentrale

Das gilt im übrigen bzgl. BidCoS auch dann, wenn man eine "echte" CCUx mit weiteren abgesetzten Funkmodulen betreibt...


Meine Schlussfolgerung aus dem Ganzen Hackel mit eQ-3 (auch was Qualität iVm. Preispolitik angeht) war, dass ich neue Geräte in der Regel nur noch in ZWave oder ZigBee kaufe...

[MadMax-FHEM]

Das gilt im übrigen bzgl. BidCoS auch dann, wenn man eine "echte" CCUx mit weiteren abgesetzten Funkmodulen betreibt...

Jep, darum ja der Hinweis auf CUL_HM (=fhem Implementierung) und VCCU
Aber so ist es deutlicher...

Meine Schlussfolgerung aus dem Ganzen Hackel mit eQ-3 (auch was Qualität iVm. Preispolitik angeht) war, dass ich neue Geräte in der Regel nur noch in ZWave oder ZigBee kaufe...

Sehe ich ähnlich.
Bzw. wird meine Erweiterung (vermutlich) auch nicht mit HMIP erfolgen...

Bzgl. Heizthermostate bin ich halt (leider) noch "ratlos"...
...schaue/lese halt so mit und hoffe, dass meine Homematic Classic noch recht lange halten...

Gruß, Joachim

[fiedel]

Hallo zusammen,

bei mir sieht es ähnlich aus: HMIP ist kein Thema, obwohl ich es sehr, sehr gern einsetzten würde.

Es müsste "einfach nur" das Protokoll direkt in FHEM zur Verfügung stehen wie bei HM ohne IP.
Könnte sich diesbezüglich der FHEM- Verein nicht mal mit Herrn Redeker in Verbindung setzen?
Seine Firmen EQ3 und ELV könnten davon nur profitieren denke ich.

Gruß
Frank

[Beta-User]

Es müsste "einfach nur" das Protokoll direkt in FHEM zur Verfügung stehen wie bei HM ohne IP.

Na ja, auch in dem Fall ist es ja nicht so, dass die Firma das Protokoll offengelegt hätte. Es waren afaik ein paar Enthusiasten, die per reverse-engineering rausgefunden haben, wie man per CUL und über die "offiziellen" Funk-Schnittstellen vorgehen muss, um das ohne die von der Fa. vorgesehene Zentrale nutzen zu können.

Die werden ihre Gründe haben, warum z.B. auch die ganzen BidCoS-Bausätze aus dem Programm fallen (bei denen könnte man ja annehmen, dass die Kundschaft um die (Sicherheits-) Grenzen des Protokolls weiß, und auch der Vertrieb "besserer" Teil-Komponenten könnte bei den bekannt problematischen Stellen stressfrei eingepflegt werden), und alles auf ein weiteres proprietäres Protokoll "einnorden" wollen.

Vielleicht hilft ja ein "offizieller" Appell, aber mir fehlt da ein bißchen der Glaube, dass es was bewirkt, zumal ja der "Doppelbetrieb" FHEM/HM-IP via Debmatic etc. ohne weiteres auf einer Hardware möglich ist.

Na ja, angesichts der Tatsache, dass FHEM superstabil läuft, habe ich auch keine großen Skrupel, die Wochenprofil-Geschichte mittelfristig an FHEM+ZWave zu übergeben... (Zur Stabilität der CCU habe ich noch die Beiträge von Baden-Power im Ohr... Viele bekannte Bugs, die nicht wahrgenommen/behoben werden).

[frank]

der aktuelle trend ist hmip devices auf bidcos umflashen. 

[MadMax-FHEM]

der aktuelle trend ist hmip devices auf bidcos umflashen. 

Jetzt bin ich aber neugierig!

Davon habe ich noch nichts mitbekommen

Gruß, Joachim

[Beta-User]

der aktuelle trend ist hmip devices auf bidcos umflashen. 

LOL. Gibt's dazu einen Link?

(Es ist ja nicht so, dass alles "schlecht" ist; z.B. für die Drehgriffsensoren gibt es afaik keine ernsthafte (Kauf-) Alternative; wobei die alten auch "zickig" sind!).

[frank]

Gibt's dazu einen Link?

https://homematic-forum.de/forum/viewtopic.php?f=76&t=74413&sid=628343b9df2fbff774dc1b1c3fb2c2e6#p720224