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

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?

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.

Zitat von: tostmann am 17 August 2026, 10:50:46[...]
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.

Zitat von: tostmann am 17 August 2026, 10:50:46[...]
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?

Zitat von: tostmann am 17 August 2026, 10:50:46[...]
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.

Zitat von: tostmann am 17 August 2026, 10:50:46[...]
"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.
[...]

ZitatErfahrungsgemäß 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 (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.

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.

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

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.

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

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

Zitat von: tostmann am 18 August 2026, 11:33:23mCCU (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?

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

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

Zitat von: tostmann am 18 August 2026, 11:33:23Und 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

Zitat von: tostmann am 18 August 2026, 11:33:23Deine 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:

Zitat von: tostmann am 18 August 2026, 11:33:23Frage 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.

Hallo,

zur Klarstellung, Anmerkungen und Fragen:

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

Das macht die tsculfw in erster Näherung.
Beim CULV3 wird das EEPROM nur als SRAM Ersatz mißbraucht, weil andere Funktionalitäten und die SlowRf Basisfunktionalität zu wenig freien SRAM übrig lassen. Wenn Du genug SRAM frei hast, können die Daten auch ins SRAM wie das bei anderen CSM-/CUL-/CUN-artigen mit mehr SRAM in der tsculfw auch so per define ist.
Die Ack-Infos werden per Channel und nicht nur per device in der tsculfw gehandhabt und gespeichert und müssen für die am System angemeldeten und vom jeweils als IO zugewiesenen CUL auf dem CUL gespeichert bleiben, damit alle Nachrichten vom device gehandhabt werden können. Also z.B. auch Tastendrücke inklusive AES Quittierung, Wakeup-Ack Vorbereitung zur Konfiguration (erfordert temporäre Channelinfoänderung).
Wie ist die device-seitige Verbindunginitiierung bei IP auf CUL Ebene geregelt? Was erfordert IP für automatische Acks? Gibt es ebenso unterschiedliche Ackanforderungen je nach Protokollzustand?

Die tsculfw wiederholt zudem auch automatisch nicht quittierte Sendenachrichten.

Die Timestamps, die die tsculfw zu Empfangs- und Versandnachrichten mitliefert sind inbesondere für das Debugging interressant, um Timingprobleme erkennen und separieren zu können. Und weiterhin, um Systemdelays ermitteln und nutzen zu können.

Weiterhin prüft die tsculfw beim Initialisieren/Umschalten und checkt regelmäßig den PLL-Lock Zustand des Transceivers und reinitialisiert ggf. den Tranceiver neu. Ein wichtiges Feature für mich, da ich genau so einen Problemkandidaten als CULV3 besitze, der sonst irgendwann im Laufe eines oder weniger Tage den Empfang einstellt. Die CC1101 Doku empfiehlt diese Prüfung ohnehin.
Ist so was auch in der q-culfw implementiert?

Werden weitere CC1101 Errata in der q-culfw behandelt? Z.B. SPI Read Synchronization Issue, RX FIFO und RXFIFO_OVERFLOW Issue...?

Zitataber on air getestet habe ich genau zwei Geräte: eine HmIP-PS-2 und einen HM-LC-SW1-PL2

Das sind sicherlich sehr dankbare Testkandidaten, da dauerhaft empfangsbereit.
Probleme (ich kann nur aus BidCos Sicht beitragen) beginnen erst richtig bei batteriebetriebenen devices, da diese nicht ständig empfangsbereit sind (inklusive Tranceiver schlafend) und auch relativ schnell wieder einschlafen, wenn sie geweckt werden (Fensteröffnen, Burst zum Schalten etc.).
Wer testet, sollte unbedingt auch batteriebetriebene Geräte testen. Inlusive Anlernen, getConfig, Register setzen.

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

Das kann ich nur bestätigen.
Ein nachvollziehbar und nicht zu umgehender Timing-"Störenfried" ist FHEMWEB, der bei mir auf weniger performanter Hardwarebasis durchaus auch mal mehrere Sekunden bei Darstellung einer Seite reinhaut. Eine ständig offene Seite stört durch die auf Grund von Events zu aktualisierenden Readings.
Timingkritische Protokollbestandteile gehören daher nach meiner Erfahrung in die Stick Firmware (wie Du für IP ja auch eingebaut hast).
Wenn Dein Container echtzeitfähig genug aufgebaut ist und auch so auf dem Gesamtsystem abgearbeitet werden kann, dann wäre auch noch Timing auf Containerebene denkbar. So ein Konzept endet aber spätestens mit Erweiterung auf andere IO-CULartige Typen, wie SCC oder gar WLAN angebundene IOs. Ich habe z.B. einen COC auf zwei SCCs sitzen, der BidCos macht. Daher hakelt der IO Richtung PI, wenn die SCCs darunter was länger busy sind. Vom Pi Richtung COC hat die tsculfw einen schnellen send through Mechanismus, um das Problem abzumildern.

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

Vom Sicherheitskonzept her (ohne physischen Zugriff auch den Stick) sicherlich gut.
Sollte CUNX doch mal als q-culfw Kandidat angedacht werden, dann braucht es ein EEPROM Backup spätestens für Firmware-Updates, da der Bootloader leider das EEPROM mit löscht, wenn das Flash gelöscht wird (ist bei meinen CUNX leider so). Sonst wäre der Schlüssel futsch, wie ich Dich verstehe -> alles neu Anlernen, wieder Sticker zusamensuchen...

Spannendes Projekt! Mangels IP Komponenten kann ich leider nicht mittesten.

Gruß, Ansgar.

Danke Euch — der Thread ist inzwischen mehr wert als der Tester-Aufruf, mit dem er anfing.

Wohin das läuft — Rallis Begriff mCCU trifft es: eine Zentrale, die zwischen Funk und Logiksystem vermittelt und sonst nichts. Dafür sammle ich hier gern weiter Anforderungen; was seit Freitag zusammengekommen ist — Quittungen im Stick, Zeitstempel, Container als HMLAN/HMUARTLGW, MQTT, Sichern, Batteriegeräte — ist schon der halbe Anforderungskatalog. Gebaut wird aber gerade die Stufe darunter, und zwar mit Absicht am unbequemsten Gerät: ein ATmega32U4 mit 2,5 kB RAM, ein CC1101, alles über USB. QCCU am CUL ist eine Machbarkeitsstudie. Was dort hineinpasst und dort das Timing hält, hält es auf RPI-RF-MOD, RFUSB oder einem ESP-Stick erst recht — dann ist das Allgemeine eine Portierung und keine Hoffnung. Andersherum hätte ich mit der bequemen Hardware angefangen und nie erfahren, wo die Grenzen wirklich liegen.

noansi — Deine Fragen, der Reihe nach
- Quittungsliste: kommt bei mir zur Laufzeit vom Wirt, nichts wird gebrannt — aber je Gerät, nicht je Kanal. Dein Hinweis auf Kanalebene samt AES-Quittung und der temporären Änderung für den Konfigurationslauf ist genau der Grund, warum ich das nicht als fertig ausgebe.
- IP: einen Verbindungsaufbau, den der Stick verwaltet, gibt es dort nicht. Das Gerät sendet, der Stick quittiert auf MAC-Ebene mit sechs Byte, wie das Modul von eQ-3; ob eine Quittung fällig ist, steht in einem Bit des Frame-Kopfes, nicht im Protokollzustand. Anlernen, Schlüsseltausch und Zähler macht der Wirt. Einen zustandsabhängigen Quittungsfall habe ich auf der IP-Seite bisher nicht gefunden — was nicht heißt, dass es keinen gibt.
- PLL-Lock: in der CUL-Firmware heute nicht drin. In meiner ESP32-Firmware schon, dort gemessen: bleibt FSCAL1 nach dem Kalibrieren auf 0x3F, ist der Synthesizer nicht eingerastet — ein tauber Empfänger lässt sich daran erkennen und neu kalibrieren, das Datenblatt (SWRS061I) empfiehlt die Prüfung ohnehin. Das wandert herüber. Der nützlichste Hinweis im Thread, danke.
- Weitere Errata: Statusregister werden nur mit Burst-Bit gelesen (SPI Read Synchronization). Ein RX-FIFO-Überlauf wird erkannt und behandelt, und geleert wird nur aus IDLE heraus — der Flush im falschen Zustand ist die Falle, in die ich anderswo schon getappt bin.
- Batteriegeräte: eins ist dazugekommen, ein HM-TC-IT-WM-W-EU, angelernt über die Seriennummer, Konfigurationslauf durch. Und der Vorlauf ist der Punkt, an dem es hängt: mit 360 ms Präambel antwortet es nach einer halben Sekunde, ohne schweigt es — zwei von zwei. Fünfzig Geräte, halb auf Batterie, sind trotzdem eine andere Hausnummer, Beta-User; Dein Angebot nehme ich an.
- CUNX: bleibt außen vor — eigenes Produkt, seit Jahren am Ende, und Dein Bootloader-Hinweis ist genau die Falle: wer den Netzschlüssel im Stick hält, darf ihn nicht bei jedem Firmware-Update verlieren. Für den Fall ,,HomeMatic über LAN statt USB" kommt stattdessen der CUL32 — ESP32-C6 mit CC1101, und dazu ein Aufsteckmodul mit W5500 für Ethernet. Wenn der steht, ist ein Test- und Tauschprogramm für CUNX-Besitzer denkbar; dann melde ich mich hier.

Seit dem Wochenende gebaut — Der Stick quittiert selbst und schluckt die Quittung des Wirts, wenn der dieselbe eben gegeben hat; auf der Luft liegt genau eine. Vorlauf für Burst-Geräte. FHEMs gewöhnlicher CUL-Weg läuft, CUL_HM am selben Stick, ohne Patch. In der Zentrale: Anlernwünsche landen in einem Posteingang, Geräte, die mit unserem Netzschlüssel funken aber nicht dazugehören, werden gemeldet, die letzten Werte überleben den Neustart (Ralli), und die Zentrale sieht selbst nach, ob ein Gerät noch da ist.

MQTT (Ralli, Sidey) — Angebot angenommen. Entwurf zum Zerpflücken: <präfix>/<gerät>/<kanal>/<datenpunkt> für den Wert, dasselbe mit /set für Befehle, /verfuegbar je Gerät und für die Zentrale. Ein Thema je Datenpunkt statt JSON je Kanal — jeder Wert lässt sich ohne Schema-Kenntnis abonnieren, Preis sind mehr Themen. Anmeldung bei Home Assistant nur aus der Parameterbeschreibung; wo die nichts hergibt, wird nichts angemeldet. Zwei Fragen: reicht ein Thema je Datenpunkt, oder zusätzlich ein Sammelstand je Kanal? Und wie viel Gerätesemantik soll der Broker sehen?

Container als HMLAN/HMUARTLGW (Beta-User) — gibt es als zweite Linie, nicht veröffentlicht, nichts zu testen; QCCU bleibt der schlanke Weg am CUL. Ein Aktor ist darüber gegen ein ungepatchtes FHEM angelernt und geschaltet. Nachgemessen und für die mCCU wichtig: der RFUSB quittiert nicht von sich aus, das macht der Wirt — bei eQ-3 genauso.

Sehr kurze Wasserstandsmeldung:

Mein ehemaliger TS-CUL läuft jetzt unter version "V 2.0.50 q-culfw".

War ein wenig tricky, weil meine Taste für den Bootloader kaputt ist, also qccu stoppen, per FHEM raw B01 gesendet, dann qccu wieder gestartet...

Erstes zu lösendes Problem: beim Einbinden in die IOList meckert die VCCU, dass dieser CUL kein CUL_HM supporten würde. Muss mal forschen, ob/wie man das löst; nur jetzt halt nicht...

Zitat von: tostmann am 20 August 2026, 12:55:05MQTT (Ralli, Sidey) — Angebot angenommen. Entwurf zum Zerpflücken: <präfix>/<gerät>/<kanal>/<datenpunkt> für den Wert

Sollte klappen, ob man zwischen <präfix> und <gerät> noch den Pfad (HmIP,HmIPW,HMRF,HMW,VIR,ENV) einfügen sollte, kann man kurz überlegen, mir fällt dafür aber auf die Schnelle kein Mehrwert ein. Für die CCU selbst brauchst du auch einen Pfad für die Variablen etc.

Zitatdasselbe mit /set für Befehle, /verfuegbar je Gerät und für die Zentrale.

aus MQTT-Sicht kannst du ja ein publish auch vom subscriber auf einen beliebigen Datenpunkt zulassen, da brauchst du keinen speziellen /set-Pfad. Das ist eher eine architektonische Frage, ob man den kompletten Geräte-Baum eher "read-only" lassen will und deswegen einen expliziten /set-Pfad generiert, auf den dann die QCCU jeweils schaut, oder ob man QCCU auf alle Key/Value-Werte schauen lässt, die aus Device-Sicht heraus gemäß Doku beschreibbar sind. Aus Nutzer-Sicht wäre es schöner, ich könnte gemäß HM-Doku einen set-publish absetzen direkt in den Geräte-Baum (Präfix/LEQ00001/4/AUTO_MODE 0 für einen Thermostat bspw.). (siehe EDIT unten)

ZitatEin Thema je Datenpunkt statt JSON je Kanal — jeder Wert lässt sich ohne Schema-Kenntnis abonnieren, Preis sind mehr Themen. Anmeldung bei Home Assistant nur aus der Parameterbeschreibung; wo die nichts hergibt, wird nichts angemeldet. Zwei Fragen: reicht ein Thema je Datenpunkt, oder zusätzlich ein Sammelstand je Kanal? Und wie viel Gerätesemantik soll der Broker sehen?

Gute Frage. Wiederum aus Nutzersicht wäre es viel einfacher, für jeden Datenpunkt ein Thema - man muss nichts großartig JSON codieren und decodieren. Sollten mehrere Datenpunkte auf einmal angepasst werden, wäre ein JSON besser. Ich glaub, die Wahrheit liegt dazwischen: JSON mit beliebig vielen Devices und Datenpunkten und Werten auf einen Gerätepfad der QCCU absetzen können und ansonsten einzelne KEY/VALUE-Paare in den Gerätepfad selbst hinein. EDIT: wenn du natürlich mehrere subscriber hast, und einer davon setzt einen Wert, dann nehmen die anderen subscriber den bereits als gegeben, obwohl die CCU das ggf. noch gar nicht ausgeführt hat bzw. das Device ggf. den Wert noch gar nicht übernommen hat ... Mmmh ...

Wichtig wäre, sich auch über retain noch Gedanken zu machen. Wenn der MQTT-Client sich vom Broker verabschiedet und nichts ist retained, dann ist der Client nach einem Neu-Verbinden "dumm".

Beta-User — ,,does not support CUL_HM"

Die Meldung kommt nicht vom Stick. Beim Setzen der IOList prüft 10_CUL_HM.pm nur das Internal Clients des IO-Gerätes; das stellt bei einem CUL erst attr rfmode HomeMatic auf CUL_HM um — und nur, wenn bei der Anmeldung in der Antwort auf ? ein A stand (Internal CMDS). Die Firmware liefert das A, der Weg läuft hier gegen ein ungepatchtes FHEM — es klemmt also davor. Magst Du mir drei Ausgaben geben?

list <deinCUL>
attr <deinCUL> rfmode HomeMatic
get <deinCUL> cmds

Interessant sind TYPE, VERSION, CMDS und Clients, und die Rückmeldung des attr. Dazu zwei Fragen: ist das Gerät als CUL definiert oder noch als TSCUL? Und hält in dem Moment der QCCU-Container den Port noch? Zwei Leser an einem Port bekommen Antworten nur bruchstückhaft — dann bleibt CMDS leer und rfmode wird abgelehnt. Falls es schlicht die Reihenfolge war (IOList vor rfmode): rfmode HomeMatic setzen, IOList noch einmal.

Ralli — MQTT

Kein Typ-Pfad zwischen Präfix und Gerät: einverstanden. Dein Hinweis auf die Variablen der Zentrale ist gut — die bekommt dafür ihren eigenen Ast neben den Geräten.

Zum /set-Pfad hat Dein EDIT die Antwort schon selbst gegeben: sobald mehrere Mitleser am Baum hängen, darf im Wertpfad nur stehen, was das Gerät bestätigt hat — sonst hält einer den Wunsch eines anderen für den Zustand. Deshalb bleibt die Trennung: .../set trägt den Wunsch, nie retained; der Wertpfad trägt den Istwert, retained, und erst nach Bestätigung. Das beantwortet auch Deinen Retain-Punkt: nach dem Neuverbinden liefert der Broker den letzten bestätigten Stand, keinen alten Wunsch.

Dein Mittelweg beim Sammel-Setzen gefällt mir: einzelne Themen je Datenpunkt bleiben die Regel, und für mehrere Datenpunkte in einem Rutsch ein Sammel-Eingang an der Zentrale, der JSON nimmt — als zweiter Befehlsweg, nicht als zweiter Zustandsbaum. Die Datenpunktnamen aus der HM-Doku übernehme ich eins zu eins; Dein Beispiel wäre dann praefix/LEQ00001/4/AUTO_MODE für das, was das Gerät tut, und dasselbe mit /set für den Befehl.

Zitat von: tostmann am 20 August 2026, 17:03:12Beta-User — ,,does not support CUL_HM"

gelöst: Das Problem war das "CLIENTS"-Internal. Ich hatte die DEF nur geändert, das Ding stand vorher schon auf rfmode=HomeMatic, war aber zwischenzeitlich deaktiviert gewesen. Neusetzen des rfmode hat geholfen.

Zitat von: tostmann am 20 August 2026, 17:03:12MQTT

Dazu habe ich ein paar grundsätzlich andere Vorstellungen:
Aus FHEM-Effizienzgesichtspunkten ist es besser
a) so wenige Topics wie möglich zu verwenden, und
b) zusammengehörende Events nicht zu verteilen, also allen Funkverkehr, der zusammengehörig ausgelesen wird, auch zusammen zu verpacken. => JSON

