Neues Modul für Alarmanlage

[Prof. Dr. Peter Henning]

Das Problem ist, dass je Sensor nur ein regulärer Ausdruck gesetzt werden kann.

In diesem komplexen Fall würde ich deshalb vorschlagen, mit einem notify auf den DS2408 8 verschiedene dummy-Devices zu setzen und jedes dieser als eigenen alarmSensor einzubinden.

Alternative: den kompletten Status des DS2408 überwachen. Als alarmActor einen dummy, als Ausführungsbefehl für diesen dummy aber eine eigene perl-Prozedur, die je nach Aufruf verschiedene Aktionen auslöst.
LG

pah

[UweH]

Hallo Peter,

Danke, das werde ich so machen. Das sollte ich hinkriegen. 
Zu meinem anderen Problem nochmal: Ich setze den state eines DS2413 mit einem stateFormat auf Port A. Den Wert dieses state soll einen Alarm auslösen. Tut er nicht, weil ich offenbar den Ausdruck falsch definiere. Nur ein "DS2413:ON" interessiert das Alarmmodul nicht, andere Varianten mit Klammern etc. auch nicht. Wie wäre es denn richtig?

Danke und Gruß
Uwe

[Prof. Dr. Peter Henning]

Hm, ich habe vage in Erinnerung, dass stateformat irgendetwas Komisches mit den Events macht. Vorschlag: Event Monitor laufen lassen und währenddessen den gewünschten Zustandswechsel manuell auslösen. Und dann nachsehen, welcher Event ausgelöst wird.

LG

pah

[UweH]

Komisches mit den Events macht.

Stimmt...sehr komisch. Das komplette Reading wird trotz "stateFormat {ReadingsVal($name,"G",0)}" in den state geschrieben:

Code Auswählen Erweitern

2015-02-15 15:12:07 OWSWITCH DS2408 A: ON B: OFF C: OFF D: OFF E: OFF F: OFF G: ONX H: OFF
Im internal STATE wird nur der Status von G angezeigt. Eine Abfrage mit "{Value("DS2408")}" zeigt den internal STATE.
Na das wird lustig...

[UweH]

Komisch geht's weiter: Ich habe zwei Dummys für Port G und H des DS2408 als Sensor. Dann ein solches Notify "DS2408:.* set dmy_Port_G %EVTPART13; set dmy_Port_H %EVTPART15". Das funktioniert alles bis %EVTPART13. Ab der 14 spuckt es sowas aus...s. Anhang. Frage: Funktioniert %EVTPART nur von 0 bis 13?

[henry123]

Hallo,
ich benutze die Alarmanlage und bin sehr begeistert, vielen Dank für dieses Modul.
Nun meine Frage, ich beschäftige mich mit Fhem erst einige Wochen und möchte den Zustand der Alarmzonen(0-7) über
ein Display anzeigen (hm-ou-led16).
Wie frage ich den Zustand von  Zone 1 (armed oder disarmed) ab um ein "set  Display_led1 led red"  zu schalten.
Bitte helft mir mal auf die Sprünge

[wtue]

Hallo Henry123,

Schau dir mal die Attribute deiner Anlage an, bei mir AAA und versuch mal eine Abfrage nach dem Muster
{(AttrVal('AAA','level0xec','') eq 'disarmed')}

Weitere Zustände sind armwait und armed.

Gruß

[henry123]

Danke für die schnelle Antwort,
define dis_level0_d notify aaa:level0xec eq "disarmed" set Display_LED1 led red
hatte ich schon versucht, leider ohne Erfolg.
Dein Vorschlag werde ich heute abend mal testen.

