Mittelfristige Migration von HM nach HMIP

Joker · 16 Januar 2020, 09:37:49

Hi,

ich betreibe seit mehreren Jahren eine einigermaßen große Installation von HM (Classic) Geräten (Raum-/Heizkörperthermostate, Fensterkontakte, Schaltaktoren, etc.).
Als IO-Device kommt ein HM-MOD-RPI-PCB auf einem Raspberry Pi zum Einsatz (auf dem auch FHEM läuft). Zur Reichweitenerweiterung nutze ich zwei weitere HM-MOD-RPI-PCB:
- eines an einem alten weiteren Pi via socat (kabelgebunden)
- eines an einem ESP8266 via esp-link (WLAN)
Alle IOs sind in eine VCCU eingebunden.

Für neue Geräte die ich in Zukunft kaufe (sei es wegen Ausfall eines alten Gerätes oder wegen Erweiterung) möchte ich nun auf HMIP setzen.
Ich möchte aber NICHT alles alte direkt migrieren, sondern vorerst paralllel betreiben.

Die Fragen:
1. Als sinnvolle Option erscheint mir einen weiteren RPI mit einem RPI-RF-MOD aufzusetzen mit piVCCU. Diesen binde ich mittels HMCCU an FHEM an, und betreibe neue HMIP Geräte darüber. Ggf. kann ich auch bestehende HM classic Geräte nach und nach migrieren, falls das sinnvoll sein sollte. Die nicht migrierten Geräte können aber jedenfalls ohne Probleme weiter laufen. Soweit richtig?
2. Wie verhält es sich mit den beiden HM-MOD-RPI-PCB die ich als Reichweitenerweiterung aktuell schon nutze? Können diese von der neuen piVCCU mitgenutzt werden? Werden diese nur von der alten Installtion genutzt? Kann es Probleme mit diesen geben?
3. Falls die bestehenden Geräte zur Reichweitenerweiterung nicht genutzt werden können, was sollte ich sinnvollerweise für die neue piVCCU als Reichweitenerweiterung nutzen?

MadMax-FHEM · 16 Januar 2020, 09:56:14

Zitat von: Joker am 16 Januar 2020, 09:37:49
Die Fragen:
1. Als sinnvolle Option erscheint mir einen weiteren RPI mit einem RPI-RF-MOD aufzusetzen mit piVCCU. Diesen binde ich mittels HMCCU an FHEM an, und betreibe neue HMIP Geräte darüber. Ggf. kann ich auch bestehende HM classic Geräte nach und nach migrieren, falls das sinnvoll sein sollte. Die nicht migrierten Geräte können aber jedenfalls ohne Probleme weiter laufen. Soweit richtig?

Ja und vermutlich die einzige Option (mal abgesehen von anderen Varianten eine CCU zu "bekommen"

).
Das gesteckte Modul auf dem PI kann entweder fhem ODER piVccu...

Zitat von: Joker am 16 Januar 2020, 09:37:49
2. Wie verhält es sich mit den beiden HM-MOD-RPI-PCB die ich als Reichweitenerweiterung aktuell schon nutze? Können diese von der neuen piVCCU mitgenutzt werden? Werden diese nur von der alten Installtion genutzt? Kann es Probleme mit diesen geben?

JEIN

NEIN.
Eine CCU (und damit auch piVccu) kennt "sowas" NICHT!
Da hilft dann wohl nur: bessere Antenne etc. ODER weitere CCUs verteilen (evtl. reicht für wenige Geräte ja eine piVccu auf Basis eines PI-ZeroW)
EDIT: oder LAN-Adapter siehe weiter unten...

Also: Nutzung NUR mit fhem!
EDIT: für die "Selbstbau-(W)LAN" Adapter gilt das aber (wohl)...

Zitat von: Joker am 16 Januar 2020, 09:37:49
3. Falls die bestehenden Geräte zur Reichweitenerweiterung nicht genutzt werden können, was sollte ich sinnvollerweise für die neue piVCCU als Reichweitenerweiterung nutzen?

Siehe 2.

Versuchen Funk zu verbessern oder eben (kleine) CCUs verteilen und dann eben zusätzlich in fhem mittels weiterer HMCCU-Instanzen...

Gruß, Joachim

Mitch · 16 Januar 2020, 10:06:38

Ich stand, bzw. stehe vor dem gleichen "Problem".

Ich habe mir auf meinem Server Debmatic installiert und in fhem nutze ich dazu HMCCU.
Also Funkmodul habe ich einen HmIP-RFUSB.
Funktioniert perfekt und der Aufwand ist sehr gering.

