Hauptmenü

Arduino entprellen

Begonnen von stobor, 08 Februar 2019, 23:39:01

Vorheriges Thema - Nächstes Thema

stobor

Hallo,
ich bin gerade bei meinen ersten Schritten mit einem Arduino Uno Rev3.
Nun habe ich einen Eingang mit einem Relais beschaltet(Pulldown Widerstand, Relais schaltet gegen +). Relais prellen nun ja von Natur aus. Im Log steht bspw. so etwas:
2019-02-08_23:10:01 Arduino_Pin9_PIR_Ost reading: on
2019-02-08_23:10:01 Arduino_Pin9_PIR_Ost reading: off
2019-02-08_23:10:01 Arduino_Pin9_PIR_Ost reading: on
2019-02-08_23:10:01 Arduino_Pin9_PIR_Ost reading: off
2019-02-08_23:10:01 Arduino_Pin9_PIR_Ost reading: on
2019-02-08_23:10:01 Arduino_Pin9_PIR_Ost reading: off
2019-02-08_23:10:01 Arduino_Pin9_PIR_Ost reading: on
2019-02-08_23:10:01 Arduino_Pin9_PIR_Ost reading: off
2019-02-08_23:10:01 Arduino_Pin9_PIR_Ost reading: on
2019-02-08_23:10:14 Arduino_Pin9_PIR_Ost reading: off
2019-02-08_23:13:07 Arduino_Pin9_PIR_Ost reading: on
2019-02-08_23:13:07 Arduino_Pin9_PIR_Ost reading: off
2019-02-08_23:13:07 Arduino_Pin9_PIR_Ost reading: on
2019-02-08_23:13:07 Arduino_Pin9_PIR_Ost reading: off
2019-02-08_23:13:07 Arduino_Pin9_PIR_Ost reading: on
2019-02-08_23:13:07 Arduino_Pin9_PIR_Ost reading: off
2019-02-08_23:13:07 Arduino_Pin9_PIR_Ost reading: on
2019-02-08_23:13:07 Arduino_Pin9_PIR_Ost reading: off

(Die Daten nutze ich für die Erstellung eines Diagramms)

Das Prellen erzeugt nun natürlich unnötige und auch störende Einträge. Eigentlich sollte das Relais einmal anziehen, und nach einigen Minuten fällt es wieder ab.

Gibt's da simple Ideen, wie ich das Prellen ignorieren kann?

Derzeit logge ich übrigens so:
define FileLog_PIR_Ost FileLog ./log/PIR_Ost-%Y-%m.log Arduino_Pin9_PIR_Ost:reading:.*
attr FileLog_PIR_Ost fm_type [{"id":"graph-light","title":"On\/Off","min":"0","max":"1","col":"7f7f00","h":1}]
attr FileLog_PIR_Ost logtype text


Danke.
Intel NUC (Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-113-generic x86_64))  mit CUL V3.2 (FW 1.57 CUL868) für FS20 und CCU3 für HM(IP) + Arduino Mega (Firmata) - FHEM Revision: 29534 - FS20, HM(IP), MQTT, Philips HUE, ModBus

Beta-User

Zum Entprellen dient bei Arduino die lib bounce2.
(Alternativ: die ältere bounce).

Das wird dir vermutlich nur nicht helfen, weil du m.E. die Frage sehr unsauber stellst...

Im Ernst: Mit diesen Angaben kann man nur raten, es scheint sich um ein FRM_IN-Device zu handeln. Gibt es da in der commandref keine Hinweise? Wenn nein, ist es vermutlich keine Anfängerfrage und gehört daher in den entsprechenden Forumsbereich verschoben.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wzut

Zitat von: stobor am 08 Februar 2019, 23:39:01
Gibt's da simple Ideen, wie ich das Prellen ignorieren kann?
Kondensator von 100nF über den "Preller" bewirkt i.d.R. wahre Wunder ....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

stobor

Ich habe jetzt eine Hardware-Lösung an den Start gebracht. Ein Monoflop verlängert den Impuls. Nun kommt ein sauberes Signal an.
Intel NUC (Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-113-generic x86_64))  mit CUL V3.2 (FW 1.57 CUL868) für FS20 und CCU3 für HM(IP) + Arduino Mega (Firmata) - FHEM Revision: 29534 - FS20, HM(IP), MQTT, Philips HUE, ModBus

DasQ

Hat das Relais eine freilaufdiode?
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

stobor

Klar, Diode ist vorhanden.
Intel NUC (Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-113-generic x86_64))  mit CUL V3.2 (FW 1.57 CUL868) für FS20 und CCU3 für HM(IP) + Arduino Mega (Firmata) - FHEM Revision: 29534 - FS20, HM(IP), MQTT, Philips HUE, ModBus