Einen MQTT-Server als Datenspeicher zu missbrauchen, finde ich konzeptionell FALSCH, retain ist ein trojanisches Pferd. Weg damit...
Stattdessen lieber eine "get"-Anfrage, um einzelne/alle vorhandene Hardware "live" abzufragen. Antwort gerne als ein JSON-Objekt.

Dass Anweisungen an ein Gerät (/set) topic-mäßig getrennt sein sollten von den Antworten, ist m.E. eine Selbstverständlichkeit.

Wieder nur meine 2ct, und aus Zeitmangel wieder eher kurz angbunden.

Beta-User — danke für die Rückmeldung zur VCCU; das Clients-Internal war genau die Stelle, und der Stick war unschuldig.

MQTT: Deinen Einwand habe ich ernst genommen und nachgelesen, und Du hast recht — an zwei Stellen sogar belegbar im FHEM-Quelltext. Erstens speichert FHEMs eigener Broker (MQTT2_SERVER) behaltene Nachrichten beim aktuellen featurelevel standardmäßig gar nicht (Attribut respectRetain, Hilfetext: ,,no use in a FHEM only environment"). Mein ,,Istwert retained" von heute Nachmittag wäre dort also schlicht wirkungslos. Zweitens reicht MQTT2_CLIENT das Retain-Bit nicht weiter: ein beim Verbinden wiedervorgelegter alter Wert erzeugt in FHEM ein ganz normales Event — ein notify auf ,,open" feuert dann beim Neustart mit dem Stand von vorgestern. FHEM restauriert seine Readings aus fhem.save ohne Events; ein behaltener MQTT-Wert tut das Gegenteil. Das ist Dein trojanisches Pferd, und es ist real.

Deshalb ändere ich das, mit zigbee2mqtt als Vorbild — das Modell kennt man hier aus den MQTT2-Vorlagen: Zustände werden standardmäßig nicht behalten (per Einstellung zuschaltbar, wer es wie Ralli möchte). Je Kanal ein JSON statt je Datenpunkt ein Thema — Datenpunktnamen aus der HM-Doku als Schlüssel, in FHEM also ein Dispatch und ein json2nameValue je Funkmeldung. Ein get-Thema je Gerät (leerer Rumpf = alles, sonst Liste der gewünschten Datenpunkte) und eines für die ganze Zentrale; die Antwort kommt auf den normalen Wertpfaden, damit getList in MQTT2_DEVICE und jeder andere Abonnent dasselbe sehen. Ralli, Dein Reconnect-Fall ist damit über get abgedeckt, und FHEM hält seine Readings ohnehin selbst.

Behalten bleiben genau zwei Dinge: die Verfügbarkeit (LWT) und die Anmeldungen für Zentralen, die auf Discovery angewiesen sind — Home Assistant etwa braucht sie behalten und bekommt beim Start auf seine Statusmeldung Anmeldungen und Zustände neu; mehr Rücksicht auf andere Welten nimmt das Schema nicht. Ereignisse wie Tastendrücke werden nie behalten, /set bleibt vom Wertbaum getrennt (da sind wir uns alle einig), und der Sammel-Eingang für mehrere Datenpunkte in einem Befehl bleibt wie besprochen.

Beispiel:
praefix/LEQ0001234/4           {"ACTUAL_TEMPERATURE":21.5,"SET_POINT_TEMPERATURE":22.0,"modified_at":1755700000}
praefix/LEQ0001234/4/set       {"SET_POINT_TEMPERATURE":21.0}
praefix/LEQ0001234/get         (leer)  -> alle Kanäle werden neu veröffentlicht
praefix/LEQ0001234/verfuegbar  online   (behalten)

Zitat von: tostmann am 20 August 2026, 21:32:45Beispiel:

Code Auswählen Erweitern

praefix/LEQ0001234/4          {"ACTUAL_TEMPERATURE":21.5,"SET_POINT_TEMPERATURE":22.0,"modified_at":1755700000}
praefix/LEQ0001234/4/set      {"SET_POINT_TEMPERATURE":21.0}
praefix/LEQ0001234/get        (leer)  -> alle Kanäle werden neu veröffentlicht
praefix/LEQ0001234/verfuegbar  online  (behalten)

Grundsätzlich und fast komplett schick. Überlege aber, ob das set tatsächlich in den Kanal gehört oder eher auf die Device-Ebene - es gibt Geräte, da kannst du in mehere Kanäle schreiben, willst du dann in jeden dieser Kanäle ein /set bringen? Das Wort "verfuegbar" würde ich für ein einheitliches Wording vielleicht dann auch englifizieren; die genaue Bedeutung? MQTT-Verbindung zwischen CCU und MQTT-Server ist gegeben? CCU ist healthy? Gerät ist online? Die ersten beiden Fälle wären mit LWT bzw. einem KEY/VALUE im CCU-Zweig abzubilden - und wenn CCU nicht verbunden, dann können die Geräte auch nicht "live" verbunden sein. Wenn damit die Anbindung des Gerätes an die CCU gemeint ist, diese ergibt sich regelmäßig aus dem Kanal 0.

Kleine Anmerkung noch zu der ganzen retained-Geschichte: Es soll Installationen geben, da wird FHEM nicht als Broker eingesetzt und ist auch nicht der einzige Client ;). Ich nutze bspw. emqx und da hängen neben FHEM auch noch ioBroker-Instanzen dran ...

Zitat von: tostmann am 20 August 2026, 21:32:45Beta-User — danke für die Rückmeldung zur VCCU; das Clients-Internal war genau die Stelle, und der Stick war unschuldig.

Sorry, wenn ich den Eindruck erweckt haben sollte, dass der Stick an irgendwas "schuldig" gewesen sein könnte. Wegen des kaputten Knopfs hat das Umstellen schlicht länger gedauert wie geplant, so dass ich nur vermelden wollte, dass das "auf dem Weg" ist (und wie die Lösung zu diesem hin und wieder auftretenden Problem mit dem kaputten button sein kann).