Theoretisch könnte die Debmatic auch alle HMs direkt übernehmen und an fhem weiter geben.

Beta-User · 16 Januar 2020, 10:19:00

Zitat von: MadMax-FHEM am 16 Januar 2020, 09:56:14
NEIN.
Eine CCU (und damit auch piVccu) kennt "sowas" NICHT!
Da hilft dann wohl nur: bessere Antenne etc. ODER weitere CCUs verteilen (evtl. reicht für wenige Geräte ja eine piVccu auf Basis eines PI-ZeroW)

Vermutlich sprechen jetzt zwei Blinde von Farbe, aber mMn. ist diese Aussage NICHT GANZ richtig. Zitat:

ZitatIn schwierigen Empfangslagen und auf sehr großen Arealen kann es vorkommen, dass die Funksignale der Homematic Zentrale CCU2 oder CCU3 weit entfernte Homematic Funkkomponenten nicht mehr sicher erreichen. Das Funk-LAN-Gateway ist hier die Lösung für eine höhere Betriebssicherheit.

Die "echten" CCUx-Geräte sollten (zumindest für "classic") schon immer weitere, entfernte IO's nutzen können.

Entsprechendes gilt vermutlich für die virtualisierten Vertreter.

Die eigentlich spannende Frage ist die: Gilt das auch für "vernetzwerkte" Pi-PCB's?
Vermutlich geht das wirklich nicht, weil das HM-LGW-O-TW-W-EU ein vollständiges Netzwerkgerät ist und eine andere Art der Kommunikation zwischen der CCU und dem LGW stattfindet als rein auf serieller Basis.

Reichweitenvergrößerung bei HM-IP läuft übrigens anders. Da gibt es einzelne Geräte, die als Router dienen (namentlich Zwischensteckdosen, vermutlich z.B. HMIP-PSM)...

Joker · 16 Januar 2020, 11:05:16

ZitatDie "echten" CCUx-Geräte sollten (zumindest für "classic") schon immer weitere, entfernte IO's nutzen können.

Entsprechendes gilt vermutlich für die virtualisierten Vertreter.

Das war eigentlich auch mein Verständnis. Gilt das vielleicht nur für HM classic? Mein Bedenken ging dahin, dass evtl. die virtualisierte CCU (ggf. wenn daran HM classic Geräte angelernt sind) auf die Idee kommen könnte, die Netzwerk-Pi-PCBs (die nach meinem Verständnis sowas wie LGWs sind) mit zu nutzen und sich mit FHEM irgendwie in die Quere kommen könnte.
Kann da wer was dazu sagen? Ich will nur ausschließen dass es Probleme geben könnte.

ZitatDie eigentlich spannende Frage ist die: Gilt das auch für "vernetzwerkte" Pi-PCB's?
Vermutlich geht das wirklich nicht, weil das HM-LGW-O-TW-W-EU ein vollständiges Netzwerkgerät ist und eine andere Art der Kommunikation zwischen der CCU und dem LGW stattfindet als rein auf serieller Basis.

Wäre, falls das so sein sollte, ein Argument dafür dass keine Probleme zu erwarten sind, da die piVCCU dann mit den Netzwerk-Pi-PCBs überhaupt nichts anfangen kann. Anderererseits dachte ich immer dass eine normale "echte" CCU2 die "vernetzwerkten" Pi-PCBs durchaus nutzen kann...?

Dass die Reichweitenerweiterung bei HMIP über Router geht war mir so jetzt neu. Wäre aber durchaus OK für mich, weil dann könnte man mit entsprechenden Geräten ja die Reichweite erweitern wenn nötig. Da ich vorerst nur wenige HMIP Geräte haben werden, ist das aber erstmal nicht wirklich relevant für mich.
Ich dachte beim Aufbau meiner CCU an sowas, damit sollte ich was die Reichweite angeht für die nächste Zeit sowieso safe sein.

Was die ganzen Möglichkeiten mit piVCCU, debmatic, Raspberrymatic etc angeht, habe ich keinen Durchblick, aber ich denke mal das gibt sich alles nicht wirklich was? piVCCU scheint mir am meisten gepflegt zu sein.

Beta-User · 16 Januar 2020, 11:21:55

Was die Einbindung von "entfernten" IO's angeht, meine ich mich dahingehend zu entsinnen, dass man die aktiv einbinden muß; ich bin jedenfalls ziemlich sicher, dass eine CCUx nicht einfach so FHEM irgendein IO "klaut"...

Grundsätzlich würde ich (mal abgesehen davon, dass mir HM-IP wegen des CCUx-Zwangs schon gar nicht ins Haus käme) dazu neigen, da ab jetzt "trial&error" walten zu lassen...
Also Einstieg in HM-IP, und dann mal sehen, wie das läuft. Testen, ob sich die "Netzwerk-PCB's" einbinden lassen, wenn nein: Erforderlichenfalls Zukauf von Router-Geräten und/oder "Modding" der CCU, wenn ja (und für HM-IP nutzbar): Umbau der betreffenden Segmente auf HMCCU-Module.

Es ist Funk, von daher geht zuviel Theorie eventuell an den praktischen Erfordernissen vorbei

.
Es gibt hier aber auch einen user, der die Details dazu sehr gut kennt (deimos (?)), der hat hier (mindestens) einen Thread laufen, in dem auch einiges zu den unterschiedlichen Schnittstellen und timing-Problemen usw. drin steht. Vielleicht suchst du den mal, schaust, was da schon steht, und den Rest kannst du dann da ggf. auch fragen

.

misux · 16 Januar 2020, 11:22:05

Zitat von: Mitch am 16 Januar 2020, 10:06:38
Ich stand, bzw. stehe vor dem gleichen "Problem".

Ich habe mir auf meinem Server Debmatic installiert und in fhem nutze ich dazu HMCCU.
Also Funkmodul habe ich einen HmIP-RFUSB.
Funktioniert perfekt und der Aufwand ist sehr gering.

Theoretisch könnte die Debmatic auch alle HMs direkt übernehmen und an fhem weiter geben.

Auf welchem Server hast du das DEBMATIC installiert?

Ich stehe mittelfristig auch vor dem Problem...

Meine Konfig: Raspi 3 mit HM-MOD-RPI-PCB

was bräuchte ich um soetwas mit Debmatic zu verwirklichen?

Beta-User · 16 Januar 2020, 11:32:55

Zitat von: Beta-User am 16 Januar 2020, 11:21:55
Es gibt hier aber auch einen user, der die Details dazu sehr gut kennt (deimos (?)),...

Kein eigener Thread, aber hier mal ein paar Links als Einstiegspunkte zur weiteren Vertiefung (in den Threads steht noch deutlich mehr zum selben Thema):
https://forum.fhem.de/index.php/topic,97295.msg905034.html#msg905034
https://forum.fhem.de/index.php/topic,77047.msg1008539.html#msg1008539

MadMax-FHEM · 16 Januar 2020, 12:30:48

Zitat von: Beta-User am 16 Januar 2020, 10:19:00
Vermutlich sprechen jetzt zwei Blinde von Farbe, aber mMn. ist diese Aussage NICHT GANZ richtig. Zitat:Die "echten" CCUx-Geräte sollten (zumindest für "classic") schon immer weitere, entfernte IO's nutzen können.

Entsprechendes gilt vermutlich für die virtualisierten Vertreter.

Die eigentlich spannende Frage ist die: Gilt das auch für "vernetzwerkte" Pi-PCB's?
Vermutlich geht das wirklich nicht, weil das HM-LGW-O-TW-W-EU ein vollständiges Netzwerkgerät ist und eine andere Art der Kommunikation zwischen der CCU und dem LGW stattfindet als rein auf serieller Basis.

Reichweitenvergrößerung bei HM-IP läuft übrigens anders. Da gibt es einzelne Geräte, die als Router dienen (namentlich Zwischensteckdosen, vermutlich z.B. HMIP-PSM)...

Jep, stimmt wohl, dann nehme ich das (teilweise

) zurück...

Allerdings sind das schon mächtige Kosten...
...und daher im Vergleich zu einer weiteren CCU (evtl. auf Basis eines ZeroW: wenn nur ein paar wenige Geräte außer Reichweite sind) nicht wirklich ein "Renner"

Gruß, Joachim

Beta-User · 16 Januar 2020, 12:38:32

Zitat von: MadMax-FHEM am 16 Januar 2020, 12:30:48
...und daher im Vergleich zu einer weiteren CCU (evtl. auf Basis eines ZeroW: wenn nur ein paar wenige Geräte außer Reichweite sind) nicht wirklich ein "Renner"

ZeroW ist evtl. ein gutes Stichwort. Ich zitiere mal aus einem der beiden verlinkten Beiträge von deimos:

Zitat von: deimos am 04 Januar 2020, 10:57:05
Es gibt auch Software, welche ein HM-MOD-RPI-PCB in ein (Fake) LAN GW verwandeln, aber das ist unabhängig von piVCCU.

