Neues Modul für Alarmanlage

Prof. Dr. Peter Henning · 04 Juni 2015, 14:40:33

Oh, teilweise schon. Aber die doofen Sprinklerdüsen des Mikrosystems sind in jedem Frühjahr zum Teil im Eimer.

Im Backend läuft bei mir: 4 x Gardena 24 V Ventil, geschaltet über FS20

LG

pah

duke-f · 04 Juni 2015, 14:54:40

Jetzt kommen wir ab vom Thema, aber der Satz sei noch genemigt: Mein "System" ist bisher recht einfach: Bewässerungscomputer - Verteiler - Bodenfeuchtesensor - Standard-Wischsprinkler (oder wie er auch wirklich heißen mag).

Wird bisher im Herbst eingemottet und im Frühsommer wieder ausgepackt. Man merkt aber schon, dass nach und nach alles verkalkt und nicht mehr so zuverlässig läuft - kann mich mit Deiner Aussage also durchaus anfreunden und merke mir: Mikrosystem will überdacht werden...

duke-f · 05 Juni 2015, 11:16:55

Ein Kritikpunkt allgemeiner Form vielleicht:
M.E. ist ein Name wie "Alarm" für so ein mächtiges Tool eigentlich nur bedingt geeignet. Das hat zwei Gründe:
1. Wie ich oben angedeutet habe, lässt er den Umfang der Möglichkeiten nicht mal annähernd abschätzen (mein erster Gedanke: Ach, ein Wecker ...)
2. Im Rahmen einer Recherche kommt sehr vieles zutage, was nichts mit dem Modul zu tun hat. Schon im Wiki gibt es die zwei Einträge: "Alarmanlage" und "Modul Alarmanlage" - ja ich weiß: Jemand, der sich an FHEM wagt ist bestimmt in der Lage, hier zwei Einträge noch zu bewältigen

).

Ansonsten: Bin die 22 Seiten Forum und das Wiki jetzt durch und werde mich, sobald Zeit ist, auch an die Umsetzung machen.

Prof. Dr. Peter Henning · 05 Juni 2015, 15:12:15

Diese Kritik weise ich zurück. Ich setze das als Alarmanlage ein, so ist es konzipiert und wird es gepflegt.

Das Problem mit dem Wiki ist bekannt, irgendwann wird das auch gelöst.

pah

DerFrickler · 08 Juni 2015, 23:42:06

ich hätte da dann noch mal eine Anregung...

wird z.B. eine Batteriewarnung ausgelöst, dann habe ich folgende Readings:

level0 warning.Battery.low

und

short Test-Batterie - Device Nr. 1: Batterie - warnung

wird jetzt ein weiterer Alarm z.B. auf Level 1 ausgelöst, dann wird 'short' mit dem Namen des Auslösenden Devices samt neuem Message Part I und II überschrieben. Bei manchen Warnungen würde ich gerne den Alarm auf dem jeweiligen Level zurücksetzten, falls das auslösende Device z.B. den Batterie Status von low auf ok zurück wechselt; z.B. nach dem Austausch der Batterie. Das aber auch nur wirklich dann, wenn es das auslösende Device gewesen ist. Dazu benötigt man aber auch Informationen zum Device die nicht überschrieben werden können.

Besteht die Möglichkeit neben dem level 0..7 noch zusätzliche Informationen zum Device pro Alarm Level zu speichern? Im Grunde könnte man natürlich auch level 0..7 direkt mit dem Device Namen füllen, nur müsste man dann für jedes Device einen eigenen Device-Detector erstellen.

Gruß!

Prof. Dr. Peter Henning · 09 Juni 2015, 04:30:43

Andersherum denken.

Ich habe diverse Watchdogs laufen, um Devices (oder Batterielevel) zu überwachen. Alle wirken sie gemeinsam auf einen dummy-Alarmsensor "Device.warn" ein, und dieser löst den Alarm Level 3 aus.

Es gibt ferner einen dummy-Alarmactor "Device.action", der in Level 3 den $EVENT übergeben bekommt. Die ausgelöste Aktion ist der Aufruf einer Perl-Prozedur, die dann z.B. je nach Gerät eine andere Warnungsmeldung auf das Tablet ausgibt.

Das Alarm-Modul ist also nur die Spinne in der Mitte des Netzes.

LG

pah

DerFrickler · 09 Juni 2015, 13:04:22

beim watchdog besteht nur leider das Problem für jedes Device ein watchdog zu definieren.

Aber jetzt mal grundsätzlich zur watchdog Lösung... wie funktioniert das genau? Das ist dann mein erster Ausflug in die Definition des watchdog.

Wenn ich ein watchdog definiere z.B. wie folgt

define TEST watchdog <Device>.battery.low 00:05:00 <Device>.battery.ok <Trigger battery Event>

würde, für den Fall dass 5 Minuten nachdem am Device eine schwache Batterie gemeldet wurde, erneut geprüft ob die Batterie weiterhin schwach ist und eventuell ein Event bezüglich der Batterie angestoßen?

