Neues Modul für Alarmanlage

Klinki · 12 Januar 2017, 15:29:49

Diese Antwort habe ich befürchtet

Ich habe soeben das Perl-Modul in Version 2.84 noch einmal nach /FHEM verschoben, fhem Neustart -> keine Alarmierung
wieder die 2.82 eingespielt -> Alarmierung funktioniert wie gewohnt.

Wie gesagt: nur die .pm-Dateien wurden getauscht.

Das Alarmmodul scheint auf das RegEx zu reagieren. Ich hatte auch schon mal das Verbose-Level auf das Alarmmodul-Device erhöht. Hier kommt dann ein

Code Auswählen

alarm0.on.N exec {main::Alarm_Exec("AlarmModul",0,"$NAME","$EVENT","on")}

wenn der Bewegungsmelder erfasst.

...aber die Set Action beim Actor wird nicht ausgeführt

was könnte ich denn noch prüfen?

gruß
klinki

Prof. Dr. Peter Henning · 12 Januar 2017, 17:29:03

Bitte mal die angehängte Version ausprobieren - kann sein, dass ein BugFix einen unerwünschten Effekt nur für Level 0 produziert.

LG

pah

Klinki · 13 Januar 2017, 06:52:30

Vielen Dank für die schnelle Reaktion!

Es alarmiert wieder!
Ich probiere noch ein bisschen rum. Soll ich noch etwas Spezielles testen?

gruß
klinki

Prof. Dr. Peter Henning · 13 Januar 2017, 07:52:21

Nö, das war nur eine minimale Änderung - die allerdings den Level 0 lahmgelegt hatte. Ist schon eingecheckt.

LG

pah

Neitcom · 13 Januar 2017, 20:32:15

Meine Frage etwas weiter oben ist evtl. untergegangen. Wenn es doch noch eine Antwort gibt, würde ich mich sehr freuen.

Gruss neitcom

Zitat von: Neitcom am 08 Januar 2017, 10:51:54

[..]
Stehen die Variablen $SHORT, $NAME und $EVENT im "Unset Action"-Fall nicht zur Verfügung?

Falls dies zutreffen sollte, wie kann ich das Problem anders lösen? Ich würde die unset-Meldung gerne dynamisch der set-Meldung zuordnen können. Hintergrund: Auf allen Alarmleveln soll der gleiche Aufruf zum Mailversand im Set und Unset Fall verwendet werden.

Prof. Dr. Peter Henning · 14 Januar 2017, 06:04:23

Bisher nicht.
Ist auch tricky, weil im Unset-Fall zuerst die Aktoren ausgelöst werden und DANN erst der State geändert wird.

LG

pah

marty29ak · 15 Januar 2017, 10:35:30

Hallo,
ich habe mir eine Alamanlage mit dem MAX! System zusammen gestellt.
Grundsätzlich funktioniert auch alles erst mal wie gewollt und zuverlässig.
Kurz der Aufbau:
Die Komponenten von Max! sind über Maxlan in Fhem eingebunden.
Genutzt werden Max! Fensterkontakte zum auslösen.
Scharf/unscharf geschaltet wird über einen Schlossschalter der wiederum einen Max! Fensterkontakt betätigt.
Dazu habe ich zwei Notify angelegt

Code Auswählen

defmod Schlossschalter_an_n notify MAX_0c1b17:opened set Schlossschalter_ein off ;; set Schlossschalter_aus on
attr Schlossschalter_an_n room F_Alarm

Code Auswählen

defmod Schlossschalter_aus_n notify MAX_0c1b17:closed set Schlossschalter_ein on ;; set Schlossschalter_aus off
attr Schlossschalter_aus_n room F_Alarm

Die wiederum zwei Dummy schalten.

Code Auswählen

defmod Schlossschalter_aus dummy
attr Schlossschalter_aus alarmDevice Sensor
attr Schlossschalter_aus alarmSettings alarm0,|Schlossschalter_aus:on|Wohnungstür auf|disarm
attr Schlossschalter_aus room F_Alarm
attr Schlossschalter_aus setList state:on,off
attr Schlossschalter_aus webCmd on:off

Code Auswählen

defmod Schlossschalter_ein dummy
attr Schlossschalter_ein alarmDevice Sensor
attr Schlossschalter_ein alarmSettings alarm0,|Schlossschalter_ein:on|Wohnungstür zu|arm
attr Schlossschalter_ein room F_Alarm
attr Schlossschalter_ein webCmd on:off

Das Problem liegt jetzt darin, das ich zwischen Wait Action und Arm Action kein Delay über 10 Sekunden setzen kann.
Wenn ich mehr wie 10 Sekunden eingebe bleibt die Alarmanlage in einer Schleife bei Wait Action hängen. Also es wird immer nur die Ansage "Alarmanlage wird in kürze scharf geschaltet" wiederholt.

Da die Max! Geräte per Maxlan angebunden sind muss ich den Max Cube ja in gewissem Intervall pollen. Dieser Intervall liegt auch bei 10 sec um eine Zeitnahe Erkennung der Fensterkontakte zu ermöglichen.
Denke dieser Pollintervall sorgt dafür das die Alarmanlage zurückgesetzt wird und so in der Schleife hängt.

