MQTT2_DEVICE bekommt keine Nachrichten

[kampi]

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

[kampi]

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

[kampi]

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.

[Beta-User]

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

[kampi]

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

[Beta-User]

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

[kampi]

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.

[Beta-User]

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:

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:

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