DOIF vs. notify

[Prof. Dr. Peter Henning]

Ich habe ein Setting, das verlässlich ein bestimmtes Event auslöst, indem ein Reading gesetzt wird.

2026-09-25 17:28:43 TelegramBot TelegramBot diagramSource: 90:XXX:ID7y.plot

Könnte mir bitte mal jemand erklären, warum

Code Auswählen Erweitern

defmod tb.d notify TelegramBot.*diagramSource.*90.* (etc...)zuverlässig triggert

Code Auswählen Erweitern

defmod TelegramBot.Diagram DOIF ([TelegramBot:"diagramSource.*90.*"]) (etc...)aber nicht?

LG

pah

P.S.: Ja, do always ist gesetzt, auch diverse Varianten habe ich ausprobiert.

[Damian]

Da muss bei dir noch etwas anders im Argen sein, denn

Code Auswählen Erweitern

setreading TelegramBot diagramSource 90:XXX:ID7y.plot
führt bei mir zu:

Code Auswählen Erweitern

Internals:
   CFGFN     
   FUUID      6ab6aafc-f33f-30f6-3df3-a86e2c6223a8d2b9
   NAME       TelegramBot
   NR         11797
   STATE      ???
   TYPE       dummy
   eventCount 2
   READINGS:
     2026-09-25 19:12:19   diagramSource   90:XXX:ID7y.plot
Attributes:
und

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        ([TelegramBot:"diagramSource.*90.*"]) ()
   FUUID      6ab6aab7-f33f-30f6-3ba0-f6cdd02d98b25472
   MODEL      FHEM
   NAME       TelegramBot.Diagram
   NOTIFYDEV  global,TelegramBot
   NR         11770
   NTFY_ORDER 50-TelegramBot.Diagram
   STATE      cmd_1
   TYPE       DOIF
   VERSION        0 2026-05-10 21:47:00
   eventCount 3
   READINGS:
     2026-09-25 19:12:19   Device          TelegramBot
     2026-09-25 19:12:19   cmd             1
     2026-09-25 19:12:19   cmd_event       TelegramBot
     2026-09-25 19:12:19   cmd_nr          1
     2026-09-25 19:12:19   e_TelegramBot_events diagramSource: 90:XXX:ID7y.plot
     2026-09-25 19:09:11   mode            enabled
     2026-09-25 19:12:19   state           cmd_1
   Regex:

[Prof. Dr. Peter Henning]

Im Argen sicher nicht. Wenn ich das "setreading TelegramBot diagramSource 90:XX:YY" von der Kommandozeile aus absetze, triggert das DOIF aus dem Post unten korrekt - das ist aber nicht der gewünschte Weg.

Sondern das Reading wird bei mir per "fhem(setreading...)" gesetzt (und der Event korrekt erzeugt) aus einem Handler für den TelegramBot, dieser Handler wiederum wird durch ein notify auf Telegram Events gestartet.

Dieser Weg funktioniert, ist auch seit Jahren mit einem anderen Reading im produktiven Betrieb. Konkret: wenn ich in diesem Handler ein anderes Reading setze - nicht "diagramSource", sondern "photoSource", triggert ein DOIF mit

Code Auswählen Erweitern

([TelegramBot:".*photoSource.*DoorPi"]) ganz verlässlich.

Also gute Frage: Was blockiert die Event-Feststellung in dem DOIF unten? Das Reading e_TelegramBot.Helper_events in dem genannten DOIF zeigt  alle TelegramBot-Events, die ich auch im Event-Monitor sehe - _bis auf das Event mit diagramSource_.

Unter welchen Bedingungen ist genau ein Event in einer Serie, die korrekt im Event-Monitor erscheint, kein Event für DOIF?

LG

pah

[Prof. Dr. Peter Henning]

Ich kann das Rätsel sogar noch erweitern.

Wenn ich das Reading diagramSource nämlich nicht in dem TelegramBot setze, sondern dazu ein Dummy TelegramBot.Helper verwende (und natürlich in dem DOIF auch auf Events von TelegramBot.Helper lausche), ist alles in Butter und wird korrekt getriggert.

Natürlich kann die Quelle im TelegramBot selbst liegen - irgendetwas sich auf die Event-Verarbeitung auswirken.

Aber warum bei "diagramSource", nicht aber bei "photoSource"?

LG

pah

[Damian]

Tja, da muss leider passen. Im DOIF sind FHEM-Standardmechanismen zur Event-Erkennung eingebaut, die sich seit Jahren bewährt haben. Ich gehe davon aus, dass es irgendetwas mit der Quelle TelegramBot zu tun hat. Ich weiß z. B., dass es Probleme gab, wenn es über FHEM2FHEM Events gab, zu denen es kein Device auf der DOIF-Seite gab. Das dürfte hier wohl aber nicht das Problem sein.

[Beta-User]