Ansonsten gibt es jetzt auch Sende- und Empfangs-RSSI-Werte in der VCCU zum CUL, er scheint also bis dahin "ganz normal" zu funktionieren. Daneben gibt es noch ein Pi-PCB (HMUART-LGW, mehr oder weniger identischer Standort) und den Maple (ein Stockwerk tiefer).

Ad "HMLAN": Bin man (eher oberflächlich) durch den Code gegangen. Wenn ich das richtig interpretiere, gäbe es folgende Unterschiede zu CUL:
- Ein HMLAN gibt der Zentrale regelmäßig ein "alive"-Signal (wird default erwartet spätestens alle 45 Sekunden)
- Das Protokoll ist BidCoS, also braucht es keinen Präfix zu den zu dispatchenden Messages (?)
- Er benötigt eine Liste der zu verwaltenden Geräte (wegen Acks und so)
- Weiter verwaltet er AES selbstständig.

Das war es schon. Meine Idee wäre, (übergangsweise zum Testen?) neben der "normalen" CUL-Funktion schlicht einen weiteren Port aufzumachen, wenn man qccu zu einem gültigen HMLAN-IO erweitern wollte.

In den HMUARTLGW-Code habe ich noch nicht geschaut, lohnt imo dann auch nicht, wenn das obige korrekt ist, oder?

Zitat von: Ralli am 21 August 2026, 06:29:01Kleine Anmerkung noch zu der ganzen retained-Geschichte: Es soll Installationen geben, da wird FHEM nicht als Broker eingesetzt und ist auch nicht der einzige Client ;). Ich nutze bspw. emqx und da hängen neben FHEM auch noch ioBroker-Instanzen dran ...

Hatte hoffentlich klar genug gemacht, dass meine Sicht aus der FHEM-Perspektive geprägt ist. Einige (ebenfalls nicht abschließende) Anmerkungen noch dazu:
- Die "retained"-Behandlung beim FHEM-Start (respectRetain) ist funktional eine Kopie des damaligen Stands bei mosquitto (V 1.5?).
- mosquitto kannte damals auch eine (imo eher knappe default-) Obergrenze der per retain möglichen Einträge (1024 (?))
- Wenn man den Broker als Datenspeicher missbrauchen will oder muss, sollte dort ein komplettes Abbild des (letzten bekannten) Gerätestatus liegen. Für FHEM braucht es "nur" den geänderten Teil (und initial das "komplett-get"), und für meine ganz persönlichen Augen ist das auch "lightweight" gemäß der MQTT-Grundidee.
Es gibt Clients, die getrennte Topics für "komplett" und "geändert" verwenden. Vielleicht ein Kompromiss, die "komplett"-Zweige optional einschalten und ggf. per "retain" marken zu können? (Weiß nicht, ob das ioBroker helfen würde).
- zigbee2mqtt empfinde ich als brauchbares Leitbild - abgesehen von der "availability"-Behandlung. Warum das auf einem getrennten Topic läuft, erschließt sich mir nicht, ansonsten gibt es da afaik nur JSON-Blobs mit Zustandsänderungen (was erklärt, warum manche Geräte zwei Messages auf einen Tastendruck erzeugen). Jedenfalls würde ich mir auch da nur einen JSON auf dem "Änderungstopic" wünschen.

Was den "set"-Teil angeht, bin ich (nahe?) bei Ralli, und würde in jedem Fall den set-Topic-Anteil weiter oben ansiedeln (dann ist das Abo viel einfacher zu vercoden, was vermutlich alle Broker freut), Beispiel:
praefix/set/LEQ0001234/4      {"SET_POINT_TEMPERATURE":21.0}Wo die Kanal-Info zu stehen hat (im Topic oder im JSON-Payload), ist aus FHEM-Sicht halbwegs egal. Im Topic ist es einfacher zu ver-Attributieren.

Hi,

ich habe mal eine Spezifikation erstellt, mit minimalen Anpassungen.

Ich finde die Idee gut, den Topic-Aufbau an Zigbee2MQTT anzulehnen. Dadurch können einzelne Geräte oder Kanäle gezielt abonniert werden, beispielsweise mit <prefix>/<geraete-id>/#.

Daher stehen set und get jeweils hinter der Geräte- bzw. Kanaladresse und nicht am Beginn des Topics.

MQTT-Topic-Schema für die Homematic-Bridge

<prefix>/<geraete-id>/<kanal> Status eines Kanals
<prefix>/<geraete-id>/<kanal>/set Wert auf einem Kanal setzen
<prefix>/<geraete-id>/<kanal>/get Kanalwerte erneut lesen/veröffentlichen

<prefix>/<geraete-id>/get Alle Kanäle erneut veröffentlichen
<prefix>/<geraete-id>/availability Erreichbarkeit des Geräts

<prefix>/bridge/state Status der Homematic-MQTT-Bridge
<prefix>/bridge/info Informationen zur Bridge
<prefix>/bridge/devices Geräte- und Kanal-Metadaten
<prefix>/bridge/request/<aktion> Administrative Bridge-Anfrage
<prefix>/bridge/response/<aktion> Ergebnis einer Bridge-Anfrage

Beispiel: Thermostat

homematic/LEQ0001234/4
{
"ACTUAL_TEMPERATURE": 21.5,
"SET_DESIRED_TEMPERATURE": 22.0,
"modified_at": "2026-08-21T06:30:00Z"
}

homematic/LEQ0001234/4/set
{
"SET_DESIRED_TEMPERATURE": 21.0
}

homematic/LEQ0001234/4/get
<leere Payload>

homematic/LEQ0001234/get
<leere Payload>

homematic/LEQ0001234/availability
online

Vorgaben

• <prefix>/<id>/<kanal>: Wird von der Bridge veröffentlicht und retained gesetzt. Enthält den letzten bekannten Zustand des Kanals.
  
• <prefix>/<id>/<kanal>/set: Wird von Clients veröffentlicht und darf nicht retained sein.
  
• <prefix>/<id>/<kanal>/get: Fordert die Aktualisierung eines einzelnen Kanals an und darf nicht retained sein.
  
• <prefix>/<id>/get: Fordert die Aktualisierung aller Kanäle des Geräts an und darf nicht retained sein.
  
• <prefix>/<id>/availability: Wird von der Bridge retained mit online oder offline veröffentlicht.
  
• <prefix>/bridge/state: Wird von der Bridge retained veröffentlicht und zeigt deren Verfügbarkeit an.
  

Nach einem
/set Befehl veröffentlicht die Bridge den tatsächlich aus Homematic gelesenen Zustand erneut auf dem jeweiligen Kanal-Topic. Dieses Status-Topic ist damit die verbindliche Bestätigung eines Befehls.

Auch wenn "retained" in der aktuellen FHEM Implementierung keine Rolle spielt, würde ich mich beim Definieren des Schemas nicht daran orientieren und mich erst einmal auf MQTT im allgemeinen konzentrieren. Was die Systeme dann aus retained machen soll doch ihnen überlassen bleiben.

Grüße Sidey

Zitat von: Sidey am 21 August 2026, 08:44:41

Code Auswählen Erweitern

<prefix>/<geraete-id>/<kanal>/set Wert auf einem Kanal setzen
<prefix>/<geraete-id>/<kanal>/get Kanalwerte erneut lesen/veröffentlichen


Nein, ein "republish" unter /set kmacht doch das /get obsolet.

Und, nein, unter jedem Kanal ist überflüssig, wenn man auf dem Device (oder sogar auf der Ebene der CCU) beim /set den jeweiligen Kanal und/oder das Device jeweils mitgibt.

Zitat

Code Auswählen Erweitern

<prefix>/bridge/state Status der Homematic-MQTT-Bridge
<prefix>/bridge/info Informationen zur Bridge
<prefix>/bridge/devices Geräte- und Kanal-Metadaten
<prefix>/bridge/request/<aktion> Administrative Bridge-Anfrage
<prefix>/bridge/response/<aktion> Ergebnis einer Bridge-Anfrage


Da bin ich leidenschaftslos. Im Endeffekt sollten idealierweise alle Variablen und alle RPC-Methoden, die ansonsten über die RPC-Schnittstelle abgebildet werden können, in geeigneter Weise in MQTT-Topics abgebildet werden.

Beta-User — Feldtest

Danke für die RSSI-Werte aus der VCCU. Mit dem Pi-PCB am fast gleichen Standort und dem Maple eine Etage tiefer hast Du drei Anbindungen im selben Haus an denselben Geräten — das ist für später viel wert.

Was auf MQTT kommt — und was nicht

Die Brücke bringt, was sie weiß, und deutet nicht. Sie weiß zweierlei: die Werte, je Kanal ein JSON mit den Datenpunktnamen aus der Gerätebeschreibung als Schlüssel; und die Beschreibung selbst auf bridge/devices — Kanäle, Datenpunkte, Typ, Operationen, Grenzen, Einheit, Werteliste. Bei den klassischen Geräten stammt das aus den Gerätebeschreibungen des rfd, bei IP aus der Zentralen-Software, beides aus den veröffentlichten CCU-Quellen. Aufzählungen stehen als der Wert, den das Gerät meldet; die Namen dazu stehen in der Beschreibung, /set nimmt beides an.

Was sie nicht tut: entscheiden, dass Kanal 4 ein Thermostat ist. Das gehört dem, der den Wert verwendet — in FHEM ein Dispatch, json2nameValue und eine Vorlage. Home Assistant bekommt per Discovery nur, was sich aus der Beschreibung mechanisch ergibt: Schalter, Messwert, Zahl, Auswahl, Ereignis, eine Geräteklasse nur wo die Bedeutung feststeht. Ein zusammengesetztes Thermostat kommt von ihr nicht — das sage ich lieber vorher.

retain

Sidey, Dein Einwand ist berechtigt: ein Schema richtet sich nicht nach einer Zentrale. Deshalb ist "behalten" keine Eigenschaft der Themen, sondern eine Einstellung; das Schema beschreibt beide Fälle. Die Voreinstellung bleibt aus, mit dem Vorbild, das Du nennst: in zigbee2mqtt ist retain eine Geräteoption mit Voreinstellung false, behalten werden dort nur die Themen der Brücke. Ralli, für emqx mit ioBroker daneben ist der Schalter da, je Gerät.

Deine eigentliche Sorge trifft der Schalter aber nicht, Ralli: Du willst einen Ort, der Deinen Neustart überlebt. Den gibt es inzwischen — anders als ich am Montag schrieb, sichert die QCCU die zuletzt gemeldeten Werte über den Neustart, und über die Schnittstelle stehen sie sofort wieder bereit. Dafür braucht es keine behaltenen Nachrichten.

set, get, Erreichbarkeit

/set bleibt am Kanal, dazu der besprochene Sammel-Eingang am Gerät für mehrere Kanäle auf einmal. Die Brücke hört auf praefix/+/+/set und hat damit alle Befehle ohne zweiten Ast. Beta-User, Dein Argument für einen Befehlsast vorne ist der reine Zustandsbaum — der bleibt auch so rein, wenn man beim Abonnieren + statt # nimmt: praefix/<geraet>/+ liefert die Kanalebene und nicht die /set-Ebene darunter.

/get ist nicht für die Bestätigung da — die kommt nach jedem /set ohnehin auf dem Wertpfad — sondern für den, der neu verbindet und den Stand will. Pflicht je Gerät und für die Zentrale, Sideys /get je Kanal lasse ich zu. Damit löst sich auch komplett gegen geändert ohne zweiten Zweig: auf dem Kanal-Thema steht, was die Funkmeldung gebracht hat, den Vollstand liefert /get auf demselben Thema.

Erreichbarkeit: englisch, und die Bedeutungen bleiben getrennt, Ralli hat recht. Die Brücke am Broker ist ihr LWT; die Erreichbarkeit eines Geräts ist ein Thema je Gerät, aus dem Funkverkehr abgeleitet, nicht gemessen — und so steht es dann auch da. Sideys Aufteilung übernehme ich samt Zeitstempel nach ISO 8601.

