Bei MQTT2_CLIENT auf Subscriptions reagieren

[kampi]

Hallo,

mal ein kurzes Update, damit ihr nicht denkt, dass mich das Thema nicht mehr interessiert :
Ich bin aktuell noch dabei mit dem Support zu diskutieren, aber ich habe schon mal eine erste Info. Prinzipiell ist es möglich den Parameter "method" anzupassen und ihm einen eigenen Namen zu geben. Dies kann man individuell für jedes Element auf dem Dashboard machen oder man ändert es gleich in der Widget-Bibliothek ab.
Aus dem Aufruf

Code Auswählen Erweitern


{"method":"setValue","params":true}


Könnte ich somit das hier machen

Code Auswählen Erweitern


{"method":"ButtonEnable","params":true}


In FHEM würde ich dann eine entsprechende Funktion machen um beim Erhalt dieses RPC irgendwas zu machen, sprich ich werte das Topic "v1/devices/me/rpc/request/+" aus und lausche ob der Parameter "method" einen bestimmten Wert hat.
Ist noch nicht ganz perfekt, weil ich im Widget an der Konfiguration des Schalters rumspielen muss, aber es ist eine Lösung. Ideal wäre es natürlich, wenn ich dem Schalter einen Namen geben könnte und ich dann den RPC so abändere, dass der als Methode den Namen des Schalters nimmt und ggf. noch einen UI-Typen mitsenden kann, sodass ich relativ einfach checken kann ob das UI-Element auch wirklich ein Schalter ist. Bei der jetzigen Lösung könnte man auch einem Slider den entsprechenden Parameter "method" mitgeben und sagen das ist ein Schalter, was dann für eine Fehlfunktion sorgen könnte.

Naja...ich bin auf jeden Fall weiter dran und es wird langsam alles klarer

[rudolfkoenig]

Ich verstehe zwar nicht wirklich, was mit Schalter/Widget/etc gemeint ist, die Uebernahme der seltsamen Nachrichten kann man in FHEM aber relativ einfach bewerkstelligen.

Aus

Code Auswählen Erweitern

ThingsBoard v1/devices/me/rpc/request/48:{"method":"ButtonEnable","params":true}
macht man mit

Code Auswählen Erweitern

attr MQTT2_ThingsBoard readingList v1/devices/me/rpc/request/.* { $EVENT=~/"method":"(.*)","params":(.*)}$/ ? {$1=>$2} : {} }

Readings/Events der Sorte

Code Auswählen Erweitern

2020-09-03 08:38:50.374 MQTT2_DEVICE MQTT2_ThingsBoard ButtonEnable: true
und diese kann man mit FHEM-eigenen Mitteln weiterverarbeiten.

Auch das "alte" Format

Code Auswählen Erweitern

ThingsBoard v1/devices/me/rpc/request/48:{"method":"setValue","params":false}
kann man relativ einfach umbauen mit sowas wie

Code Auswählen Erweitern

attr MQTT2_ThingsBoard readingList v1/devices/me/rpc/request/48:.* { $EVENT=~/"params":(.*)}$/ ? {"ButtonEnable"=>$1} : {} }
Fuer diese Version muss man die "Uebersetzungstabelle" (48 ist ButtonEnable, usw.) im FHEM pflegen, z.Bsp. indem man fuer jede bekannte Nummer das readingList Attribut um eine Zeile erweitert.

[Beta-User]

Mir fehlt auch noch irgendwie das Gesamtbild.

Grundsätzlich hatten wir an mehreren Stellen ja schon festgestellt, dass man mit FHEM (fast) alles irgendwie ausgewertet bekommt. Die Frage ist eigentlich immer, wie man es am geschicktesten anstellt, gerade, wenn eine firmware/ein Dienst/... noch irgendwie in der Entwicklung ist.

Hier empfinde ich das "Verpacken" des "Bedienelement-Namens" (?) in ein flaches JSON zwar als Fortschritt in die richtige Richtung, aber mein "Bauchgefühl" meint, dass es mindestens zwei bessere Varianten gibt. (Ich kann mich auch täuschen, und evtl. sehe ich das auch zu sehr durch eine FHEM-Brille):

Variante 1 wäre, den "Bedienelement-Namen" (auch) in der Topic-Struktur zu berücksichtigen. Das ginge z.B. so:

Code Auswählen Erweitern

ThingsBoard v1/devices/me/rpc/request/48/ButtonEnable:{"method":"ButtonEnable","params":true}oder so:

Code Auswählen Erweitern

ThingsBoard v1/devices/me/rpc/request/48/ButtonEnable:{"params":true}
Das wäre meine persönliche Präferenz.

Variante 2 würde eine eher verschachtelte JSON-Struktur vorsehen. Beispiel:

Code Auswählen Erweitern

[code]ThingsBoard v1/devices/me/rpc/request/48:{"ButtonEnable":{"params":true}}[/code]

(Falls der Entwickler ein Beispiel/eine Referenz sucht: https://tasmota.github.io/docs/Zigbee/. Das ist aber mMn. zu sehr verschachtelt, in FHEM verarbeiten wir daher dorch nur den "inneren JSON". Dafür gibt es mit SetOption89 zumindest eine Referenz, wie das mit der Integration des Objekts in die Topic-Struktur gemeint ist.)

[rudolfkoenig]

Wenn ich auch was wuenschen darf , dann wuerde ich es weiter vereinfachen. Entweder als "JSON-Free":

Code Auswählen Erweitern

v1/devices/me/rpc/request/ButtonEnable true
oder mit JSON:

Code Auswählen Erweitern

v1/devices/me/rpc/request { "ButtonEnable":true }

Beide Varianten werden in FHEM per autocreate "perfekt" in Readings umgewandelt, keine Benutzeraktion ist notwendig.

[Beta-User]

Fully agreed!

Bei meinen Varianten hatte ich unterstellt, dass es nicht nur eine Detailinformation geben kann/muß, die zu einem bestimmten Bedienelement gehört, sondern - wie z.B. bei Leuchten - mehrere (an/aus, Helligkeit, Farbe, Farbtemperatur, ...). Falls es sowas geben kann (?) ist es _vermutlich_ einfacher, alles über einen Kamm zu schehren und dann eben ein passendes jsonMap zu vergeben.

Vielleicht noch eine Anmerkung zum Thema Verarbeitung in FHEM:

_Vermutlich_ ist es ok, MQTT2_DEVICE zu verwenden. Aber wenn es eigentlich darum geht, FHEM-Geräte über eine "mqtt-sprechende Bedienoberfläche" von der Ferne bedienen zu können, wäre es auch eine Überlegung, das mit MQTT_GENERIC_BRIDGE zu machen. In dem Kontext könnte dann auch (direkt oder indirekt) json2nameValue() verwendet werden, es wäre aber sehr viel einfacher, die Infos auszuwerten, wenn zum einen _keine_ fortlaufende Nummer verwendet werden würde und zum anderen jedes "Bedienelement" (oder eine Gruppe, wie z.B. Leuchten) einen eigenen Topic bekäme.

[kampi]

Ich verstehe zwar nicht wirklich, was mit Schalter/Widget/etc gemeint ist, die Uebernahme der seltsamen Nachrichten kann man in FHEM aber relativ einfach bewerkstelligen.

Sorry, da habe ich wohl das ein oder andere übersprungen. Also mit "Widget" ist ein Bedienelement auf dem Dashboard (der Bedienoberfläche) gemeint (siehe Screenshot). Dieses Dashboard ist direkt in ThingsBoard integriert und ThingsBoard stellt die Möglichkeit zur Verfügung verschiedene Kontrollwidgets auf einem Dashboard zu integrieren (z. B. ein Drehregler wie von einem Thermostat). Jedes dieser Widgets setzt beim bedienen eine Nachricht ab und diese Nachricht möchte ich dann mit dem Gerät, welches ich mit dem jeweiligen Dashboard auslese, auswerten. Und eben dieses Gerät ist eine FHEM-Instanz

Hoffe das ist jetzt ein bisschen klarer was ich machen möchte...
Den Rest der Antworten von euch arbeite ich gleich mal durch. Auch der Support hat mir noch ein paar Dinge geschrieben, die ich jetzt erst einmal checken muss.

[kampi]

So ich habe eine eine neue Antwort vom Support bekommen. Das Topic lässt sich leider nicht anpassen und es gibt auch keine Möglichkeit den Namen des Bedienlementes automatisch in die Nachricht zu bekommen. Was ich wohl machen kann, ist die Nachricht händisch anzupassen und den Namen des Bedienelements dann da rein zu schreiben. Ich würde somit sowas in der Richtung senden

Code Auswählen Erweitern


{ "method":"setValues", params : {"value": true,"name":"ButtonEnable"} }


Ist war nicht ganz ideal, aber wenigstens etwas...