Neues Modul für Alarmanlage

[Prof. Dr. Peter Henning]

Daher 1. der Vorschlag, dieses Zeichen zu entwerten, denn sonst zerschießt man sich schnell seine Config!

Sicher nicht.

LG

pah

[Peete]

Ich habe meine Alarmanlage soweit fertig und sie funktioniert auch zufriedenstellend.

Ein Problem bleibt allerdings. Wenn die Alarmanlage auf arm oder disarm schaltet, dann spielt mein mp3 Gong den Ton für jedes aktive Level ab.
In meinem Fall 3 mal.

Code Auswählen Erweitern

2016.02.03 10:42:47 3: CUL_HM set mp3.Gong playTone 001
2016.02.03 10:42:47 3: [Alarm 3] will be armed from device Alarm_arm with event on, delay 00:30
2016.02.03 10:42:47 3: alarm3.arm.N return value: [Alarm 3] will be armed from device Alarm_arm with event on, delay 00:30
2016.02.03 10:42:47 3: CUL_HM set mp3.Gong playTone 001
2016.02.03 10:42:47 3: [Alarm 6] will be armed from device Alarm_arm with event on, delay 00:30
2016.02.03 10:42:47 3: alarm6.arm.N return value: [Alarm 6] will be armed from device Alarm_arm with event on, delay 00:30
2016.02.03 10:42:48 3: CUL_HM set mp3.Gong playTone 001
2016.02.03 10:42:48 3: [Alarm 7] will be armed from device Alarm_arm with event on, delay 00:30
2016.02.03 10:42:48 3: alarm7.arm.N return value: [Alarm 7] will be armed from device Alarm_arm with event on, delay 00:30
2016.02.03 10:43:20 3: CUL_HM set mp3.Gong playTone 002
2016.02.03 10:43:20 3: CUL_HM set mp3.Gong playTone 002
2016.02.03 10:43:20 3: CUL_HM set mp3.Gong playTone 002
2016.02.03 10:45:09 3: alarm3.disarm.N return value: [Alarm 3] disarmed from device Alarm_disarm with event on
2016.02.03 10:45:09 3: alarm6.disarm.N return value: [Alarm 6] disarmed from device Alarm_disarm with event on
2016.02.03 10:45:09 3: alarm7.disarm.N return value: [Alarm 7] disarmed from device Alarm_disarm with event on
2016.02.03 10:45:12 3: CUL_HM set mp3.Gong playTone 003
2016.02.03 10:45:12 3: CUL_HM set mp3.Gong playTone 003
2016.02.03 10:45:12 3: CUL_HM set mp3.Gong playTone 003

Hättet Ihr einen Lösungsansatz?

Btw. Bei mir wird die Alarmanlage aktiviert, sobald die Keymatic locked ist. Deaktiviert über unlocked. Somit wird sie immer automatisch aktiviert.

[jmike]

Hi Peete.

Ich hatte ein ähnliches "Problem" da meine Alarmanlage ein anderes System updated und dies jeweils pro Level "doppelte" Updates erzeugt hat.
Soweit ich mich erinnere hat sich Herr Henning dazu schon geäußert hier im Thread und derzeit ist keine Änderung geplant.

Mein Workaround sieht so aus:
In der wait/arm action rufe ich ein Script auf (php script welches einen websocket bedient).
Am Anfang des Scripts wird der aktuelle Befehl (kann bei mir variieren), der von FHEM übergeben wird, in ein File geschrieben und am Ende wieder entfernt.

Das PHP script läuft ca. 2 Sekunden.
Sollte innerhalb dieser Zeit ein weiteres Script mit gleichem Befehl gestartet werden, beendet es sich. Ähnlich wie PID Files für Prozesse.

Somit konnte Ich sicher stellen dass zwar andere Befehle starten können während das Script läuft, aber gleiche Befehle nicht ausgeführt werden.

Also:
1) file lesen
2) wenn content mit aktuellen Befehl übereinstimmt beenden
2a) ansonsten Befehl in file schreiben
3) Websocket-Zeug ausführen (in deinem Fall MP3 abspielen)
4) file content löschen

Fühlt sich ein bisschen frickelig an, geht aber sehr gut.

lg
Mike

[Hermann]

Hallo,

