QCCU — Homematic-IP-Zentrale im Container am alten CUL, Tester gesucht

[tostmann]

Worum es geht

eQ-3 hat am 8. Juli 2025 angekündigt, neue Homematic-IP-Produkte noch bis Ende 2026 in die CCU3 zu integrieren; ab 2027 sollen Nutzer eigene Anpassungen vornehmen können, die Weiterentwicklung geht schrittweise an die Community (Meldung bei homematic-ip.com). Das war für mich der Anlass, eine Frage praktisch zu beantworten: Wie klein kann die Zentralenseite werden, wenn man sie nur noch für FHEM braucht?

Herausgekommen ist QCCU: ein Container, der gegenüber FHEM eine Zentrale nachbildet, und ein CUL als Funkzugang (aus Tradition). FHEM bindet mit seinem gewohnten HMCCU an, kein eigenes Modul nötig.
Der Container wandelt im Kern nur den IP-Funkverkehr in XML-RPC und ReGa um, damit HMCCU unverändert damit arbeiten kann — zugegeben von hinten durch die Brust ins Auge, aber so bleibt FHEM auf dem Weg, den es ohnehin beherrscht, und es braucht kein eigenes Modul.
CUL_HM.pm könnte aber auch leisten IP-Frames kommen mit "Pxxx" Prefix von culfw

Ein Stick, beide Funkfamilien

Der CUL bekommt eine eigene Firmware (q-culfw) und trägt danach BidCoS/AskSin und IP gleichzeitig. In FHEM stehen dann nebeneinander:

Code Auswählen Erweitern

define ccu  HMCCU <rechner>            # IP-Seite, über XML-RPC und ReGa
define qcul CUL   <rechner>:2000 1234  # BidCoS/AskSin, wie an jedem CUL

Die klassische Seite reicht QCCU als CUL-Zugang über TCP durch, dort ist der Stick reiner Transceiver und CUL_HM macht wie gewohnt alles selbst. Beide Familien teilen sich das 1-%-Sendezeitkonto des Sticks.

Installation

Code Auswählen Erweitern

docker run -d --name qccu --restart unless-stopped \
    -v /dev:/dev \
    --device-cgroup-rule='c 166:* rmw' --device-cgroup-rule='c 189:* rmw' \
    -v qccu-data:/data \
    -e ADVERTISE=<IP dieses Rechners> \
    -e CUL_PORT=2000 \
    -p 2000:2000 -p 2010:2010 -p 8181:8181 -p 8080:8080 \
    tostmann/qccu

Beim ersten Start legt der Container die Gerätetabellen selbst an — er lädt dazu das debmatic-Paket, liest die Beschreibungen aus und verwirft es wieder. Auf einem Pi 5 dauerte das 18 Sekunden, danach entfällt der Schritt. Im Abbild selbst liegt nichts von eQ-3; für die Nutzung der geladenen Software gelten deren Lizenzbedingungen (HMSL), der Container weist beim Laden darauf hin.

Danach: Weboberfläche auf Port 8080. Dort wird die Stick-Firmware eingespielt und angelernt.

Abbild 343 MB (amd64) / 370 MB (arm64), Quelltext und Rezept unter github.com/tostmann/QCCU.

Was ich belegen kann — und was nicht

Belegt ist der Durchstich, mehrfach und zuletzt komplett von vorn: Container aus dem veröffentlichten Abbild, CUL im Auslieferungszustand, Firmware über die Weboberfläche eingespielt, eine HmIP-Schaltsteckdose angelernt und aus FHEM geschaltet, dazu parallel ein klassischer BidCoS-Schaltaktor am selben Stick — beide Familien gleichzeitig, Rückmeldung jeweils am echten Kanalzustand geprüft.

Nicht belegt ist alles andere. Die Gerätetabellen kennen 304 Gerätetypen und 127 Kanaltypen, aber on air getestet habe ich genau zwei Geräte: eine HmIP-PS-2 und einen HM-LC-SW1-PL2. Alles jenseits davon — Thermostate, Fensterkontakte, Wettergeräte, mehrere Geräte gleichzeitig, Dauerbetrieb über Wochen — ist offen. Deshalb dieser Beitrag.

