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.