[Gelöst]Probleme mit der Auswertung von MQTT-Subscriptions

[freddie]

Hallo Zusammen

Ich bin der Freddie und beschäftige mich seit einigen Wochen mit FHEM. Inwischen habe ich bereits Einiges erreicht: Über die Web-Oberfläche (Taster) kann ich Programme (Ausgänge) an einer NodeMCU via MQTT steuern,  der Floorplan ist erstellt und Buttons sind darauf abgelegt, die allerdings anders funktionieren als auf der Weboberfläche (), aber das werde ich noch austesten.
Mein aktuelles Problem hat mit dem Auswerten von MQTT-Subscriptions zu tun:
Ich habe ein Device angelegt, das MQTT-Nachrichten (Statusmeldungen) empfängt und dann an einen Dummy zur Anzeige (Zustands-Icons) weiterleitet.  Der Dummy funktioniert und setzt die Icons wie gewünscht. Was leider nicht funktioniert ist das Auslesen und Transferieren der Statusmeldungen an den Dummy. Ich bekomme die Meldung, daß Nachrichten eingegangen sind ("incoming publish received"), aber ich kann diese Meldungen irgendwie nicht weiterreichen. Ich habe schon alle möglichen Dinge probiert (stateFormat geändert, userReadings angelegt, notifies angelegt, event-on change-reading, etc.). Irgendwie kann ich die Rückmeldung nicht auslesen. Leider steht in der Commandref nciht viel zu diesem Thema und auch das Wiki gibt nicht viel her. Aus den Threads die ich gelesen habe, bin ich auch nicht viel schlauer geworden. Irgendwie stehe ich hier gewaltig auf dem Schlauch!
Für alle Fälle habe ich mal die Internals des Empfangsdevice hier mit angehängt:

Code Auswählen Erweitern


DeviceOverview
WZ_RR_Status incoming publish received
Internals
CHANGED
IODev MQTT_RasPI
NAME WZ_RR_Status
NR 29
STATE incoming publish received
TYPE MQTT_DEVICE
Readings transmission-state incoming publish received 2018-04-12 22:42:24

IODev MQTT_RasPI
autoSubscribeReadings WZRR_Status
devStateIcon up:fts_shutter_10 down:fts_shutter_1w_90 stopped:fts_shutter_manual active_up:fts_shutter_up active_down:fts_shutter_down window_open:fts_window_2w_open_r window_closed:fts_window_2w
room Wohnzimmer
stateFormat transmission-state
subscribeReading WZRR_Status
subscribeReading_status status WZRR_Status

Vielleicht kann mir ja einer der etwas erfahreneren FHEM-User einen Schubs in die richtige Richtung geben ...

CU

Freddie

[Beta-User]

Zur Anzeige von Daten aus "Gross-Devicen" ist oft readingsGroup oder readingsProxy besser geeignet.

[freddie]

Sorry, irgendwie stehe ich immer noch auf demselben Schlauch!
Mit readingsProxy kann ich ein Reading einem anderen (neuen) Device zuordnen, soviel ist klar. Mit readingsGroup kann ich Readings mehrerer Devices ausgeben. Soweit ist das klar. Nur: Irgendwie bekomme ich als Reading immer nur "incoming publish received" und die Uhrzeit, aber keinen Text. Wo ist der gesendete Text? Ich habe schon eine kleine Perl-Routine geschrieben, die das Reading auswerten soll, da aber immer nur "incoming publish received" und die Uhrzeit kommt, kann die Routine natürlich nichts auswerten ...

CU Freddie

[Beta-User]

OK, sieht so aus, als hättest du die readings noch gar nicht im MQTT-DEVICE - die Frage, wie man das in einen/mehrere Dummy bekommt (wofür?!?), hat mich in die falsche Richtung geschickt.

Also: Erst mal muss das MQTT_DEVICE ordnungsgemäß funktionieren, dann sollten da mehr readings exisiteren.

Bitte dazu das Wiki (Einführung) konsultieren und evtl. mal posten, was z.B. mosquitto_sub so an Verkehr zu diesen Devices mitbekommt. Du benötigst ggf. expandJSON.

Gruß, Beta-User

[freddie]

Die Statusmeldungen kommen an, zumindest behauotet MQTTfx das. Dort kann ich sowohl die Kommandos als auch die Rückmeldung bekommen. Die Meldungen kommen im Klartext (der MQTTfx steht auf "Plain text decoder", sodaß ein expandJSON in dem Fall nicht notwendig sein sollte). Es kommen einfache Meldungen, wie "up", "down", "active_up", "active_down", "stopped", window_open", "window_closed". Aus diesen Meldungen sollen Icons generiert werden. Da das nicht geklappt hat, habe ich versucht, die Readings an einen Dummy zu schicken um sie dort umzusetzen.
Das MQTT_Device sollte funktionieren, da die Kommandos ja auch abgeschickt werden.
Die Internals zeigen, daß es verbunden ist:

Code Auswählen Erweitern


Internals:
   DEF        192.168.xxx.xxx:1883
   DeviceName 192.168.xxx.xxx:1883
   FD         4
   NAME       MQTT_RasPI
   NOTIFYDEV  global
   NR         22
   NTFY_ORDER 50-MQTT_RasPI
   PARTIAL   
   STATE      opened
   TYPE       MQTT
   buf       
   msgid      3
   ping_received 1
   timeout    60
   READINGS:
     2018-04-13 17:06:44   connection      active
     2018-04-13 16:46:44   state           opened
   messages:
Attributes:
   fp_Grundriss 400,810,0,
   icon       Raspberry32
   room       Buero

Leider steht in der Einführung nicht allzu viel zum Thema MQTT. Ich mache gerne viel selbst (auch um zu lernen) und habe vor einiger Zeit angefangen "C" zu lernen und schreibe eigene Programme für die NodeMCUs. Daher auch die Status-Meldungen. Die NodeMCUs sind per WLAN mit dem RasPI (AP) verbunden, der jedoch nicht als Bridge fungiert. Lediglich der MQTT sendet in und empfängt aus dem  LAN.

CU

Freddie

[Beta-User]

Bin auch erst am Einarbeiten in das ganze Thema, kann also nur sehr bedingt helfen.

Was mir auffällt: stateFormat sollte dann woanders hin zeigen (vermutlich nach status), oder?

Habe ich das richtig verstanden: du schickst alle Detailinfos dann auf unterschiedliche Topics unterhalb status? Dann sollten irgendwann auch entsprechend mehr subscribe-Attribute und readings entstehen. Oder kommt alles auf denselben Kanal? Dann wäre vermutlich Dekodieren auf FHEM-Seite besser. Mind. Dinge, die nichts miteinander zu tun haben, sollten auf unterschiedliche Topics gehen (hier: Rolladen und Fenster, das erspart die Nacharbeit auf der FHEM-Seite.

Das ganze sollte dann eigentlich auch direkt am Device bzw. mit den genannten Modulen readings... visualisierbar sein, ohne Dummys.

[freddie]

Das ganze sollte dann eigentlich auch direkt am Device bzw. mit den genannten Modulen readings... visualisierbar sein, ohne Dummys.

Genau das hatte ich als erstes versucht, hat aber auch nicht geklappt, da anscheinend nichts übergeben wird. Mit "stateFormat" habe ich auch schon mehrere Ansätze versucht, nichts davon hat geklappt. Mit einem Homematic-Device bekomme ich Readings. Irgendwo werden die Readings ins Nirwana geschickt!
Zur Zeit versuche ich, zunächst einmal einen Rolladen ans Laufen zu bekommen, daher nur ein Topic. Jeder Rolladen bekommt dann seinen eigenen Topic. Das Einzige was mir jetzt noch einfällt, ist, daß der Topic nur einen Namen ohne "/" hat! Vielleicht muß ich den Topic-Namen ja ändern und statt der "_" "/" einführen. Werde ich gleich mal testen!

CU

Freddie

[helmut]

Hallo Freddie,

Dein Listing vom MQTT_DEVICE ist vollstaendig?

Die "subscribeReading"s sehen auch nicht gesund aus. Erweitere als erstes das autoSubscribeReadings:

Code Auswählen Erweitern

attr WZ_RR_Status autoSubscribeReadings +/<topic>/+

Ersetze <topic> mit dem Wert des Topics Deines NodeMCU.
Dann sollten alle zur Verfuegung stehenden Topics in den Attributen und den Readings erscheinen.
Danach kannst Du Dich um stateFormat und den Rest kuemmern.

Gruss Helmut

[freddie]

Hallo Helmut

Mein im letzten Post geäußerter Verdacht war richtig! Anscheinend muß das Topic einen "/" enthalten, dann sind zumindest im "list <name des MQTT_DEVICE> Readings vorhanden, wenn auch noch nicht gefüllt:

Code Auswählen Erweitern


Internals:
   CHANGED   
   IODev      MQTT_RasPI
   NAME       WZ_RR_Status
   NR         27
   STATE      Status
   TYPE       MQTT_DEVICE
   OLDREADINGS:
   READINGS:
     2018-04-13 20:27:13   transmission-state incoming publish received
   message_ids:
   sets:
   subscribe:
     WZ/RR_Status
     Status
   subscribeExpr:
     ^WZ\/RR_Status$
     ^Status$
   subscribeReadings:
     Status:
       cmd       
       name       .*
     WZ/RR_Status:
       cmd       
       name       .*
Attributes:
   IODev      MQTT_RasPI
   autoSubscribeReadings WZ/RR_Status
   room       Wohnzimmer
   stateFormat Status

Jetzt muß ich sie nur noch füllen.
N.B.: Das Einfassen des Topic in +/<Name des Topic>/+ ändert hier nichts.

CU

Freddie

[freddie]

So, jetzt hab ich das Reading!
Das Problem war, daß ich das Atrribut "subscribeReading_" in der Web-Oberfläche über "subscribeReading_.*" gesetzt habe! Dann wird das "subscribeReading_" anscheinend nicht richtig gesetzt. Wenn man aber das Ganze mit "attr subscribeReading_state <Topic>" setzt, funktioniert es anschließend.
N.B.: Man kann den Status auch für das "Extend devStateIcon" nutzen. Damit hat sich das Dummy-Device auch erledigt. Nur: die "Extend devStateIcon"s werden wohl im Floorplan nicht angezeigt (Leeres Feld). Da werde ich wohl noch zu lesen müssen ...

CU Freddie