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