Meine Vermutung ist, das die Notify für den Schlüsselschalter geändert werden müssen. Aber wie? $:-\$

Ps.: Hat sich erledigt. Hatte es schon erfolglos mit dem Attribut event-on-change-reading versucht, was aber jetzt nach einem Neustart von Fhem doch geht.

SGi · 15 Januar 2017, 17:46:09

Bin gerade (zum 3. Mal) dabei, mir das Alarm-Modul mal wieder näher anzusehen und damit zu experimentieren. Gibt es eigentlich einen Grund, warum ich bei beispielsweise Verwendung des msg-Moduls

in der Wait-Action

Code Auswählen

msg audio @FHEM_EG Test Vorwarnung
schreiben kann, aber eine Zeile darunter in der Arm-Action mit

Code Auswählen

msg audio \@FHEM_EG Test scharf
mein @-Zeichen in der Zielangabe escapen muss ? Sonst bleibt die Ausgabe stumm und es erscheint ein Fehler im Log:

Code Auswählen

Global symbol "@FHEM_EG" requires explicit package name at (eval 1899) line 1.

Als Programmierer nehme ich an, das liegt an der Art, wie diese dort eigegebenen Zeichenketten ans Modul übergeben werden und dann mit den eigentlichen PERL-Routinen kollidieren. Aber als Anwender ist mir natürlich nicht klar, warum ich für eine identische Aktion jeweils eine verschiedene Syntax benutzen muss. Ist das auch noch an den anderen (Action-)Stellen auf diese Art inkonsistent oder nur ein Bug ?

Gruss, Sven

Prof. Dr. Peter Henning · 15 Januar 2017, 21:33:59

ZitatAls Programmierer nehme ich an, das liegt an der Art, wie diese dort eigegebenen Zeichenketten ans Modul übergeben werden

Falsch, beide werden auf dieselbe Art übergeben. Allerdings werden die "wait"-Strings direkt ausgeführt, während die "arm"-Strings als Parameter in einem at-Kommando auftauchen und erst später ausgeführt werden. Es ist das erste Mal, dass dieses Problem dabei auftaucht, insofern halte ich den Tonfall der Frage

ZitatIst das auch noch an den anderen (Action-)Stellen auf diese Art inkonsistent oder nur ein Bug ?

für nicht angemessen. Werde ich vielleicht irgendwann abfangen.

pah

ulorczyk · 16 Januar 2017, 19:11:08

Ich habe ein ähnliches Verhalten wie Sven festgestellt. In der Arm-Action muss ich für mp3-Ausgaben auf Sonos mittels PlayURITemp die Backslash-Angaben jeweils maskieren. Bei allen anderen Aktionen ist das nicht notwendig.

Gruss, Udo

GG33 · 17 Januar 2017, 09:15:49

Hallo, ich habe versucht gemäss dem Wiki Eintag eine Alarmanlage einzurichten.
Dazu habe ich mir div. dummys erstellt und möchte dies jetzt mir den vorhanden Fensterkontakten testen. Leider funktioniert dies aber nicht!
Ich hoffe jemand kann mir auf die Sprünge helfen?!

Grüsse
Björn

PSI69 · 17 Januar 2017, 10:10:25

Was funktioniert nicht? Ich sehe z. Bsp. im Screenshot keinen Level 'armed'...
Peter

GG33 · 17 Januar 2017, 16:40:29

Ich denke das Kästchen "Armed" wird gesetzt über den Arm Button??
Müssen noch notify's erstellt werden oder ist die Eingabe in die Maske alles?

PSI69 · 17 Januar 2017, 17:02:30

Ich stelle noch einmal die Frage, was genau funktioniert nicht? Wo kommst Du nicht weiter? Armen, disarmen, auslösen von Level 6?

Laut Deinem Screenshot kann ich vermuten, Du willst über den Sensor Alarmanlage (Alarmanlage:scharf) den Alarmlevel 6 arm'en und ein Sensor Tuer_Kueche (Tuer_Kueche:open) löst dann ggf. Level 6 aus. Als Actor wird ein Device Test auf 'Einbruch gesetzt'; hm - aber Vermutungen sind verdammt unkonkret, oder?!?

Peter

GG33 · 17 Januar 2017, 17:34:43

Zitat von: PSI69 am 17 Januar 2017, 17:02:30
Ich stelle noch einmal die Frage, was genau funktioniert nicht? Wo kommst Du nicht weiter? Armen, disarmen, auslösen von Level 6?

Laut Deinem Screenshot kann ich vermuten, Du willst über den Sensor Alarmanlage (Alarmanlage:scharf) den Alarmlevel 6 arm'en und ein Sensor Tuer_Kueche (Tuer_Kueche:open) löst dann ggf. Level 6 aus. Als Actor wird ein Device Test auf 'Einbruch gesetzt'; hm - aber Vermutungen sind verdammt unkonkret, oder?!?

Peter

Ganz genau!

Eigentlich funktioniert nichts... nichteinmal scharfstellen. Und wenn ich über das Kästchen scharfstelle, dann pasiert nichts, wenn ich das Fenster öffne...