Neues Modul für Alarmanlage

Begonnen von Prof. Dr. Peter Henning, 08 September 2014, 20:43:06

Vorheriges Thema - Nächstes Thema

Spezialtrick

Wäre es möglich einen Delay für Aktoren, wie z.b. einen Reed Kontakt an der Haustür, einzurichten?

Optimal wäre eine Implementierung direkt ins Modul, oder?
FHEM - Debmatic - Zigbee2MQTT - Homekit

dklueh

Ich bekomme auch nach Integration immer noch:

Undefined subroutine &main::Alarm_Html called at (eval 43) line 1.

Kann mir jemand helfen?

Prof. Dr. Peter Henning

@Spezialtrick: Nicht sinnvoll - weil dann nicht der Alarm deaktiviert werden muss, sondern nur das notify für den einzelnen Sensor. Und schon gar nicht sinnvoll im Modul selbst - das müsste dann für jeden Sensor das Timing übernehmen.

So, wie es jetzt ist, wird der Alarm gleich ausgelöst - aber seine Aktionen verzögert. Irgendwie will man ja auch demjenigen, der die Haustür gerade geöffnet hat, ein Warnsignal geben ...

Wer trotzdem den Alarm verzögert auslösen will: Notify auf den Reed-Kontakt setzen, damit eine verzögerte Auslösung des Alarms in sagen wir 30 Sekunden.

LG

pah

Spezialtrick

Danke für deine Antwort, Pah!

Bei mir besteht das Problem, dass die Anlage hinter der Haustür an einem gesicherten Schalter an/ausgeschaltet wird, d.h., dass derjenige, der die Haustür befugt öffnet, nur 2-3 Sekunden Zeit hat, die Anlage unscharf zu stellen. In dieser kurzen Zeit ist das aber nicht möglich, so dass sofort die Sirene ertönt.

Dieses Problem könnte ich ziemlich einfach über die eingebaute Delay Funktion lösen. Somit hätte man genügend Zeit die Anlage unscharf zustellen. Dann ergibt sich jedoch das Problem, dass der Alarm bei jeder Auslösung, unabhängig vom Sensor, zeitverzögert ausgelöst wird. Bei der Haustür ist dies wie zuvor beschrieben auch so gewollt. Bei der unbefugten Öffnung eines Fenster sollte der Alarm jedoch sofort und ohne Zeitverzögerung ausgelöst werden.

Hast du hierfür vllt. einen Lösungsvorschlag?  :-\
FHEM - Debmatic - Zigbee2MQTT - Homekit

Prof. Dr. Peter Henning

Ich habe das eigentlich genauso aufgebaut. Bei mir gibt es einen "Voralarm": Licht geht an. Damit wird nicht nur der Einbrecher abgeschreckt, sondern gleichzeitig derjenige, der die Tür korrekt geöffnet hat, auf den drohenden Alarm in 30 Sekunden hingewiesen.

In den nächsten Wochen ergänze ich das um einen MP3-Abspieler, der dann entsprechend warnt. Etwa "pannensichere Selbstvernichtung in 30, 25, --- 5 Sekunden".

LG

pah

alec_osborne

#125
Hallo Zusammen,


ich erhalte immer beim setzen der Parameter über set Alarms folgende Fehlermeldung: State locked, cannot create new notifiers.
Dadurch werden keine notifiers gesetzt und nichts geht.

Das Attribut lockstate steht dabei aber auf unlock

Hat jemand einen Tipp für mich?


LÖSUNG: wichtig ist das lockstate in den READINGs steht.
Kommando "attr <alarmname> lockstate unlocked" absetzen. -> reicht also nicht!

Über das setzen mit  set <alarmname> unlock" funktioniert es nun.



svenr

Hallo pah,

ich habe ein Problem nach Update des Moduls von v1.4 auf v1.9 bei der Fensterüberwachung.
Ich habe die wie im Wiki beschrieben eingerichtet (wobei ich den Delay des TFOpen.check von 10 min auf 10 sec abgeändert habe). Es funktionierte bisher auch prima. Nach dem Update wird der Alarm nun nicht mehr widerrufen, sobald alle Fenster wieder geschlossen sind. Es scheint als ob der in der HouseOpen() angelegte delay für den Dummy TFClose.warn nicht ausgelöst bzw. dieser den Alarm nicht widerruft.
Wenn ich mit Set Alarms die Alarme neu setze, erscheint im Log folgende Fehlermeldung:


[Alarm 4] not raised, alarmSensor global has wrong settings


Was bedeutet das? Liegt scheinbar an meinen Einstellungen? Hättest Du einen Tipp?

Danke und viele Grüße
Sven

Prof. Dr. Peter Henning