Wer mitmachen kann

Gebraucht wird ein busware CUL V3 (868 MHz). Beim Containerstart im Bootloader wird q-culfw aufgespielt: Der Stick spricht danach ausschließlich BidCoS und IP, die übrigen Funkarten (FS20, IT, EM) entfallen. Genau deshalb finde ich den Weg reizvoll — ein CUL, der irgendwo in der Schublade liegt, bekommt eine zweite Aufgabe.

Was ihr vorher wissen solltet:

• Geräte müssen vorerst neu angelernt werden. Eine laufende CCU-Installation zu übernehmen, ist geplant, aber noch nicht gebaut — und hätte einen angenehmen Nebeneffekt: Wer übernimmt, braucht die Aufkleber gar nicht, weil Netzwerkschlüssel und Geräteliste aus der alten Zentrale kommen.
• Solange neu angelernt wird, braucht ihr für jedes IP-Gerät den Key vom Aufkleber. Ohne ihn geht es nicht — bei fest verbauten Geräten also vorher nachsehen, ob ihr ihn noch habt.
• Der Netzwerkschlüssel entsteht im Stick und bleibt dort. Geht der Stick kaputt, müssen alle Geräte neu angelernt werden.
• Keiner der Ports fordert derzeit eine Anmeldung. Das gehört ins eigene Netz, nicht ins Internet.

Was mich interessiert

Vor allem: Welche Geräte funktionieren, welche nicht? Wenn ein Gerät sich anlernen lässt, aber keine sinnvollen Werte liefert, ist das der interessanteste Fall — dann fehlt die Auswertung für seinen Statustyp, und das lässt sich gezielt nachziehen. Genauso wertvoll: Wo hakt die Installation, wo ist die Oberfläche unverständlich, was fehlt in der Anleitung?

Rückmeldungen gern hier im Thread oder als Issue auf GitHub.

Und für die, die ihre CCU behalten wollen

Der Weg oben ersetzt die Zentrale. Es geht aber auch andersherum: Der Funkteil im Stick beherrscht bereits die Geräterolle — er bringt eine eigene Kennung und einen eigenen Aufkleberschlüssel mit und lässt sich damit an einer vorhandenen Zentrale anmelden wie jedes gekaufte IP-Gerät. Daraus soll ein Stack werden, mit dem man eigene Aktoren und Sensoren baut, die an der eigenen CCU hängen — sinngemäß das, was AskSinPP für die klassische Seite ist. Das ist noch nicht fertig und bekommt einen eigenen Beitrag, wenn es soweit ist.

Euch noch einen schönen Sommer ...

[tndx]

Moin,

das klingt interessant. Ich frage mich zwar, wer die Zielgruppe dafür sein soll, denn die meisten sind mittlerweile wahrscheinlich mit einer Bare-Metal- oder virtuellen CCU und eq3-Funkmodulen bedient, aber mich reizt der Bastelfaktor, bzw. die Möglichkeit, alter Hardware neues Leben einzuhauchen. Aber genau da gehen die Fragen los:
- wie hast du es hingekriegt, dich mit deiner Hardware in den HmIP-Funkverkehr einzuklinken? Bis jetzt hieß es immer, HmIP wäre proprietär und verschlüsselt, man käme nicht an Originalhardware von eq3 vorbei.
- ist q-culfw Open Source?
- werden längerfristig auch andere Busware-CUL-Derivaten unterstützt, wie z.B. CUNX? Wie sieht es mit Nicht-Busware-Hardware (Nano-CUL) aus?

Edit:
- von culfw wird seit Jahren als HM-SW abgeraten, kann q-culfw es besser?

[tostmann]

Moin,

kurz der Reihe nach.

Zur Zielgruppe: wer eine laufende CCU hat, hat keinen Grund zu wechseln. Gedacht ist es für die, die keine CCU betreiben wollen — und für genau den Bastelfaktor, den Du nennst.

Wie komme ich in den Funkverkehr?

