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.