Ich habe ein notify, das bei Änderung eines bestimmten Readings mittels get-Befehl ein anderes Reading desselben Geräts holt.
Das funktioniert wunderbar, nur wird das geholte Reading nie gelogged. Weder bei Änderung noch bei Zeitschwelle (event-min-interval).
Dasselbe Problem habe ich mit einem Notify, das ein selbstgeschriebenes Modul im 99_myUtils aufruft. Dieses Modul setzt verschiedene Parameter eines Geräts. Die Änderungen werden aber nicht ins Filelog geschrieben.
Rufe ich das Modul direkt auf, wird protokolliert.
Was mache ich falsch bzw. wie könnte es funktionieren?
(Aufruf des notify funktioniert, nur möchte ich alles, was mittels get oder set passiert ins entsprechende gerätespezifische FileLog protokollieren.)
Es werden immer Events in ein Gerätelog geschrieben. Natürlich muß Deine Log Definition entsprechend gestaltet sein.
Also Frage
1. generieren die von Dir monierten Readings Events?
2. ist Deine Gerätespezifische Logdefinition entsprechend?
Hier die relevanten Auszüge der Konfiguration:
Das Gerät Mythz hat u.a. Readings mit Namen "sGlobal" und "sDewPointHC1". sGlobal wird im Gerät zyklisch abgefragt.
define Mythz THZ /dev/ttyAMA0@115200
attr Mythz event-min-interval s.*:600
attr Mythz event-on-change-reading .*
attr Mythz interval_sGlobal 300Filelog:
define FileLog_Mythz FileLog ./log/Mythz-%Y-%m.log MythzNotify:
define Mythz.GetDewPoint notify Mythz:sGlobal:.* get Mythz sDewPointHC1Ich sehe, dass sich der Zeitstempel des Readings sDewPointHC1 in der Detailansicht von Mythz ändert bzw. auch die Werte aktualisiert werden.
Im Eventmonitor ist das Event sichtbar, aber der Eintrag im Filelog fehlt:
Auszug von gerade eben:
ZitatEvents (Filter: Mythz:sGlobal:.*|Mythz:sDewPointHC1:.*) FHEM log
2017-07-17 20:05:05 THZ Mythz sGlobal: outsideTemp: ...
2017-07-17 20:10:05 THZ Mythz sGlobal: outsideTemp: ...
2017-07-17 20:10:05 THZ Mythz sDewPointHC1: 12.3 °C
2017-07-17 20:15:05 THZ Mythz sGlobal: outsideTemp: ...
2017-07-17 20:15:05 THZ Mythz sDewPointHC1: 12.4 °C
Filelog:
Zitat2017-07-17_20:00:05 Mythz sGlobal: outsideTemp: ...
2017-07-17_20:05:05 Mythz sGlobal: outsideTemp: ...
2017-07-17_20:10:05 Mythz sGlobal: outsideTemp: ...
2017-07-17_20:15:05 Mythz sGlobal: outsideTemp: ...
Niemand eine Idee?
Scheint irgendwie mit den Namen der Defines zusammenzuhängen...
Ich habe folgendes ursprüngliche Notify inaktiv gesetzt:
define Mythz.GetDewPoint notify Mythz:sGlobal:.* get Mythz sDewPointHC1
Folgendes Notify habe ich neu definiert:
define DummyDewPoint notify Mythz:sGlobal:.* get Mythz sDewPointHC1
Die Einträge im Filelog sind nun vorhanden.
Woran liegt das?
Ist der "Punkt" in meinem ursprünglichen Namen Schuld oder, dass der Name ein Teil der Filelog-Regex ist?
Ich muss mich nochmal melden...
Das Problem existiert an anderer Stelle immer noch...
Nachdem die Readings, die ich in einem meiner Module auslese, immer noch nicht im Filelog landen, wenn das Modul aus einem Notify aus aufgerufen wird und ein zusätzliches Auslesen im gleichen Notify nach dem Modul auch nicht funktioniert, habe ich ein weiteres Notify angelegt, das vom modulaufrufenden Notify getriggert wird.
Rufe ich das neue Notify händisch auf, funktioniert alles wie erwartet. Wird es aus dem anderen Notify aus getriggert, wird nichts protokolliert.
Hier der Code vom Notify mit dem Modulaufruf und Trigger des 2. Notify:
define Kuehlparameter notify (Mythz:sDewPointHC1:.*|Mythz:Compressor:.*|Mythz:Cooling:.*) \
IF (([Mythz:Cooling:d] == 1) && ([Mythz:Compressor:d] == 1)) \
(\
{setCoolingParameters}, \
trigger Mythz.getCoolingParameters\
)
Und hier das neue Notify, das die Parameter ausliest:
define Mythz.getCoolingParameters notify Mythz.getCoolingParameters \
{fhem "trigger Mythz p99CoolingHC1SetTemp: " . ReadingsVal ('Mythz', 'p99CoolingHC1SetTemp', 0)};;;; \
{fhem "trigger Mythz p99CoolingHC1HystersisFlowTemp: " . ReadingsVal ('Mythz', 'p99CoolingHC1HystersisFlowTemp', 0)}
Gebe ich händisch "trigger Mythz.getCoolingParameters" ein, landen die beiden Parameter sofort im Filelog.
Der automatische Aufruf selbst funkioniert aber, weil sich der Zeitstempel im STATE ändert.
Ich blicke einfach nicht mehr durch... was mache ich falsch?
Zitatdefine Mythz.getCoolingParameters notify Mythz.getCoolingParameters
Darf ein notify sich selbst triggern? Ist das nicht gefährlich (Endlosschleife)?
EDIT: ja, anscheinend darf es
Guck mal mit
Zitatattr global verbose 5
, ob Du komische Meldungen in der Log hast, wie z.B.
ZitatStarting notify loop for
Ich hab irgendwo gelesen, dass verschachtelte Notifies unterbunden sind.
ich hatte mal ein ähnliches problem, https://forum.fhem.de/index.php/topic,26826.0.html (https://forum.fhem.de/index.php/topic,26826.0.html)
fazit: das ist so gewollt.
du kannst das problem aber mit userreadings lösen. das, was dein notify macht, musst du durch das userreading machen lassen.
Zitat von: frank am 06 August 2017, 10:43:52
ich hatte mal ein ähnliches problem, https://forum.fhem.de/index.php/topic,26826.0.html (https://forum.fhem.de/index.php/topic,26826.0.html)
fazit: das ist so gewollt.
du kannst das problem aber mit userreadings lösen. das, was dein notify macht, musst du durch das userreading machen lassen.
Ganz habe ich das noch nicht verstanden...
Ich habe ein Helper-Modul (99_myLWZUtils), in dem ein Modul teilweise "set"-Befehle an ein Gerät absetzt. Die Parameter werden im Gerät gesetzt, wenn ich das Modul direkt aufrufe. Zusätzlich erscheinen die Parameter im zugehörigen FileLog.
Rufe ich dasselbe Modul aus einem Notify aus auf, funktioniert das Setzen der Parameter immer noch, die zugehörigen Readings des Geräts werden ebenfalls aktualisiert (aktueller Wert plus Zeitstempel), aber die Änderungen landen nicht im Filelog.
In dem Link von Dir geht es ja darum, Readings "willkürlich" zu ändern. Bei mir passiert die Änderung aber durch einen Set-Befehl an ein Device ohnehin schon.
ZitatGanz habe ich das noch nicht verstanden...
ich auch nicht, da es nicht wirklich konsistent ist.
in meinem fall hat es ja mit dem notify im prinzip (anzeige) funktioniert, aber eben nicht in allen fällen mit filelog.
filelog und userreadings sind ja quasi auch notify's. daher war/bin ich der meinung, dass sie dann "eigentlich" auch identisch funktionieren müssten/sollten. wenn es trotzdem teilweise funktioniert, ist das eher der fehler. wie du auch selber sagst, manuell kannst du den trigger erzeugen, aber das notify kann keinen brauchbaren trigger für filelog erzeugen.
wenn ein device ein notify triggert, kann/darf das notify keinen erneuten trigger(event) im selben device erzeugen.
damit soll eine endlosschleife unterbunden werden.
für diese fälle einfach userreadings nutzen. ist ja im prinzip das selbe.
in meinem fall wollte ich mit
einem generischen notify mehrere devices parallel bearbeiten, um mir mehrere identische userreadings zu ersparen.
edit:
wenn du meinst, dein fall liegt doch anders, musst du es im anderen forumbereich mit einem neuen thread rudi vortragen.
Letztendlich möchte ich einfach mein Problem lösen. Nur habe ich noch nicht verstanden, wie ich das mit Userreadings machen soll.
Gegeben:
Ich möchte Parameter der Wärmepumpe bei bestimmten Ereignissen ändern, nämlich abhängig vom Taupunkt immer dann, wenn die Kühlung aktiv ist und der Verdichter läuft.
Dafür habe ich das notify angelegt, das auf obige Events reagiert und mein Helper-Modul aufruft.
Im Helper-Modul werden dann 2 Parameter für die Wärmepumpe abhängig von diversen anderen Parametern und Umgebungsbedingungen berechnet und ggf. verändert in die Wärmepumpe geschrieben.
Jetzt möchte ich einfach nur, dass die Parameteränderung auch im Filelog sichtbar ist.
Ich habe jetzt versucht innerhalb des Helper-Moduls die geänderten Parameter nochmal mittels "setreading" zu schreiben. Das Schreiben funktioniert prinzipiell, nur kommt's trotzdem nicht ins Filelog. Rufe ich innerhalb des Notifys nach dem Helper-Modul nochmal ein "get" oder "setreading" bzw. "trigger" auf, kommt es auch nicht ins Filelog.
Übrigens sind hier alle betroffenen Readings Teil desselben Devices, also sowohl die das notify triggernden Readings als auch die im Helper-Modul veränderten Readings.
Andernorts, wo unterschiedliche Devices im Spiel sind, funktioniert's.
Ich habe mehrere Notify, die von unterschiedlichen Readings aus einem CustomReadings getriggert werden und dort unterschiedliche Module aufrufen, die Readings in einem Dummy setzen/ändern. Das wird alles brav protokolliert.
Geht es nur um die Log, oder willst Du auch Events davon?
Wenn es nur um die Log geht, mach einfach "Log3 1,<device>,"was du willst" in deinem Helpermodul
Zitat von: amenomade am 06 August 2017, 19:27:52
Wenn es nur um die Log geht, mach einfach "Log3 1,<device>,"was du willst" in deinem Helpermodul
Das habe ich aktuell als Workaround ohnehin drin, aber dann landet es eben im System-Logfile und nicht im dem Device zugehörigen Logfile.
Zu Deinem ursprünglichen Beitrag bzgl. Logs mit "verbose 5":
Kommt noch, nur voraussichtlich erst morgen Abend, weil heute mangels sommerlicher Temperaturen die Kühlung nicht freigegeben wurde. Möchte nicht irgendwas verfälschen, wenn ich die Readings händisch setze/überschreibe.
Na dann hast Du kein Wahl. userReading ist wahrscheinlich die einzige mögliche Lösung.
Wg. verbose 5: den Beitrag hab ich gelöscht, da die Ursache vermutlich schon bekannt ist, und es nicht viel helfen wird, dein Problem zu lösen, wenn wir feststellen: "ja, das ist die Ursache, kann man aber nicht ändern" ;)
Zitat von: amenomade am 06 August 2017, 20:34:07
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...)
Das einfachste wäre m.A. die beiden Readings zu "verdoppeln". Etwas in der Art:
attr Myth userReadings logCoolingHC1SetTemp:p99CoolingHC1SetTemp.* {ReadingsVal ('Mythz', 'p99CoolingHC1SetTemp', 0)}, logCoolingHC1HystersisFlowTemp:p99CoolingHC1HystersisFlowTemp.* {ReadingsVal ('Mythz', 'p99CoolingHC1HystersisFlowTemp', 0)}
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?
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.
Zitat von: dev0 am 06 August 2017, 22:50:53
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 :D
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...
Zitat von: TheTrumpeter am 07 August 2017, 06:18:05
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'.
So, keine der beiden Varianten funktioniert...
Also weder das Userreading noch ein "get" nach "sleep" im Notify selbst.
Was noch gefehlt hat, ist
attr Mythz event-on-update-reading p.*
Und das, obwohl ich bereits folgendes hatte:
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?
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