FRM_IN taster - notify problem

[pula]

Hallo,

habe an einem Uno ein Configurable Firmata per ethernet angebunden und daran hängen ein paar Taster für die Beleuchtungs-Steuerung.
Daran habe ich dann notifies gehängt, die das Licht an und ausschalten.
Mein Problem ist, daß ab und an das entsprechende event (zb bad_taster_oben_links:reading:.on) zwei mal direkt hintereinander (lt. log in der gleichen Sekunde) kommt. Natürlich könnte ich das mit Hardware entprellen (vermute ich zumindest). Aber geht das nicht auch irgendwie direkt per Software in fhem?
Zb. wenn das event innerhalb von 2 Sekunden mehrmals kommt, ignoriere alle außer das erste?
Bin ein wenig ratlos und dankbar für hilfreiche Hinweise!

Danke im voraus!

Pula

[jensb]

Hallo Pula,

im notify kannst du z.B. auch "time_str2num(ReadingsTimestamp(...))" die Änderungszeit eines Readings in Sekunden abfragen. Merk dir immer wenn du die 1. steigende Flanke bekommst diesen Zeitstempel in einem eigenen Reading, also z.B. im FRM_IN oder einem Dummy. Wenn die nächste steigende Flanke kommt, vergleichst du den neuen ReadingsTimestamp mit dem gemerkten. Liegen weniger als deine 2 Sekunden dazwischen, machst du einfach nichts.

Grüße,

Jens

[Wzut]

Ich würde beim FRM_IN "event-on-change-reading reading" setzen dann dürfte das zweite gleiche Signal gar nicht mehr das notify triggern.

[jensb]

... beim FRM_IN "event-on-change-reading reading" setzen

hilft, wenn man zwei oder mehr aufeinander folgende identische Events unterdrücken will.

Hat man es aber mit einem flatternden Digitalsignal zu tun, ist die Abfolge z.B. 1010 innerhalb weniger Sekunden und "event-on-change-reading" würde das nicht nicht filtern, da sich der Wert ändert. Man könnte zusätzlich "event-min-interval" setzen, hat dann aber keine Unterscheidung mehr zwischen steigenden und fallenden Flanken, so dass u.U. auch eine steigenden Flanke unterdrückt würde, die man eigentlich verarbeiten will. In diesem Fall würde der Ansatz über ReadingsTimestamp greifen.

[pula]

Hallo,

danke für die Tips! Bin mittlerweile aber auf den Trichter gekommen, daß es besser wäre, bounce arduino-seitig zu verwenden. User limats hat hier http://forum.fhem.de/index.php/topic,18708.0.html scheinbar eine funktionierende Lösung, die bei mir allerdings leider noch nicht compiliert...

Cheers,

Pula