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

[tostmann]

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?

Code Auswählen Erweitern

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.

[Beta-User]

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

MQTT

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.

[tostmann]

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:

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)

[Ralli]

Beispiel:

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

[Beta-User]

Beta-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?

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

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:

Code Auswählen Erweitern

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.

[Sidey]

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

Code Auswählen Erweitern

<prefix>/<geraete-id>/#.

Daher stehen

Code Auswählen Erweitern

set und

Code Auswählen Erweitern

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

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

Code Auswählen Erweitern

<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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

/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

[Ralli]

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.

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.

[tostmann]

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?

[Beta-User]

Danke für die RSSI-Werte aus der VCCU.

Code Auswählen Erweitern

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.

Die 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!

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

[Beta-User]

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.

[noansi]

Hallo Beta-User,

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

[Beta-User]

Ups, klar, "uptime" war gemeint.

get cmds liefert 

Code Auswählen Erweitern

CUL_CUL cmds =>  A V X T

Wie 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?

[Sidey]

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

[noansi]

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

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

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.

[tostmann]

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:

Code Auswählen Erweitern

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.