Hallo,
in Zeile 3067 von fhem.pl steht:
Log 5, "Notify loop for $dev $hash->{CHANGED}->[0]";
Das hat zur Folge, dass bei der Ausgabe immer auch erste geänderte Reading nach einem readings...Update() ins Protokoll geschrieben wird:
2016.03.27 23:22:22 5: Notify loop for W fooBar: baz
Es hat mich eine Weile gekostet zu verstehen, dass mein Code nichts schlimmes macht.
Ich denke, es sollte nur das Device ausgegeben werden.
Viele Grüße
Boris
Ich habe es leicht umformuliert:
ZitatStarting notify loop for r4, first event cSceneSet: 2
Bin mit der notify-debugausgaben trotzdem noch nicht zufrieden, da man verschachtelte notifies nicht so recht folgen kann.
Danke.
[Mich hat irritiert, dass nur das erste Event gezeigt wird, und dieses bei mir auch noch einen leeren Wert hatte (lastError wird auf leeren String gesetzt).]
Warum zeigst Du nicht alle Events? Wer den Loglevel auf 5 dreht, braucht sich ja über ein prallgefülltes fhem.log nicht wundern. Allerdings... das Wettermodul feuert je Update 100 Events.
Mit verschachtelten Notifies meinst Du, dass DoTrigger rekursiv aufgerufen wird? Ich würde die Rekursionstiefe mitführen und der Ausgabe von "Notify loop..." voranstellen.
Viele Grüße
Boris
ZitatWarum zeigst Du nicht alle Events? Wer den Loglevel auf 5 dreht, braucht sich ja über ein prallgefülltes fhem.log nicht wundern. Allerdings... das Wettermodul feuert je Update 100 Events.
Weil join/etc auch bei verbose 3 ausgefuehrt wird (und das ist mir zu teuer), und ich zu faul war eine explizite attr global verbose Abfrage einzubauen :). Das diese Zeilen sehr haeufig durchgelaufen werden, will ich mit "unnoetigen" code sparsam umgehen.
ZitatMit verschachtelten Notifies meinst Du, dass DoTrigger rekursiv aufgerufen wird?
Ja, nicht unbedingt mit dem gleichen "Erzeuger", das wird unterbunden. Aber haeufig ruft das erste notify "set a b;set x y" auf, was wieder notify-loops zur Folge hat, und ich habe nach eine Weile Probleme festzustellen, welche Events im Log gerade aktuell sind.