MQTT2_DEVICE bekommt keine Nachrichten

[kampi]

Hallo zusammen,

ich habe einen MQTT-Broker mit dem sich FHEM verbindet und periodisch mit Daten füttert

Code Auswählen Erweitern


defmod MQTT_Client MQTT2_CLIENT <IP>
attr MQTT_Client room MQTT
attr MQTT_Client mqttVersion 3.1.1


Nun möchte ich den Broker nutzen um Kontrollinstruktionen zu dem Gerät zu senden. Dazu habe ich mir gemäß dieses Links

http://heinz-otto.blogspot.com/2019/11/mqtt-ich-muss-das-testen.html

ein MQTT2_DEVICE angelegt:

Code Auswählen Erweitern


defmod MQTT_Device MQTT2_DEVICE
attr MQTT_Device IODev MQTT_Client
attr MQTT_Device room MQTT


Allerdings tauchen im Event monitor keine empfangenen Nachrichten auf und bei dem Device stehen auch nur drei "?" als State.

Was habe ich falsch gemacht?

[Beta-User]

Wenn du MQTT2_CLIENT nutzt, wird per default kein readingList-Attribut an keinem MQTT2_DEVICE erstellt. Du musst daher die Attribute readingList und setList selbst füllen.

Wenn du die Topics (und für setList die Payloads) nennen würdest, könnten wir Starthilfe geben...
Den MQTT-Verkehr sieht man im Event-Monitor erst, wenn man RAW-Events am IO aktiviert.

[kampi]

Hi,

das Topic ist "<DeviceID>/request" und die Payload ist ein JSON-String mit einem Eintrag "method" und "params".

[Beta-User]

Willst du (von FHEM aus) senden oder empfangen?

Empfangen wäre readingList:

Code Auswählen Erweitern

attr MQTT_Device readingList <DeviceID>/request/.* { json2nameValue($EVENT) }
(Das mit dem Strich hinter request kommt mir komisch vor, ggf. mal entfernen...)

(Und auch mal in die commandref schauen würde ggf. nicht schaden).

[kampi]

Hi,

FHEM soll das Topic nur empfangen.

Ich habe das Attribut entsprechend gesetzt, aber es passiert immer noch nichts. Wie kann ich mir den mal alle empfangenen Nachrichten im Log anzeigen lassen? Weil gesendet werden die wohl erfolgreich...

[Beta-User]

Den MQTT-Verkehr sieht man im Event-Monitor erst, wenn man RAW-Events am IO aktiviert.

.* zeigt dann dort alles, was nach dem Setzen des Attributs (am MQTT2_CLIENT) reinkommt. Ansonsten mal ein externes Tool nutzen (z.B. mosquitto_sub), um den MQTT-Verkehr mitzuhören bzw. mitzuschneiden.
Ohne (MQTT-) Daten ist Hilfe praktisch unmöglich, und geloggt wird nur entweder mit verbose 5 am IO oder entsprechendem Eventhandler (wie z.B. FileLog, was aber auch Events benötigen würde...)

[kampi]

Hi,

ich habe noch etwas herumgespielt und bin bisschen weiter und musste auch ein paar Dinge ändern...

Ich versuche von ThingsBoard aus einen MQTT-RPC in FHEM auszulösen.

https://thingsboard.io/docs/reference/mqtt-api/#rpc-api

FHEM-seitig klappt schon alles und ich kann ein JSON per mosquitto an FHEM senden und dann wird eine bestimmte Aktion ausgeführt. Allerdings klappt es noch nicht bei der Verwendung von ThingsBoard. Wenn ich mich mittels MQTT.fx mit meinem ThingsBoard verbinde und das Topic "v1/devices/me/rpc/request/+" subscribe erhalte ich regelmäßig eine MQTT-Nachricht (ist aktuell nur ein periodisches Senden eines Strings zum testen).

Aber in FHEM kommen die nicht an. Ich verwende für mein MQTT-Device folgende readingList:

Code Auswählen Erweitern


attr MQTT_Device readingList v1/devices/me/rpc/request/.* { json2nameValue($EVENT) }


[Beta-User]

Ich meine, die Logik ist anders:

The client should publish the response to the following topic:

Code Auswählen Erweitern

v1/devices/me/rpc/response/$request_id

Will aber nicht ausschließen, dass es doch anders ist, aber eigentlich müsste das hier passen:

Code Auswählen Erweitern

attr MQTT_Device readingList v1/devices/me/rpc/response/.*:.* { json2nameValue($EVENT) }

Mir ist aber noch nicht klar, wer eigentlich welche Daten von wem haben will...

[kampi]

Hi,

das Topic muss "v1/devices/me/rpc/request/+" sein, da über "response" die Antwort vom Client (in diesem Fall FHEM) übertragen wird. Ich habe es dennoch mit beiden probiert und im Eventlog erscheint keine Nachricht.

[Beta-User]

