[gelöst] Zusammenhang event-on-change-reading und Aktualisierung von subscribe..

Begonnen von qubit, 03 Dezember 2017, 18:05:51

Vorheriges Thema - Nächstes Thema

qubit

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.

  • Ohne Verwendung von event-on-change-reading erhalte ich für alle  <mqtt_msg> Readings Aktualisierungen vom MQTT Broker.
  • Gebe ich aber z.B. ein <mqtt_msg> Reading in event-on-change-reading an, wird nur noch dieses <mqtt_msg> Reading im MQTT_DEVICE aktualisiert.
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.

hexenmeister

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?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

qubit

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.