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:
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
Zur Anzeige von Daten aus "Gross-Devicen" ist oft readingsGroup oder readingsProxy besser geeignet.
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
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
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:
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
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.
Zitat von: Beta-User am 13 April 2018, 17:33:32
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
Hallo Freddie,
Dein Listing vom MQTT_DEVICE ist vollstaendig?
Die "subscribeReading"s sehen auch nicht gesund aus. Erweitere als erstes das autoSubscribeReadings:
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
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:
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
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