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?