Nachdem auch Dank hilfe von zwehn meine Fenster-/Türkontrolle läuft habe ich noch ein Problem. Ich würde gerne die Prüfung auf offene Fenster auch dann durchführen wenn die Haustür geöffnet wird.

Lege ich mir folgendes notify an funktioniert das ganze schon mal:

define HausTuerOffen notify EV.T:open.* {fhem ("{HouseOpen()}")}

Dann läuft das ganze jedoch immer. Ixh möchte es noch daran koppeln das das notify nur abgearbeitet wird, wenn dar Alarm 4 auch scharf ist. Daran scheitere ich jedoch. Mit folgenden Befehl komme ich nicht weiter:

define HausTuereOffen notify EV.T:open.* {if ("Alarm_Pruefung" eq "on") {fhem("{HouseOpen()}"))}}

Kann mir jemand weiterhelfen.

Hermann

Ich darf mich selber korrigieren. Mit folgenden Befehl klappt es :

define HausTuereOffen notify EV.T:open.* {if (Value("Alarm_Pruefung") eq "on") {fhem("{HouseOpen()}")}}

[Warlock_2016]

Hallo Hermann,
kannst du mir nochmal helfen.

Ich selber kommt mit der Routine nicht ganz klar. Sub HouseOpen()" nicht klar. Diese  Überwachungsroutine soll ja checken, ob ja den Status der Fenster oder anderen Sensoren überwachen.

Wenn ich mir den Quellcode durchlese, dann kann sich beispielsweise im Code:
...
if( $main::value{'BK.F'} ne "Closed" ){
   $kfo++;
   $kfs = "BK/";
}

sehen, dass hier hard auf den Sensornamen gegangen wird  (z.b. BK.F. ). D.h. würde ja heissen, dass ich dann alle meine 4 Fenstersensoren über ein If zu prüfen hatte ?.

Könnte man die Logik nicht generisch aufbauen oder muss wirklich jeder einzelner Sensor geprüft werden indem man zugewiesen Attributen an Sensoren prüft.

Hast du einen Tip? Sonst ist das ganze ja Genial.

Gruss, Markus

[Prof. Dr. Peter Henning]

Zur Logik der HouseOpen-Routine:

Tür- und Fenstersensoren können an ganz verschiedenen Orten auftauchen. Aber nicht jeder Sensor wird abgefragt - ich möchte beispielsweise nicht die Alarmanlage auslösen, wenn im Schlafzimmer des 1. OG das Fenster geöffnet wird. Damit scheidet entweder aus, die Sensoren alle systematisch zu benennen - oder sie alle mit einer Wildcard abzufragen. Also: Es wird wirklich im Code dieser Routine jeder abzufragende Sensor einzeln aufgeführt.

@Warlock: Wem das nicht gefällt => bitte eigenen Code schreiben, und bitte nicht als Neuling fortwährend über meinen Code meckern.

@Peete & jmike: Es macht durchaus Sinn, sich alle aktivierten Alarmlevel ansagen zu lassen - dann weiß man, welche Level aktiv sind. Man braucht übrigens nur 20 Zeilen Perl-Code, um aus drei einzelnen Meldungen eine Gesamtmeldung "Alarmlevel 4, 5 und 6 scharf geschaltet" zu machen. Und wenn  immer dieselben Level zusammen scharf oder unscharf geschaltet werden, sollte man die sowieso besser zusammen legen.

Ich halte das auch mt den unterschiedlichen Alarmleveln, die man manuell einschalten muss, für wenig benutzerfreundlich - es ist bei einer komplexen Installation eben nicht einfach, sich zu merken, welcher Sensor zu welchem Level gehört. Viel besser: Nur EIN Level wird manuell scharf oder unscharf geschaltet, alle anderen laufen permanent mit (bzw. nur zu bestimmten Zeiten).

Und nur so als Fußnote: Es ist ungünstig, das Aussortieren von Doppelkommandos mit einem Skript und PHP zu machen. Mit einer Instanz des DOIF-Moduls lässt sich das in drei Zeilen FHEM-Code unterbringen.

LG

pah

[jmike]

Hallo Herr Henning.

Dem gibt es wohl kaum etwas hinzuzufügen.
Ich wollte ja auch keine Komplettlösung, sondern nur einen "Ansatz" liefern.

