Hi,
ich poste es mal in Anfägerfragen, weil ich echt ein Brett vorm Kopp habe momentan :o :o
Also, ich habe eine Sensormatte, die auslöst, wenn man sich ins Bett legt. Auswerten tut das ein Tasmota Device (per mqqt). Beim hinlegen kommt es zu einem "Flapping", das heißt, es wird ganz schnell zwischen hin "liegt" und "liegt nicht" gewechselt.
Jetzt hab ich mir mal die Kombinationen von Event-Begrenzern (event-on-change-readings, event-min-interval) etc angeschaut, aber irgendwie ist da wohl nicht bei, was ich suche.
Am liebsten wäre mir, das er eine Zeitspanne nach einem Event alle folgenden Events ignoriert Also 60 sec keine Event mehr
Ich hoffe, ich hab mein Problem gut beschrieben.
Jemand eine Idee oder einen Schubs für mich von der Leitung?
Danke euch
Also event-min-interval sollte schon das passende sein, allerdings
ohne event-on-change, weil das die Wirkung wieder reduziert.
Zitatevent-min-interval
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind. Falls event-on-change-reading auch spezifiziert ist, dann werden sie mit ODER kombiniert, d.h. wenn einer der beiden Bedingungen wahr ist.
Alternativ könnte man auf der nächsten Ebene bei der Auswertung ansetzen, bei DOIF z. B. mit dem Attribut "repeatsame" oder "cmdpause", aber das vermeiden von Events sollte immer höchste Priorität haben.
Gruß
Danny
wenn event_min_interval nicht reicht:
es reicht schon
DOIF ([sensor] eq "on")
wait 60:60
der Status des Moduls sollte um 60 Sekunden verzögerten stabilen Zustand cmd_1 bzw. cmd_2 haben.
Zitat von: Damian am 13 November 2020, 23:45:07
wenn event_min_interval nicht reicht:
es reicht schon
DOIF ([sensor] eq "on")
wait 60:60
der Status des Moduls sollte um 60 Sekunden verzögerten stabilen Zustand cmd_1 bzw. cmd_2 haben.
ach mist, ich wußte, ich hab das irgendwo bei doif gesehen und nach mehrmals schauen nicht gefunden. Na klar: wait - greift ja nur, wenn der Status in der Wait-Time stabil ist, weil sonst die Wait-Time wieder von vorne los geht. Genial. 8)
Danke Euch
Zwei Anmerkungen noch:
- zum einen wäre die Frage, warum der Eingang an der MCU/dem ESP prellt. Wenn man da direkt was machen könnte, wäre das die bessere Lösung, als hinterher über FHEM unnötige Events wieder zu ignorieren (entweder schaltungstechnisch (Kondensator?) oder über eine debounce-Funktion (lib z.B. bounce2); evtl. kann man das an dem Tasmota direkt auch entsprechend einstellen?).
- notify kennt "disabledAfterTrigger"
Zitat von: Beta-User am 15 November 2020, 08:19:47
Zwei Anmerkungen noch:
- zum einen wäre die Frage, warum der Eingang an der MCU/dem ESP prellt. Wenn man da direkt was machen könnte, wäre das die bessere Lösung, als hinterher über FHEM unnötige Events wieder zu ignorieren (entweder schaltungstechnisch (Kondensator?) oder über eine debounce-Funktion (lib z.B. bounce2); evtl. kann man das an dem Tasmota direkt auch entsprechend einstellen?).
- notify kennt "disabledAfterTrigger"
Hi, es liegt wohl an der verwendeten Billo Sensormatte - die ist extrem empfindlich und wenn man sich hinlegt, dann flappt sie ein wenig rum, bis man letztendlich liegt. Das selbe kann beim herumdrehen in der Nacht passieren, das kurzeitig der Kontakt der Matte offen ist. Da ich die Automation eh mit Doif gemach hatte, war wait ein guter Hinweis
Das Ausgangsproblem ist schon klar, ähnliche Effekte kann man haben, wenn man einen Taster einfach an einen Arduino-PIN anschließt usw.. Sowas kann man eben auch auf der Arduino/ESP-Seite lösen, indem man direkt dort schon passend "entprellt". Das hat eben den Vorteil, dass es schon gar keine Events gibt, um die sich FHEM dann kümmern müßte...
Zitat von: Beta-User am 16 November 2020, 12:10:55
Das Ausgangsproblem ist schon klar, ähnliche Effekte kann man haben, wenn man einen Taster einfach an einen Arduino-PIN anschließt usw.. Sowas kann man eben auch auf der Arduino/ESP-Seite lösen, indem man direkt dort schon passend "entprellt". Das hat eben den Vorteil, dass es schon gar keine Events gibt, um die sich FHEM dann kümmern müßte...
Ich muss zugeben, das ich da auch schon dran gedacht habe und es auch besser finde - aber ich bin nicht so erfahren mit Tasmota und muss mich da noch ein bißchen einarbeiten. Zumindest die Regeln für die Custom Topics hab ich hinbekommen. Du hast natürlich recht - Eventvermeidung ist besser als Event-Unterdrückung
Suche mit "tasmota button debounce" bringt einen ziemlich direkt hierhin: https://tasmota.github.io/docs/Commands/#control (Stichwort ButtonDebounce). Vielleicht hilft die Sekunde schon, die man da einstellen kann...
Zitat von: Beta-User am 16 November 2020, 12:33:56
Suche mit "tasmota button debounce" bringt einen ziemlich direkt hierhin: https://tasmota.github.io/docs/Commands/#control (Stichwort ButtonDebounce). Vielleicht hilft die Sekunde schon, die man da einstellen kann...
ach cool - das schaue ich mir mal an. Evtl hatte ich nicht den richtigen Suchbegriff parat. Hatte bei Tasmota eher nach sowas wie flapping/limit etc gesucht.