Wie richtet man eine bestehende VCCU und 2 CCU2 Ergänzungen richtig ein?

Begonnen von Burny4600, 02 Januar 2026, 18:08:58

Vorheriges Thema - Nächstes Thema

Burny4600

Ich habe schon lange die VCCU mit mehreren HM-MOD-UART im Einsatz, dass bisher gute Dienste mit den BidCos Geräten leistet.
Nun bin ich genötigt HomeMatic-IP Geräte zu ergänzen. Dazu habe ich zwei Homematic-CCU2 Geräte vorgesehen um das gesamte Projekt mit FHEM und Homematic abzudecken.
Die CCU2-Geräte sind mit FHEM verknüpft. Es würde auch schon ein Import der IP-Geräte nach FHEM funktionieren. Auch Firmware-Updates erkennen die CCU2-Geräte für die Ergänzungen.
Bisher konnten mittels VCCU und HMTools die Verbindung zu den BidCos-Geräten entsprechend optimiert werden.

Wie richtet ich am besten die CCU2 Geräte mit der bestehenden VCCU ein, damit die IP-Geräte optimale Verbindungen zu FHEM haben?
Können die beiden CCUs miteinander kommunizieren, oder muss ich die Geräte an beiden CCUs für FHEM konfigurieren?
Würde eine Lastverteilung bzw. die Sende-Empfangsleistung entsprechend an die CCUs ersichtlich werden?
Wie gehe ich für die IP-Geräte Erweiterung richtig vor?
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

Beta-User

ZitatWie richtet ich am besten die CCU2 Geräte mit der bestehenden VCCU ein,
Einmal mehr: CUL_HM/VCCU und HMIP sind zwei (unvereinbare) Welten, man kann nicht zeitgleich dieselbe Hardware für beides nutzen.

HMIP kennt (eingeschränkt) Repeater-Geräte zur Reichweitenverbesserung.
Server: HP-elitedesk@Debian 13, 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

Burny4600

Wenn ich die IP-Geräte an der CCU2 anlege, über die CCU2 in FHEM einbinde, kann FHEM doch die Steuerung der IP-Geräte übernehmen.
Die IP-Schnittstelle der CCU2 arbeitet doch bidirektional mit FHEM.
Zumindest funktionierte das mit einem Testgerät.
War das nur Zufall?

Wenn ich beide CCU2 Geräte nicht wie die VCCU mit mehreren HM-MOD-UART in Einklang bringe wäre das nicht so schlimm. Die Aufteilung erfolgt dann manuell auf den CCUs. Die Aufteilung muss ich dann abschätzen, da ich keine Signalstärke zwischen CCU2 und IP-Geräte auf der CCU ersichtlich habe.

Was mir auch noch aufgefallen ist, ist FHEM erkennt nicht das z.B. für ein HM-ES-PMSW1-PL-DN-R1 Gerät ein Update vorliegt. Die CCUs aber sehr wohl.
Unter https://update.homematic.com/firmware/api/firmware/search/DEVICE wäre zwar ein Update für HM-ES-PMSW1-PL-DN-R1 verfügbar, wird aber unter FHEM nicht ausgewertet.
Das HM-ES-PMSW1-PL-DN-R1 Gerät hat die Firmware 2.5. Für ein Update steht eine 2.6 zur Verfügung.
list eQ3
Siehe Anhang.

Da passt unter FHEM mit der Update-Erkennung etwas nicht.
Ich habe mir das Aufgrund der fehlerhaften Update-Erkennung unter FHEM so vorgestellt. Wirklich alle bestehenden Homematic BidCos-Geräte auch zusätzlich auf den CCUs anzulegen, um auch alle letzten Updates auf die BidCos-Geräte zu übertragen. Die BidCos-Geräte auf den CCUs werden aber nicht nach FHEM importiert. Die IP-Geräte muss ich von den CCUs nach FHEM importieren, um diese auch auswerten bzw. steuern zu können.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

Ralli

Zitat von: Burny4600 am 03 Januar 2026, 08:51:39Wenn ich die IP-Geräte an der CCU2 anlege, über die CCU2 in FHEM einbinde, kann FHEM doch die Steuerung der IP-Geräte übernehmen.
Die IP-Schnittstelle der CCU2 arbeitet doch bidirektional mit FHEM.

Das kannst du so machen.

