Notify holt Reading eines Geräts, Reading soll ins Geräte-Filelog

[TheTrumpeter]

Na dann hast Du kein Wahl. userReading ist wahrscheinlich die einzige mögliche Lösung.

Und wie soll das dann laufen?

Z.B. ein Dummy-Device anlegen, in das ich von meinem Helper-Modul aus die geänderten Parameter als UserReading schreibe und dieses Dummy-Device dann ins FileLog von meinem eigentlichen Device aufnehmen?

Oder ginge es umgekehrt auch:
Die Readings, die ich zum Triggern des Notify brauche, in ein Dummy-Device spiegeln und das Notify vom Dummy-Device aus triggern?
(Das wäre der schönere Workaround, weil ich das FileLog vom eigentlichen Device unverändert lassen kann...)

[amenomade]

Das einfachste wäre m.A. die beiden Readings zu "verdoppeln". Etwas in der Art:

Code Auswählen Erweitern

attr Myth userReadings logCoolingHC1SetTemp:p99CoolingHC1SetTemp.* {ReadingsVal ('Mythz', 'p99CoolingHC1SetTemp', 0)}, logCoolingHC1HystersisFlowTemp:p99CoolingHC1HystersisFlowTemp.* {ReadingsVal ('Mythz', 'p99CoolingHC1HystersisFlowTemp', 0)}

[TheTrumpeter]

Hm... das probiere ich doch glatt mal aus... nur mache ich statt dem Präfix "log" wie von Dir vorgeschlagen einen Suffix "log", damit ich mein Filelog, das nur Readings, die mit p oder s beginnen, enthält, nicht ändern muss...

EDIT:
Vielleicht noch zusammengefasst mein bisheriges Verständnis der Situation:
Innerhalb des Notify werden keine weiteren Events mehr desselben Geräts getriggert, richtig?
D.h. wird Notify von einem Device1 aufgerufen, erscheinen im Filelog keinerlei Einträge zu Device1 mehr. Falls aber beispielsweise innerhalb dieses Notifys Änderungen in einem Device2 vorgenommen werden, so erscheinen diese Änderungen sehrwohl im FileLog?

[dev0]

Zum Loggen werden Events benötigt. FHEM versucht allerdings Event Schleifen zu entdecken und zu unterbinden. Um aus dieser Loop Detection auszubrechen kannst Du auf FHEM Ebene 'sleep' und auf Perl Ebene 'InternalTimer' verwenden.

[TheTrumpeter]

Um aus dieser Loop Detection auszubrechen kannst Du auf FHEM Ebene 'sleep' und auf Perl Ebene 'InternalTimer' verwenden.

D.h. ich könnte innerhalb des Notify nach dem Helper-Modulaufruf einfach "sleep 0.1" machen und anschliessend die beiden Parameter mittels "get ..." erneut abfragen? Das funktioniert?
Das wäre die einfachste und eleganteste Lösung 

Oder ich ändere die "sleep x", die ich im Helper-Modul ohnehin habe, in "InternalTimer", dann klappt es auch? Das wäre ja fast zu einfach...

[dev0]

D.h. ich könnte innerhalb des Notify nach dem Helper-Modulaufruf einfach "sleep 0.1" machen

Ich habe mir Deinen Code nicht angesehen, aber wenn die Ursache die fehlenden Events sind, dann funktioniert das so. Allerdings besteht das Risiko Event Loops zu bauen. Mit aktuellem FHEM funktioniert auch ein 'sleep 0'.

[TheTrumpeter]

So, keine der beiden Varianten funktioniert...
Also weder das Userreading noch ein "get" nach "sleep" im Notify selbst.

Was noch gefehlt hat, ist

Code Auswählen Erweitern

attr Mythz event-on-update-reading p.*
Und das, obwohl ich bereits folgendes hatte:

Code Auswählen Erweitern

attr Mythz event-on-change-reading .*

Liegt das daran, dass die Parameteränderung innerhalb des vom Notify aufgerufenen Helper-Moduls kein Event erzeugt und beim anschliessenden erneuten Auslesen der Parameter durch das Attribut event-on-change-reading kein Event erzeugt wird, weil keine Änderung vorliegt?
Durch das zusätzliche Attribut event-on-update-reading erzeugt das Aktualisieren aber das Event und damit den Filelog-Eintrag?

[amenomade]

Falls es noch hier nach 4 Jahren geschaut wird, und für diejenige, die evtl nach einer Suche mit dem gleichen Problem hier landen, siehe die Antwort von Rudi hier : https://forum.fhem.de/index.php/topic,121839.msg1165464.html#msg1165464