Hallo zusammen,
ich habe mittlerweile erfolgreich mein FHEM über MQTT mit ThingsBoard verbunden und bekomme nun schon ein paar Werte übertragen, die ich mir dann anzeigen lassen kann. Jetzt möchte ich noch auf Bedienelemente im Board reagieren können und dafür muss ich mich auf ein bestimmtes MQTT-Topic subscriben. Gemäß der Doku für einen MQTT2_CLIENT habe ich dies über das "subscriptions"-Attribut gemacht:
defmod ThingsBoard MQTT2_CLIENT 192.168.178.52:1883
attr ThingsBoard subscriptions v1/devices/me/rpc/request/+
Wie kann ich nun auf eine eingehende Nachricht in diesem Topic reagieren? Kann ich das über ein "notify" machen oder wie funktioniert das? In der Dokumentation und im Wiki habe ich leider nichts passendes gefunden.
Danke und Gruß
Ja, Events im Eventmonitor beobachten, und dort das passende notify erstellen lassen.
Oder autocreate auf simple stellen und mit MQTT2_DEVICE als Zwischenschicht arbeiten.
Zitat von: amenomade am 29 August 2020, 14:51:34
Ja, Events im Eventmonitor beobachten, und dort das passende notify erstellen lassen.
Das habe ich gerade gemacht, aber anscheinend wird kein Event ausgelöst, wenn ich eine entsprechende Nachricht sende.
Um das im Event-Monitor zu sehen, muß bei dem MQTT2-IO's auch rawEvent entsprechend gesetzt werden. Falls das Teil im JSON-Format sendet, würde ich in jedem Fall MQTT2_DEVICE verwenden.
Zitat von: Beta-User am 29 August 2020, 15:43:24
Um das im Event-Monitor zu sehen, muß bei dem MQTT2-IO's auch rawEvent entsprechend gesetzt werden. Falls das Teil im JSON-Format sendet, würde ich in jedem Fall MQTT2_DEVICE verwenden.
Okay ich habe mir nun ein MQTT2_DEVICE angelegt:
defmod ThingsBoard_RPC MQTT2_DEVICE
attr ThingsBoard_RPC room ThingsBoard
attr ThingsBoard_RPC readingList v1/devices/me/rpc/request/+:.* { ThingsBoard_Utils_Receiver($NAME) }
Die Funktion ThingsBoard_Utils_Receiver ist ebenfalls definiert und schreibt vorerst nur was ins Log. Aber anscheinend scheint da nochwas falsch zu sein, weil wenn ich eine JSON-Nachricht mit dem Topic "v1/devices/me/rpc/request/+" sende passiert weiterhin nichts.
Lass besser mqtt2-autocreate machen, das geht idR. schneller. RL ist Perl/regex => .* statt +
Zitat von: Beta-User am 29 August 2020, 16:24:09
RL ist Perl/regex => .* statt +
Das "+" stammt aus dem vorgegebenen Topic (Server-side RPC):
https://thingsboard.io/docs/reference/mqtt-api/
+ ist eine MQTT-Wildcard, readingList folgt aber Perl- bzw. allg. regex-Regeln (das subscriptions-Attribut am CLIENT folgt dagegen MQTT-Regeln, wenn ich die Commandref richtig lese).
Nochmal: Du tust dich leichter, wenn du das händisch erstellte Device löschst und einfach autocreate am CLIENT auf "simple" stellst (und dann dafür sorgst, dass auch Nachrichten kommen).
Das gibt dann zwar immer noch keine optimalen Ergebnisse bzw. Nacharbeitsbedarf, aber es ist einfacher, das dann hinterher zu (er-)klären.
rawEvents (aus dem Event-Monitor, kannst du beim CLIENT erst mal auf ".*" stellen) würde ich trotzdem gerne mal sehen (alternativ: den relevanten MQTT-Verkehr z.B. mit mosquitto_sub mitschneiden), die Doku ist nicht sonderlich aufschlußreich.
Entsprechendes gilt für das per autocreate dann erstellte Device; davon bitte ein RAW-list.
So ich habe die entsprechenden Attribute aktiviert
attr ThingsBoard autocreate 1
attr ThingsBoard subscriptions v1/devices/me/rpc/request/+
Nachdem ich einen Slider in meinem Dashboard bewegt habe, wurde ein entsprechendes Device angelegt und für jede Aktion kommt nun ein Eintrag in das Attribut "readingList".
2020-08-30 00:31:46 Global global UNDEFINED MQTT2_ThingsBoard MQTT2_DEVICE ThingsBoard ThingsBoard
2020-08-30 00:31:46 Global global DEFINED MQTT2_ThingsBoard
2020-08-30 00:31:46 Global global DEFINED FileLog_MQTT2_ThingsBoard
2020-08-30 00:31:46 MQTT2_CLIENT ThingsBoard v1/devices/me/rpc/request/48:{"method":"setValue","params":true}
2020-08-30 00:31:46 Global global ATTR MQTT2_ThingsBoard readingList ThingsBoard:v1/devices/me/rpc/request/48:.* { json2nameValue($EVENT) }
2020-08-30 00:31:46 MQTT2_DEVICE MQTT2_ThingsBoard method: setValue
2020-08-30 00:31:46 MQTT2_DEVICE MQTT2_ThingsBoard params: true
Im Event-Log erhalte ich die folgende Ausgabe (das Element ist nur ein Slider mit On und Off):
2020-08-30 00:29:38 MQTT2_CLIENT ThingsBoard v1/devices/me/rpc/request/47:{"method":"setValue","params":false}
2020-08-30 00:29:38 Global global ATTR MQTT2_ThingsBoard readingList ThingsBoard:v1/devices/me/rpc/request/39:.* { json2nameValue($EVENT) } ThingsBoard:v1/devices/me/rpc/request/40:.* { json2nameValue($EVENT) } ThingsBoard:v1/devices/me/rpc/request/41:.* { json2nameValue($EVENT) } ThingsBoard:v1/devices/me/rpc/request/42:.* { json2nameValue($EVENT) } ThingsBoard:v1/devices/me/rpc/request/43:.* { json2nameValue($EVENT) } ThingsBoard:v1/devices/me/rpc/request/44:.* { json2nameValue($EVENT) } ThingsBoard:v1/devices/me/rpc/request/45:.* { json2nameValue($EVENT) } ThingsBoard:v1/devices/me/rpc/request/46:.* { json2nameValue($EVENT) } ThingsBoard:v1/devices/me/rpc/request/47:.* { json2nameValue($EVENT) }
2020-08-30 00:29:38 MQTT2_DEVICE MQTT2_ThingsBoard method: setValue
2020-08-30 00:29:38 MQTT2_DEVICE MQTT2_ThingsBoard params: false
Oha, das scheint eine neue Variante zu sein, wie man Infos via MQTT+JSON verpacken kann...
Interpretiere ich das richtig: Das Bedienen desselben Elements auf dem Gerät/der Hardware (oder was immer das ist) generiert eine fortlaufende Nummer, unter der dann JSON-verpackt gesendet wird, was passiert ist, ohne dass allerdings eine echte Rückverfolgbarkeit gegeben ist, die z.B. darauf schließen läßt, welcher slider (es kann mehrere geben, oder?) betätigt wurde?
Wenn das so ist, ist das insgesamt wenig hilfreich und kaum als input-Methode geeignet (ich würde das als Bug ansehen), nur, wenn es eine Beziehung gibt zwischen der Zahl und dem Slider, sieht es anders aus. Dann können wir mit etwas regex+Perl in readingList durchaus was nettes daraus basteln; (auch als eigener Merker:) spezielle Berücksichtigung von topic-Elementen bei der Reading-Benennung macht z.B. OpenMQTTGateway_BT_scanner, regex zur Auswertung der Payload tasmota_rf u.a..
Aber erst würde ich mal Info benötigen, wie das dann aussieht, wenn andere Bedienelemente ins Spiel kommen. Hast du da irgendwelche Infos? (Ich habe gesehen, dass es da irgendwelche Videos usw. gibt, will mir aber nach Möglichkeit nicht alles selbst zusammensuchen bzw. zusammenreimen. Gibt es irgendwo eine knappe Info, um was es da eigentlich geht?)
Zitat von: Beta-User am 30 August 2020, 07:02:09
Oha, das scheint eine neue Variante zu sein, wie man Infos via MQTT+JSON verpacken kann...
Interpretiere ich das richtig: Das Bedienen desselben Elements auf dem Gerät/der Hardware (oder was immer das ist) generiert eine fortlaufende Nummer, unter der dann JSON-verpackt gesendet wird, was passiert ist, ohne dass allerdings eine echte Rückverfolgbarkeit gegeben ist, die z.B. darauf schließen läßt, welcher slider (es kann mehrere geben, oder?) betätigt wurde?
Wenn das so ist, ist das insgesamt wenig hilfreich und kaum als input-Methode geeignet (ich würde das als Bug ansehen), nur, wenn es eine Beziehung gibt zwischen der Zahl und dem Slider, sieht es anders aus. Dann können wir mit etwas regex+Perl in readingList durchaus was nettes daraus basteln; (auch als eigener Merker:) spezielle Berücksichtigung von topic-Elementen bei der Reading-Benennung macht z.B. OpenMQTTGateway_BT_scanner, regex zur Auswertung der Payload tasmota_rf u.a..
Aber erst würde ich mal Info benötigen, wie das dann aussieht, wenn andere Bedienelemente ins Spiel kommen. Hast du da irgendwelche Infos? (Ich habe gesehen, dass es da irgendwelche Videos usw. gibt, will mir aber nach Möglichkeit nicht alles selbst zusammensuchen bzw. zusammenreimen. Gibt es irgendwo eine knappe Info, um was es da eigentlich geht?)
Guter Punkt. Daran habe ich bisher noch nicht gedacht, bzw. noch nicht überlegt. Ich werde das morgen mal den Support fragen, weil irgendwie muss man die Elemente doch voneinander unterscheiden können.
Testweise habe ich mir mal einen Drehschalter und einen On/Off-Schalter rein gezogen und die Nachrichten geloggt:
{"method":"setValue","params":true} <- Wird bei Betätigung des Schalters gesendet
{"method":"getValue"} <- Wird permanent vom Drehschalter gesendet
{"method":"setValue","params":33.33} <- Wird bei Veränderung am Drehschalter gesendet
Alle Nachrichten wurden mit einer anderen Request-ID gesendet.
Ich schreibe morgen früh mal direkt ein entsprechendes Ticket bei Git, weil ich brauche da auch schon eine gute Lösung für, da die Kommunikationsrichtung zwischen FHEM und ThingsBoard schon gerne bidirektional halten möchte. Die Antwort werde ich dann hier posten.
Kleines Edit und bissl Offtopic für die Zwischenzeit (vielleicht hast du da ja eine Anlaufstelle für):
Ich würde gerne im zweiten Schritt (wenn alles läuft) ein eigenes Modul für ein Gerät schreiben um die ganze MQTT-Kommunikation darüber abzuwickeln anstatt ein MQTT2_CLIENT, ein MQTT2_DEVICE und die Events händisch anzulegen, sodass man nur noch die Adresse von der ThingsBoard-Instanz und den API-Key eingeben muss. Gibt es irgendwelche weiterführende Dokumentation, wie ich den MQTT2-Code in meinem eigenen Modul nutzen kann?
ZitatJetzt möchte ich noch auf Bedienelemente im Board reagieren können und dafür muss ich mich auf ein bestimmtes MQTT-Topic subscriben. Gemäß der Doku für einen MQTT2_CLIENT habe ich dies über das "subscriptions"-Attribut gemacht:
MQTT2_CLIENT bestellt per Voreinstellung alle Topics (subscripotions=#). subscriptions setzt man nur dann, wenn man nicht alle Topics bekommen soll.
ZitatGibt es irgendwelche weiterführende Dokumentation, wie ich den MQTT2-Code in meinem eigenen Modul nutzen kann?
Mir nicht bekannt, und der Code in den erwaehnten Modulen ist auch nicht mit dem Gedanken gebaut, als Bibliothek verwendet zu werden. Meiner Ansicht nach laesst sich das Problem mit setzen der richtigen Attribute per attrTemplate fuer den Benutzer bequem loesen.
Zitat von: rudolfkoenig am 30 August 2020, 11:30:44
Meiner Ansicht nach laesst sich das Problem mit setzen der richtigen Attribute per attrTemplate fuer den Benutzer bequem loesen.
Sehe ich ähnlich, wobei mir die MQTT-Kommunikation von diesem Ding noch ziemlich "unausgegoren" vorkommt und ich auch bei der Diskussion in diesem Thread noch nicht erkennen konnte, wo denn der Mehrwert eines eigenen Moduls liegen soll. Mir kam es eher so vor, als wären dir (kampi) Grundlagen der Kommunikation via MQTT und die Funktionsweise der vorhandenen Module noch nicht vertraut und würde daher auch eher empfehlen, erst mal da anzusetzen.
Das Framework, das Rudi da bereitgestellt hat, ist so flexibel, dass wir es eigentlich bisher immer geschafft haben, Lösungen zu basteln, die die betreffenden User (mind.) gut fanden (genauer gesagt: ich kann mich bisher nur an eine Ausnahme erinnern (das BT-Thermostat-Ding), aber da wollte der TE - warum auch immer - nicht weitermachen).
Zitat von: Beta-User am 30 August 2020, 14:00:42
Sehe ich ähnlich, wobei mir die MQTT-Kommunikation von diesem Ding noch ziemlich "unausgegoren" vorkommt und ich auch bei der Diskussion in diesem Thread noch nicht erkennen konnte, wo denn der Mehrwert eines eigenen Moduls liegen soll. Mir kam es eher so vor, als wären dir (kampi) Grundlagen der Kommunikation via MQTT und die Funktionsweise der vorhandenen Module noch nicht vertraut und würde daher auch eher empfehlen, erst mal da anzusetzen.
Das Framework, das Rudi da bereitgestellt hat, ist so flexibel, dass wir es eigentlich bisher immer geschafft haben, Lösungen zu basteln, die die betreffenden User (mind.) gut fanden (genauer gesagt: ich kann mich bisher nur an eine Ausnahme erinnern (das BT-Thermostat-Ding), aber da wollte der TE - warum auch immer - nicht weitermachen).
Gut dann schiebe ich die Idee erst einmal beiseite. Die Grundidee war eigentlich auch nur das ganze sauber zu unterteilen, aber wenn es nicht notwendig ist, bzw. am Ende mehr Arbeit macht als eine ordentliche Parametrierung durch die Attribute vorzunehmen kann ich auch drauf verzichten. Es war (wenn überhaupt) eh eine Idee für später :)
Anyway ich habe mal ein Ticket bei Git erstellt (keine Lust gehabt zu warten und vielleicht schauen die zuständigen Leute ja heute noch rein...) und mal gefragt ob es eine Möglichkeit gibt die Dinger über MQTT zu identifizieren. Leider scheint auch die HTTP-Implementierung keine vernünftige Identifizierung mitzubringen (bzw. es ist nichts dokumentiert).
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
{"method":"setValue","params":true}
Könnte ich somit das hier machen
{"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 :)
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
ThingsBoard v1/devices/me/rpc/request/48:{"method":"ButtonEnable","params":true}
macht man mit
attr MQTT2_ThingsBoard readingList v1/devices/me/rpc/request/.* { $EVENT=~/"method":"(.*)","params":(.*)}$/ ? {$1=>$2} : {} }
Readings/Events der Sorte
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
ThingsBoard v1/devices/me/rpc/request/48:{"method":"setValue","params":false}
kann man relativ einfach umbauen mit sowas wie
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.
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:
ThingsBoard v1/devices/me/rpc/request/48/ButtonEnable:{"method":"ButtonEnable","params":true}oder so:
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]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.)
Wenn ich auch was wuenschen darf :), dann wuerde ich es weiter vereinfachen. Entweder als "JSON-Free":
v1/devices/me/rpc/request/ButtonEnable true
oder mit JSON:
v1/devices/me/rpc/request { "ButtonEnable":true }
Beide Varianten werden in FHEM per autocreate "perfekt" in Readings umgewandelt, keine Benutzeraktion ist notwendig.
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.
Zitat von: rudolfkoenig am 03 September 2020, 08:52:04
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.
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
{ "method":"setValues", params : {"value": true,"name":"ButtonEnable"} }
Ist war nicht ganz ideal, aber wenigstens etwas...