ZitatWenn ich beide CCU2 Geräte nicht wie die VCCU mit mehreren HM-MOD-UART in Einklang bringe wäre das nicht so schlimm. Die Aufteilung erfolgt dann manuell auf den CCUs. Die Aufteilung muss ich dann abschätzen, da ich keine Signalstärke zwischen CCU2 und IP-Geräte auf der CCU ersichtlich habe.

Ich würde auf keinen Fall mehrere CCUs nebeneinander betreiben. Da ist Chaos bspw. in Sachen CarrierSense vorprogrammiert. Was du machen kannst, ist in der Tat eine CCU für HmIP nehmen und die FHEM-VCCU für klassisches HM. Die Reichweitenverlängerung für HmIP funktioniert entweder über schaltbare HmIP-Steckdosen oder über einen (!!) HmIP-HAP.

Perspektivisch würde ich aber dann auch die jetzt über FHEM-VCCU eingebundenen klassischen HM-Geräte in die CCU überführen und daran, wenn tatsächlich überhaupt erforderlich, ggf. noch ein oder zwei Repeater für klassisches HM anbinden, damit es nur einen Chef im Ring gibt.
Gruß,
Ralli

Proxmox 9 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte OpenCCU (3.85.7.20251129) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Beta-User

Zitat von: Burny4600 am 03 Januar 2026, 08:51:39War das nur Zufall?
Natürlich nicht...

Zitat von: Burny4600 am 03 Januar 2026, 08:51:39Wenn ich beide CCU2 Geräte nicht wie die VCCU mit mehreren HM-MOD-UART in Einklang bringe wäre das nicht so schlimm. Die Aufteilung erfolgt dann manuell auf den CCUs. Die Aufteilung muss ich dann abschätzen, da ich keine Signalstärke zwischen CCU2 und IP-Geräte auf der CCU ersichtlich habe.
Nach meinem Verständnis würde ich nur eine CCU2 als "Master" anlegen. Die andere wäre dann entweder Reserve (ausreichend Repeater-fähige HMIP-Geräte vorausgesetzt), oder man kann die auch afaik umkonfigurieren, dass sie als IO von der anderen mit genutzt werden (für HM-BidCoS und HMIP). Für BidCoS musst du uU. irgend ein weiteres RPC-Ding konfigurieren...

Siehe auch, was Ralli geschrieben hat.

Grundsätzlich klingt dein Post, als hättest du die Funktionalitäten noch nicht verinnerlicht.

Was updates angeht: Solange alles funktioniert, ist das nicht so wichtig, und wenn man weiß, wo man die update-files her bekommt, kann man die auch via CUL_HM updaten.
Ständig alles zwischen den Welten umzuziehen, macht keinen Sinn. Wenn du dich für CCUx entschieden hast (was ich nie (!) machen würde, schon gleich nicht wegen HMIP-Geräten), dann ziehe mittelfristig alles dahin um...

Just my2ct.
Server: HP-elitedesk@Debian 13, 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

betateilchen

Um es in zwei Sätzen zusammenzufassen:

  • Eine HMIP "Zentrale" kann auch mit klassischen Homematic Geräten umgehen, umgekehrt geht das nicht.
  • Es gibt also technisch begründet normalerweise keinen Grund, dauerhaft beide Systeme in FHEM zu konfigurieren.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Burny4600

Wie wäre die beste Lösung HM-IP-Geräte in FHEM aufzunehmen.
Alles was unter FHEM jetzt ist, jetzt irgendwie umzuziehen wäre ein Wahnsinn.
Das sind über 100 BidCos Geräte die unter FHEM tadellos funktionieren. Aufgeteilt über mehrere große Bereiche mit 9 Pis und 5 HM-MOD-UART zur Flächenabdeckung. Abgesehen von der Software die unter FHEM läuft.
Homematic Geräte-Erweiterung gibt es nur mehr als IP-Geräte. Mir sind zwei Rauchmelder eingegangen. Beide sollten 10 Jahre laufen und waren aber schon nach 4 und 5 Jahren Betrieb mit den Batterien am Ende. Ersatz gibt es nur mehr als IP-Rauchmelder, oder ich tausche die Batterie aus. Nur das kann man vergessen. Bei einem der beiden Rauchmelder habe ich einen Batteriewechsel durchgeführt, die war aber auch schon nach 2 Jahren wieder leer. Somit kann ich die Rauchmelder alle wegwerfen, da diese auch mit neuen Batterien des gleichen Herstellers und gleichen Fabrikates bestückt, nach Ablauf der original Batterie plötzlich einen höheren Stromverbrauch haben.

