FHEM Forum

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 (https://homematic-ip.com/de/news/ccu3-smart-home-naechstes-kapitel)). 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:

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

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 (https://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 ...