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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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/ (https://smartkram.de/shop/diy-bausaetze/platine-hb-rf-eth/)
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.
OK, soweit bin ich nicht gegangen.
Das wirft kein gutes Zeichen auf den Webshop.
Zitat von: Ralli am 03 Januar 2026, 13:03:32Meine 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.
Dass sieht mir nach der aktuell besseren Lösung aus.
Die CCU2 auf LAN-Gateway umrüsten ist kein Thema. Auch die RPI-RF-MOD ist eine günstige Alternative und Pi ist vorhanden. OpenCCU wird nach wie vor gepflegt.
Dann werde ich diese Lösung in den nächsten Tagen starten.
Zitat von: Burny4600 am 04 Januar 2026, 07:45:48Dass sieht mir nach der aktuell besseren Lösung aus.
Das ist in der Tat eine bessere Lösung, als die von dir zuerst angedachte Lösung mit mehreren CCU2. Aber bedenke, dass wenn du für deine HM-Classic-Installation 5 IOs brauchst und deine HmIP-Installation ähnlich weitläufig sein wird, brauchst du auch dafür eine ähnliche Anzahl der Reichweitenverlängerer. Das funktioniert bei HmIP aber nicht mit denselben IOs wie bei HM-Classic, sondern dafür brauchst du HmIP Access Points (HAP) und/oder HmIP-Geräte mit Routing-Funktionalität, z.B. schaltbare HmIP-Steckdosen.
Zitat von: tndx am 04 Januar 2026, 09:25:19Das funktioniert bei HmIP aber nicht mit denselben IOs wie bei HM-Classic, sondern dafür brauchst du HmIP Access Points (HAP) und/oder HmIP-Geräte mit Routing-Funktionalität, z.B. schaltbare HmIP-Steckdosen.
Das habe ich schon mitbekommen. Das wäre schön wenn das auch mit den HM-IP Geräten so funktioniert hätte.
Ich ergänze die defekten BidCos-Geräte aus anderen Bereichen, um sowohl die BidCos als auch die HM-IP Geräte als zusammengefassten Bereich zu definieren. Dort wo jetzt ein Tausch zu den HP-IP Geräten erfolgt wird das ohne HmIP-Access-Points mit Sicherheit funktionieren. Sollten es mehr HM-IP Geräte später einmal werden, steht auch eine Antennenlösung im Raum um die Fläche abzudecken.
Aber eins nach dem anderen.
Jetzt habe ich zumindest eine Lösung für den BidCos Geräte Schwund.
Danke für Eure Tipps.
Überhaupt einmal
EIN SCHÖNES, ERFOLGREICHES NEUES JAHR EUCH ALLEN.
Ohne dich jetzt noch einmal von dem in meinen Augen gut zu gehenden Weg abbringen zu wollen:
Solltest du dich perspektivisch für eine ganz andere Lösung interessieren, die zwar ähnlich proprietär aber in Sachen Funk viel robuster ist, dann schau dir mal free@home von ABB bzw. Busch Jäger an. Die haben sowohl wired als auch wireless und sowohl Aktoren für die Hutschiene als auch für Installationsdosen inkl. Kombination mit in Schalterprogramme zu integrierende Wippen. Auch für dieses System wird eine Zentrale, ein SysAP (System-Access-Point aktuell in Version 3) benötigt. Der große Vorteil im Funk-Bereich liegt darin, dass im 2,4GHz-Bereich gefunkt wird, also kein Duty-Cycle, und außerdem ein Mesh-Netz aufgebaut/genutzt wird.
Ich trage mich aktuell mit dem Gedanken, bei zunehmenden Aktor-/Sensor-Defekten von HM vor allem aufgrund der zu integrierenden Bedien-Displays auch auf free@home zu setzen - ich nutze aktuell ein HM-OU-LED16 für die Darstellung von Fenster-Zuständen etc und wenn das defekt ist, gibt es m.E. keinen adäquaten Ersatz. Fremd-Aktoren und -Sensoren können in free@home auf dort einzurichtende virtuelle Geräte gemapped werden. Eine Integration mit anderen Systemen ist über eine REST-API möglich, es gibt allerdings bisher leider kein Modul für FHEM.