.. hab es auf die schnelle mal getestet : bringt folgenden Fehler : Bad regexp: Unmatched ( in regex; marked by <-- HERE in m/^{( <-- HERE AttrVal('aaa','level0xec','')$/ at ./FHEM/91_notify.pm line 42.
.. es war eine ( ) zu viel, funktioniert aber immer noch nicht.

[wtue]

Hallo henry123,
ich habe mir auch eine Weile überlegt wie ich den Status des Alarmmodul anzeigen kann und habe mich erstmal für rss entschieden. Siehe hier http://forum.fhem.de/index.php/topic,22520.msg160064.html#msg160064  Damit zeige ich die Stati auf einem Tablett an. Das wird aber aus verschiedenen Gründen sicher nicht so bleiben. Ausschnitt aus meiner rss.layout:

Code Auswählen Erweitern

condition {(AttrVal('AAA','level2xec','') eq 'armwait')}
rgb "FFFF00"
moveby 0 35
text x y "Alarm 2  -->  Sensorüberwachung  -->   wird aktiviert"
condition 1
condition {(AttrVal('AAA','level2xec','') eq 'armed')}
rgb "00FF00"
moveby 0 35
text x y "Alarm 2  -->  Sensorüberwachung  -->   ist aktiviert"
condition 1
condition {(AttrVal('AAA','level2xec','') eq 'disarmed')}
rgb "FF0000"
moveby 0 35
text x y "Alarm 2  -->  Sensorüberwachung  -->   ist deaktiviert"
condition 1

Aber das gehört hier nicht her.

Mein Post war als Hinweis zu verstehen, nicht als die Lösung die 1 zu 1 übernommen werden kann.

Gruß
Edit:
Diese Funktion

Code Auswählen Erweitern

{(AttrVal('AAA','level2xec',''))}

in der Commandline von Fhem liefert mir armed zurück.

[Prof. Dr. Peter Henning]

@henry123: Da der Post keinerlei Klammern enthält, kann man ihn auch nicht auf Richtigkeit überprüfen

pah

[henry123]

Hallo wtue,
dein Beitrag war korrekt, hatte zu wenig Zeit heut morgen.
Habe es jetzt aber anders gemacht (alle 8 LEDs als Actor) und über Wait Action alle 8 leds gesetzt.
Danke nochmal.

[MiWe58]

Hallo,

Das Modul für die Alarmanlage habe ich für meinen geplanten Einsatz ausprobiert und komme damit recht gut voran.

Mir geht es nun darum, die möglichen Reaktionen auf den Eintritt der jeweiligen Alarm-Level für meinen Einsatz zu konzipieren und möglichst gut strukturiert umzusetzen.

Die Überlegung ist, dass das Eintreten eines der Alarmlevels meist mehrere der folgenden, aber individuell unterschiedlichen, Reaktionen auslösen soll:
akustisches Signal mit Zeitsteuerung
optisches Signal mit Zeitsteuerung
einen oder mehrere generischer Aktoren
Das Versenden von Nachrichten
und eine "Cancel " Möglichkeit je Alarm-Level

Schön wäre es also, wenn je Alarm-Level für diese Reaktionen separate Eingabefelder für das Verhalten der Aktoren vorhanden wäre.
Damit würde, nach meiner Einschätzung, die Lösung der gesamten Alarmanlage noch deutlich übersichtlicher und einfacher realisierbar werden.

Vielleicht finden sich ja noch Andere, die diesen Vorschlag für interessant halten.

Gruß
Michael

[Prof. Dr. Peter Henning]

Da ist wohl ein Wunsch Vater des Gedankens. Mehrere Eingabefelder je Alarmlevel und Aktor bewirken nämlich Eines sicher nicht: Größere Übersichtlichkeit und Einfachheit.

Im Übrigen lässt sich das problemlos bereits jetzt realisieren, ich nutze das schon seit langer Zeit

1. Angenommen sei ein aktustischer Aktor (z.B. ein MP3-Gong), der in Level 1 "A" und in Level 4 "B" sagen soll.
2. Man definiert je einen Dummy "adummy" und "bdummy", beide erhalten das Attribut "alarmActor". Dadurch tauchen sie in der Liste der Aktoren auf
3. In dieser Liste werden sie mit jeweils anderen "Set Action"-Befehlen versehen: adummy wird dem Level 1 zugeordnet und erhält die Action "set Gong play A",  bdummy wird dem Level 4 zugeordnet und erhält die Action "set Gong play B"
4. Selbstverständlich kann jede dieser Aktionen auch eine andere Verzögerung bekommen...



LG

pah

[kvo1]

Hallo pah,

sagt Dir diese Meldung im Log nach dem Update etwas ??

2015.02.23 21:38:03 1: Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015.02.23 21:39:42 1: EN FHEM/95_Alarm_v1.4.pm: No <a name="Alarm_v1.4"> link

kvo1

[Prof. Dr. Peter Henning]

Ja.

LG

pah