Ich würde wetten, dass diese Art "Hack" auch mit einem ZeroW geht

. (ich hatte im Hinterkopf, dass man da eigentlich nur ein flag irgendwo in der Konfiguration der CCU-Software setzen muß; kann aber falsch sein).

(Da ist übrigens noch viel Raum für Wiki-Beitragsersteller-Neulinge, um diese Dinge mal irgendwie in eine anfängertaugliche Form zu bringen

. Ich melde mich mangels CCUx-Einsatzes mal dafür definitiv ab

).

Mitch · 16 Januar 2020, 13:16:23

Zitat von: misux am 16 Januar 2020, 11:22:05
Auf welchem Server hast du das DEBMATIC installiert?

Ich stehe mittelfristig auch vor dem Problem...

Meine Konfig: Raspi 3 mit HM-MOD-RPI-PCB

was bräuchte ich um soetwas mit Debmatic zu verwirklichen?

Läuft bei mir auf einem Atom Nettop mit Ubuntu.
Du brauchst nur einen Rechner mit Debian oder auf Debian basierendem OS. Sollte beim Raspi eigentlich passen.

misux · 16 Januar 2020, 14:20:22

Könnte man das alles auf einem Raspi 4 oder sogar PI3b laufen lassen? Ich meine HM, HMIP Fhem und debmatic?

MadMax-FHEM · 16 Januar 2020, 15:01:15

Zitat von: misux am 16 Januar 2020, 14:20:22
Könnte man das alles auf einem Raspi 4 oder sogar PI3b laufen lassen? Ich meine HM, HMIP Fhem und debmatic?

Pinzipiell: ja.

Also zumindest gibt es genügend Leute, die das so auf einem PI3 laufen haben.

Deshalb bzgl. PI4 (evtl. noch) etwas Vorsicht, da du da zwingend Buster brauchst und ich nicht weiß, ob da debmatic (schon) problemlos drauf läuft...

Und dann nat. aufpassen bzgl. Funkmodul.

Weil ein HMOD-PCB halt nur entweder fhem oder debmatic kann...

Evtl. für fhem einen per USB/LAN/WLAN...

Allerdings weiß ich nicht, ob das schon probiert wurde.
Meistens wird dann der Teil fhem und CUL_HM (direkte Anbindung HM-BidCos) auch auf die CCU/debmatic "umgezogen"...

Evtl. eh ratsam, da dann alles "einheitlich" ist bzgl. weiterer Verwendung: Readings, Events, ...

Homematic Devices "sehen" per CUL_HM anders aus als per HMCCU...

Gruß, Joachim

misux · 16 Januar 2020, 15:17:06

hmm... habe im Netz etwas gefunden was vielversprechend läuft.

https://technikkram.net/2019/07/debmatic-installation-und-umstieg-homematic-auf-den-neuen-raspberry-pi4

Aber wenn es stabil und Vernünftig auf dem PI3 läuft, dann wäre das die einfachere, günstigere Alternative...

zap · 16 Januar 2020, 18:01:06

Zitat von: Joker am 16 Januar 2020, 09:37:49

1. Als sinnvolle Option erscheint mir einen weiteren RPI mit einem RPI-RF-MOD aufzusetzen mit piVCCU. Diesen binde ich mittels HMCCU an FHEM an, und betreibe neue HMIP Geräte darüber. Ggf. kann ich auch bestehende HM classic Geräte nach und nach migrieren, falls das sinnvoll sein sollte. Die nicht migrierten Geräte können aber jedenfalls ohne Probleme weiter laufen. Soweit richtig?

Wenn Du sowieso einen dedizierten Raspi aufsetzt (finde ich die beste Option), kannst Du Dir ja mal das "Charly" Set von EQ-3 anschauen. Das ist ein Raspi mit passendem Funkmodul. Darauf packst Du Rasperrymatic und läuft. Nachteil: Raspberrymatic ist ein eigener root build, heißt: Das Ding ist mehr oder weniger exklusiv für Rasperrymatic. Du kannst da also (ohne das selbst zu bauen) kein Perl oder so installieren.

piVCCU würde ich empfehlen, wenn Du die CCU parallel zu FHEM auf dem gleichen PI haben willst. Nachteil von der Variante: Das korrekte Verhalten beim Starten einzurichten ist etwas tricky, da FHEM wesentlich schneller startet als die CCU. FHEM muss also auf die CCU warten => kann problematisch sein.

Debmatic wiederum bietet sich ebenfalls für dedizierte Rechner an.