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).

[tostmann]

Danke Euch dreien — aus dem Tester-Aufruf ist eine Konzeptwerkstatt geworden, und das hilft mir mehr als jedes "läuft/läuft nicht".

mCCU (Ralli) — Du beschreibst ziemlich genau, was QCCU ist; offenbar kam das in der Eröffnung nicht klar heraus. Kein CCU-Betriebssystem, keine ReGa, keine Programme, Oberfläche nur fürs Anlernen und die Diagnose — nur das verbindende Element: XML-RPC mit Rückruf, die ReGa-Auskünfte und JSON-RPC, weil die vorhandenen Anbindungen sie erwarten. Gegen FHEM (HMCCU) und Home Assistant geprüft, mehrere Systeme gleichzeitig, als Container. Dein erster Schritt ist also nicht Plan, sondern Stand. Zum Neustart: was nur die Zentrale weiß, wird geschrieben und überlebt ihn — Geräteliste, Adresszuordnung, Rückrufziele und vor allem die Sequenzzähler je Gerät, der Teil, der bei HmIP wirklich weh tut; sie werden beim Laden mit Sicherheitsabstand fortgesetzt. Messwerte und Schaltzustände sichere ich bewusst nicht, die gehören dahin, wo die Logik sitzt. Zu Deinem Cluster-Fall: am Container hängt ein USB-Stick, und der wandert nicht mit. Die Antwort darauf ist ein Funkmodul mit Netzanschluss statt am USB — das ist auch tndx' HB-RF-ETH-Punkt —, ein eigenes Thema, noch nicht spruchreif.

Hardware (tndx) — Heute CUL V3, das stimmt. Der Weg, den ich sehe, ist aber nicht "noch ein Stick zum Kaufen", sondern mehrere Funk-Module hinter derselben mCCU: neben dem CUL das RPI-RF-MOD und der RFUSB, also Hardware, die viele ohnehin haben. Das brächte zwei Dinge zugleich: Ihr wärt nicht außen vor, und wer sein Funkmodul von der CCU mitnimmt, nimmt den Netzwerkschlüssel mit — dann muss kein Gerät neu angelernt werden; die Geräteliste müsste noch aus der alten Zentrale kommen, das ist der offene Teil. Beides ist Plan, nicht Stand — aber der Punkt, an dem sich für mich entscheidet, ob das mehr wird als ein Bastelprojekt. Zum Selbstbau: Beta-User hat recht, der Pro Micro ist derselbe Chip wie im CUL V3, das ist Anpassung an die Beschaltung; der Nano-CUL ist ein anderer Chip mit serieller statt USB-Schnittstelle, also mehr — beides ohne Zusage, wann. Und zum Disassemblieren: ja. Kein Quelltext ist eine Hürde, kein Beweis; wer den Aufwand treibt, kommt an die Sperre heran, sie liegt nur nicht als fertiges Werkzeug herum.