Zurück zum eigentlichem Thema.
Ich habe mich mit den IP-Geräten erst seit es notwendig wurde beschäftigt. Ob ich jetzt eine CCU2 nehme oder etwas anderes um Homematic IP-Geräte zu verwenden ist eigentlich egal. Die beiden CCU2 haben nur ein paar Euro gekostet um mich mit den IP-Geräten zu beschäftigen, wie ich das jetzt am besten lösen kann.
Ich brauche jetzt Euren Ratschlag, wie ich die IP-Geräte am Besten für meine Gegebenheiten einbinde.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

Ralli

Ich habe dazu schon ein paar mal im Forum was geschrieben und auch andere haben dazu schon zig mal ihre Gedanken verschriftlicht.

Meine Empfehlung lautet, ein RPI-RF-MOD und ggf. ein HB-RF-ETH zu kaufen und mit einer virtualisierten CCU (OpenCCU) die HmIP-Geräte anzusteuern und über HMCCU in FHEM zu integrieren. Die beiden gekauften CCU2 könntest du umflashen bzw. umfkonfigurieren und als LAN-GWs als Reichweitenverlängerer für klassisches HM verwenden. Den Rest bitte recherchieren.

Und auch wenn es "Wahnsinn" ist, bleibt es bei der Empfehlung, alles HM in einem System zusammenzuführen, also letztendlich in der virtualisierten OpenCCU und diese Systemlandschaft dann mit FHEM zu integrieren. So habe ich es gemacht, und ich hatte (ganz viel) früher auch meine HM-Komponenten nativ in FHEM über CUL_HM bzw. VCCU.

Kleiner Edit: wenn du große Areale zu versorgen hast, solltest du bei deinen Migrations- und Transformationsüberlegungen auch mal ein paar Gedanken in Richtung der Wahl der richtigen (externen) Antennen "verschwenden". Bspw. nutze ich als Haupt-Antenne für das RPI-RF-MOD eine Groundplane direkt unter dem Dach, welche naiv geschrieben eine Art Kuppel über das Haus spannt.
Gruß,
Ralli

Proxmox 9 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte OpenCCU (3.85.7.20251129) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

tndx

Es spricht nichts dagegen, abgesehen davon, dass CCU2 längst abgekündigt ist und keine neuen Firmwares und Geräte-Updates erhält, meherere eigenständige CCU2-HmIP-Netze zu nutzen, die unter FHEM zusammengefasst werden. Vorteil: man braucht keine HAPs zur Reichweitenverlängerung, die durchaus ihre Tücken haben. Nachteil: erhöhter Konfigurationsaufwand (unterschiedliche WebUIs/Zentralen für unterschiedliche Geräte), keine Direktverknüpfungen zw. den Geräten der unterschiedlichen CCU2-Netze.

Burny4600

Gut, das muss ich mir noch anschauen mit CCU2 umflashen.

Die Platine HB-RF-ETH kann ich schon mal vergessen. Diese gibt es nirgends mehr.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

rabehd

Zitat von: Burny4600 am 03 Januar 2026, 14:27:47Die Platine HB-RF-ETH kann ich schon mal vergessen. Diese gibt es nirgends mehr.
Keine Ahnung wie Du suchst, aber
Zitat von: Ralli am 03 Januar 2026, 13:03:32Ich habe dazu schon ein paar mal im Forum was geschrieben und auch andere haben dazu schon zig mal ihre Gedanken verschriftlicht.
lässt mich was vermuten.
Wenn ich nach HB-RF-ETH suche, dann hat der erste Treffer das Teil an Lager.
https://smartkram.de/shop/diy-bausaetze/platine-hb-rf-eth/
Auch funktionierende Lösungen kann man hinterfragen.

Burny4600

ZitatWenn ich nach HB-RF-ETH suche, dann hat der erste Treffer das Teil an Lager.
https://smartkram.de/shop/diy-bausaetze/platine-hb-rf-eth/

Genau, wenn du diese Seite wählst, und das Produkt auswählst, und kaufen gehst, bekommst du
ZitatDieses Produkt ist leider nicht verfügbar. Bitte wähle eine andere Kombination.

Zumindest bekomme ich diese Meldung, egal welches der beiden Produkte ich mich entscheide.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess