FHEM Forum

Hallo zusammen,

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


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:


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?

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.

Hi,

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

Willst du (von FHEM aus) senden oder empfangen?

Empfangen wäre readingList:
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).

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...

Zitat von: Beta-User am 11 Mai 2021, 11:13:01
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...)

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:


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


Ich meine, die Logik ist anders:

Zitat
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:

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...

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.

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?

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

ZitatMQTT2_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 list MQTT_Client damit man beurteilen kann ob der überhaupt einen Verbindung hat?

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.

Zitat von: Otto123 am 11 Mai 2021, 16:47:25
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

Zitat von: Otto123 am 11 Mai 2021, 16:47:25
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:

Zitat von: kampi am 11 Mai 2021, 16:35:23
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)

Zitat
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...

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


defmod MQTT_Client MQTT2_CLIENT <IP>:1883


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

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...

Hi,

der Server ist ein privater von mir (gibt es auch als Probeversion: https://cloud.thingsboard.io/home). Für die MQTT-Verbindung werden Zugangsdaten (in Form eines zufälligen Usernames) benötigt, welche beim Erstellen des Gerätes im ThingsBoard erzeugt werden. Diese Zugangsdaten habe ich bei FHEM eingegeben:


attr MQTT_Client username abcdefghijklmnopqr


Username ist nach meinem Verständnis nur die halbe Miete, es muss vermutlich auch ein PW gesetzt werden. Es macht aber keine Freude, das alles dann erst auf Nachfrage zu erfahren...

Zitat von: Beta-User am 11 Mai 2021, 17:39:32
Username ist nach meinem Verständnis nur die halbe Miete, es muss vermutlich auch ein PW gesetzt werden. Es macht aber keine Freude, das alles dann erst auf Nachfrage zu erfahren...

Nein das Passwort ist optional. Das Senden per MQTT in Richtung ThingsBoard habe ich bereits im Vorfeld über MQTT.fx getestet und ohne Passwort, aber mit Username konnte ich eine Verbindung zum Broker herstellen. Als ich beides weg gelassen habe gab es Verbindungsfehler. So habe ich schon ausprobiert was ich senden muss und was ich zurück bekomme und aktuell scheitert halt nur das MQTT2_DEVICE, sprich der Weg von ThingsBoard zu FHEM. :(

Hab es gerade noch einmal direkt auf dem System mit FHEM über mosquitto probiert:


mosquitto_sub -h <IP> -p 1883 -t v1/devices/me/rpc/request/+ -u <Username>


Das klappt soweit und ich bekomme auch die Nachrichten.


{"method":"Fancy","params":"Method"}
{"method":"Fancy","params":"Method"}
{"method":"Fancy","params":"Method"}
{"method":"Fancy","params":"Method"}
{"method":"Fancy","params":"Method"}
{"method":"Fancy","params":"Method"}


Hmm, dann sorry für den Einwand :( .

Kannst du denn die Messages sehen, wenn du dich mit mosquitto_sub auf dem Server subscribest?
(ja, geht offenbar)
Wenn M2_CLIENT kein opened hinbekommt, kann jedenfalls nichts im DEVICE ankommen.

Ggf. musst du mal Rudi um Hilfe bitten, wenn das ganze so nicht klappt (wobei mir nicht klar ist, warum es einen speziellen Broker braucht; evtl. hat auch der Eigenheiten, die wir (noch) nicht kennen).

Hi,

noch einmal kurz zusammengefasst was ich bereits weiß und probiert habe:

- Ich habe mich über MQTT.fx mit meinem ThingsBoard verbunden und das Topic "v1/devices/me/rpc/request/+" subscribed, woraufhin ich die gesendeten Nachrichten von ThingsBoard bekomme. Die Nachrichten hatten das Format (Beispiel):

Topic: v1/devices/me/rpc/request/256
Payload: {"method":"Fancy","params":"Method"}

- Ich habe FHEM mit einem mosquitto-Broker (ohne ThingsBoard) verbunden und folgendes konfiguriert:


defmod MQTT_Client MQTT2_CLIENT <IP>:1883
defmod MQTT_Device MQTT2_DEVICE
attr MQTT_Device IODev MQTT_Client
attr MQTT_Device readingList v1/devices/me/rpc/request/.* { json2nameValue($EVENT) }


Und dann per mosquitto die folgende Nachricht abgesetzt:


mosquitto_pub -t "v1/devices/me/rpc/request/256" -m '{"method":"Fancy","params":"Method"}'


Und die Nachricht tauchte im Log auf:


2021-05-11 18:09:55 Global global ATTR ThingsBoard_Device readingList v1/devices/me/rpc/request/.* { json2nameValue($EVENT) }
2021-05-11 18:10:10 MQTT2_DEVICE ThingsBoard_Device method: Fancy
2021-05-11 18:10:10 MQTT2_DEVICE ThingsBoard_Device params: Method


- Ich habe in FHEM die Verbindung zum Broker umgeändert in eine Verbindung zur ThingsBoard-Instanz (URL angepasst und den Username eingegeben). Daten von FHEM zur ThingsBoard-Instanz werden gesendet (sehe ich sowohl im Log, als auch im ThingsBoard). Daten von ThingsBoard zu FHEM werden nicht gesendet

- Wenn ich auf dem System mit FHEM mich per mosquitto auf das Topic von ThingsBoard subscribe erhalte ich die Nachrichten ebenfalls:


mosquitto_sub -h <IP> -p 1883 -t v1/devices/me/rpc/request/+ -u <UserName>
{"method":"Fancy","params":"Method"}
{"method":"Fancy","params":"Method"}
{"method":"Fancy","params":"Method"}


Somit ist klar das die Nachrichten auf dem System ankommen. Aber irgendwie kommen sie nicht bei FHEM an.

Du hast meine Frage nach list MQTT_Client in #11 mit einem list MQTT_Device beantwortet.
Entweder bist Du wirr oder Dein System!!!

Kannst Du mal nachliefern damit man sich überzeugen kann, dass es überhaupt eine Verbindung gibt?! Und bitte nicht alles faken, private IP Adressen sind sowas von egal...
Accounts sollst Du natürlich rausnehmen!

Gruß Otto

Zitat von: Otto123 am 11 Mai 2021, 20:04:07
Du hast meine Frage nach list MQTT_Client in #11 mit einem list MQTT_Device beantwortet.

Sorry hab mich verlesen...


Internals:
   BUF       
   CFGFN     
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        h2907213.stratoserver.net:1883
   DeviceName h2907213.stratoserver.net:1883
   FD         10
   FUUID      609ac8da-f33f-15ff-8a04-73a5f2332f0adf21
   NAME       MQTT_Client
   NR         492
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   MQTT_Client
   lastMsgTime 1620756774.97591
   nextOpenDelay 5
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2021-05-11 20:11:54   state           opened
Attributes:
   username   ...


Warum hast Du das MQTT_Client Device nicht mal  auf autocreate simpel gestellt und geschaut was da angelegt wird? Wir rätseln doch immer noch um den richtigen topic?

Zitat von: Otto123 am 11 Mai 2021, 20:22:19
Warum hast Du das MQTT_Client Device nicht mal  auf autocreate simpel gestellt und geschaut was da angelegt wird? Wir rätseln doch immer noch um den richtigen topic?

Ich habe eben "simple" und "complex" probiert und bei beiden passiert nichts.

Das Topic ist m. M. n. soweit klar, weil ich mich (wie bereits geschrieben) über mosquitto verbinden kann und auch die Nachricht empfange (nur halt in FHEM nicht).

simpel ist sinnvoll, complex ist speziell - deswegen habe ich simpel gesagt. Da wurde kein neues MQTT2_DEVICE erzeugt - nachdem dein MQTT mal gesendet hat?
list TYPE=MQTT2_DEVICE
Wenn das so ist behaupte ich: Dein MQTT2_CLIENT steht allein im Wald.

Vermutung: das mit User ohne Passwort ist nicht vorgesehen in m2c.

mmh wie kann man das Problem den jetzt möglichst elegant lösen?

Habe mal in den Code von M2C geschaut, aber eigentlicht sieht mir das (mit meinen diesbezüglich aber sehr ungeübten Augen!) nicht so aus, als wäre trotz user-Angabe zwingend ein PW erforderlich.

Und "opened" sieht mir auch ok aus.

Vermutlich wäre es sinnvoll, den M2C mal auf verbose 5 zu setzen, autocreate auf simple zu lassen und dann mal den Connect neu zu initiieren und ein paar Nachrichten zu schicken. Eigentlich müsste dann was im Log stehen. Falls da "schwierige Daten" drin stehen, müsstest du Rudi fragen, ob du das Log als Email-Anhang schicken kannst bzw. ihm ggf sagen, wie er selbst ein Testszenarium aufbauen kann. Falls du selbst eine Art Testserver aufziehen könntest, kannst du das ggf. auch hier einfach anpinnen (für code-Tags vermutlich zu viel).

Es wäre aber vermutlich hilfreich, wenn du Rudi die Vorarbeit dahingehend abnimmst, dass wenigstens klar ist, was das für ein Server-Typ ist, der da im Hintergrund den Broker mimt, warum 3.1.1 "richtig" ist, usw..

(Generell ist mir das vom Datenfluss her etwas suspekt, dass auf diese Art und Weise was von den Clients erfragt wird. Eventuell würde es auch genügen, einfach die "erwünschten Daten" jeweils bei der Generierung (also der Reading-Aktualisierung in FHEM) an die Zentrale (ThingsBoard soll das wohl sein) zu schicken; dafür wäre dann MQTT_GENERIC_BRIDGE vermutlich die zu wählende Lösung).

Wie sollen wir helfen? Meine Frage aus #25 hast Du nicht beantwortet  :'(

ZitatDa wurde kein neues MQTT2_DEVICE erzeugt - nachdem dein MQTT mal gesendet hat?

Ein list hast Du auch nicht geliefert.

Edit: Ich habe jetzt mal ganz frech den Client aus #22 als mqt ohne username angelegt. autocreate simpel gemacht, sofort wird ein Device angelegt:
Internals:
   CFGFN     
   CID        mqt
   DEF        mqt
   DEVICETOPIC MQTT2_mqt
   FUUID      609bf2f3-f33f-27f7-ad94-77f010afd54ab17e
   IODev      mqt
   LASTInputDev mqt
   MSGCNT     1
   NAME       MQTT2_mqt
   NR         402917
   STATE      ???
   TYPE       MQTT2_DEVICE
   mqt_MSGCNT 1
   mqt_TIME   2021-05-12 17:24:31
   READINGS:
     2021-05-12 17:24:31   telemetry       {
'heartbeat' : 1620833071
}
Attributes:
   IODev      mqt
   readingList mqt:v1/devices/me/telemetry:.* telemetry
   room       MQTT2_DEVICE
Das Herz schlägt  :-*
Ich trage mal den Servernamen nicht weiter ?!
defmod mqt MQTT2_CLIENT hxx07xxy.stratoserver.net:1883
attr mqt autocreate simple
attr mqt rawEvents .*
attr mqt verbose 5
attr mqt username willi
Edit: Nach dem Motto: Namen sind Schall und Rauch hab ich ihm mal noch den usernamen willi gegeben. Das herz schlägt weiter und es kommt noch ein learning attribute :)

Wenn da mit einem mqtt Explorer etwas publishe topic v1/devices/me/otto dann bekommt mein Client das auch zurück:
2021-05-12 17:49:51   otto            "eins zwei drei"
Also ich sage mal Dein MQTT Server funktioniert und der Zugriff mit MQTT2_Client und MQTT2_DEVICE funktioniert auch !
Allerdings ist er völlig offen und jeder darf ...  :-X

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)


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...

Was mich an dem list wieder stört:

ZitatREADINGS:

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

die Leerzeile. Hast Du da was rausgelöscht?

ZitatAber 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.

ZitatlastMsgTime 1620844771.64464
   nextOpenDelay 5

Zitat1) 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

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)


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



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) }



Das ist doch nicht wirklich die Ausgabe von diesem Befehl: ?
list TYPE=MQTT2_DEVICE
Und wenn ja, dann hast Du nur ein MQTT2_DEVICE ? und da ist die readingList mMn falsch  :o

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?

Hi Otto,

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


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...

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

Nein gar nichts

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

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

Hi,

Zitat von: Beta-User am 13 Mai 2021, 10:19:35
Weiß nicht, ob wir das schon abgesichert hatten, aber FHEM ist aktuell? (=> "version MQTT2.*")


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


Zitat von: Otto123 am 13 Mai 2021, 09:08:11
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)


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 :(

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?

Hi,

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

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

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/

ich denke dieses ThingsBoard ist zu speziell, eventuell deswegen:

ZitatThe 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.

Hi Otto,

also dieses Problem konnte ich jetzt nicht nachvollziehen, weil die Daten ja bei meinem Raspberry Pi (auf dem FHEM läuft) ankommen.

Anbei mal eine Bilderreihe von meiner Regelkette, die periodisch eine Nachricht an mein FHEM sendet. Dabei ist das Gerät "Arbeitszimmer" das Gerät, mit dessen Login-Daten FHEM sich dann beim ThingsBoard anmeldet.

Und wenn ich mich an dem Raspberry Pi per SSH einlogge und dort mosquitto starte empfange ich auch die Nachrichten (sprich sie kommen am Gerät an), aber sie tauchen halt nicht im FHEM auf. Also irgendwas muss mosquitto offenbar anders machen als FHEM :)

Mir ist (glaube ich) eine gute Idee gekommen wie ich das Problem lösen kann...

Ggf. "degradiere" ich FHEM einfach nur zu einem EnOcean-Reader und nehme das FHEM-Modul von Python um die MQTT-Übertragung zu realisieren. Ein erster Wurf sieht vielversprechend aus...

Also das "Problem" hat sich nun komplett erledigt. Ich habe heute mal den ganzen Tag das Python-Modul für FHEM (https://forum.fhem.de/index.php?topic=63816.0) getestet und ich bin wunschlos glücklich damit. Ich bin nun so verblieben, dass ich das MQTT komplett über Python laufen lasse und eine FhemEventQueue verwende um auf die Updates der EnOcean-Sensoren zu reagieren und dann die Telemetrie ins ThingsBoard zu pushen. Das Auswerten von Nachrichten aus dem ThingsBoard klappt auch wunderbar.

...dann ist ja gut...
An sich klingt mit das danach, als wäre das eigentlich ein Fall für MQTT_GENERIC_BRIDGe gewesen...

Zitat von: Beta-User am 16 Mai 2021, 20:29:44
...dann ist ja gut...
An sich klingt mit das danach, als wäre das eigentlich ein Fall für MQTT_GENERIC_BRIDGe gewesen...

So auf den ersten Blick stimme ich dir zu, aber ich weiß leider nicht ob ich nicht mit der Bridge auf das selbe Problem wie jetzt beim Device gestoßen wäre :)