Auf der Luft ist HmIP BidCoS: gleiche Frequenz, gleiche Modulation, gleiche Datenrate, gleiches Synchronwort, gleiche Verwürfelung. Deshalb trägt ein CUL beide Familien gleichzeitig. Das "IP" sitzt eine Ebene höher (Nachbarschaftsmeldungen im ICMPv6-Stil), auf dem Funk merkt man davon nichts.

Bei den Schlüsseln ist das Modell das von Zigbee. Die Zentrale hält einen Netzwerkschlüssel, das neue Gerät bekommt ihn beim Anlernen verpackt zugestellt, danach läuft alles mit AES-CCM darüber. Verpackt wird der Netzwerkschlüssel beim Pairing entweder mit dem geräteindividuellen Schlüssel, den außer dem Gerät nur eQ-3 kennt — die CCU schickt ihren Netzwerkschlüssel an den eQ-3-Dienst und bekommt ihn für das Gerät verpackt zurück, das ist der bequeme Weg — oder mit dem Schlüssel, der auf dem beiliegenden Sticker aufgedruckt ist. Letzteres entspricht dem Install-Code von Zigbee 3.0, und das ist der Weg, den QCCU geht.

Damit ist es so sicher wie Zigbee mit Install-Code. Ohne diesen Sticker oder den eQ-3-Dienst lernt man kein Gerät an, auch mit QCCU nicht. Bei QCCU entsteht der Netzwerkschlüssel im Stick und bleibt dort: er kommt nie im Klartext heraus, einen fremden Schlüssel nimmt der Stick nicht an, und einen Befehl zum Lesen des EEPROMs gibt es nicht.

Wichtig fürs Verständnis: das ganze Schlüssel-Voodoo von eQ-3 — Master-Key, Keyserver, Sticker — betrifft nur die AUSLIEFERUNG des Netzwerkschlüssels beim Pairing. Der Schlüssel selbst ist danach die eine Grenze: wer ihn hat, egal wie beschafft, hat Vollzugriff aufs ganze Netz — genau wie bei Zigbee.

Eine Angriffsfläche liegt nicht in der Verschlüsselung, sondern in der Infrastruktur davor: eine Zentrale, die ihre Schnittstellen offen ins Netz hält. Wer die erreicht, braucht den Netzwerkschlüssel gar nicht mehr — er bedient die Zentrale; nicht die Krypto ist gebrochen, die Zentrale steht offen. Empfehlung wie eh und je: die CCU (und ebenso QCCU) gehören ins eigene Netz, nicht ans offene Internet.

Ist q-culfw Open Source?

Nein. Die Firmware liegt dem Container bei und wird aus der Weboberfläche eingespielt, Lizenz PolyForm Perimeter 1.0.1 — und auch deshalb kein Quelltext: die Sperre gegen fremde Schlüssel von oben wäre mit Quelltext eine Zeile Arbeit, und der Stick damit ein Werkzeug zum Mitlesen fremder Anlagen. Ein culfw-Ableger ist sie nicht: kein culfw-Code (der USB-Stack ist LUFA, wie bei culfw auch), culfw-kompatibel ist nur die Schnittstelle nach außen (V, Ar/As und die A-Zeilen), damit CUL_HM unverändert damit spricht.

Andere Hardware?

Heute CUL V3, sonst nichts.

"von culfw wird als HM-SW abgeraten"

Für BidCoS ändert q-culfw ohnehin nichts: der Stick ist reiner Transceiver, das Protokoll macht CUL_HM wie an jedem CUL. Auf der IP-Seite ist es umgekehrt — da macht der Stick Empfang, Entschlüsselung und Quittung selbst; die Gegenstelle erwartet die Quittung binnen weniger Dutzend Millisekunden, das erledigt der Stick, statt es dem Rechner zu überlassen. Woran genau machst Du den alten Rat fest? Dann sage ich Dir gezielt, wie es bei q-culfw aussieht.

Einordnung

