GPIO Überwachung -> Notify erst wenn bestimmte Zeit Signal da?

Begonnen von Malvin83, 05 Juni 2016, 14:12:00

Vorheriges Thema - Nächstes Thema

Malvin83

Servus,

Ich hoffe ihr könnt mir hierbei helfen.

Ich habe eine Gerät über einen GPIO Pin am Raspi angeschlossen und überwache über fhem den pi.
Wenn dann ein signal anliegt, soll etwas passieren (Push Nachricht):

Ungefähr so:
define Rauchmelder_Alarm_ON_Notify notify Rauchmelder_Alarm:on* {my $tme=TimeNow();; fhem ("set Pushover_sbn msg 'Feueralarm ausgelöst' 'Feueralarm um $time ausgelöst' '' 0 ''")}

Das klappt gut, jedoch habe ich immer wieder Störsignale und hätte gerne eine art Regel: "Schicke mir erst die Nachricht wenn das Signal für 30 Sekunden am Stück anliegt".

Habt ihr eine Idee wie ich das einfach umgehen könnte?

Grüsse
Malvin

Icinger

Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

Malvin83

#2
Hi,

kannst mir mir hier bitte etwas helfen?

Es geht um einen Rauchmelder und der Notify dazu schaut so aus:
   
Rauchmelder_Alarm:on* { DebianMail('MEINEMAILADRESSE@MAIL.COM','FEUERALARM','Dein Raspi meldet einen Feueralarm - bitte pruefen','');; }

Also immer wenn meine Brandmeldeanlage den Rauchmeldealaram auch "on" setzt will ich eine Mail erhalten.
Die Tests funktionieren gut, nur immer wieder wenn das Netzteil der Brandmeldeanlage anschalte erhalte ich diese Mails.

In der FHEM Oberfläche habe ich aber "STATE: off"...

Ich denke das es einfach immer wieder kurz zu "on" signalen kommt, warum auch immer.

LOG:
2016-06-05_13:54:39 Rauchmelder_Alarm off
2016-06-05_13:54:39 Rauchmelder_Alarm Longpress: off
2016-06-05_13:54:39 Rauchmelder_Alarm Pinlevel: high
2016-06-05_13:54:39 Rauchmelder_Alarm on
2016-06-05_13:54:42 Rauchmelder_Alarm Dblclick: off
2016-06-05_13:54:42 Rauchmelder_Alarm Pinlevel: low
2016-06-05_13:54:42 Rauchmelder_Alarm off

Deshalb hätte ich gerne wenn für 30 Sekunden am Stück ohne Unterbrechung das Signal auf "on" steht die Mail...

Wie würde der Watchdog da aussehen?

Vielen Dank!

klausw

Zitat von: Malvin83 am 05 Juni 2016, 20:32:13
In der FHEM Oberfläche habe ich aber "STATE: off"...

Ich denke das es einfach immer wieder kurz zu "on" signalen kommt, warum auch immer.

LOG:
2016-06-05_13:54:39 Rauchmelder_Alarm off
2016-06-05_13:54:39 Rauchmelder_Alarm Longpress: off
2016-06-05_13:54:39 Rauchmelder_Alarm Pinlevel: high
2016-06-05_13:54:39 Rauchmelder_Alarm on
2016-06-05_13:54:42 Rauchmelder_Alarm Dblclick: off
2016-06-05_13:54:42 Rauchmelder_Alarm Pinlevel: low
2016-06-05_13:54:42 Rauchmelder_Alarm off

Deshalb hätte ich gerne wenn für 30 Sekunden am Stück ohne Unterbrechung das Signal auf "on" steht die Mail...

Inst am GPIO ein pullup bzw. pulldown angeschlossen?

evtl kannst du Longpress auswerten. Der schaltet erst nach 1s (glaube ich) auf on.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Malvin83

Ja, die haben wir. Das sind 2 mal 10k widerstände auf gnd...Wie kann ich das mit Longpress machen?

Könntest du mir da für die FHEM Befehle helfen?

Vielen Dank!

budy

Moin,

mal davon abgesehen, dass ich einem solchen wackeligen Brandmelder nicht trauen würde, hat Icinger mit dem Watchdog schon recht. Der macht genau das, was du möchtest. Er triggert auf ein Ereignis und wartet dann anschließend eine einstellbare Zeit auf ein weiteres, wie ein Wachhund eben.

Wenn du also 30s verstreichen lassen willst, in denen das Event ohne Unterbrechung anliegen soll, dann ginge das so:

define wBrandalarm watchdog Rauchmelder_Alarm:on 00:00:30 Rauchmelder_Alarm:off {fhem("trigger wBrandalarm .");;fhem("set Alarm on")}


Der trigger setzt den Watchdog neu, damit er auch auf neue Events achtet und der zweite Befehl, ist der, welcher dann "etwas tut". Was genau das ist, musst du dann sehen. Z.B. ein Notify auslösen, welches dann weitere Dinge anschiebt.

Nichtsdestotrotz sind 30s bei einem Zimmerbrand wertvolle Zeit und nicht umsonst kosten gute Rauchmelder ihre Kohle...

Gruß,
Stephan
Debian stretch, FHEM 5.9.
HM-CC-RT-DN, HM-ES-PMSw1-Pl, HM-LC-Dim1TPBU-FM, HMUARTLGW, HMLAN, HM-SEC-KEY, HM-SEC-RHS, HM-SEC-SC-2, HM-SEC-SCo, HM-SEC-SD-2, HM-OU-CFM-TW, div. HUEs, Wifilight, Ring Video Pro

Malvin83

#6
Merci, werde ich morgen mal versuchen :)

Habe übrigens sehr gute Rauchmelder im ganzen Haus vernetzt (Ei Electronics 650W) kostet einer mit Funkmodul um die 80€...

Das mit der Brandmeldeanlage ist nur ein "Feature"  8)

Aktuell habe ich noch ein sehr gutes Netzteil am testen...seit gestern kein Störsignal mehr...wenn wieder eines kommt versuche ich die Watchdog Variante...

Grüsse


klausw

Zitat von: budy am 06 Juni 2016, 19:01:58
mal davon abgesehen, dass ich einem solchen wackeligen Brandmelder nicht trauen würde, hat Icinger mit dem Watchdog schon recht. Der macht genau das, was du möchtest. Er triggert auf ein Ereignis und wartet dann anschließend eine einstellbare Zeit auf ein weiteres, wie ein Wachhund eben.
Das wird weniger am Brandmelder liegen. Eine 3,3V Signalleitung durch das ganze Haus gezogen ist nun mal recht störanfällig.
Der Interrupt reagiert nun mal auch auf Spikes, die von der Netzleitung überkoppeln.

Longpress:
das Attribut interrupt muss auf both gesetzt sein
über das Attribut longpressinterval kannst du die Zeit in s setzen, nach der ein longpress erkannt wird (Standard ist 1s und sollte bei kurzen Spikes völlig ausreichen)
Folgende Änderung an deinem Notify sollte funktionieren:
define Rauchmelder_Alarm_ON_Notify notify Rauchmelder_Alarm:Longpress:on* {my $tme=TimeNow();; fhem ("set Pushover_sbn msg 'Feueralarm ausgelöst' 'Feueralarm um $time ausgelöst' '' 0 ''")}

Alternativ könntest du einen Tiefpass in die Leitung bauen.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280