Einen Tipp ? Klar. Sich mal die Konfigurationsdatei anzusehen, es sollte nämlich keinen Alarmsensor "global" geben.

LG

pah

svenr

OK, ich war auf der falschen Fährte. ;-)
Einen Alarmsensor "global" gab es nicht, das hätte ich auch zuerst vermutet. Jedoch hat sich in die Config von "TFOpen.warn" ein Fehler eingeschlichen. Es gab eine Zeile:
attr TFOpen.warn alarm4,|TFOpen.warn:yes|$EVENT|on 1
Wie die enstand, ist mir schleierhaft. Die war der Fehler.

Das eigentliche Fehlverhalten habe ich nun auch verstanden, zumindest hoffe ich das. ;-)
In Zeile 290 des Moduls hast Du eine weitere Prüfung ergänzt:

#-- only if this level is sharp and not yet active
if( ($xec eq "sharp") && ($hash->{READINGS}{"level".$level}{VAL} eq "off") )


In der alten Version fehlte das Prüfen auf "nicht schon aktiv". Daher funktionierte es bei mir vorher wie gewünscht.

Ich habe Alarm 4 nicht zeitgesteuert, sondern durch ein Öffnen eines Fensters ausgelöst. Ziel war es, ein geöffnetes Fenster auf einem Display anzuzeigen. Dabei soll sich die Anzeige beim Schließen aller Fenster wieder auf "ok" zurücksetzen. Die in der "HouseOpen()" definierten delays lösten den Alarm über die beiden dummies und damit die "HouseOpen()" erneut aus. Da jetzt geprüft wird, ob der Alarm schon aktiv ist, wird der Aktor und damit "HouseOpen()" nicht mehr ausgeführt und somit der Alarm nicht mehr durch das setzen von "set TFClose.warn yes" zurückgesetzt.
Ich habe den Ablauf geändert, somit passt das wieder für mich. Ich hatte nur einen Denkfehler.

Noch eine Frage dazu:
Im Wiki steht: "Dabei wird um 22:00 der erste Test auf ein ordnungsgemäß geschlossenes Haus gestartet - und bis Mitternacht alle 10 Minuten wiederholt". Das macht sicher bei Dir "TFOpen.bedtime" zyklisch, oder? Das fehlt bei mir dann wohl einfach. Vielleicht kannst Du das im Wiki noch ergänzen.

VG
Sven

betateilchen

Hinweis:

Im wiki steht:

Zitat
Anzeige der Zustände
...
Das Problem ist, dass möglicherweise das reading state an anderer Stelle verwendet werden soll - z.B. beim Versenden von Mails als
Value('AAA')

Mit Value() wird aber gar nicht das reading state abgefragt, sondern das internal STATE - insofern können im reading und im internal durchaus unterschiedliche Werte stehen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Prof. Dr. Peter Henning


Prof. Dr. Peter Henning

#131
Neue Version 2.0 eingecheckt.

Änderung: 3 neue Attribute sharpact,unsharpact,cancelact => FHEM-Aktionen, die bei scharf/unscharf schalten sowie Widerruf eines Alarms ausgelöst werden.

Ich habe das jetzt mit dem Teil hier verbunden: http://www.elv.de/homematic-mp3-funk-tuergong-mit-signal-led.html

Mit einigen zusätzlichen dummies sagt mir das Teil jetzt an, woher der Alarm kommt. Die beste Stimme für diese Systemmeldungen habe ich hier gefunden: http://www.ivona.com/. Einfach eigene Texte vorlesen lassen, mit audacity aufnehmen und in MP3 konvertieren.

Die nach Ansicht meines Jüngsten coolste Message starte ich 30 Sekunden vor Auslösung der Rauchmelder als Einbruchalarm - habe ich mal hier angehängt.

LG

pah

alec_osborne

Hallo Pah,


hast du ein Beispiel zu den 3 neuen Attributen? Im Wiki ist noch nicht erfasst oder? Mit ist im Moment unklar wie und wo ich die Aktionen abfange und meine Aktionen anhänge.


Gruß A.

HolyMoly

Vielen Dank für dieses nützliche Modul!
Eine kleine Anmerkung, sharpen/unsharpen sollte wohl arm/disarm heißen
siehe z.B. http://dict.leo.org/forum/viewUnsolvedquery.php?idThread=554410&idForum=1&lang=de&lp=ende
FHEM auf Raspi2 & Radxa Rock

Prof. Dr. Peter Henning

Ich denke nicht, dass ich für irgendetwas ein englisches Dictionary benötige ...

Der Begriff "sharp"/"unsharp" ist ebenfalls in Gebrauch, die Alarmanlage meines Hauses in Stony Brook, NY hatte entsprechende Schlüsselstellungen.

LG

pah