Vermeidung von mehrfachen events/notifys bei gleichzeitigem Empfang mit mehreren CULs

[pantau]

Ich hatte hier Link über Probleme beim  gleichzeitigen Empfang von EM devices mit mehreren CULs berichtet.
Die Diskussion hatte einen Nebenaspekt, wie man vermeiden kann, das gleiche Nachrichten von mehreren Empfängern an einem FHEM empfangen, nicht zu mehreren events führen, auch wenn FHEM bei der Abarbeitung durch z.B. Logs in Datenbank oder Files ausgebremst wird:
Lezter Kommentar von Rudi:
> Erwartet hätte ich, das der CheckDuplicates _vor_ der Abarbeitung der "notify"/trigger/events erfolgt,

Wenn man etwas nachdenkt, dann sieht man dass das nicht wirklich eine Alternative ist:
- fhem muesste immer erst X Sekunden warten, bevor sie die notifies losschicken kann
- es wuerde nicht mal in deinem Fall wirklich helfen: die 10-Sekunden-Blockade besteht weiterhin.

Ich schlage vor ein neues Thread mit besseren Titel anzulegen.

Wie schon gesagt verstehe ich momentan die aktuelle Implementierung nicht ganz. Nachgedacht habe ich aber... :-)

> - fhem muesste immer erst X Sekunden warten, bevor sie die notifies losschicken kann
Wieso, jede neue Empfangsnachricht müßte doch nur mit alten Nachrichten in einem dupTimeout "langen" Buffer verglichen werden.
Wenn es sie schon gibt => löschen, wenn nicht sofort weiterverarbeiten...
So macht es doch auch CheckDuplicate() in Dispatch()?
Da muß doch nicht erst dupTimeout lange gewartet werden?

Damit es mit mehreren Empfängern(CUL,RFR,CUNO) funktioniert müßten diese dann auch zeitnah, ohne Unterbrechungsmöglichkeit durch andere Aktionen abgefragt werden.

Wo ist mein Denkfehler?

[rudolfkoenig]

>  Ich schlage vor ein neues Thread mit besseren Titel anzulegen.

Damit meinte ich sowas wie: Schreiben ins DbLog dauert ueber 10 Sekunden.

>  Wieso, jede neue Empfangsnachricht müßte doch nur mit alten Nachrichten in einem dupTimeout "langen" Buffer verglichen werden.

Das wird doch. Aber beim ersten mal ist es ja nichts drin, und Du moechtest, dass events erst beim letzten eintreffenden Duplikat ausgeloest werden. D.h. FHEM muesste dupTimeout lang warten, um zu wissen, dass keiner mehr eintrifft.

[pantau]

>Damit meinte ich sowas wie: Schreiben ins DbLog dauert ueber 10 Sekunden.

Missverständnis, den Punkt hier fand ich dringender, anderer kommt noch.

>>  Wieso, jede neue Empfangsnachricht müßte doch nur mit alten Nachrichten in einem dupTimeout "langen" Buffer verglichen werden.
>Das wird doch. Aber beim ersten mal ist es ja nichts drin, und Du moechtest, dass events erst beim letzten eintreffenden Duplikat ausgeloest werden. D.h. FHEM muesste dupTimeout lang warten, um >zu wissen, dass keiner mehr eintrifft.

Wenn Du mit "beim ersten Mal" beim Start von fhem.pl meinst sehe ich das auch so, aber das ist kein großes Problem.
Aber wo ist das Problem mit einem dupTimeout langen Ringpuffer der die Nachtichten der letzten dupTimout sec. enthält?
Wenn neu ankommende Nachricht schon drin => nichts tun (außer Nachricht in Buffer aufnehmen), sonst notify ausführen. Außer der Zeit zum durchsuchen des Ringbuffers geht doch keine Zeit verloren?
Und ich möchte ja auch nicht beim letzten Duplikat was machen - da weiß man ja nie wann das _letzte_ kommt :-)

Aber zurück zum eigentlichen Problem: ohne das Modul dblog geht das ja auch mit den Duplikate löschen. Mit nicht.
Also vermute ich das sich dblog irgendwo dazwischenmogelt und 10s verbrät.
Entweder beim Füllen des Buffers oder beim Abfragen der einzelnen Empfänger.
Und da würde mir ein Hinweis auf die fhem.pl interne Abarbeitung helfen, das konnte ich leider nicht nachvollziehen...

[rudolfkoenig]

dupTimeout wird so realisiert, wie Du es beschrieben hast. Aus diesem Grund generiert fhem.pl ein event nach dem ersten Funktelegramm, aber nicht nach dem zweiten/dritten/usw, wenn diese innerhalb von dupTimeout eintreffen _UND_ von einem _anderen_ IODev (d.h. CUL) stammen.

Und sicher "mogelt" sich DbLog dazwischen, schliesslich wir es mit dem ersten Event aufgerufen.