Timing (Beta-User, und tndx' Wiki-Zitat) — Das Zitat zielt genau auf Beta-Users Punkt, und der trifft. Bei q-culfw ist es heute zweigeteilt: auf der IP-Seite quittiert der Stick selbst; für BidCoS ist er reiner Transceiver, kein ACK, kein Zeitstempel — da gilt der Wiki-Rat unverändert. Was ich will, ist genau Dein Mechanismus: der Stick bekommt die Liste der HmIDs, für die er quittiert — aber zur Laufzeit vom Host, bei jedem Verbindungsaufbau, so wie FHEM sie dem HMLAN mitteilt, statt ins EEPROM gebrannt. Damit fällt der Verschleiß-Punkt weg, der Dich stört. Im RPI-RF-MOD ist das Modul bereits so gebaut, es quittiert für die Geräte, die man ihm nennt — dort fehlt nur die Host-Seite; auf dem CUL ist es Firmware-Arbeit, und ob sie in den kleinen Chip passt, messe ich, bevor ich etwas zusage. Deine tsculfw-Erfahrung — welche Zeitfenster in der Praxis wirklich zählen — spart mir dabei eine Menge Messerei.

bidcos2mqtt (Ralli) — Dein zweiter Schritt ist mein eigentliches Ziel: nicht die Zentrale nachbauen und MQTT anflanschen, sondern die Geräte direkt sprechen lassen, mit Discovery, wie es zigbee2mqtt vormacht. Das hängt nicht an der Funk-Hardware und läuft deshalb parallel zur Öffnung oben, nicht danach — bidcos2mqtt als Einstieg, wie Du es nennst, die IP-Seite zieht nach. Wenn Du dort mitdenken magst — Topic-Struktur, was Discovery liefern soll, wie viel Gerätesemantik der Broker sehen darf —, ist mir das lieber als jede Umfrage.

Richtung — Bevor ich mich verrenne, gebe ich Rallis Frage nach Aufwand und Nutzen offen in die Runde zurück, denn sie entscheidet die Reihenfolge: die IP-Seite am CUL in die Breite bringen (mehr Gerätetypen, Dauerbetrieb — der ursprüngliche Aufruf)? Laufende Anlagen über RPI-RF-MOD/RFUSB übernehmen, ohne neu anzulernen? BidCoS-Timing, also ein Funkzugang, der selbst quittiert? Oder MQTT statt RPC? Das ist keine rhetorische Frage: wo Ihr den Nutzen seht, dahin sortiere ich.

Und damit die konkrete Bitte: Mir fehlen weniger Tester für "geht der Knopf" als Mitdenker an den zwei Ecken, die heute den Ausschlag geben — das MQTT-Schema (Ralli) und das HM-Timing (Beta-User). Wer eine überschaubare Anlage hat und Lust auf ein, zwei Runden Mitmessen: meldet Euch, ich richte das gezielt ein. Lieber wenige an der richtigen Stelle als viele, die dasselbe bestätigen.

[tndx]

Speziell zu TSCUL gibt es viel Lesestoff und die Sourcen hier:

https://forum.fhem.de/index.php?topic=24436.0

[Ralli]

mCCU (Ralli) — Du beschreibst ziemlich genau, was QCCU ist; offenbar kam das in der Eröffnung nicht klar heraus.

Danke für die Klarstellung - dann habe ich aber immer noch eine Denkblockade: die QCCU wird über HMCCU angesprochen. QCCU kommuniziert über den CUL mit den HmIP-Devices. Und parallel wird aber CUL_HM genutzt, um über die QCCU mit dem CUL das "alte" BidCoS-RF zu sprechen. Warum? Warum nicht aus FHEM-Sicht alles tatsächlich über HMCCU abwickeln - läuft ja eh über die gleiche Maschine? "Nur", um damit den aktuellen CUL_HM-Installationen die Transformation zu erleichtern oder hat das einen sonstigen architektonischen Hintergrund?

... Messwerte und Schaltzustände sichere ich bewusst nicht, die gehören dahin, wo die Logik sitzt.

Mmmh, da müsste ich jetzt noch einmal in die Dokumentation schauen, aber ist es nicht so, dass ich über RPC einerseits den in der CCU gespeicherten Zustand abfragen und andererseits die CCU zum "aktiven" Status-Abholen beim Device auffordern kann? Beides hat seine Vor- und Nachteile was Aktualität, Verlässlichkeit der Daten und den Duty-Cycle betrifft. Gerade in dem von mir beschriebenen Szenario der Migration der VM, was ja öfter vorkommt als ein CCU-Update, bin ich froh, dass die Zustände in der CCU erhalten bleiben, denn sie sind für meine Logik-Schicht (FHEM) damit nach wie vor der Status-Quo des Devices (wenn auch mit Vorbehalt).

Und damit die konkrete Bitte: Mir fehlen weniger Tester für "geht der Knopf" als Mitdenker an den zwei Ecken, die heute den Ausschlag geben — das MQTT-Schema (Ralli) und das HM-Timing (Beta-User). Wer eine überschaubare Anlage hat und Lust auf ein, zwei Runden Mitmessen: meldet Euch, ich richte das gezielt ein. Lieber wenige an der richtigen Stelle als viele, die dasselbe bestätigen.

Sehr gerne versuche (!) ich zu unterstützen, ob ich da aber tatsächlich Mehrwert bieten kann, wird sich zeigen.

Gerade das MQTT-Schema ergibt sich m.E. relativ schnell aus den Kanälen und Datenpunkten der Devices, das ist ja schon alles harmonisiert, strukturiert und hierarchisch aufgebaut.

[Sidey]

Und damit die konkrete Bitte: Mir fehlen weniger Tester für "geht der Knopf" als Mitdenker an den zwei Ecken, die heute den Ausschlag geben — das MQTT-Schema (Ralli) und das HM-Timing (Beta-User). Wer eine überschaubare Anlage hat und Lust auf ein, zwei Runden Mitmessen: meldet Euch, ich richte das gezielt ein. Lieber wenige an der richtigen Stelle als viele, die dasselbe bestätigen.

Also ich habe eine HM (biscos) Anlage. Bisher kein HMip.
Allerdings besitze ich nur das HM Mod RPI.
Wenn ich damit was messen kann, dann lass es mich wissen.

Das ganze in MQTT bringen könnte ich auch mal mitdenken.  Das habe ich zuletzt mit AlexaCookie und MideaAC gemacht. Ein bisschen Erfahrung ist vorhanden.


Grüße Sidey

[Beta-User]

Deine tsculfw-Erfahrung — welche Zeitfenster in der Praxis wirklich zählen — spart mir dabei eine Menge Messerei.

Vorbemerkung:
Ich hatte hier "eigentlich" nur geantwortet, um es dir zu ersparen, den ganzen (von tndx nochmal verlinkten) tscul-Thread durchzuackern und/oder die sourcen zu durchpflügen, nur um auf den eigentlichen wesentlichen Inhalt/Mehrwert von TS_CUL zu kommen.

Meine eigenen Erfahrungen mit CUL "pur" sind soweit gut. Im Moment habe ich noch einen MapleCUN im Einsatz, den ich "eigentlich mal" durch einen LAN-Signalduino mit durchgereichter Schnittstelle für ein HM-Mod-RPi-PCB ersetzen wollte.
Meinen (Original-CUL) hatte ich einige Zeit als TS_CUL eingebunden, und er ist wohl auch noch mit dieser firmware-Variante geflasht. Letztlich war es mir aber im Zusammenhang mit dem letzten Hardware-Wechsel (noch) zu viel Aufwand, die ganzen Module "drumrum" auch noch mit zu tauschen, nur um ein "optimales backup" zu haben, und mich damit rumzuschlagen, was denn jetzt optional zu tauschen wäre und was zwingend... 

Meine Helfer-Erfahrungen hier aus dem Forum waren u.a. mit Anlass für die Klarstellung, die sich heute im Wiki findet: Viele User hatten erhebliche (und teils "unerklärliche" (da sporadisch festzustellende)) Probleme mit CUL, v.a. in Umgebungen mit schwacher (Pi-) Hardware und hohem Event-Aufkommen.

Kurz gefasst: Die "Probleme von CUL" sind nach meiner persönlichen Bewertung v.a. eine Folge der timing-Abhängigkeit von der Abarbeitung des FHEM-Prozesses. Klar, dass das nicht die reine Lehre ist, just my2ct.

Wenn wir Leute brauchen, die insbesondere Probleme im Funkverkehr besser verstehen, würden mir v.a. frank und noansi einfallen, natürlich neben martinp876.

ABER:

Frage nach Aufwand und Nutzen offen in die Runde zurück

Für mich würde sich (subjektiv) der Mitarbeits-Aufwand lohnen, wenn man die wesentlichen Vorteile einer von der FHEM-loop entkoppelten zeitnahen Kommunikation zwischen dem IO und der BidCoS-Welt hinbekäme. Die "Vision" ging in die Richtung, dass man den an der QCCU "angeschlossenen" CUL nicht als CUL einbindet, sondern den QCCU-container selbst als HMLAN oder HMUARTLGW (ggf. als spezielles "model"), der Container also die von FHEM/CUL_HM-VCCU gesteuerte Verteilung der IOs als Basis hernehmen könnte und entsprechende Infos an FHEM sendet.

Ich hatte vor ziemlich langer Zeit mal das "Vergnügen", die CUL_HM-Modul-Welt einschließlich der zugehörigen IO-Module intensiver beackert zu haben, um einige Problemchen zu beseitigen, die durch die damalige "Abriegelung" vieler "Freiheiten" der User entstanden gewesen waren und traue mir daher zu, ggf. entprechende patches für FHEM bereitzustellen, allerdings sind meine Kenntnisse etwas eingerostet und das Zeitbudget eher gering.
Ich würde das direkt auf meine Installation loslassen, count meint, es wären 66 Geräte da mit 6-stelliger HMId (ein Teil ist virtuell, aber ca. 50 Geräte sollte das schon sein, die Hälfte "on battery").

Kurz: Ich hielte (erst mal ohne näheren Blick in den Code, zugegeben!) den Aufwand, eines der IO-Module entsprechend zu patchen für ziemlich gering, und zwar unabhängig davon, ob letztlich die neue firmware auf dem CUL werkelt (Mehrwert (für andere): auch IP möglich), oder sowas wie mein MapleCUN oder ein "Pro-Mini-CUL" (Vorteil: bestehende "andere" Hardware kann "beschleunigt" recycled werden).

Anders formuliert: Vermutlich wären auch einige andere User froh, nicht der Empfehlung aus dem Wiki folgen zu müssen, tscul "voll" zum Einsatz zu bringen, wenn man das (vergleichsweise) einfache Angebot hätte, einen Docker-Container zu installieren und nur ein anderes, bekanntes "Standard"-IO-Modul dafür einzubinden, um den CUL besser zu nutzen .

Noch zur Portabilität hinsichtlich HMIP: Insbesondere ZWave-Sticks bieten die Option an, die komplette firmware einschließlich der gespeicherten Geräte-Liste usw. wegzusichern, um sie auf einem (baugleichen) Chip zu flashen (oder auch nur die Geräteliste?). Wie dem auch sei: sowas wäre m.E. ein sinnvoller Punkt für die feature-Liste...

Ansonsten wäre aus meiner Sicht nicht die Einbindung auch von BidCoS an QCCU erforderlich (den Teil macht FHEM/CUL_HM doch sehr gut, wenn man von der unübersichtlichen Aufteilung mancher Geräte in viele Kanäle absieht), "schöner" wäre es ggf. wenn man HMIP (nur) über MQTT abwickeln könnte. Um HMIP habe ich bisher einen großen Bogen gemacht, und das lag zum Teil auch daran, dass ich keine wirkliche Lust auf die HMCCU.*-Module hatte.