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.