Kein Logeintrag trotz Event im Monitor

[Damian]

Es wurde folgendes Problem beim Loggen festgestellt:

Im DOIF-Modul wird per readingsSingleUpdate ein Reading des eigenen Devices gesetzt, auf dieses Event reagiert das selbe DOIF-Device und setzt per readingsSingleUpdate ein zweites Reading im eigenen Device.

Beide Events werden im Event-Monitor angezeigt, allerdings wird nur das erste geloggt.

siehe: https://forum.fhem.de/index.php/topic,101093.msg945529.html#msg945529

[rudolfkoenig]

Kannst du mir bitte hier eine Anleitung zum Nachstellen zeigen?
Bin aus dem verlinkten Thema nicht schlau geworden.

[Damian]

Code Auswählen Erweitern

defmod di_testcmd DOIF {set_Reading("test",[FS:state],1)}
attr di_testcmd event_Readings test2: [$SELF:test]


und

Code Auswählen Erweitern

defmod FileLog_di_testcmd FileLog ./log/di_testcmd-%Y-%m.log di_testcmd

FS könnte ein Dummy sein, bei mir ist es eine FS20-Fernbedienung.

Mit

Code Auswählen Erweitern

set FS on kann man es testen.

Im Event-Monitor erscheinen die Einträge für das Reading test und test2, im Log nur zum test.

PS: Ein Logeintrag zu test2 erscheint zwar auch im Log, allerdings nur bei der Definition des Attributes (dann wir das Reading ebenfalls gesetzt), aber nicht durch die Selbsttriggerung des DOIF-Devices, wie oben geschildert.

[rudolfkoenig]

Hat mit der Benachrichtigungsreihenfolge (NTFY_ORDER) zu tun, und die Art, wie DOIF die Events erzeugt (mAn ungewoehnlich):
- set FS on
- DOIF notifyFn fuer FS: erzeugt test:on
- FileLog notifyFn fuer di_testcmd: die eine Zeile (test:on) wird geschrieben
- DOIF notifyFn fuer di_testcmd: erweitert die eigene(!) Event-Liste mit test2:on. Um eine Endlosrekursion zu vermeiden wird keine neue Benachrichtigungsrunde gestartet.
- FHEMWEB: zeigt di_testcmd an (die Liste enthaelt jetzt beide Events)
- FHEMWEB: zeigt FS on (irrelevant fuer unser Problem)

Fuer die Loesung faellt mir Folgendes ein:
- die beiden Events im DOIF zusammen erzeugen (fuer mich am ehesten intuitiv)
- NTFY_ORDER auf Kleineres setzen. Das ist aber nachteilig, wenn DOIF auf von anderen Modulen "angereicherten" Events reagieren will.
- test2 per InternalTimer setzen

[Damian]

OK, danke für die Analyse.

Wie ich es schon vermutet habe, hat es mit der Selbsttriggerung zu tun.

Das Attribut event_Readings habe ich zuletzt eingeführt, um unabhängig von der eigentlichen Definition eigene Readings definieren zu können (mit Event), auf die man auch im selben Modul zugreifen kann.

Da es sich hier um benutzerspezifische Definitionen (set_Reading) handelt, ist es schwierig alle Events in einem readingsBulkUpdate unterzubringen.

[Damian]

Fuer die Loesung faellt mir Folgendes ein:
- die beiden Events im DOIF zusammen erzeugen (fuer mich am ehesten intuitiv)

Ich könnte am Anfang von DOIF_Notify readingsBeginUpdate setzen und vor dem Ausstieg mit readingsEndUpdate($hash,1) den Eventblock beenden.

Die Benutzerfunktion set_Reading könnte ich dann statt auf readingssingleUpdate auf readingsBulkUpdate abbilden.

Allerdings werden einige Readings bewusst im DOIF-Code ohne Event bisher geschrieben. Wie bekomme ich das dann hin, ohne jedes Mal den Event-Block zu schließen und neu zu öffnen? Ich möchte nicht für unwichtige Readings Events erzeugen.

Man bräuchte ein readingsBulkUpdate mit und ohne Eventerzeugung für einen offenen Eventblock.

[rudolfkoenig]

Man kann $changed auf 0 setzen, dann sollte es keine Events geben.