Mit was publishst du?
Gib mal bitte wenn möglich eine ClientID mit an, sonst kann es sein, dass das mangels eindeutigem Topic "verschütt" geht (für mosquitto_pub müßte es der "i"-Parameter sein).

(Edit: Doch nicht, wir sind ja bei M2_CLIENT).

Ist da über RAW-Events was zu sehen?

[Otto123]

Die Angabe beim Client ist doch nicht optional ? <host>:<port>
Da fehlt doch das Port in der DEF?

MQTT2_CLIENT
MQTT2_CLIENT is a cleanroom implementation of an MQTT client (which connects to an external server, like mosquitto) using no perl libraries. It serves as an IODev to MQTT2_DEVICES.

Define
define <name> MQTT2_CLIENT <host>:<port>

Connect to the server on <host> and <port>. <port> 1883 is default for mosquitto.
Notes:
only QOS 0 and 1 is implemented

Mal bitte ein

Code Auswählen Erweitern

list MQTT_Client damit man beurteilen kann ob der überhaupt einen Verbindung hat?

[kampi]

Das Publishen wird aktuell von meiner ThingsBoard-Instanz übernommen und ist ein simpler JSON mit ein paar Dummy-Inhalten, welcher periodisch gesendet wird.

Hab "rawEvent" mit ".*" gesetzt und es taucht ebenfalls nichts in den Logs auf.

Mal bitte ein

Code Auswählen Erweitern

list MQTT_Client damit man beurteilen kann ob der überhaupt einen Verbindung hat?

Eine Verbindung besteht, weil FHEM parallel Daten an ThingsBoard schickt (FHEM -> ThingsBoard funktioniert, ThingsBoard -> FHEM nicht).

Internals:
   CFGFN     
   DEVICETOPIC MQTT_Device
   FUUID      609a729b-f33f-15ff-61ee-db771306400aef4d
   IODev      MQTT_Client
   LASTInputDev MQTT_Client
   MSGCNT     12
   NAME       MQTT_Device
   NR         81
   STATE     
   TYPE       MQTT2_DEVICE
   MQTT_Client_MSGCNT 12
   MQTT_Client_TIME 2021-05-11 14:34:01
   READINGS:
Attributes:
   IODev      MQTT_Client
   readingList v1/devices/me/rpc/response/.*:.* { json2nameValue($EVENT) }
   room       ThingsBoard

[Beta-User]

Die Angabe beim Client ist doch nicht optional ? <host>:<port>
Da fehlt doch das Port in der DEF?

Guter Hinweis!

Im M2C muss jedenfalls erkennbar sein, dass eine Verbindung besteht (opened oder so im state). Dass ggf. was rausgeht, bedeutet nicht zwangsläufig, dass FHEM die Verbindung dauerhaft hält, um zu hören!

Ergänzend evtl. noch, weil da auch "Missverständnispotential" drinsteckt:

das Topic muss "v1/devices/me/rpc/request/+" sein,

Hinweis: In FHEM/readingList muss man das "+" als regex notieren, also ".*" (bzw. etwas enger: "[^/]+", wenn man einzelne Teile des Topic-Trees meint)

da über "response" die Antwort vom Client (in diesem Fall FHEM) übertragen wird. Ich habe es dennoch mit beiden probiert und im Eventlog erscheint keine Nachricht.

Jetzt ist zwar klarer, dass du eine Art von extern gesteuertem Dialog realisieren willst, aber "Eventlog" deutet m.E. darauf hin, dass das Verständnis noch nicht klar ist, was FHEM eigentlich wo macht.
- Eingehende Nachrichten werden per default nicht geloggt und erzeugen auch nur dann Events, wenn man ein Attribut am IO (M2_CLIENT) setzt. Geloggt wird das aber NICHT, die Ausgabe erfolgt wie bereits geschrieben am Event-Monitor...
- Am MQTT2_SEVICE sollte eine eingehende Nachricht einfach Readings erzeugen, hier zwei mit den Infos aus den key-value-Paaren in dem JSON.
Da du alles händisch angelegt hast, gibt es kein FileLog, das die Readings mitschreiben würde...

[kampi]

Also ich habe das MQTT2_CLIENT jetzt noch einmal mit zusätzlicher Portangabe erzeugt und das Device neu angelegt.

Code Auswählen Erweitern


defmod MQTT_Client MQTT2_CLIENT <IP>:1883


Geändert hat es leider nichts. Bei State vom Client stehen immer noch drei "?".

[Beta-User]

Da ich mal unterstelle, dass das irgendein öffentlicher Server ist, den du da anzapfen willst:

Braucht man dafür keine Zugangsdaten? Publishen mag ja noch angehen, aber spätestens beim Abholen würde mich das sehr wundern...

Jedenfalls wird das nicht klappen, solange der CLIENT keinen "state" hat. $ACCESS_TOKEN und https://thingsboard.io/docs/user-guide/basic-mqtt/ wären die Stichworte, wenn ich das hier richtig gepuzzelt habe...