HMLAN

Beta-User, ich habe Deine vier Punkte gegen 00_HMLAN.pm gelesen. Drei stimmen, einer ist andersherum:

- Das Lebenszeichen kommt von FHEM, nicht vom Adapter: das Modul schickt ein K im Takt des Attributs wdTimer, Voreinstellung 25 Sekunden. Der Adapter muss antworten, mit Version, Seriennummer, HMId, Laufzeit, Zahl angemeldeter Adressen und Auslastung. Dreimal keine Antwort, dann trennt FHEM. Eine 45 finde ich im Modul nicht.
- Auf dem Draht liegt kein nacktes BidCoS, sondern Sätze mit Zähler, Status, Zeitstempel und Empfangspegel; die Zeile für den Dispatcher baut FHEM daraus.
- Die Geräteliste stimmt: Adressen werden einzeln an- und abgemeldet, und im Quelltext steht, dass der Adapter die Quittungen selbständig sendet.
- AES stimmt: Schlüssel als eigene Befehle, und der Status jeder Nachricht sagt, ob AES in Ordnung war, fehlschlug oder abgelehnt wurde.

Der Dialekt ist die kleinere Hälfte. Was ein HMLAN gegenüber einem CUL bringt, sind drei Eigenschaften: Quittung im Gerät, Zeitstempel aus dem Gerät, AES im Gerät. Die hängen an der Firmware, nicht am Dialekt — und AES im Stick ist das Stück, das ich offen gelassen habe. Deshalb die Rückfrage: geht es Dir um den Dialekt, weil Deine Anlage daran hängt, oder um die drei Eigenschaften? Beim zweiten ist es dieselbe Baustelle wie noansis Kanal-Quittungen.

Ralli, Deine Frage von Montag

Warum aus FHEM-Sicht nicht alles über HMCCU läuft — die bin ich Dir schuldig geblieben, und die Lage hat sich geändert. Seit gestern spricht die QCCU bei mir im Labor auch die zweite Schnittstelle einer Zentrale, die für die klassischen Geräte; gegen Home Assistant angelernt und geschaltet, gegen HMCCU noch nicht, veröffentlicht noch nicht. Wenn das hält, ist die Antwort nicht mehr "CUL_HM, weil es das Einzige ist, was geht", sondern eine Wahl: HMCCU bringt beide Familien nach FHEM, CUL_HM bleibt für alle, die ihre Einrichtung nicht anfassen wollen.

Dabei ist mir etwas aufgefallen, das ich früher hätte erwähnen sollen: Homematic nach MQTT gibt es längst. Den CCU-Jack seit Jahren, und seit Mai OpenCCU-Loom, das MQTT samt Home-Assistant-Anmeldungen, Matter und REST in einem Dienst macht. Beide docken an einer Zentrale an — an genau der Schnittstelle, die die QCCU nachbildet. Wer eine Zentrale hat, für den ist die Frage beantwortet; hier fehlt nicht der Konverter, sondern die Zentrale darunter.

Deshalb zwei Fragen, bevor ich das Schema festklopfe:

- Wofür soll der Bus da sein? Für FHEM selbst — dann ist HMCCU der kürzere Weg und MQTT der Umweg. Oder für die anderen Systeme am selben Broker — dann zählt, dass ein vorhandenes Schema passt, mehr als jede FHEM-Optimierung.
- Und falls Letzteres: was fehlt den beiden vorhandenen Konvertern, dass sie hier niemand nennt? Der CCU-Jack fährt ein Thema je Datenpunkt und behält die Zustände — also genau das, wogegen wir heute früh entschieden haben. Wer hat ihn im Einsatz, und was hat gestört?

Zitat von: tostmann am 21 August 2026, 14:48:16Danke für die RSSI-Werte aus der VCCU.

define VCCU CUL_HM ....
#   CUL_CUL_MSGCNT 28
#   CUL_CUL_RAWMSG A102FA001425EE22BD9AE01040000000001::-68.5:CUL_CUL
#   CUL_CUL_RSSI -68.5
#   CUL_CUL_TIME 2026-08-21 16:02:53

#   mapleCUN1_MSGCNT 66
#   mapleCUN1_RAWMSG A0F8C803F425EE22E7A9C0202321B22DC::-67.5:mapleCUN1
#   mapleCUN1_RSSI -67.5
#   mapleCUN1_TIME 2026-08-21 15:53:16
#   myHmUART_MSGCNT 80
#   myHmUART_RAWMSG 0500003E2FA001425EE22BD9AE01040000000001
#   myHmUART_RSSI -62
#   myHmUART_TIME 2026-08-21 16:02:53
#   protLastRcv 2026-08-21 16:02:53
#   protRcv    128 last_at:2026-08-21 16:02:53
#   protRcvB   8 last_at:2026-08-21 13:52:28
#   rssi_at_CUL_CUL cnt:25 min:-75 max:-64 avg:-67.83 lst:-68.5
#   rssi_at_mapleCUN1 cnt:53 min:-71.5 max:-66.5 avg:-68.47 lst:-67.5
#   rssi_at_myHmUART cnt:80 min:-71 max:-59 avg:-62.21 lst:-62
...
#     io:
#       nextSend   1787320973.48901
#       vccu       VCCU
#       ioList:
#         CUL_CUL
#         HmUART_Maple
#         mapleCUN1
#         myHmUART
#       prefIO:
#         myHmUART
#         mapleCUN1
#         HmUART_Maple
#         CUL_CUL
#     mRssi:
#       mNo        2F
#       io:
#         CUL_CUL:
#           -68.5
#           -68.5
#         mapleCUN1:
#         myHmUART:
#           -58
#           -58
#     peerIDsH:
#     prt:
#       bErr       0
#       sProc      0
#       rspWait:
#     q:
#       qReqConf  
#       qReqStat  
#     role:
#       dev        1
#       vrt        1
#     rssi:
#       at_CUL_CUL:
#         avg        -67.84
#         cnt        25
#         lst        -68.5
#         max        -64
#         min        -75
#       at_mapleCUN1:
#         avg        -68.4716981132076
#         cnt        53
#         lst        -67.5
#         max        -66.5
#         min        -71.5
#       at_myHmUART:
#         avg        -62.2125
#         cnt        80
#         lst        -62
#         max        -59
#         min        -71
#     tmpl:
#
Zur Interpretation der RSSI-Werte noch:
FHEM bzw. die VCCU lief bereits, als der qccu-CUL als CUL_CUL-IO dazu gekommen ist. Da ist eine (damals mit gekaufte) externe Antenne dran (mit Magnetstandfuß, ca. 10-12 cm hoch). Am Pi-PCB und dem Transceiver am Maple hängt je eine Stumme-Schraubantenne.

Zitat von: tostmann am 21 August 2026, 14:48:16Die Brücke bringt, was sie weiß, und deutet nicht.

Der Ansatz gefällt mir gut, das MQTT-seitig als transparente Brücke (ohne allzu große Interpretation) zu verstehen!
Zum Thema "subscription" einfach halten mit "+"-Wildcard: auch volle Zustimmung!

Zitat von: tostmann am 21 August 2026, 14:48:16Deshalb die Rückfrage: geht es Dir um den Dialekt, weil Deine Anlage daran hängt, oder um die drei Eigenschaften?

Auf den Dialekt "HMLAN" bin ich gekommen, weil ich mir die Frage gestellt hatte, wie man die drei Eigenschaften "näher an den Transceiver" bekommen könnte, ohne in FHEM neue IO-Module einzuführen (also anders, als wie TSCUL es benötigt). Ob die "Eigenschaften" dann aus der firmware kommen, oder von qccu als Zwischenschicht erzeugt werden, ist dabei sekundär. Wichtig ist imo v.a., dass man den FHEM-Prozess von der Aufgabe trennt, diese Teile auch noch mit abzuarbeiten.

Zwischenbemerkung: Großes Dankeschön an noansi zu den heute kritischen Punkten in der "normalen" culfw!!!

Wenn man bei der Gelegenheit dann als "Bonus" noch eine (noch) stabilere firmware auf den Stick bekommt, "lohnt" sich aus meiner Warte der Umweg über den Container. Wenn der Weg zwischen dem "besseren CUL" und FHEM letztlich nur länger wird, eher nicht. Mein klares Ziel für meine heutige BidCoS-Welt ist jedenfalls, die nach Möglichkeit nicht anzufassen. Eventuell doch noch HMIP-Geräte mit einbinden zu können, ist für mich ein bloßes Options-Gimmik ohne allzu großen Reiz.

Wie immer: meine 2ct.

Kurze Zwischeninfo: der qccu-CUL ist nach wie vor "online", bisher keine Auffälligkeiten, fhem-uptime sind 17 Tage (cul-update-Anfrage via FHEMWEB wird nicht beantwortet/läuft in einen timeout).
Vermutlich mache ich demnächst ein FHEM-update, also bitte um einen Schubs, falls Interesse an irgendwelchen Daten besteht.

Hallo Beta-User,

