FHEM Forum

FHEM - Hausautomations-Systeme => MQTT => Thema gestartet von: qubit am 03 Dezember 2017, 18:05:51

Titel: [gelöst] Zusammenhang event-on-change-reading und Aktualisierung von subscribe..
Beitrag von: qubit am 03 Dezember 2017, 18:05:51
Hallo,

ich habe eine Verständnisfrage zum Verhalten eines MQTT_DEVICEs bei Verwendung von event-on-change-reading.
Ich habe mehrere subscribeReading_<mqtt_msg> Attribute definiert aus denen mehrere Readings <mqtt_msg> resultieren.
Erwartet hätte ich, das ich für alle <mqtt_msg> Readings die aktualisierten Werte vom MQTT Broker im MQTT_DEVICDE gezeigt werden. Es soll aber nicht für alle ein FHEM Event ausgelöst werden.

Hintergrund ist eigentlich die Verwendung von userReadings mit Bezug zu den rohen <mqtt_msg> Readings. Ziel ist es, nur für die userReadings ein Event auszulösen, nicht für die rohen <mqtt_msg> Readings. Genau das bekomme ich nicht hin.

Für jeden Hinweis auf FHEM Grundlagen oder Device-Eigenschaften bin ich dankbar.
Titel: Antw:Zusammenhang event-on-change-reading und Aktualisierung von subscribeReading_*
Beitrag von: hexenmeister am 03 Dezember 2017, 18:13:01
So ganz habe ich das Problem nicht verstanden (den gewünschten Zustand hingegen schon).
Wenn man diese Eigenschaft setzt, werden auch nur die angegebenen Readings einen Event auslösen (und nur dadurch wird das auch in WebUI automatisch aktualisiert). Bei einem Refresh im Browser sollten dennoch alle Änderungen sichtbar sein. Da mWn die UserReadings auch per Event aktualisiert werden, werden diese ggf. eben nicht aktualisiert.
Oder habe ich Dich völlig falsch verstanden?
Titel: Zusammenhang event-on-change-reading und Aktualisierung von subscribeReading_*
Beitrag von: qubit am 03 Dezember 2017, 20:23:55
Hallo hexenmeister,
Danke, der Hinweis mit dem automatischen Aktualisieren des WebUIs hat mir geholfen. Die geänderten Werte der MQTT Nachrichten werden nach dem Refresh angezeigt.
Ich habe auch noch einmal das event-on-change-reading Attribut nur mit meinen userReadings konfiguriert. Im Gegensatz zu meinen ersten Versuchen, habe ich dabei keine Trigger auf die rohen <mqtt_msg> Readings verwendet (und ggf. noch einen unentdeckten Fehler vermieden), z.B.

attr MQTT_D_EBUSD userReadings StorageCylLowerTemp { getEbusdMsgValue('1', 'HWC_StorageCylStatus', $name) }

Im Event Monitor und der Device Übersicht sehe ich nur die geänderten Readings.
Ich verbuche das mal unter Lehrgeld, denn es geht ja wie erwartet.