Einfach nur publishen? Nö, müsste problemlos gehen...

Zitat von: Beta-User am 16 Mai 2021, 21:25:21
Einfach nur publishen? Nö, müsste problemlos gehen...

Ne ich meinte Publishen und Subscriben - quasi das was ich mit dem Client und dem Device versucht hatte.

Zitat von: kampi am 16 Mai 2021, 22:13:02
Ne ich meinte Publishen und Subscriben - quasi das was ich mit dem Client und dem Device versucht hatte.

Man kann mit MQTT_GENERIC_BRIDGE auch eingehende Nachrichten verarbeiten, klar. Voraussetzung aber auch hier: Es muss was eingehen... Und da lag ja beim MQTT2_DEVICE der Hase im Pfeffer.

ABER:

Zitat von: kampi am 16 Mai 2021, 19:15:43
Also das "Problem" hat sich nun komplett erledigt. [...] um auf die Updates der EnOcean-Sensoren zu reagieren und dann die Telemetrie ins ThingsBoard zu pushen.

Das klingt danach, als sollte einfach nur EnOcean-Sensorik nach MQTT gebracht werden. Dazu braucht es kein subscribe...

Das ist aber GANZ GENAU DAS GEGENTEIL von dem, was ursprünglich gefordert war:

Zitat von: kampi am 11 Mai 2021, 11:40:50
FHEM soll das Topic nur empfangen.

Aus der ganzen Diskussion schließe ich: Es ist immer noch nicht klar, wie und warum welche Daten wann wohin gesendet werden. Was an der Stelle von FHEM "verlangt" wird, ist nicht anscheinend nicht das, was ein MQTT-Client üblicherweise tut, nämlich (ungefragt) Sensordaten dann an den MQTT-Server zu senden, wenn diese anfallen, sondern erst auf (sehr speziell geartete) Anfrage(n) rauszurücken. (Bzw.: auf bestimmte Topics _dauerhaft_ auf (Schalt-) Anweisungen zu warten (=subscribe).)
Eigentlich _glaube_ ich nicht, dass das die wirkliche "Denkweise" von ThingsBoard ist und würde empfehlen, das nochmal kritisch zu hinterfragen, damit du nicht unnötig komplexe Routinen baust, nur um einfache Standards abzudecken...