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

Begonnen von tostmann, 15 August 2026, 16:38:17

Vorheriges Thema - Nächstes Thema

Beta-User

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.
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

tostmann

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.

Beta-User

#47
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:12
Der 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 / 900
Bin 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
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

tostmann

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.

Beta-User

Thx, bin jetzt unterwegs, Rückmeldung dann nicht vor morgen.
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors