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

[Beta-User]

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

[Beta-User]

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:

Code Auswählen Erweitern

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?

[noansi]

Hallo Beta-User,

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

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?

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.

[tostmann]

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:

Code Auswählen Erweitern

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.

[Beta-User]

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.

Das hier, oder:

Code Auswählen Erweitern

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?

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

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

[noansi]

Hallo Beta-User,

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

[tostmann]

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"):

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

attr <aktor> IOgrp <vccu>:<cul>

3. Stand vorher:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

set <aktor> statusRequest

5. Dieselben drei Lists noch einmal.

Quittung da: Sendeweg belegt. missing ack:

Code Auswählen Erweitern

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.

[noansi]

Noch als Ergänzung zu "Ohne prefIO":

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

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!

[Beta-User]

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

2. Netzversorgten Aktor auf den CUL legen:

Der hier war noch auf qCUL als IO, man sieht den erfolglosen Steuerungsversuch von eben:

Code Auswählen Erweitern

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.

[Beta-User]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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


[tostmann]

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:

Code Auswählen Erweitern

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.

[Beta-User]

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:

Code Auswählen Erweitern

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.

[tostmann]

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.