Auf die IP-Seite von Homematic kam ich über ein Nachbarprojekt — einen Zigbee-Coordinator auf einem ESP32 (esp-coordinator), den ich maintaine und der bei zigbee2mqtt als ZBOSS-Adapter gelistet ist; die Frage war, ob dieselbe billige Hardware auch die eQ-3-Funkwelt tragen kann.

Der Vergleich zeigt auch den wunden Punkt, den HmIP mit Zigbee teilt: EIN netzweiter Schlüssel für die ganze Anlage — wer ihn hat, hat das ganze Netz. Thread/Matter, wie es z.B. IKEA zum halben Preis verbaut, hängt die Gerätesicherheit nicht mehr allein daran; HmIP und Zigbee sind an der Stelle eine Generation älter.

Wenn alles an einem Schlüssel hängt, zählt umso mehr, in wessen Händen die Zentralen-Software liegt — und die gibt eQ-3 schrittweise an Dritte ab: Ende 2026 endet die eigene Weiterentwicklung der CCU3, sie geht an die Community (OpenCCU). Ob sich eQ-3 damit langfristig einen Gefallen für die eigene Systemsicherheit tut, wage ich zu bezweifeln: je mehr offene Zentralen-Software mit ihren bekannten Standardvorgaben zirkuliert, desto mehr hängt an genau der Sorgfalt von oben — Zentrale und Netzwerkschlüssel nicht offen ins Netz.

Und ein Punkt, der bei dieser Abgabe gern übersehen wird: der Schlüsseldienst bleibt bei eQ-3, an der Zentrale hängt er nicht. Sollte der eines Tages ebenfalls abgeschaltet werden — Bose hat mit SoundTouch dieses Jahr vorgemacht, wie so etwas läuft —, dann läuft jede bestehende Anlage zwar weiter, aber jedes HmIP-Gerät, dessen Sticker im Altpapier gelandet ist, lässt sich nirgends mehr anlernen: nicht an einer neuen Zentrale, nicht beim Käufer. Elektroschrott. Den Sticker also aufheben wie den Zweitschlüssel vom Auto.

Genau deshalb ist QCCU für mich auch nur der Kompatibilitäts-Nachbau, nicht das Ziel. Das Ziel ist weg vom CCU-Monolithen, hin zu Geräten direkt per MQTT, wie es zigbee2mqtt vormacht — und ja, an der Schlüsselfrage arbeite ich auch, dazu mehr, wenn es gebaut ist.

[tndx]

[...]
Gedacht ist es für die, die keine CCU betreiben wollen
[...]

Auch bei dir muss ja ein Container ausgeführt werden und die Kommunikation mit diesem erfolgt über HMCCU. OpenCCU kann man ja auch als Docker laufen lassen, ob da jetzt die Oberfläche dabei ist oder nicht, fällt ja nicht so sehr ins Gewicht, sondern ist im Zweifelsfall sogar nützlich, wenn irgendwas klemmt.

[...]
Ist q-culfw Open Source?
[...]
die Sperre gegen fremde Schlüssel von oben wäre mit Quelltext eine Zeile Arbeit, und der Stick damit ein Werkzeug zum Mitlesen fremder Anlagen.
[...]

Ich bin ja kein Fachmann, aber läßt sich sowas nicht durch disassemblieren/dekompilieren auch auslesen? Das Fehlen der Sourcen macht das höchstens umständlicher aber schließt das nicht aus, oder?

[...]
Andere Hardware?

Heute CUL V3, sonst nichts.
[...]

Das reduziert den Bastelfaktor enorm bzw. ist aus Sicht des Users ein weiteres Funkmodul, das man ggf. erst kaufen muss. Dann kann man ja genauso Original-Hardware kaufen und hat auch noch einen Trumpf in Form von HB-RF-ETH.

[...]
"von culfw wird als HM-SW abgeraten"
[...]
Woran genau machst Du den alten Rat fest? Dann sage ich Dir gezielt, wie es bei q-culfw aussieht.
[...]