Sondern das Reading wird bei mir per "fhem(setreading...)" gesetzt (und der Event korrekt erzeugt) aus einem Handler für den TelegramBot, dieser Handler wiederum wird durch ein notify auf Telegram Events gestartet.

Kann es sein, dass des Rätsels Lösung in der nachträglichen Erweiterung des Event-Stapels (hier:) zum TelegramBot liegt?

Um Rekursionen zu vermeiden, wird jeder Eventhandler pro Device nur einmal aufgerufen, wenn zu diesem Events vorliegen. Ist das DOIF also schon "durch", bevor die 2. Reading-Aktualisierung zum "bulk" kommt, wird es nicht nochmals aufgerufen.

Abhilfe schafft  (außer der Prefix-Zahl des betreffenden NotifyFn()-Moduls an sich zu ändern) in der Regel eine passende Namensgebung der Eventhandler, so dass dann erst das notify durchläuft, bevor das DOIF dran ist. Oder eben der userReadings-Weg, einen Timer dazwischenzuschalten...

Kann aber auch falsch liegen...

[Prof. Dr. Peter Henning]

Kann aber auch falsch liegen...

Muss so sein - weil im Telegram Event-Handler (der einfach die Telegram-Keyboards abarbeitet) mal das reading photoSource, mal das reading audioSource und mal das reading diagramSource gesetzt werden. Damit hole hole ich jeweils irgendwo aus FHEM (auch von einer anderen Kiste, z.B. mit der IP ...90) ein Kamerabild, eine Audiodatei oder ein Diagramm und sende es an den anfordernden Telegram-Client.

Alle nach demselben Prinzip angelegt: Ein DOIF triggert auf das Setzen des Readings und macht die Arbeit.

photoSource und audioSource funktionieren, nur diagramSource zickt. Und zwar nur aus dem Telegram Event-Handler heraus - nicht, wenn ich das setreading aus der Kommandozeile mache.

Jetzt wird es gleich noch witziger: Gestern abend habe ich das DOIF komplett gelöscht, FHEM neu gestartet. Und dann das DOIF komplett neu angelegt. Und, oh Mirakel: PLötzlich lief alles wie gewünscht. Bis heute morgen 

LG

pah

[Beta-User]

Alle nach demselben Prinzip angelegt: Ein DOIF triggert auf das Setzen des Readings und macht die Arbeit.

Nun ja, schade, dass des Rätsels Lösung nicht so einfach war, einfach nur zu vergleichen, was

Code Auswählen Erweitern

list .*:FILTER=NTFY_ORDER=.+ NTFY_ORDERausspuckt (falls DOIF das auch setzt, was ich hier nicht verifizieren will, weil man dafür ein DOIF anlegen müßte...)

Wenn das genannte dir Ursache gewesen wäre (was ja nicht der Fall ist, oder...) hängt es jedenfalls weniger am "Prinzip", sondern (fast) ausschließlich an der Namensgebung der handler.

PS: Dieser "funktioniert manchmal doch"-Effekt wäre eventuell dadurch zu erklären, dass es erst mal nach Löschen des Arrays, wer auf wessen Event reagieren möchte (per setNotifydev(), durch wen auch immer und wie die Funktion auch genau benannt sein mag) innerhalb derselben prefix-Ziffer Zufall ist, in welcher Reihenfolge etwas abgearbeitet wird, bis nach dem ersten Event dann wieder die sortierte Liste aufgebaut ist?

[Prof. Dr. Peter Henning]

Es ist ja nicht so, dass ich das nicht überprüft hätte.
Tatsächlich war die Reihenfolge so:

TelegramBot.Diagram      50-TelegramBot.Diagram
TelegramBot.N            50-TelegramBot.N
TelegramBot.Photo        50-TelegramBot.Photo

- also TelegramBot.Diagram vor TelegramBot.N, der den Handler startet.

Also habe ich gestern schon das DOIF TelegramBot.Diagram umbenannt in TelegramBot.Plot: Kein Effekt.

Nachdem Du das mit dem zufälligen Eintrag geschrieben hast (Danke für den Tipp), habe ich das noch einmal von A-Z durchgezogen.

Es stellt sich heraus, dass ein rename die Reihenfolge eben nicht ändert, sondern vielmehr daraus ein

TelegramBot.N            50-TelegramBot.N
TelegramBot.Photo        50-TelegramBot.Photo
TelegramBot.Plot        50-TelegramBot.Diagram

macht. Und offenbar wird die Liste nach alphabetischer Sortierung rechts abgearbeitet.

Ein Neustart der FHEM-Instanz liefert dann korrekt

Code Auswählen Erweitern

TelegramBot.N            50-TelegramBot.N
TelegramBot.Photo        50-TelegramBot.Photo
TelegramBot.Plot         50-TelegramBot.Plot
- und siehe da, plötzlich läuft das wie gewünscht.

Sehr trickreicher Effekt, das ist mir zu wackelig. Ich werde also statt dem Setzen von Readings im TelegramBot bei einem Helper-Dummy bleiben.

LG

pah