Für mich war das synchrone Schalten mehrerer Levels notwendig da ich die Haustüre bei ein paar Aktionen von den anderen Sensoren trennen wollte. Wer durchs Fenster einsteigt bekommt z.B. keinen "Entschärfungs-delay".

Das besagte PHP Skript ist ein komplexer Websocket Client, den konnte und wollte ich nicht in Perl neu schreiben nur um ihn in FHEM zu integrieren

lg
mike

ps: für das Modul möchte ich mich an der Stelle bedanken. Es wurde an so vieles Gedacht und wenn das Konzept steht sind kleinere Änderungen, Tests etc. super umzusetzen!

[Prof. Dr. Peter Henning]

Dann würde ich doch den "Entschärfungsdelay" direkt bei den Sensoren einbauen - so verhindere ich z.B., dass irgend ein Vorgang ausgelöst wird, nur weil ich mal kurz die Katze rauslasse.

LG

pah

[jmike]

...den "Entschärfungsdelay" direkt bei den Sensoren einbauen

Hört sich gut an, hatte ich nicht mal auf dem Schirm dass dies geht.
Das wäre natürlich der sauberste Weg da es dann auch keine doppelten Aktoren (mit und ohne delay) gibt.

Danke für den Tip!

mike

[Prof. Dr. Peter Henning]

Was für Sensoren sind das genau ?

LG

pah

[NilsB]

Hallo allerseits,

nach länglicher Einlesephase mit anschließender Beschaffung bin ich nun auch soweit eine Alarmanlage mit dem hier diskutierten Modul einzurichten. Vorab herzlichen Dank an den Autor pah für die investierte Arbeit!

Zwar läuft das Modul bisher wie vorgesehen, aber ich habe eine grundsätzlich Frage zu den "Sensorregeln". Ich verstehe generell, warum ein Cancel-Button unbedingt da sein muss. In meinem Anwendungsfall stellt es sich jetzt allerdings so dar, dass ein Canceln des Alarms mit den Disarm Sensoren durchgeführt werden soll. Meinen Tests nach ist dies auch problemlos möglich: Die Cancel Aktion wird beim Betätigen eines Disarm-Sensors durchgeführt.
Damit die Alarmdefinition valide ist habe ich als Cancel-Sensor einfach einen ungenutzten Kanal eines HM-PBI-4-FM eingetragen.

Übersehe ich irgendwelche Nachteile durch das Auslassen eines Cancel-Buttons?

Grüße
Nils

[Bytechanger]

Hallo

@Prof. Dr. Peter Henning:
Kurze frage, warum nicht?
Das Phänomen was auftritt ist, wenn ich in das Feld "Notify on RegExp" ein | eintrage,
ist nach dem Speichern der Konfigeintrag DEFEKT. D.h. das Notify und Messagepart, etc. werden nicht mehr korrekt gefüllt.

Nachvollziebar, da die "attr SENSOR alarmSettings " Ihre Eingenschaften mit | Zeichen trennt. Das nicht entwertete | bringt dann die ganze Config durcheinander.

Oder sehe ich das falsch?
Wäre gerne mit mehr als nur :

Sicher nicht.

LG

pah

abgespeist worden...

Greets

Byte

[jmike]

@ pah: Ich nutze dort die HM-SEC-SCo.

[Prof. Dr. Peter Henning]

Register heißt R-eventDlyTime

LG

pah

[Depechem]

Nun habe ich auch noch mal eine Frage, bei Alarm bekomme ich automatisch eine Email mit den aktuellen Infos wie bereits beschrieben:

Code Auswählen Erweitern

{DebianMail('...@gmail.com','Alarm',Value('AAA'))}

nun würde ich gern die gleiche Nachricht auf meinem Tablet als Sprachansage ausgeben wollen:

Code Auswählen Erweitern

set androidTablet ttsSay ...
wie müsste der Ausgabecode heißen das mir aufs Tablet die gleiche Nachricht wie in der Mail angesagt wird?

kann mir hier wirklich keiner weiterhelfen 

das habe ich auch schon probiert, funktioniert aber leider auch nicht

Code Auswählen Erweitern

{fhem('set androidTablet ttsSay'.ReadingsVal('AAA', 'short',undef))}