MQTT2_DEVICE bekommt keine Nachrichten

[kampi]

Hi Otto,

my bad - ich habe die List für den falschen Server erstellt, weil ich parallel ein paar Lösungen testen wollte (sorry, der Server ist nur zum Testen der MQTT-Verbindung ganz allgemein da - das es damit funktioniert weiß ich auch, aber ThingsBoard ist das Problem).

Vergiss bitte die alte List. Damit das nicht noch einmal passiert hier noch einmal eine Zusammenfassung was ich jetzt gemacht habe:

1) In FHEM die Serveradresse und den Username für ThingsBoard eingetragen
2) List erstellt (IP entferne ich hier mal, weil ich die nicht im Netz stehen haben will)

Code Auswählen Erweitern


Internals:
   BUF       
   CFGFN     
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        ...
   DeviceName ...
   FD         12
   FUUID      609adff8-f33f-15ff-0567-65a8c55f96358158
   NAME       ThingsBoard_Client
   NR         634
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   ThingsBoard_Client
   lastMsgTime 1620844771.64464
   nextOpenDelay 5
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:

     2021-05-12 20:33:01   state           opened
Attributes:
   autocreate simple
   rawEvents  .*
   username   YDy8IoRnZOG68HYXnxaa
   verbose    5


Aber da passiert nichts und da kommt auch nichts in FHEM an...

Wenn ich mich nun wieder direkt per SSH auf dem System mit der FHEM-Installation einlogge und mich per mosquitto bei dem ThingsBoard-Server subscribe erhalte ich die Nachrichten korrekt.

Also ganz konkret:

- ThingsBoard publisht Nachrichten in v1/devices/me/rpc/request/*
- Ich erstelle in FHEM einen Client und ein Device und Subscribe mich mit einem Username auf das Topic (autocreate simple) und nichts passiert
- Ich subscribe mich mittels mosquitto mit einem Username auf das Topic und erhalte die Nachrichten

Ich hoffe es ist nun etwas klarer geworden. Sorry nochmal für das Missverständnis, aber da habe ich gepennt, bzw. eine Änderung nicht rückgängig gemacht (wie gesagt ich versuche auch so ein bisschen den Fehlerbereich einzugrenzen). Da die Nachrichten definitiv an dem System mit FHEM ankommen muss das Problem irgendwo bei FHEM liegen, da mosquitto in der Shell super funktioniert...

[Otto123]

Was mich an dem list wieder stört:

READINGS:

     2021-05-12 20:33:01   state           opened

die Leerzeile. Hast Du da was rausgelöscht?

Aber da passiert nichts und da kommt auch nichts in FHEM an...

Ein list TYPE=MQTT2_DEVICE hast Du auch noch nicht gemacht. Du gehst davon aus, FHEM macht einen Fehler. Alles was Du bisher zeigst sagt mir: Du machst den Fehler.
Denn Nachrichten kommen in deinem Client offenbar an! Sonst gäbe es das Internal nicht.

lastMsgTime 1620844771.64464
   nextOpenDelay 5

1) In FHEM die Serveradresse und den Username für ThingsBoard eingetragen

Ein Passwort hast Du bei deinem Client auch gesetzt?

Also bitte jetzt ein list TYPE=MQTT2_DEVICE

[kampi]

Hi,

da stand ein längerer JSON-String mit Telemetriedaten von FHEM drin, welcher an mein ThingsBoard übertragen wurde. Den habe ich zwecks Übersichtlichkeit raus geschmissen.

Hier das angeforderte Listing (und der vollständigkeit halber das komplette andere Listing)

Code Auswählen Erweitern


Internals:
   BUF       
   CFGFN     
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        ...
   DeviceName ...
   FD         5
   FUUID      609adff8-f33f-15ff-0567-65a8c55f96358158
   NAME       ThingsBoard_Client
   NR         634
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   ThingsBoard_Client
   lastMsgTime 1620846466.12286
   nextOpenDelay 5
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2021-05-12 21:07:45   lastPublish     v1/devices/me/telemetry:{
'heartbeat' : 1620846465,
'current1' : 1.2,
'current2' : 2.3,
'current3' : 0.0,
'current4' : 0.3,
'current5' : 0.6,
'temperature1' : 21.2,
'temperature1' : 18.3,
'temperature1' : 20.5,
'temperature1' : 23.0,
'lamp1' : false,
'lamp2' : false,
'lamp3' : false,
'lamp4' : false,
'lamp5' : false,
'lamp6' : true,
}
     2021-05-12 20:42:45   state           opened
Attributes:
   autocreate simple
   rawEvents  .*
   username   YDy8IoRnZOG68HYXnxaa
   verbose    5


Code Auswählen Erweitern


Internals:
   CFGFN     
   CID        ThingsBoard_Client
   DEF        ThingsBoard_Client
   DEVICETOPIC ThingsBoard_Device
   FUUID      609ae067-f33f-15ff-7069-f998c68913daa488
   IODev      ThingsBoard_Client
   NAME       ThingsBoard_Device
   NR         658
   STATE      ???
   TYPE       MQTT2_DEVICE
Attributes:
   IODev      ThingsBoard_Client
   readingList v1/devices/me/rpc/request/.* { json2nameValue($EVENT) }



[Otto123]

Das ist doch nicht wirklich die Ausgabe von diesem Befehl: ?

Code Auswählen Erweitern

list TYPE=MQTT2_DEVICE
Und wenn ja, dann hast Du nur ein MQTT2_DEVICE ? und da ist die readingList mMn falsch 

Dieses internal lastpublish hast Du in FHEM erzeugt?

Kannst Du Dich mit mqtt Explorer zu deinem ThingsBoard verbinden und das was Du willst (was ich nicht verstanden habe) nachvollziehen?

[kampi]

Hi Otto,

doch das ist die vollständige Ausgabe von dem Befehl (siehe Screenshot).

Code Auswählen Erweitern


list TYPE=MQTT2_DEVICE


Das internal lastPublish vom Client habe ich selbst in FHEM erzeugt.

Was soll ich den mit dem MQTT Explorer prüfen? Ich kenne das Tool nicht und weiß gerade auch noch nicht so richtig wie ich es bedienen muss...

[Otto123]

Und im FHEM Logfile stehen trotz verbose 5 keine Einträge vom ThingsBoard_Client?

[kampi]

Nein gar nichts

[Otto123]

Moin,
ich weiß nicht was ich davon halten soll. Egal was ich bei einem MQTT2_CLIENT eintrage, mit verbose 5 kommt da nicht "gar nichts" der "redet" ständig, wenigstens Ping requests ...

Dein FHEM Logfile funktioniert ansonsten ? - oder ist das irgendwie "abgeschaltet"?
Das einzige was Du bisher als Log gepostet hast sah aus wie aus dem Eventmonitor... 

Ein schöner verregneter Himmelfahrtstag
Otto

[Beta-User]

Weiß nicht, ob wir das schon abgesichert hatten, aber FHEM ist aktuell? (=> "version MQTT2.*")

[kampi]

Hi,

Weiß nicht, ob wir das schon abgesichert hatten, aber FHEM ist aktuell? (=> "version MQTT2.*")

Code Auswählen Erweitern


00_MQTT2_CLIENT.pm 23612 2021-01-25 09:33:06Z rudolfkoenig
10_MQTT2_DEVICE.pm 23596 2021-01-23 17:25:12Z rudolfkoenig

fhemweb.js                 23453 2021-01-01 18:10:12Z rudolfkoenig


Moin,
ich weiß nicht was ich davon halten soll. Egal was ich bei einem MQTT2_CLIENT eintrage, mit verbose 5 kommt da nicht "gar nichts" der "redet" ständig, wenigstens Ping requests ...

Dein FHEM Logfile funktioniert ansonsten ? - oder ist das irgendwie "abgeschaltet"?
Das einzige was Du bisher als Log gepostet hast sah aus wie aus dem Eventmonitor... 

Ein schöner verregneter Himmelfahrtstag
Otto

Im Log steht tatächlich etwas mehr... (das vorherige war nur der Eventlog)

Code Auswählen Erweitern


2021.05.13 12:03:55 5: ThingsBoard_Client: sending PINGREQ (192)(0)
2021.05.13 12:03:55 5: ThingsBoard_Client: received PINGRESP
2021.05.13 12:04:25 5: ThingsBoard_Client: sending PINGREQ (192)(0)
2021.05.13 12:04:25 5: ThingsBoard_Client: received PINGRESP


Aber das ist auch nur der Client, der seit gestern fröhlich Daten zum ThingsBoard sendet. Vom Device fehlt jede Spur

[LuckyDay]

Code Auswählen Erweitern

00_MQTT2_CLIENT.pm    24349 2021-04-28 15:13:33Z rudolfkoenig
10_MQTT2_DEVICE.pm    23843 2021-02-27 19:42:42Z rudolfkoenig

warum benutzt man so alte Versionen bei Problemen?

[kampi]

Hi,

hab ein Update ausgeführt, aber das Problem bleibt leider bestehen.

[Otto123]

Ich hab mal ein ThingsBoard als docker container aufgesetzt. Aber irgendwie komm ich damit nicht klar. Ich kann diese Einleitung in der Doku nachvollziehen und Daten dort hin schicken (mosquitto_pub). Das Gerät im ThingsBoard empfängt dies.
Aber eine dauerhafte Verbindung mit MQTT2_CLIENT bekomm ich nicht hin. Der wechselt immer den status.
Auch mit mosquitto_sub bekomme ich keine dauerhafte Verbindung, die wird immer aufgebaut und abgebrochen. Daten kommen nicht zurück.

Was muss ich dafür tun, das ThingsBoard die Daten wieder hergibt. Aus meiner Sicht ist das erstmal nur eine Senke.

Gruß Otto

[kampi]

Hi Otto,

eine MQTT-Verbindung von ThingsBoard zum Device ist etwas spezieller, weil das Device innerhalb von einer bestimmten Timeout-Zeit mit der Request-ID einen Publish machen muss.

Schau dir mal den "Server-side RPC" an. Das ist im Prinzip das was ich erreiche möchte.

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

[Otto123]

ich denke dieses ThingsBoard ist zu speziell, eventuell deswegen:

The following example is written in javascript and is based on mqtt.js. Pure command-line examples are not available because subscribe and publish need to happen in the same mqtt session.

Die Session wird getrennt in dem Moment wo MQTT2_CLIENT etwas published. Dieses Verhalten hat man auch wenn man mit mosquitto_sub _pub arbeitet.

Ich habe versucht zu verstehen, was man mit ThingsBoard machen könnte. Mir ist es nicht gelungen 

ThingsBoard ist offenbar kein normaler MQTT Broker, das ist eher ne Verarbeitungsmaschine mit mqtt Ein- und Ausgang.
Man kann mit MQTT2_CLIENT Daten dorthin schaufeln. Welche von dort wegzubekommen gelingt mir nicht. Aber ich weiß auch zu wenig von der Thematik.