Zitat(cul-update-Anfrage via FHEMWEB wird nicht beantwortet

Ich nehme an, Du meinst uptime, sprich, das 't' Kommando wird nicht beantwortet.
EDIT: welche Cmds werden gemeldet? get raw ? Antwort?

Bezogen auf HM ohne IP:
Wie viele HM-devices sind ihm denn zugeordnet und wie sehen die protoEvents dazu aus?

Gruß, Ansgar.

Ups, klar, "uptime" war gemeint.

get cmds liefert 
CUL_CUL cmds =>  A V X T

Zitat von: noansi am 06 September 2026, 18:06:56Wie viele HM-devices sind ihm denn zugeordnet und wie sehen die protoEvents dazu aus?

Meine Installation läuft vollständig mit automatischer IODev-Verwaltung, es sind derzeit keine ausdrücklichen Zuordnungen (mehr) vorhanden. Da die anderen beiden IOs vorher schon unter der VCCU liefen und der CUL erst im laufenden Betrieb dazukam, scheint es bislang weiter so zu sein, dass die Kommunikation mehr oder weniger ausschließlich über das Pi-Modul (HMUARTLGW) bzw. den MapleCUL läuft, vorrangig (und wenig überraschend) meint mein HMinfo-Device (bzw. franks HMInfo-Tools), dass das sich im jeweiligen Stockwerk befindliche IO im ranking die Nase vorn hat.
Was mich etwas überrascht hat: Da taucht der CUL überhaupt nur bei den Devices auf, die seit der (Wieder-) Inbetriebnahme des CUL irgendwelche Probleme hatten (Strom weg oder die Batterien getauscht...).

protoEvents meldet dementsprechend auch (fast) keine Probleme, im Moment hängen noch ein paar Konfigurations-cmds an einen (bekanntermaßen zickigen) HM-SEN-MDIR-O.

Beantwortet das (halbwegs) die Frage?

Hi,

Gibt es schon was neues bezüglich des HMUART Adapters oder könnte ich da irgendwas helfen?

Wenn ja, dann bräuchte ich den Punkt, an dem ich was tun könnte. Aktuell verstehe ich noch zu wenig von der Gesamtarchitektur :(

Grüße Sidey

ZitatCUL_CUL cmds =>  A V X T

Ok, 't' wird nicht gemeldet, also auch nicht zu erwarten, dass uptime funktioniert.
Eher eine Schwäche des CUL Moduls, es dennoch zu probieren, statt eine Fehlermeldung auszuwerfen oder uptime gar nicht erst anzubieten.

ZitatWas mich etwas überrascht hat: Da taucht der CUL überhaupt nur bei den Devices auf, die seit der (Wieder-) Inbetriebnahme des CUL irgendwelche Probleme hatten (Strom weg oder die Batterien getauscht...).

Der RSSI muss besser sein und eine Kommunikation muss von FHEM inititiert werden, damit ein IO Wechsel stattfinden kann.
Beim Antworten (ACK) darf ein IO-Wechsel nicht stattfinen, weil HM-LAN/HMUARTLGW/TSCUL schon geantwortet hätten oder noch antworten würden, CUL aber noch vom CUL_HM aus muss. Ebenso im Lauf von Multi-Message Kommunikation ist ein IO-Wechsel nicht günstig, wegen Zeitaufwand.
Totes oder überlastetes bisheriges IO ist ein sonstiger Wechselgrund.
Ein "unmotivierter" IO-Wechsel zwischendurch oder beim Empfang mit besserem RSSI ist nicht vorgesehen.
FHEM-Neustart behält den letzten Zustand, gibt ja dann auch noch keine RSSI-Info.
Also mal manuell motivieren, z.B. einem IO eine Weile den Stecker ziehen.

Gruß, Ansgar.

Danke euch beiden. Bestätigt: uptime, also das t-Kommando.

Die cmds-Zeile zeigt es: der CUL-Zugang von QCCU meldete "A V X T", beantwortete aber nur V, ? und T01 (und nahm As entgegen). t stand nicht in der Liste, X und C<hh> wurden verworfen. uptime, fhtbuf, credit10ms und raw liefen damit in den 3-s-Timeout von CUL_ReadAnswer, und der generische Zweig von CUL_Get ruft dann DevIo_Disconnected: Verbindung weg, Neuanmeldung (V, ?, X21, Ar, T01). Daher der Neuaufbau im Log. Nur ccconf gibt bloß den Timeout zurück.

Behoben in 2026.9.7. cmds lautet jetzt "A C T V X t", so antwortet eine laufende Zentrale:

V      V 2.0.92 q-culfw
?      ? (? is unknown) Use one of A C T V X t
t      00001B6A        -> uptime 0 00:00:56
T03    00              -> fhtbuf (kein FHT hier)
X      21 900          -> credit10ms des Sticks
C0D    C0D = 21 / 33
C0E    C0E = 65 / 101
C0F    C0F = 6A / 106
C10    C10 = C8 / 200
C1B    C1B = 43 / 67
C1D    C1D = 91 / 145
C3F    ?              -> quittiert, nicht ausgeführt
W0F21  ?
B01    ?

get ccconf ergibt daraus freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB. Dafür war eine Umschrift nötig: der Stick antwortet C0D=21, CUL_Get prüft ^C.* = .* und nimmt den Dezimalwert aus dem fünften Feld. t kennt der Stick nicht; die Zentrale antwortet mit ihrer eigenen Laufzeit in 8-ms-Ticks.

Ansgar, zu #28: ja, CUL_Get prüft nur %gets, nicht CMDS — das t geht auch an einen Stick, der es nie angeboten hat. Trotzdem mein Fehler: wer sich als CUL ausgibt, muss t können und melden. Zu get raw: Unbekanntes quittiert der Zugang jetzt mit "? " wie der Stick selbst, kostet also nicht mehr die Verbindung. Ausgeführt wird davon nichts: W0F/W10/W11, B01 und C<hh> oberhalb 0x2E bleiben draußen und stehen als verworfen im Protokoll der Zentrale. Grund ist die zweite Familie am selben Stick: ein verstellter Träger oder ein Sprung in den Bootlader legt die HmIP-Seite mit still, und 0x3F ist der RX-FIFO.

IO-Wechsel: deine Erklärung in #28 trifft es besser als meine Vermutung; der Nebensatz (beim Antworten kein Wechsel, weil HM-LAN/HMUARTLGW/TSCUL selbst quittieren, der CUL aber von CUL_HM aus) ist die Trennlinie für alles Weitere. Beta-User: den CUL-Anteil siehst du, wenn du einem der anderen IOs eine Weile den Stecker ziehst. Nach dem FHEM-Update wären list <cul> und get <hminfo> protoEvents short interessant, vor allem ob der HM-SEN-MDIR-O über ihn läuft. Nimm 2026.9.7 vor dem FHEM-Update mit, dann hast du beide Wechsel in einem Rutsch.

Sidey, zur Richtung: nicht ,,noch ein FHEM-Modul", sondern wer quittiert.

HM-LAN, HMUARTLGW und TSCUL quittieren selbst, der CUL lässt quittieren. Der Stick kann es seit 19.08. auch: Aa setzt die eigene Adresse, Aq1 schaltet die Selbstquittung ein (100 ms nach Empfang), und die später vom Wirt gebaute Quittung schluckt er — sonst lag sie doppelt auf dem Funk, byte-gleich im Abstand von 23 ms. Einschalten darf man das nur, wenn der Wirt schweigt, und mit dem gewöhnlichen CUL-Modul tut er das nicht: CUL_HM prüft IODev->{helper}{VTS_ACK}, gesetzt wird das allein von 00_TSCUL.pm, nicht von dem, was in FHEM mitkommt.

Dazu kommt, was der Stick nicht wissen kann: ob noch etwas ansteht. Ein Wakeup-Gerät braucht das Wach-Bit in der Quittung, sonst schläft es ein und der wartende Befehl verpasst sein Fenster — genau das würde eine blinde Selbstquittung verursachen. Das Gegenstück gibt es (Aw<Adresse>, Aw000000 wenn nichts ansteht), sagen muss es der Wirt, so wie CUL_HM es mit $wulzy führt. Dasselbe für aesCommReq (Challenge statt Quittung) und Sensoren mit ACK-Status (motionDetector, HM-SEC-SC). CUL_HM baut das je Gerät längst zusammen — hmInitMsg mit Adresse, Flags, Schlüsselindex, AES-Maske — gibt es aber nur an HMLAN, HMUARTLGW und IOs mit VTS_AES weiter.

Was fehlt, ist die Zahl, die das rechtfertigt. Am 19.08. gemessen quittiert CUL_HM sieben Frames hintereinander nach 100–101 ms ohne eine einzige Wiederholung des Geräts; die 100 ms sind in 00_CUL.pm Absicht ($waitTgt). Der Gewinn liegt also nicht im Normalbetrieb, sondern wo der Wirt die Frist nicht hält: über Netz, unter Last, oder wenn er gar nicht quittiert. Beta-User, deshalb sind deine protoEvents mehr wert als jede Messung hier: ohne Resends ist die Quittung bei dir nicht das Problem, und ich baue an der falschen Stelle.

Ansgar, dazu brauche ich dich: welchen Zustand führt TS-CUL je Gerät, und was liefert der Wirt zur Laufzeit nach? Was der Stick hat (eine Adresse, ein Wach-Bit für eine Gegenstelle, Duplikat-Schlucken), ist die Fassung für ein Gerät; für mehrere braucht es je Gerät einen Eintrag, und die Duplikatprüfung vergleicht heute nur Zähler und Ziel — eine abweichende Quittung des Wirts würde sie ebenfalls schlucken.

Sidey, HMUARTLGW-Emulation: als Erkundung lohnt sie nicht, was FHEM einem IO mitgibt, steht in 00_HMUARTLGW.pm und 10_CUL_HM.pm. Sinn hat sie, wenn QCCU diese Schnittstelle am Ende anbietet — dann als Alternative zum CUL-Weg, nicht als Vorprodukt: das Modul erwartet vom IO das komplette Sendeverhalten samt Wiederholungen, Credits und AES. Beides zu pflegen ist unrealistisch.

Wenn du dafür bist, ist der Anmeldeautomat das Stück ohne Funk: 16 Zustände (STATE_QUERY_APP bis STATE_SET_TEMP_KEY) bis RUNNING, bei der LAN-Variante ein zweiter Port mit KeepAlive alle 10 s und optional Rijndael mit MD5(lgwPw) als Schlüssel. Zwei Stolpersteine: das Modul schickt einen laufenden Coprozessor beim Start per CHANGE_APP erst in den Bootlader zurück, die Gegenstelle muss damit anfangen; und die Antwort auf ADD_PEER trägt AssignedPeerCnt, taugt also nicht als feste Tabelle. Erfolgskriterium: cond = ok, KeepAlive läuft, je Gerät ein ADD_PEER im Log, bei aesCommReq zusätzlich PEER_ADD_AES. Dafür lieber ein eigenes Thema.

Zitat von: tostmann am 06 September 2026, 22:51:48Nimm 2026.9.7 vor dem FHEM-Update mit, dann hast du beide Wechsel in einem Rutsch.

So, die Quiche ist aktuell, die firmware auch, update mit "ohne" Button war kein Problem, Danke!

Das HMUARTLGW stecke ich heute nachmittag mal eine Zeitlang aus, dann sollte der CUL tatsächlich auch was zu tun bekommen.

Der Maple hat es die Nacht über übrigens nicht geschafft, die (zur Änderung angeforderte) peer-Liste im Bewegungsmelder zu aktualisieren. Hab's jetzt neu gestartet, aber vermutlich muss ich das Ding doch von der Wand holen, um den Knopf zu drücken...

Hmmm, seltsam...

Als ich vorhin nach Hause gekommen bin, waren im OG noch alle Rollläden zu. Sollte eigentlich anders sein. Den HMUART (USB) abgestöpselt und versucht, die Rollläden im Büro (auch OG) zu öffnen - missing ack, IODev wäre nach dem Internal der CUL gewesen.

Wie es aussieht, war nach dem Neustart des ganzen Rechners heute morgen zwar der QCCU-Container automatisch mit gestartet, und auch der CUL beantwortete alle Anfragen (insbesondere nach der version) korrekt, aber im Endergebnis war anscheinend die gesamte BidCoS-Kommunikation tot - zumindest von FHEM aus.

Habe dann den HMUART wieder angestöpselt und mal die Hoch-Taste an einem der Aktoren gedrückt - Schwups war IODev das HMUARTLGW und ich konnte dann auch wieder von FHEM aus steuern. Entsprechendes gilt für die anderen Aktoren: Alle erst dann steuerbar, wenn mal eine der Tasten gedrückt wurde und das IODev damit eines der anderen beiden IO's wurde.

Dementsprechend listet HMinfo auch bei den protoEvents aller bestromten CUL_HM-Devices Fehler auf, auszugsweise:
name                      :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    Aussenlichter             : done           |  -       | 20       | 3        # 2        | 1        |  -       |  -       
    Balkontuer                :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    Bewegungsmelder_1         : pending        | 4 pending|  -       |  -       #  -       |  -       |  -       |  -       
    Bodenkonvektor            : done_Errors:1  |  -       | 24       | 72       # 24       | 24       |  -       |  -       
Kann sich einer einen Reim darauf machen?
Eigentlich hätte sich doch die IODev-Zuweisung nach den weiter in configDB abzurufenden IODev-Readings richten sollen, oder habe ich da was falsches im Kopf?

Hallo Beta-User,

ZitatKann sich einer einen Reim darauf machen?

Kommunikationsprobleme nur mit raw Logging, um zu sehen, was rein kommt/ob überhaupt was rein kommt.
Da die Aktoren via FHEM auch nicht geschaltet haben, wäre mit anderem IO mitzulauschen, ob überhaupt was und/oder was raus geht.

ZitatEigentlich hätte sich doch die IODev-Zuweisung nach den weiter in configDB abzurufenden IODev-Readings richten sollen, oder habe ich da was falsches im Kopf?

Es wird das Reading vom device bei der IO-Zuweisung gelesen, nicht aus configDB.
In configDB wird das Reading beim shutdown geschrieben und beim Start wieder daraus restauriert.
Jede IO-Zuweisung aktualisiert das Reading auf das gewählte IO. War nach Deiner Beschreibung CUL vor Tastendruck.

Du hast HMUARTLGW angstöpselt, Taste gedrückt -> HMUART empfängt Tastendruck mit (RSSI besser als CUL?!?),
Ansteuerung via FHEM -> neue Kommunikation gestartet -> neue IO Zuweisung auf HMUART -> geht wieder. Wäre mein Reim darauf.

Gruß, Ansgar.

Bevor ich zu deinem Befund etwas sagen kann, brauche ich eine Zahl aus QCCU: der CUL-Zugang zählt mit, was er empfängt. Sie steht nur im JSON-Zustand, nicht in der Oberfläche — Adresse deiner QCCU-Oberfläche plus /api/state:

curl -s http://<rechner>:8080/api/state | jq .cul

Ohne jq tut es der Browser, dann im Text nach "cul" suchen. Bitte vor einem Neustart des Containers ablesen, die Zähler laufen seit dem Start.

rx sind die BidCoS-Rahmen, die der Zugang vom Stick bekommen und an FHEM weitergereicht hat, tx die Sendungen von FHEM, klienten die anliegenden Verbindungen. Steht rx auf 0, während tx zählt, hat QCCU gesendet und nichts gehört — dann liegt es bei mir. Ist rx hoch, kam Funk herein, und die Ursache liegt woanders.

Zwei Einordnungen noch: Die protoEvents-Zähler laufen kumulativ seit FHEM-Start und werden nicht nach IO getrennt geführt — der Verkehr über das HMUARTLGW steckt in denselben Werten, der Unterschied zwischen deinen beiden Aktoren lässt sich also keinem der beiden Interfaces zuordnen. Und lehnt der Stick eine Sendung ab, reicht QCCU das derzeit nicht an FHEM durch (ein echter CUL meldet dort LOVF) — ein missing ack unterscheidet bei uns damit nicht zwischen "nicht gesendet", "nicht gehört" und "Quittung nicht angekommen". Das ändere ich unabhängig davon, was bei dir die Ursache war.

Zitat von: tostmann am 07 September 2026, 20:39:51Ohne jq tut es der Browser, dann im Text nach "cul" suchen. Bitte vor einem Neustart des Containers ablesen, die Zähler laufen seit dem Start.

Das hier, oder:
cul
port 2000
klienten 1
rx 3087
tx 1326
verworfen 0
letzte_unbekannt null
Der Container läuft noch, den Stick hatte ich zwischendurch abgezogen, s.u.
Sieht also unauffällig aus, oder missverstehe ich das?

Zitat von: noansi am 07 September 2026, 19:49:22Da die Aktoren via FHEM auch nicht geschaltet haben, wäre mit anderem IO mitzulauschen, ob überhaupt was und/oder was raus geht.

Tja, sniffen wäre eine Idee... Bisher war ich davon ausgegangen, dass die Hardware ok sein müßte. Falls @tostmann rückmeldet, dass die firmware nicht kaputt gegangen sein könnte, versuche ich mich einzuarbeiten oder das Ding nochmal mit der normalen culfw zu flashen.

Zitat von: noansi am 07 September 2026, 19:49:22In configDB wird das Reading beim shutdown geschrieben und beim Start wieder daraus restauriert.

Schon klar. Die eigentliche Frage war: Warum werden die alten Reading-Werte anscheinend nicht übernommen?!? Vor dem Neustart schien alles soweit ok zu sein, nur dass halt - wie beschrieben - effektiv nur bei "problematischen" Devices irgendwann mal überhaupt der CUL mit im Spiel war, aber nicht gestört hat. Also war ich davon ausgegangen, dass selbst bei Problemen mit dem CUL nach dem Neustart erst mal ohne manuellen Eingriff alle IO's wie vorher genutzt werden.
Erst hatte ich vermutet, dass der CUL den "babbling idiot" mimt, aber dann hätte es nach dem Wiedereinstöpseln des HMUARTLGW auch nicht funktionieren dürfen (?). Diese CUL hatte ich - soweit ich mich entsinne - erst ausgestöpselt, nachdem die erste Neuzuordnung durch war, um danach zu testen, ob dann andere Aktoren angesprochen werden können, Ergebnis ist bekannt... 

So stellt sich imo v.a. die Frage, warum CUL_HM-VCCU unbedingt (trotz gegenteiliger Vorgaben aus den Reading-Werten) diese CUL als IO verwenden will, obwohl die Kommunikation darüber offenkundig (keine ACKs) gestört ist. Möglicherweise täten wir gut daran, die Module nochmal auf die diesbezügliche Logik zu checken?
Edit: eventuell hängt es auch an der von @tostmann genannten fehlenden Unterscheidung der weitergegebenen Infos? Den Teil hatte ich eigentlich schon fertig geschrieben und den möglichen Zusammenhang leider erst etwas später realisiert.)

Hallo Beta-User,

Zitatobwohl die Kommunikation darüber offenkundig (keine ACKs) gestört ist.

Ich erinnere mich nicht daran, dass das je ein Grund für einen IO-Wechsel gewesen wäre.

Keine ACKs lässt per se nicht auf ein gestörtes IO schließen. Ebenso (und im Normalfall wahrscheinlichst) kann das anzusprechende device tot sein.

Gestörtes IO geht über dass Reading cond und das Internal XmitOpen bei HMLAN, HMUARTLGW und TSCUL. Bei CUL lediglich über disconnected state.

Um das richtig zu klären, schlage ich vor, an einem device das ganze Vorgehen nochmal step by step mit jeweiligem List von IOs und device davor und danach durchzuführen.
Sonst verschwimmen die relevanten Details in der Erinnerung.

Gruß, Ansgar.

Firmware: nach allem, was der Code hergibt, nicht kaputt. ,,V 2.0.x q-culfw" bei get version kommt vom Stick selbst, rx 3087 heißt: er empfängt, dekodiert und liefert ab. Den Flash beschreibt im Betrieb allein der Bootlader, und dorthin schickt QCCU den Stick nur beim Firmware-Einspielen über die Oberfläche. Kippen kann im Betrieb nur Laufzeitzustand, und den hat das Abziehen zurückgesetzt. Zurückflashen auf culfw setzt nichts weiter zurück; lass es. Nicht ausschließen kann ich, dass der Stick während des Ausfalls Sendungen abgelehnt hat.

Dauersender: ausgeschlossen, jede Sendeschleife der Firmware ist zeitlich begrenzt.

Die Zähler laufen seit dem Start des Containers: rx 3087 = BidCoS-Rahmen vom Stick an die Klienten, tx 1326 = Sendungen von FHEM an den Stick, verworfen 0, klienten 1. Ob die 1326 hinausgingen, steht nicht darin; die Zähler des Sticks (txerr, lovf) mischen HmIP und BidCoS und stehen seit dem Abziehen wieder auf null.

Verdacht, kein Befund: Sendezeit-Konto leer. Es ist eines für HmIP und BidCoS zusammen; über den Tag verteilt fahren 1326 Sendungen es nicht leer, eine Ballung schon (FHEM-Neustart, alle Geräte auf dem CUL). Wenn der Rohmitschnitt lief (raw_log in der Add-on-Konfiguration, Knopf ,,Rohmitschnitt laden"):

grep -c "Ps ERR" qccu-luft.log

VCCU (noansi in #35): CUL_HM hält einen CUL für sendebereit, solange state nicht disconnected ist; ausbleibende ACKs gehen in dieses Urteil nicht ein. Ohne prefIO gewinnt das IO mit dem besten zuletzt empfangenen RSSI, und der CUL hört weiter — so bleibt er vorn, obwohl über ihn nichts ankommt. Die Verbindung kappen, damit state disconnected greift, mache ich nicht: FHEM verbindet erst nach 60 s neu, dazwischen fehlt der Empfang ganz, und ein leeres Konto ist nach Sekunden bis einer Minute wieder voll genug.

Neu in 2026.9.8, liegt als Add-on-Update bereit: meldet der Stick Ps ERR LOVF, bekommt FHEM die Zeile LOVF wie von einem CUL; bisher fiel sie unter den Tisch. FHEM loggt sie als ,,Unknown code LOVF" (Loglevel 3), CUL_HM wertet sie nicht aus. /api/state zählt unter cul.lovf und cul.sendefehler nur die FHEM-Seite; für andere Sendefehler gibt es keine Zeile, nur den Zähler.

Nächster Durchgang, nach noansis Vorschlag:

1. Add-on auf 2026.9.8, raw_log einschalten.

2. Netzversorgten Aktor auf den CUL legen:
attr <aktor> IOgrp <vccu>:<cul>

3. Stand vorher:
list <aktor>
list <vccu>
list <cul>
Gebraucht: IODev, rssi_at_*, protState beim Aktor; state, IOopen bei der VCCU; state beim CUL.

4. Befehl absetzen, Uhrzeit notieren:
set <aktor> statusRequest

5. Dieselben drei Lists noch einmal.

Quittung da: Sendeweg belegt. missing ack:

grep LOVF fhem.log
curl -s http://<rechner>:8080/api/state | jq .cul
grep "Ps ERR" qccu-luft.log

Rückmeldung: die Lists, die LOVF-Zeilen mit Zeitstempel, der Stand von cul.lovf. Danach IOgrp zurücksetzen.

Noch als Ergänzung zu "Ohne prefIO":

ZitatOhne prefIO gewinnt das IO mit dem besten zuletzt empfangenen RSSI, und der CUL hört weiter — so bleibt er vorn, obwohl über ihn nichts ankommt

Wenn noch keine RSSIs zum device vorliegen (oder die IOs mit RSSI nicht funktional sind), dann wird das erste funktionale IO aus der IOList der VCCU zugegordnet. Die IOList ist zwangsweise alphabetisch sortiert, CUL steht da mit hoher Warscheinlichkeit vorne!

Zitat von: tostmann am 08 September 2026, 13:14:161. Add-on auf 2026.9.8, raw_log einschalten.

Bin jetzt auf 2026.9.9, allerdings starte ich den container via "docker run". Vermutlich übersehe ich was, aber im Web-IF der Quiche ist nichts zu finden, und Einschalten über configuration.yaml oder HASS-Add-on scheint es auch nicht zu geben?
Kann man das auch via docker run starten? Auf die Schnelle blieb meine diesbezügliche Suche erfolglos.

Wie dem auch sei, ich mache erst mal mit den vorhandenen Mitteln weiter:

Das Sendebudget zeigt derzeit aber 900 oder nahe dran an, habe bisher nur den Container selbst aktualisiert und FHEM noch nicht neu gestartet. Der qCUL antwortet auf version und uptime, firmware ist unverändert die derzeit aktuelle (V 2.0.92 q-culfw). Antenne sitzt bombenfest angeschraubt.

Zitat2. Netzversorgten Aktor auf den CUL legen:

Der hier war noch auf qCUL als IO, man sieht den erfolglosen Steuerungsversuch von eben:
setstate Rollladen_Treppenhaus 2026-09-08 17:22:01 IODev CUL_CUL
setstate Rollladen_Treppenhaus 2026-09-08 17:22:17 commState CMDs_done_Errors:1
Jetzt starte ich den Rechner erst mal neu, damit die RSSI-Werte die Chance auf einen einheitlichen Anfang haben.

Neustart, erst mal gleiches Bild: qCUL ist in FHEM verfügbar, Aktoren lassen sich nicht steuern, die ihn als IODev haben. Das Web-Interface meldet 900/900 verfügbares budget, das nimmt nach (erfolglosen) Versuchen auch kurzfristig ab. Es kommt also was beim der QCCU an.

In der VCCU sind zwar alle drei IO's "ok", RSSI-Werte sind im Moment aber nur bei den beiden anderen zu sehen (beide Richtungen).

prefIO gesetzt für einen toten Aktor auf den MapleCUL: läßt sich steuern, nach dem Befehl habe ich RSSI-Werte in der VCCU auch für den qCUL:

define VCCU CUL_HM 425EE2
#   CUL_CUL_MSGCNT 2
#   CUL_CUL_RSSI -70.5
#   CUL_CUL_TIME 2026-09-08 17:56:52
#   mapleCUN1_MSGCNT 36
#   mapleCUN1_RSSI -72.5
#   mapleCUN1_TIME 2026-09-08 17:52:59
#   myHmUART_MSGCNT 82
#   myHmUART_RSSI -67
#   myHmUART_TIME 2026-09-08 17:56:52
#   rssi_at_CUL_CUL cnt:2 min:-70.5 max:-70.5 avg:-70.5 lst:-70.5
#   rssi_at_mapleCUN1 cnt:36 min:-74 max:-71.5 avg:-72.68 lst:-72.5
#   rssi_at_myHmUART cnt:82 min:-67 max:-7 avg:-9.42 lst:-67
Sieht so aus, als würde der qCUL an sich funktionieren, aber jetzt ist erst mal Schluss mit Testen.

Nachtrag noch - Stand eben  meldet die QCCU im Webinterface:
Stick meldet
    V q-culfw 2.0.92
Angeschlossen
    /dev/serial/by-id/usb-busware.de_q-culfw_85330323834351E0A1C1-if00
Empfangen
    5254 beide Familien · entschlüsselt 1587 · Quittungen 0 · gesendet 1501
Nicht für uns
    3667 — meist BidCoS, kein Fehler

Sendezeit900 / 900
Rauschboden-114 dBm · Spitze -19 dBm


Richtig, einen Laufzeitschalter gab es nicht - nur den Startparameter, bei docker run -e RAW_LOG=1 plus Neustart des Containers.

2026.9.10 ist raus und kann es ohne Neustart: Knopf "Mitschnitt einschalten" auf der Startseite, oder per Skript:

curl -X POST -H "Content-Type: application/json" -d '{"an":true}' http://<rechner>:8080/api/mitschnitt

Download über "Rohmitschnitt laden", auch nach dem Ausschalten. Einschalten hängt an eine vorhandene Datei an - älterer Inhalt kann also mit drinstehen, Zeitstempel beachten.

Zum Sendebudget: der Wert misst den Moment der Abfrage, nicht den des Ausfalls. Entscheidender ist, was in deiner Zeile FEHLT - hinter "gesendet 1501" stünde ein "Fehler <n>", wenn der Stick auch nur eine Sendung abgelehnt hätte. Der Zähler dahinter fasst LOVF und die übrigen Sendefehler beider Familien zusammen und steht bei dir auf null, über den ganzen Zeitraum seit dem Neustart. Das Konto ist damit aus dem Verdacht.

Ich habe unterdessen nachgeholt, was mir gefehlt hat: der Sendeweg dieser Firmware war bei uns nur für 2.0.50 on-air belegt, nicht für 2.0.92. Jetzt ist er es. Drei Rahmen über denselben Weg, den du benutzt - TCP-Klient an Port 2000 -, mitgeschnitten von zwei unabhängigen Empfängern (anderer Chip, andere Antenne, anderer Rechner), byte-identisch, ohne Fehlermeldung des Sticks; vom Eintreffen der Zeile bis zum Schreiben an den Stick vergingen 3 bis 7 ms. Der Rahmen verlässt den Stick also korrekt geformt. Was das NICHT belegt: die absolute Sendeleistung, und dass ein Rahmen mit anderem Inhalt genauso hinausgeht.

Damit ist die Frage nicht mehr, OB etwas hinausgeht, sondern ob es ankommt. Und das kannst du mit deiner eigenen Hardware trennen, ohne dass ein Gerät antworten muss: lass den qCUL senden, während ein anderes deiner IOs lauscht. Taucht der Rahmen dort auf, sendet der qCUL - dann liegt es an Pegel, Antenne oder Bindung. Taucht er nicht auf, ist es die Sendeseite deines Sticks, und wir suchen dort weiter.

Dazu wie in #36: Mitschnitt an, statusRequest, Uhrzeit notieren. Zurück brauche ich die Zeilen beider IOs mit Zeitstempel.

Kurze Zwischeninfo: update gemacht und den CUL_CUL umbenannt zu qCUL. prefIO an der VCCU weist den qCUL jetzt erst zuletzt zu.

Jetzt funktioniert die Installation grundsätzlich wieder, es scheint die Sendeseite des CUL zu sein, die zickt. Hier ein kurzer Auszug aus dem luft-log:
05:29:17.303 >> As0E23A011425EE252A1D00201000000  [ask]
05:29:18.162 >> m  [probe]
05:29:18.164 << Pm ein rolle=Zentrale addr=302BED key=1 sn=A2410CB2 ack=1 icmpack=1 router=0 nurlesen=0 relais=0
05:29:18.164 << Pm budget=1 credit=899/900 lovf=0
05:29:18.168 << Pm rx=7978 ok=2349 mic=5629 dup=0 acks=0 k6tx=0 k6rx=0 akdop=0 fwd=0 tx=2957 txerr=0 burst=0 pll=0/0/0 recal=149 noise=-115 npk=-19
05:29:18.173 >> V  [ask]
05:29:18.173 << V q-culfw 2.0.92
05:29:20.235 >> m  [probe]
05:29:20.236 << Pm ein rolle=Zentrale addr=302BED key=1 sn=A2410CB2 ack=1 icmpack=1 router=0 nurlesen=0 relais=0
Der angesprochene Aktor hat (via qCUL) nicht reagiert, vorher war der Maple das IO, damit ging es. Luftweg ist zwar anders, er sollte aber auch vom qCUL aus in etwa gleich gut zu erreichen sein.

Zu deinem Auszug: der Rahmen ist aus Sicht des Sticks hinausgegangen. Bei Erfolg schreibt der Stick auf ein As nichts zurück; bei Ablehnung stünde unmittelbar dahinter eine Zeile Ps ERR oder Ps ERR LOVF. Dazu passen die Zähler: txerr=0 und lovf=0, und zwar über die gesamte Laufzeit des Sticks. Die kennt man aus recal=149 (eine Zwangskalibrierung je Viertelstunde): rund 37 Stunden, der Stick läuft also seit deinem Rechner-Neustart am 07.09. und die Zähler decken den ganzen Ausfall ab. Auch credit=899/900 rechnet auf: 0,9 s nach dem As sind zwei Einheiten für 14 Byte abgebucht und eine Einheit nachgefüllt, mehr wurde in diesen Sekunden nicht gesendet. Das Erfolgsmerkmal des Sticks ist die geleerte Sendewarteschlange des CC1101, der Chip hat die Bytes also moduliert. Das Pegelregister ist fest auf denselben Wert gesetzt wie in culfw für AskSin (PATABLE C3), QCCU verändert es nie.

Was der Auszug nicht zeigt: in den drei Sekunden nach dem As steht keine einzige A-Zeile vom Stick. In unserer Messung antwortete ein Aktor rund 150 ms nach dem Rahmen; eine Quittung stünde als Zeile mit A0A am Anfang und dem Aktor als Absender im Mitschnitt. Ist dein Auszug ungekürzt, hat der Stick in dieser Zeit nichts vom Aktor gehört. Das lässt zwei Fälle offen: der Rahmen kam beim Aktor nicht an, oder der Aktor hat gehandelt und quittiert, und der Stick hat die Quittung nicht gehört. Dass der Stick nach einer Sendung wieder zuverlässig empfängt, haben wir für 2.0.50 gemessen (sechs Statusfragen, sechs Antworten); für 2.0.92 steht diese Messung noch aus, die holen wir nach.

Die beiden Fälle trennt dein Rollladen: hat er sich um 05:29:17 bewegt? Ja heißt, der Stick hört die Quittung nicht. Nein heißt, der Rahmen kommt nicht an.

Zu den Wiederholungen: CUL_HM wartet bei einem set 2 bis 6 Sekunden auf die Quittung und wiederholt dann über dasselbe IO, bis zu dreimal (Attribut msgRepeat), mit demselben Zählerbyte 23. Dein Auszug endet drei Sekunden nach dem As, die Wiederholungen können also noch gar nicht drinstehen. Ich brauche den Mitschnitt ungekürzt von 05:29:17 bis etwa 05:29:45, mit allen Zeilen, die mit A beginnen.

Und der Test aus #40 steht noch aus: ob Maple oder HmUART den Rahmen des qCUL gehört haben. Das steht in der VCCU, weil der Rahmen ihre Adresse als Absender trägt: rssi_at_mapleCUN1 und rssi_at_myHmUART samt Zeitstempel, also list <vccu> direkt nach dem Befehl. Genau so ist übrigens dein rssi_at_CUL_CUL cnt:2 aus #39 zu lesen: der qCUL hat um 17:56:52 die Sendung des Maple mit -70,5 dBm gehört. Das belegt seinen Empfang, über seine Sendeseite sagt es nichts.

Nebenbei zur Zeile Quittungen 0 in der Oberfläche: der Zähler zählt Quittungen, die der Stick selbst sendet (HmIP-Kurzquittung, BidCoS-Selbstquittung). Mit FHEM am CUL quittiert FHEM, der Wert bleibt 0 und ist kein Befund. Die Beschriftung ändere ich.

Wollte eben meine Hausaufgaben erledigen. Vorher ein kurzer Blick auf github - aha, es gibt ein update. Gemacht, aber: Das QCCU-Webinterface zeigt mir zwar die Knöpfe für Funk an, allerdings kommt das mir bislang gezeigte popup nicht, mit dem man die firmware aktualisieren kann, Infos zum Stick zeigt die default-Webseite auch nicht.

Auszug aus /api/state:
firmware
mitgeliefert "q-culfw 2.0.95"
installiert "q-culfw 2.0.92"
zustand "laeuft"
aktualisierbar true
hinweis "Aktualisieren auf 2.0.95"
laeuft false
protokoll []version/uptime unter FHEM zeigen die erwarteten Werte an, der Container bzw. die CUL an sich sind also erreichbar.

Was mache ich falsch?

Hallo Beta-User,

hast Du die Readme beachtet?

ZitatStick-Firmware

Der CUL wird im Bootlader ausgeliefert und meldet sich beim ersten Start nicht als serielles Gerät. Weboberfläche → Stick-Firmware → Einspielen. Danach spricht der Stick nur noch BidCoS und Homematic IP; die übrigen culfw-Funkarten (FS20, IT, EM ...) entfallen. Zurück geht es, indem culfw wieder eingespielt wird.

Erscheint dort kein Stick, ist keiner im Bootlader. Entweder einen fabrikneuen CUL einstecken — der meldet sich von selbst — oder bei einem bereits benutzten die BL-Taste auf der Rückseite gedrückt halten, während er eingesteckt wird. Das gilt auch, wenn der Bootlader nach einem abgebrochenen Versuch stumm bleibt.

Der Stick muss demnach hart in den Bootloader gebracht werden. Vielleicht löst das Dein Problem?

Gruß, Ansgar.

Das betraf bisher nur das erstmalige Flaschen mit qculfw. Seit die drauf ist, habe ich mind. schon ein Update per QCCU-Interface ohne Knopf durchgeführt.

Da ist imo was anderes faul, weil auch sonst nichts angezeigt wird.

Du machst nichts falsch, der Fehler lag bei uns. In 2026.9.11 und 2026.9.12 steckte ein Programmierfehler im Skript der Weboberfläche, an dem der Browser das ganze Skript verworfen hat. Übrig blieb nur das Gerüst der Seite: keine Stick-Angaben, kein Firmware-Dialog, und kein Knopf tat etwas. Die Zentrale selbst lief normal weiter, deshalb antworten version und uptime unter FHEM.

2026.9.13 behebt das. Mit docker run: Abbild 2026.9.13 (auch latest) ziehen und den Container damit neu anlegen. Danach steht oben wieder der Hinweis auf die neuere Stick-Firmware, und das Einspielen geht wie gewohnt ohne Taste.

Falls du in 2026.9.11 oder 2026.9.12 schon ,,Mitschnitt einschalten" oder ,,Frequenzdiagnose einschalten" gedrückt hast: auch diese Knöpfe haben dort nichts ausgelöst.

Thx, update ist durch, Maple und HMUART hören die Message:

lastMsg    No:E1 - t:11 s:425EE2 d:52A1D0 0201B4
   mapleCUN1_MSGCNT 7
   mapleCUN1_RAWMSG A0CE1A011425EE252A1D00201B4::-74.5:mapleCUN1
   mapleCUN1_RSSI -74.5
   mapleCUN1_TIME 2026-09-13 11:46:12
   myHmUART_MSGCNT 42
   myHmUART_RAWMSG 05000008E1A011425EE252A1D00201B4
   myHmUART_RSSI -8
   myHmUART_TIME 2026-09-13 11:46:12Der Rollladen reagiert nur leider nicht darauf...
Mache mal Mitschnitt und Frequenzdiagnose, oder?

Wechsel auf MapleCUN (prefIO gelöscht) => Ack nach nächstem Kommando...

Wechsel zurück auf qCUL als prefIO: Wieder kein Ack, die anderen IOs sehen das Kommando via Funk.
Stick meldet
    V q-culfw 2.0.95
Angeschlossen
    /dev/serial/by-id/usb-busware.de_q-culfw_85330323834351E0A1C1-if00
Empfangen
    41 beide Familien · entschlüsselt 17 · Quittungen 0 · gesendet 20
Nicht für uns
    24 — meist BidCoS, kein Fehler

Sendezeit900 / 900Bin etwas ratlos...

Nachtrag:
luft.log (mit Frequenzanalyse) gibt mir im Moment auch keine weiteren Aufschlüsse, etwas komisch kommen mir nur die Adressangaben vor.
Da die anderen IOs das Kommando mit der richtigen Id sehen, sollte da nicht das Problem liegen.
Weiter ratlos

Damit ist der Test aus #40 beantwortet: der qCUL sendet, und Maple und HmUART dekodieren den Rahmen genau so, wie FHEM ihn gebaut hat (Zähler E1, an 52A1D0, 0201B4). Dass der Stick nicht sendet, scheidet damit aus. Offen bleiben Frequenzversatz und Pegel am Rollladen.

Ja, als Nächstes die Frequenzdiagnose. Mit 2026.9.13 funktionieren die Knöpfe:

1. Startseite: erst "Mitschnitt einschalten", dann "Frequenzdiagnose einschalten".
2. Den Rollladen über den Maple schalten. Seine Antwort kann der qCUL mithören.
  Danach ein paar Minuten laufen lassen, damit auch andere Geräte senden.
3. "Rohmitschnitt laden".

Je empfangenem Rahmen steht dort eine Zeile PH fe=... und direkt darunter die Zeile des Rahmens selbst; bei BidCoS beginnt sie mit A und enthält den Absender. fe ist der Versatz in Schritten zu je 1,587 kHz, der nach dem Ausgleich der Firmware bleibt. Gebraucht werden die fe-Werte vor den Rahmen von 52A1D0 und zum Vergleich die einiger anderer Geräte.

Liegt fe beim Rollladen und bei den anderen Geräten innerhalb weniger Schritte um 0, scheidet der Versatz aus. Liegen alle Geräte gemeinsam daneben, liegt es am Stick: dann den Container mit -e FREQ_OFFSET=<Wert> neu anlegen und erneut messen; nach dem Neustart sind beide Schalter wieder aus. Der Wert wird auf den Ausgleich der Firmware addiert, fe=-6 heißt FREQ_OFFSET=-6. Steht fe am Anschlag, also bei 15 oder 16 Schritten, ist der wahre Versatz größer; dann nach dem ersten Eintrag erneut messen und den neuen Wert dazurechnen. Weicht nur der Rollladen ab, liegt es an seinem Quarz, und eine Korrektur am Stick würde die anderen Geräte verschieben; dann bitte erst die Werte posten.

Thx, bin jetzt unterwegs, Rückmeldung dann nicht vor morgen.

Hallo Beta-User,

solltest Du bei Nutzung mit tsculfw den "hmFreqOffs" gesetzt haben und damit den Rolladen und andere devices erfolgreich gesteuert haben und Dich noch an den genutzten Wert erinnern, dann wäre der Wert/1.587, auf Ganzahl gerundet, ein guter Start-Ansatz für FREQ_OFFSET.

Für den Test der Frequenzdiagnose ist ein Start bei 0 natürlich noch aussagekräftiger.


Noch eine Auffälligkeit:
myHmUART_RSSI -8qCUL und myHmUART sind demnach sehr dicht beieinander positioniert, wenn immer so ein hoher RSSI für empfangene qCUL Sendenachrichten angezeigt wird.
Würdest Du tsculfw verwenden, würden mich dann CCA Probleme nicht wundern und ich würde Dir größere Distanz empfehlen. Für q-culfw trifft zumindest dieser CCA Hinweis jedoch nicht zu.

Gruß, Ansgar.

Bin endlich mal dazu gekommen, das durchzuspielen...

Also: Mit -27 als offset kann man jetzt den Rollladen auch wieder über den qCUL schalten, der Versatz war auch bei den anderen Geräten jeweils im gleichen Range.

Zwei Fragen:
Ist es normal, dass man den Container häufig mehrfach starten muss, bis der Parameter übernommen wird? Es kam häufiger was von "nicht lesbar"...

Das ist ja kein permanentes setting, es muss also jedes Mal neu gesetzt werden, oder?

Danke. Damit liegt es am Frequenzversatz des Sticks, nicht am Rollladen.

FREQ_OFFSET gehört zum Container: Solange er mit -e FREQ_OFFSET=-27 angelegt ist, stellt QCCU den Wert bei jedem Start am Stick ein, auch nach einem Neustart des Containers. Neu angeben muss man ihn nur, wenn der Container neu angelegt wird, also auch beim Aktualisieren.

Mehrfach starten zu müssen ist nicht normal; warum FSCTRL0 bei dir wiederholt nicht lesbar war, ist offen, deshalb unten die Bitte um die Logzeile. Ein Folgefehler ist seit 2026.9.14 behoben: ging nach dem Schreiben nur die Rückmeldung des Sticks verloren, addierte der nächste Start den Versatz ein zweites Mal. Aktuell ist 2026.9.15. Zum Aktualisieren:

1. aus docker logs die Zeile mit "nicht lesbar" wörtlich kopieren (mit dem alten Container ist das Log weg)
2. den alten Container entfernen, den Stick kurz abziehen und wieder anstecken (setzt den Versatz auf den Wert der Firmware zurück)
3. den Container mit 2026.9.15 und -e FREQ_OFFSET=-27 neu anlegen
Der erste Start dauert länger als sonst, weil QCCU seine Gerätetabellen neu anlegt. Danach sollte auf der Startseite in der Zeile "Frequenzversatz" "FSCTRL0 +17 → -10" stehen. Bitte die Zeile aus 1. hier posten, dazu die Startseitenzeile, falls dort etwas anderes steht.

Moin.

Leider habe ich die Anleitung nicht genau genug gelesen, luft.log war noch offen gewesen, gefragt aber was anderes, sorry :-[ .

Wie dem auch sei: Der Stick läuft jetzt mit .101, das offset ist darin gespeichert, der -e Parameter aus docker run entfernt, und der Rollladen läßt sich steuern.
Die kurze "fe="-Suche im aktuellen luft.log zeigt Werte zwischen 5 und -5, das "nicht lesbar" kam die lezte Handvoll Starts nicht mehr.
Klingt zumindest auf den ersten Blick danach, als sei das Problem gelöst. DANKE!

Die Frage wäre nur, wo der offset her kam. Ist zwar alles schon ewig her, ich kann mich aber nicht daran erinnern, jemals was an der Einstellung geändert zu haben... Die CUL ist ein Original aus 2013, und war damals mind. für einige Monat das einzige IO für BidCoS.

Als Anregung: Falls jemand ähnliche Probleme haben sollte, wäre m.E. eine Art Schieberegler hilfreich, direkt über das Web-Interface erreichbar. Prominent präsentieren sollte man das allerdings nicht in der direkt bedienbaren Form, schließlich soll niemand zum unmotivierten Spielen eingeladen werden...

Danke, damit ist es erledigt; die Logzeile brauche ich nicht mehr. fe zwischen -5 und +5 ist das ,,wenige Schritte um 0" aus meinem Beitrag vom 13.09.

Woher der Versatz kommt: du hast nichts verstellt. culfw setzt FSCTRL0 im AskSin-Betrieb nicht, das Register bleibt nach dem Reset des Chips auf 0. Dein Stick liegt damit rund 16 kHz über den eq-3-Geräten (deine -10 Schritte zu je 1,587 kHz), und das fängt die Nachführung des Empfängers mit ±25,4 kHz noch ein — deshalb lief er 2013 ohne jede Einstellung. q-culfw setzt für den CUL V3 fest FSCTRL0 = 0x11, also +17 Schritte = +27 kHz, gemessen an drei Exemplaren, die alle rund 27 kHz unter den eq-3-Geräten lagen. Bei deinem addiert sich das zu +43 kHz, außerhalb des Fangbereichs. Das ist Quarzstreuung zwischen Exemplaren, rund 50 ppm zwischen deinem und jenen dreien; kein fester Wert je Platine trifft alle. Deshalb gibt es seit .101 den Abgleich je Stick im EEPROM, und neue CUL V3 werden in der Fertigung vermessen und tragen ihren Wert von dort mit (,,Werksabgleich" auf der Startseite). Für einen Stick aus 2013 bleibt der Weg über die Diagnose.

Der gespeicherte Wert ersetzt beim Start den Wert der Platine, überlebt neuen Container, Firmware-Update und Werksreset des Sticks und gilt auch ohne QCCU. FREQ_OFFSET bezieht sich seit .101 auf ihn, nicht mehr auf die +17 — den Parameter zu entfernen war richtig; stünde er noch da, warnt die Startseite, dass er obendrauf addiert wird. ,,Abgleich löschen" stellt die +17 wieder her.

Schieberegler: notiert. Heute sind es vier Stationen (Diagnose einschalten, fe im Mitschnitt lesen, FREQ_OFFSET setzen und neu starten, ,,im Stick speichern"); ein Feld auf der Startseite spart die letzten beiden. Deinen Vorbehalt teile ich: ein falscher Wert macht den Stick auf beiden Funkfamilien still, ohne dass man es ihm ansieht — das gehört nur zusammen mit der Diagnose bedienbar, nicht als freier Regler. Versprochen ist damit nichts.

Den Frequenzoffset per CUL einstellbar zu haben, ist gut und sinnvoll.

Den relativen Frequenzoffset Schätzwert auslesbar zu haben, ist ein prima Feature alternativ zum Abgleich mit z.B SDR.

Für meine CUL-artigen und tsculfw Experiment zum Auslesen komme ich bezogen auf meinen HM device Zoo auf
CUL  freqOffs:-20.630kHz
COC  freqOffs:-14.282kHz
SCC  freqOffs:-23.804kHz
CUNX freqOffs:19.043kHz

0 ist für die also ein günstiger Ausgangswert, wenn keine Infos zur Frequenzabweichung vorliegen.
Da die HM-device auch in ihrem Frequenzoffset streuen (~ +/-9.5kHz) reicht 0 jedoch nicht, um für all meine devices gut zu passen. -> Abgleich macht Sinn!

Ich sehe bei mir bei Offset Auslesewerten auch Ausreißer. Je device muss man mehrere Auslesewerte vergleichen und Außreißer verwerfen, um den tatsächlichen Offset zu bestimmen.
Temperaturunterschiede machen sich auch bemerkbar. Sommer und Winter Messung ergeben damit sicherlich etwas unterschiedliche Werte.

Danke auf alle Fälle für die Weiterentwicklung!

Habe eben mal die Probe gemacht und den HM-SEN-MDIR-O (im Nachgang zu diversen Umbauten hier) umkonfiguriert. Der ist nach wie vor zickig, leztendlich sind aber die peers erfolgreich neu geschrieben via qCUL als prefIO.

Im Moment haben ein paar Devices (sowohl dauerbestromt wie auch auf Batterie) den qCUL automatisch als IODev zugewiesen bekommen, die prefIO-Einträge nehme ich jetzt erst mal wieder vollständig raus, das Testen scheint ja vorläufig beendet zu sein.

Kann ich im Moment noch weitere sinnvolle Info liefern?