MQTT_GENERIC_BRIDGE und SETREADING - Reading wird nicht rausgeschickt

[Grml]

Hallo zusammen,

ich habe ein MQTT_GENERIC_BRIDGE Device und schicke von einigen HM-Sensoren in FHEM die states etc. per MQTT raus um sie in Node Red darzustellen.
Funktioniert soweit auch recht gut. Aber bei einem Punkt habe ich gerade Probleme.

Ich habe ein Notify das auf die Änderung eines Dummy-Devices reagiert. Wenn die Änderung kommt, soll das Notify bei diesem Dummy-Device per setreading ein neues/zusätzliches READING hinpappen.

Code Auswählen Erweitern


Internals:
   DEF        Alarmanlage.Status:Scharf setreading Alarmanlage.Status lastset {($today." ".$hms)}
   FUUID      5cc03fe9-f33f-b8cb-f0b5-c000ebad9cb47552
   NAME       Alarmanlage.Status.SetDate.Notify
   NOTIFYDEV  Alarmanlage.Status
   NR         252
   NTFY_ORDER 50-Alarmanlage.Status.SetDate.Notify
   REGEXP     Alarmanlage.Status:Scharf
   STATE      2019-08-10 22:50:27
   TRIGGERTIME 1565470227.51303
   TYPE       notify
   READINGS:
     2019-08-04 20:48:58   state           active
Attributes:
   DbLogExclude .*
   room       Alarm

Das funktioniert auch. Sobald mein Dummy-Device Alarmanlage.Status im state "Scharf" hat, bekommt es zusätzlich ein neues READING "lastset" mit dem aktuellen Datum und Uhrzeit.

Dieses Dummy-Device soll nun "state" und "lastset" (und später auch "lastunset") per MQTT verschicken. Beim "state" funktioniert das auch. "lastset" wird aber nicht verschickt.
Hat da jemand eine Idee wo ich auf dem Schlauch stehe?

Kann es daran liegen, dass "state" schon mit dem Anlegen des Devices existiert, "lastset" aber erst später durch ein Notify hinzukommt? Und Wenn ja, ist das gewollt oder ein Bug in MQTT_GENERIC_BRIDGE?

Code Auswählen Erweitern


Internals:
   FUUID      5c4adb72-f33f-b8cb-e949-c81481837a34c5c0
   NAME       Alarmanlage.Status
   NR         92
   STATE      Unscharf
   TYPE       dummy
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1565470256.46338
           VALUE      Unscharf
   READINGS:
     2019-08-10 22:50:27   lastset         2019-08-10 22:50:27
     2019-08-10 22:50:56   lastunset       2019-08-10 22:50:56
     2019-08-10 22:50:56   state           Unscharf
Attributes:
   DbLogExclude .*
   DbLogInclude state
   devStateIcon Scharf:secur_locked@red Unscharf:secur_open@grey Warten:hourglass@orange
   icon       building_security
   mqttPublish state:topic={"$base/Alarmanlage/$device/$name"} lastset:topic={"$base/Alarmanlage/$device/$name"} lastunset:topic={"$base/Alarmanlage/$device/$name"}
   room       Alarm,Eingang


[rudolfkoenig]

Wenn die Änderung kommt, soll das Notify bei diesem Dummy-Device per setreading ein neues/zusätzliches READING hinpappen.

Achtung: bei so einem Verfahren kann der Benutzer die Reihenfolge der Benachrichtigungen nur bedingt beeinflussen, und fhem.pl verhindert eine rekursive Benachrichtigung. Vmtl. ist in diesem Fall userReadings die bessere Loesung.