Hallo Kellerkind86,
das freut mich, wenn es geklappt hat. Noch mehr freut es mich, wenn die Zusammenhänge klar(er) geworden sind. Es gibt viele Beiträge hier, deren beschriebene Probleme im Prinzip die gleiche Ursache haben: Man will, das fhem was tut, versucht das mit DOIF/notify/at etc zu lösen und hat noch gar nicht umrissen, wie der "Trigger" dafür zustande kommt und sich in fhem verhält. Das von mir beschriebene habe ich auch erst mit der Zeit (für mich) so rausgekriegt, und es funktioniert eigentlich ganz gut.
-neues Device, was irgendetwas auslösen soll
-Eventmonitor ausreichend lange mitplotten, um die erzeugten Events zu sehen und deren Logik (wichtig wie in Deinem Fall: ein Event von einem Reading, das einen gleichbleibenden Wert hat: mit einem pauschalen event-on-change-reading .* machst Du das Reading "stumm". (War wohl in Deinem Fall u.a. auch beteiligt.)
-vorsichtiges begrenzen der Events, sollten sehr viele kommen (bsp.: die Wetterstation ist sehr gesprächig) mittels event-on... attributen.
-immer mal wieder im Eventmonitor schauen, ob das gewünschte auch noch durchkommt.
-den Trigger am einfachsten im Eventmonitor erzeugen lassen
-dann erst DOIF/notify beginnen, hier evtl auch erst mal nur eine Logausgabe erzeugen, um zu sehen, daß der Trigger auch funktioniert.
Besonderheit DOIF: Ereignissteuerung und Ereignissteuerung mittels Events. Das Wissen um den Unterschied ist der Schlüssel zum Erfolg. Diesen Fehler sieht man hier auch ständig. (zum notify und at kann ich leider nichts (mehr) beitragen (habe noch 10 notifys aus meinen fhem-Anfangstagen, die meisten copy-paste aus irgendwelchen Anleitungen. at finde ich keines mehr...)
- insgesamt den Blick der erzeugten Events im System nicht aus den Augen verlieren. Unerklärliche "Hänger" oder Verzögerungen kommen wohl oft aus dieser Ecke. Events, die man nicht zur Steuereung und/oder logging braucht müssen nicht "im System rumgeistern".
Dann weiterhin
Viel Erfolg!
Sany