Erfahrungsgemäß ist der Einsatz originaler HomeMatic IOs empfehlenswert, da es bei allen CUL-Derivaten immer wieder zu Schwierigkeiten kommen kann, vor allem in größeren Installationen und bei der Kommunikation mit komplexeren Geräten. Wer dennoch einen CUL für HomeMatic verwenden will, sollte eine speziell für den Betrieb mit HomeMatic optimierte CUL-firmware (tsculfw - TimeStamp Firmware) verwenden. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING_ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen! Zusätzlich sind unbedingt die Hinweise im Artikel AES Encryption zu beachten!

https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale

Auch wenn ich dein Engagement gut finde (Konkurrenz belebt das Geschäft), erscheint mir der Abstand zu den bereits etablierten Lösungen zu gering und die Vorteile als eher theoretisch. Da ich keinen Original-CUL besitze, bin ich leider auch außen vor, CUNX und Nano-CUL hätte ich gehabt. Aber ich bin gespannt auf die Weiterentwicklung und lese hier weiterhin mit.

[Ralli]

Zunächst einmal finde ich das Engagement und überhaupt eine solche Idee zu entwickeln sehr respektabel. Danke dafür.

Allerdings stelle ich mir die Frage, ob die zu betreibenden Aufwände tatsächlich den Nutzen und vor allem die Zukunftsfähigkeit einer solchen Lösung rechtfertigen.

Ja, die Leistungsfähigkeit von "PCs" ist enorm gestiegen und sicherlich ist es heute einfacher, auch in gesharten Umgebungen echtzeitsensitive Anwendungen zu betreiben, allerdings bin ich auch ein Verfechter der vom Vorschreiber zitierten Philosophie, dass gerade dann, wenn es um zeitkritische Challenge-Response-Verfahren in größeren Systemumgebungen geht, man diese lieber durch eine dedizierte Hardware-Lösung, die nichts anderes als das tut, lösen lässt. Also z.B. ein RPI-RF-MOD - oder eben ein ESP32 oder STM32 mit angeflanschtem CUL.

Was m.E. jedoch fehlt, ist ein CCU-Ersatz, der von der grottigen Oberfläche und der REGA befreit wird und tatsächlich ausschließlich das verbindende Element ("mCCU") zwischen der Hardware-Schnittstelle bzw. den Hardware-Schnittstellen (es gibt ja auch noch Bus ...) und dem Logik-System darstellt. Und hier könnte man im ersten Schritt auf die etablierte RPC-Schnitstellen zurückgreifen und in einem zweiten Schritt stattdessen/zusätzlich bidcos2mqtt implementieren.

Eine solche mCCU könnte dann bspw. über einen schlanken Container bereitgestellt werden. Eine kleinere Herausforderung ist dann die bisherige Tatsache, dass bei einem Neustart der CCU bzw. eines Containers alle Systemzustände verloren gehen. Darum nutze ich bspw. aktuell auch nicht CCU im Container sondern tatsächlich als VM, denn wenn ich diese bei Systemwartungen im HA-Cluster verschiebe/migriere, bleiben die Zustände bestehen.

[Beta-User]

Kurz zum Thema TS-CUL und der Empfehlung, für BidCoS die zugehörigen Modul-Varianten zu verwenden: Auch bei BidCoS ist timing wichtig, v.a., wenn die jeweiligen Gegenstelle ein ACK erwartet oder allgemein eine schnelle Reaktion. Bei der TS_CUL-firmware wird jedem Stick (dynamisch) mitgeteilt, für welche HmId's er ACKs senden soll. Insoweit verhält sich so ein CUL nicht anders als ein HMLAN-GW. Weiter erhält (soweit ich mich entsinne) jede Nachricht auch einen timestamp (ebenfalls wie über HMLAN kommend).

Von daher wäre es auf alle Fälle eine sehr coole Sache, wenn es eine (weitere) CUL-Variante gäbe, die sich timing-mäßig "korrekt" verhält. Leider muss bei jeder Änderung diese Info über die zu verwaltenden HMId's ins EEPROM geschrieben werden.

Ansonsten dürfte es auch möglich sein, einen "normalen" Selbstbau-CUL mit der firmware zu versorgen, sofern er auf dem richtigen Chipset aufbaut (bei Arduino müßte das unter "Pro Micro" firmieren).