Gruß!

Prof. Dr. Peter Henning · 09 Juni 2015, 20:45:06

Oh sorry, mit Watchdog ist nicht notwendigerweise eine Instanz des Watchdog-Moduls gemeint.

Für Batterien geht das viel einfacher

Code Auswählen


#-- Batteriewarnung alle Geräte
define LBatt.N notify .*:[Bb]attery.*[Ll]ow.* set LBatt.warn $NAME
attr LBatt.N group deviceDetector
attr LBatt.N room Alarm

define LBatt.warn dummy
attr LBatt.warn alarmDevice Sensor
attr LBatt.warn alarmSettings alarm2,|LBatt.warn|Batt. $EVENT|on
attr LBatt.warn group deviceDetector
attr LBatt.warn room Alarm

attr AAA level2end 23:59
attr AAA level2msg schwach
attr AAA level2offact set  OWLCD line 0;;set WWW.warn no_warning;;set WZ.Gong.LED off;;
attr AAA level2onact {fhem('set OWLCD line 0 '.ReadingsVal('AAA','short',0))};;{fhem('set WWW.warn '.$defs{'AAA'}{READINGS}{'short'}{VAL})};;set WZ.Gong.LED led orangeS 255;;set WZ.Gong.MP3 playTone 52;;
attr AAA level2start 0:00
attr AAA level2xec armed

Notify setzt dummy, dummy wirkt als Alarmsensor => Alarm wird ausgelöst

LG

pah

new_rasp · 16 Juni 2015, 21:31:40

Hallo,

erst mal kurz ... echt super Modul!

Hab da aber leider ein Problem. Und zwar wollte ich mit der Fernbedienung der Keymatic das Modul bedienen. Leider senden diese einen anderen Status zurück:

CUL_HM Master_Remote battery: ok
CUL_HM Master_Remote Master_Remote_lock LongRelease
CUL_HM Master_Remote_lock LongRelease 1_96 (to EG_Haustuer)
CUL_HM Master_Remote_lock trigger: Long_96
CUL_HM Master_Remote_lock trigger_cnt: 96

Wenn ich:

Master_Remote_lock:LongRelease

bei "Notify on RegExp" konfiguriere dann wird keine Aktion ausgeführt. Mit den normalen Wandtaster funktioniert es ohne Probleme...

Prof. Dr. Peter Henning · 16 Juni 2015, 21:48:34

.* anhängen und RegExp verstehen lernen.

LG

pah

new_rasp · 16 Juni 2015, 22:14:08

Dankeschön! Da wäre ich jetzt nicht drauf gekommen!

Kurze Frage noch wegen einem Aktor. Wenn ich hier:
set OG_Treppenlicht on-for-timer 5
konfiguriere dann wird der Alarm nur einmal ausgegeben. Gibt es hier evtl auch einen Trick oder muss der Alarm abgeschaltet (cancel) werden damit der Aktor wieder auslöst?

LG

Ralli · 17 Juni 2015, 07:11:55

Zitat von: new_rasp am 16 Juni 2015, 22:14:08
Wenn ich hier: set OG_Treppenlicht on-for-timer 5 konfiguriere dann wird der Alarm bei nur einmal ausgegeben.

Diesen "Satz" habe ich bezüglich des "bei" nicht verstanden.

Zitat
Gibt es hier evtl auch einen Trick oder muss der Alarm abgeschaltet (cancel) werden damit der Aktor wieder auslöst?

Ist der Alarm einmal ausgelöst, bleibt er - logischerweise - so lange ausgelöst, bis er gecancelt oder der Kreis unscharf geschaltet wurde.

new_rasp · 17 Juni 2015, 10:04:18

@Ralli: Ach da hab ich mich verschrieben. Hätte den Satz nochmal lesen sollen!

Okay dann muss ich also den Einbruchsalarm wieder canceln damit der erneut ausgelöst werden kann. Hätte ja sein können das es hier einen Trick gibt ohne einen Dummy dafür zu verwenden z.B. bei "Set Action" vom Aktor den Alarm per Befehl zu canceln oder per Delay...

Danke für die Antwort

Ralli · 17 Juni 2015, 12:16:07

http://forum.fhem.de/index.php/topic,26893.msg213505.html#msg213505

Leinad · 27 Juni 2015, 22:09:14

Habe das Modul nun auch eingerichtet. Sehr gut!

Zwei Problemchen habe ich allerdings, bei Alarm lasse ich mir eine Pushnachricht schicken und über das System eine .wav Datei ausgeben. Wenn ich beides mit der gleichen "Verzögerung" mache, kommt nur die Pushnachricht an. Wenn ich beides nacheinander um ein paar Sekunden verzögert ausgebe, funktioniert beides?! Kann FHEM nicht zwei Befehle gleichzeitig verarbeiten?

Kann ich irgendwo einstellen, dass nicht automatisch ein "cancel" beim Setzen von "disarm" ausgeführt wird?