Diese Seite beschreibt die Konfiguration und Verwendung des Moduls 95_Alarm.pm. Weitere Hinweise dazu findet man im Buch Smart Home Hacks.

Allgemeines

Alarm
Zweck / Funktion
	Das Modul stellt eine komfortable Oberfläche bereit, um per Webinterface Sensoren mit Aktoren zu verknüpfen - und zwar nur innerhalb bestimmter Zeitfenster sowie an- und abschaltbar
Allgemein
Typ	Hilfsmodul
Details
Dokumentation	EN / DE
Support (Forum)	Unterstuetzende Dienste
Modulname	95_Alarm.pm
Ersteller	Prof. Dr. Peter A. Henning
	Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Das Modul 95_Alarm.pm stellt eine komfortable Oberfläche bereit, um per Webinterface bestimmte auslösende Elemente (nachfolgend 'Sensoren' genannt) mit bestimmten Aktionen (nachfolgend 'Aktoren' genannt) zu verknüpfen - und zwar nur innerhalb bestimmter Zeitfenster sowie an- und abschaltbar ("scharf/armed" bzw. "unscharf/disarmed"). Diese Verknüpfungen werden als "normale" FHEM-Definitionen gespeichert.

Erste Schritte

Damit FHEM-Devices als Aktoren oder Sensoren für die Alarmanlage genutzt werden können, müssen zwei neue globale Attribute namens alarmDevice und alarmSettings eingeführt werden. Dazu muss in der Grundkonfiguration von FHEM die Definition der nutzerspezifischen Attribute via userattr angepasst werden. Bei Konfiguration über FHEMWEB ist es ratsam dazu die folgenden beiden Befehle zu nutzen:

{ addToAttrList("alarmDevice:Actor,Sensor") }
{ addToAttrList("alarmSettings") }

Alternativ: Möchte man dies direkt im global device ändern, so sollten die weiteren Attribute beibehalten werden, dies sieht etwa so aus:

attr global userattr alarmDevice:Actor,Sensor alarmSettings devStateIcon devStateStyle ...(hier folgen weitere Attribute)

Zur Erläuterung:

Soll ein FHEM-Device als Sensor für die Alarmanlage genutzt werden, wird der Wert seines alarmDevice-Attributes auf 'Sensor' gesetzt.
Soll ein FHEM-Device als Aktor für die Alarmanlage genutzt werden, wird der Wert seines alarmDevice-Attributes auf 'Actor' gesetzt
Das Attribut alarmSettings wird beim Setzen der Alarme auf der Alarmkonfigurationsseite automatisch befüllt.

Ferner muss das Modul 95_Alarm.pm im Modulpfad installiert werden, ebenso die JavaScript-Datei alarm.js in www/pgm2.

Definition

Die Alarmanlage - hier mit dem Namen AAA versehen - selbst wird über

define AAA Alarm

definiert. Diese Definition legt einen versteckten Raum "AlarmRoom" an, welcher über einen Weblink im oberen Menü des Webinterfaces erreichbar ist.

Der Name dieses Raumes kann durch das Attribut hiddenRoom geändert werden.
Es wird ein weiterer Raum benötigt, der in der gegenwärtigen Fassung des Moduls den Namen Alarm trägt. Dieser wird automatisch erstellt, sobald die Alarme wie unten konfiguriert werden.
Dieses Modul verwendet das globale Attribut language zur Bestimmung der Anzeigedaten (Standard: EN=english). Für deutsche Ausgabedaten muss in FHEM das Attribut

attr global language DE

gesetzt werden. Für dieses Wiki werden die deutschen Ausgabedaten verwendet.

Beim Anklicken des Begriffes Alarmanlage im oberen Menü des Webinterfaces wird dieser versteckte Raum angezeigt. Er enthält an erster Stelle das Alarm-Device. Für die Konfiguration dieses Devices siehe den nächsten Abschnitt, für die Bedienung siehe den Abschnitt [Bedienung].

Konfiguration des Alarm-Device

Das Alarm-Device kennt nur wenige Set- und Get-Befehle.

Bedienung im FHEMWEB Frontend

In diesem Abschnitt wird die Bedienung der Weboberfläche und damit die Konfiguration der Alarmanlage beschrieben. Um sie zu erreichen, klickt man auf den Begriff Alarmanlage im oberen Menü des Webinterfaces.

Settings

Im oberen Bereich sind drei Eingabefelder zu sehen:

Wait Action ist ein FHEM-Befehl, der beim Scharfschalten des Alarms ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagt Alarmanlage wird in Kürze scharf geschaltet.
Arm Delay ist eine Verzögerungszeit, die zwischen dem Scharfschalten des Alarms und der tatsächlichen Wirksamkeit vergeht. Diese Zeit kann beispielsweise genutzt werden, um das Haus ohne Auslösung des Alarms zu verlassen.
Arm Action ist ein FHEM-Befehl, der beim Scharfschalten ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagt Alarmanlage scharf geschaltet.
Disarm Action ist ein FHEM-Befehl, der beim Unscharfschalten ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagt Alarmanlage unscharf geschaltet.
Cancel Action ist ein FHEM-Befehl, der beim Widerrufen eines Alarms ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagt Alarm widerrufen.

Achtung, das nachfolgende Bild ist nicht ganz up to date, wird demnächst ersetzt

8 Alarmlevel sind für das Modul normalerweise möglich (kann durch Setzen eines einzelnen Parameters im Modulcode verändert werden). In der Tabelle 'Settings' können für jeden Level eine Bedingung, die Startzeit ts und Endzeit te sowie die Zeit tc' für das automatische Widerrufen des Alarmlevels gesetzt werden.

Die Bedingung wird als Perl-Code eingegeben, nur wenn sie den Wert 1 ergibt, wird der Alarm ausgeführt. Will man keine zusätzliche Bedingung prüfen lassen, muss hier einfach eine 1 stehen.

Formate für die Zeitangaben können sein:

hh:mm - direkte Eingabe einer festen Zeit.
{funktion} - eine beliebige Perl-Funktion in geschweiften Klammern, die einen gültigen Zeitwert hh:mm zurückliefert. Die Gültigkeit wird erst zur Laufzeit überprüft. Beispielsweise "30 Minuten vor Sonnenuntergang" als {sunset_abs(-1800)}.

Diese Aktivierungszeiten wirken sich wie folgt auf den Alarmlevel aus:

Wenn ts < te, ist dieser Alarmlevel aktiv, falls ts < Zeit < te.
Wenn ts >= te, ist dieser Alarmlevel aktiv, falls ts < Zeit <= 23:59 sowie wenn 0:00 < Zeit <= te.

Der Alarmlevel wird automatisch nach der Zeit für den Autowiderruf widerrufen. Setzt man diese Zeit auf 0:00, erfolgt kein automatischer Widerruf.

Ferner kann für jeden Alarmlevel gesetzt oder bedient werden

Eine Nachricht zur Erläuterung des Alarms (Teil 2)
Eine Checkbox Armed = scharf
Ein Button Cancel zum Canceln = Aufheben des Alarms

Sensors

Danach wird die Tabelle der Sensoren angezeigt. Für jeden Sensor kann gesetzt werden:

Alarmlevel, die hierdurch ausgelöst werden
Ein regulärer Ausdruck, bei dessen Erkennung die Auslösung erfolgt
Eine Nachricht zur Erläuterung des Alarms (Teil 1)
Ein Selektor, um festzulegen, ob dieser Sensor den Alarm
- auslöst (=Raise),
- widerruft (=Cancel),
- scharf schaltet (=Arm) oder
- unscharf schaltet (=Disarm).

Achtung: Es ist zwingend notwendig, dass für einen auszulösenden Alarmlevel auch ein Sensor für den Widerruf (=Cancel) des Alarms definiert wird, ansonsten ignoriert das Modul die Definition dieses Levels.

Die insgesamt in den STATE der Alarmanlage geschriebene Nachricht besteht dann aus

(Anzeige der Zustände) (Nachricht Teil 1)' '(Nachricht Teil 2).

Bitte weiter unten nachlesen, was mit der Anzeige der Zustände gemeint ist. In diesen Nachrichten werden die folgenden Ersetzungen vorgenommen

$NAME vird durch den Namen des auslösenden Devices ersetzt
$EVENT wird durch den kompletten Event ersetzt
$EVTPART1... wird durch den 1. Teilstring des Events gefüllt, etc.

Actors

Anschließend wird die Tabelle der Aktoren angezeigt. Für jeden Aktor kann gesetzt werden:

Alarmlevel, die diesen Aktor starten
Ein FHEM-Kommando zum Starten des Aktors
Ein FHEM-Kommando zum Stoppen des Aktors
Eine Zeitverzögerung - entweder als Angabe von Sekunden (<60) oder im Format mm:ss

In den Strings für diese Aktionen werden folgende Ersetzungen vorgenommen:

$NAME vird durch den Namen des auslösenden Devices ersetzt
$EVENT wird durch den kompletten Event ersetzt
$EVTPART1... wird durch den 1. Teilstring des Events gefüllt, etc.
$SHORT wird durch die vollständige Kurznachricht der Alarmauslösung ersetzt

Bedienung mit anderen Frontends

Tablet-UI

Eine Anleitung, wie das Modul mittels eines Keypads über das Tablet-UI scharf und unscharf geschaltet werden kann, findet sich auf dieser Seite

Aktivierung

Durch Anklicken des Buttons Set Alarms werden die alarmSettings-Attribute befüllt. Achtung, Folgendes beachten

Es ist zwingend notwendig, dass für einen auszulösenden Alarmlevel auch ein Sensor für den Widerruf (=Cancel) des Alarms definiert wird, ansonsten ignoriert das Modul die Definition dieses Levels.
Der Button Set Alarms wird nur funktionieren, wenn keine Sperrung vorliegt, siehe unten.
Es empfiehlt sich, danach ein Save Config auszuführen, damit die Attribute und Notifier permanent sind.

Anzeige der Zustände

Auf Wunsch können die Zustände der Alarmanlage zusammen mit der konkreten Meldung im internal STATE (bzw. reading state, beide sind in diesem Modul identisch) angezeigt werden. Hierfür gibt es ein Attribut statedisplay mit den folgenden möglichen Werten, die nachfolgend am Beispiel für den Zustand "Alarm Level 1 ausgelöst" erläutert sind:

none - keine Anzeige
simple - OXOOOOOO
color - 0 1 2 3 4 5 6 7
table -

Das Problem ist, dass möglicherweise das internal STATE an anderer Stelle verwendet werden soll - z.B. beim Versenden von Mails als Value('AAA') Es macht natürlich keinen Sinn, eine HTML-Tabelle in eine Mail zu packen. Deshalb sollte für die Weiterverarbeitung statt des obigen Code die Abkürzung $SHORT in den Feldern des Alarm-Moduls verwendet werden. Sie wird vor der Ausführung ersetzt durch $defs{'AAA'}{READINGS}{"short"}{VAL} Dies enthält nur die Meldung, nicht aber die Anzeige aller Zustände.

Alternativ kann man auch die Zustandsanzeige durch Wahl des Attributwertes none komplett abstellen.

Sperrung

Das Reading lockstate muss den Wert unlocked haben, damit durch Anklicken des Buttons Set Alarms die alarmSettings-Attribute befüllt werden können. Das ist in der Regel beim ersten Laden des Moduls nicht der Fall, hierzu muss also das Reading von Hand auf den richtigen Wert gesetzt werden. Dazu muss der Befehl set ... unlocked ausgeführt werden.

Sensoren

Rauchalarm

Dieser Alarm ist mit Lebensgefahr verbunden und wird deshalb unabhängig von FHEM ausgelöst, und von FHEM nur registriert und mit weiteren Aktoren verbunden.

Im Beispiel werden vernetzte Rauchmelder des Typs HM-SEC-SD verwendet. Deren Teamleader erhalten das Attribut alarmDevice Sensor, so dass sie in der Sensorenliste der Alarmanlage auftauchen. Sie lösen den Alarm mit dem höchsten Level aus. Diese Einbindung in die Alarmanlage lässt sich aber auch für beliebige andere in FHEM eingebundene Rauchmelder erreichen.

Öffnung von Fenstern oder Türen

Dies dient der Überwachung von Zustandsänderungen, ebenso wie zur Überprüfung eines statischen Zustands

Szenarien

Kontrollrunde

Dieses Alarmszenario (Alarmlevel 4) liegt vor, wenn die Hausbewohner anwesend sind, aber irgendwann zu Bett gehen wollen und vorher noch überprüfen, ob auch alle Türen und das Garagentor geschlossen sind. Sagen wir, beginnend um 22:00 bis 23:59. Man könnte diesen Alarmlevel aber auch durch einen externen Regensensor auslösen, der die Dachfenster auf ihren Öffnungszustand untersucht. Jedenfalls sollte dieser Alarmlevel immer scharf sein.

Durch einen externen Auslöser (sagen wir, beginnend um 22:00 Uhr) wird in periodischen Abständen eine Hilfsroutine gestartet, welche die Zustandsprüfung vornimmt und registriert. Nur wenn diese Registrierung eine Öffnung ergibt, wird der Alarm ausgelöst. Dieser Alarmlevel gehört also zur Kategorie Warnung und wird deshalb nur eine moderate Signalisierung benötigen - beispielsweise

eine Sprachmeldung wird auf einem wandhängenden Tablet ausgegeben
eine Nachricht mit gelbem Hintergrund erscheint auf einem Digitalen Bilderrahmen
eine Nachricht erscheint auf einem 1-Wire_Textdisplay
eine LED geht an auf dem 1-Wire LED-Statusmonitor

Zutritt

Dieses Alarmszenario (Alarmlevel 5) liegt vor, wenn die Hausbewohner anwesend sind, aber vermutlich schlafen gegangen sind. Sagen wir, von 0:00 bis 5:00.

Wenn morgens um 4:00 die Haustür geöffnet wird, handelt es sich entweder um ein spätes Heimkommen eines Hausbewohners von einer Party - oder um einen Einbruchsversuch. Der Partygeher sollte also eine gewisse Warnungszeit bekommen, bevor ein moderater akustischer Aktor (sagen wir, ein Funkgong) losgeht. Dieser Aktor muss deshalb mit einer Verzögerung eingeschaltet werden, und der Partygeher erhält eine Warnung. Diese Warnung - sagen wir, eine bestimmte Lampe geht an - informiert ihn, dass er innerhalb von 30 Sekunden einen bestimmten Schalter betätigen muss. Etwa den für genau diese Lampe, um sie auszuschalten. Der Einbrecher kennt diesen Schalter nicht, der moderate Alarm wird also die schlafenden Hausbewohner wecken und ihn abschrecken.

Zusätzlich verfügt dieser Level auch noch über einen Partymodus: Mit diesem kann er für 24 Stunden abgestellt werden, so dass man auch um 3:00 in der Frühe die eigenen Partygäste aus dem Haus lassen kann, ohne ihn auszulösen.

Einbruch

Dieses Alarmszenario (Alarmlevel 6) liegt vor, wenn die Hausbewohner abwesend sind und diesen Level vorher scharf geschaltet haben - und idealerweise von 0:00 bis 23:59. Jeder Zutritt zu Haus löst diesen Alarm aus, und der akustische Aktor kann durchaus kräftig sein (etwa Einschalten der Rauchmelder für 1 Minute).

Da die Auslösung auch erfolgt, wenn der Hausbesitzer heimkommt, muss der akustische Aktor eine Verzögerung haben und innerhalb dieser einer Warnung gegeben werden, z.B. indem zunächst eine bestimmte Lampe angeht. Dies informiert ihn, dass er innerhalb von 30 Sekunden einen bestimmten Schalter betätigen muss. Etwa die Kombination, um diesen Alarmlevel unscharf zu schalten. Der Einbrecher kennt diese Kombination nicht, die Beleuchtung wird ihn also zunächst abschrecken und der nachfolgende laute akustische Aktor auch die Nachbarn wecken.

Zustandsänderung

Dazu werden alle überwachten Fenster- und Türkontakte mit dem Attribut alarmDevice Sensor versehen, so dass sie in der Sensorenliste der Alarmanlage auftauchen. In der Alarmkonfiguration sieht das dann so aus:

Zustandsprüfung

Dies dient der Überprüfung eines statischen Zustands, konkret ob und welche Fenster oder Türen offen sind - z.B. abends, oder bei Regenwetter. Dazu benötigen wir drei dummy Devices, von denen zwei als alarmDevice Sensor und einer als alarmDevice Actor attributiert werden und somit in der Sensoren- bzw. Aktorenliste der Alarmanlage auftauchen.

define TFOpen.warn dummy
attr TFOpen.warn alarmDevice Sensor
attr TFOpen.warn alarmSettings alarm4,|TFOpen.warn:.*[TF].*|$EVENT|on (Diese Zeile wird vom Modul 95_Alarm.pm automatisch erzeugt)
attr TFOpen.warn group windowDetector
attr TFOpen.warn room Alarm

define TFClose.warn dummy
attr TFClose.warn alarmDevice Sensor
attr TFClose.warn alarmSettings alarm4,|TFClose.warn:yes|Alle zu|off (Diese Zeile wird vom Modul 95_Alarm.pm automatisch erzeugt)
attr TFClose.warn group windowDetector
attr TFClose.warn room Alarm

define TFOpen.check dummy
attr TFOpen.check alarmDevice Actor
attr TFOpen.check alarmSettings alarm4,|{HouseOpen()}||10:00 (Diese Zeile wird vom Modul 95_Alarm.pm automatisch erzeugt)
attr TFOpen.check group windowDetector
attr TFOpen.check room Alarm

Als nächstes muss eine Überwachungsroutine geschrieben werden. Das kann entweder als FHEM-Skript geschehen, oder in der Datei 99_myUtils.pm als perl-Code. Dieses Unterprogramm muss

den obigen dummy TFOpen.warn setzen, und zwar auf den oder die Namen der geöffneten Fenster und Türen oder "none", wenn keine geöffnet sind.
den obigen dummy TFClose.warn setzen, und zwar auf den Wert "no", wenn irgendeine geöffnet ist und "yes", wenn keine geöffnet sind.

Ein Beispiel für eine solche Überwachungsroutine ist weiter unten zu sehen.

Diese Doppelung ist nötig, weil jeder Sensor nur mit einem notify in den Alarmen auftauchen kann - das dient der Sicherheit gegen Fehlkonfiguration und ist beabsichtigt.

In dem nebenstehenden Flussdiagramm wird der Ablauf dargestellt, der sich mit diesem System ergibt. Dabei wird um 22:00 der erste Test auf ein ordnungsgemäß geschlossenes Haus gestartet - und bis Mitternacht alle 10 Minuten wiederholt. Alternativ könnte man das auch mit einem Regensensor als Erstauslöser koppeln.

Beispielcode für eine Überwachungsroutine:

sub HouseOpen()
{
 my $kfo = 0;
 my $kfs = "";
 my $kto = 0;
 my $kts = "";
 my $str = "";
 if( $main::value{'BK.F'} ne "Closed" ){
   $kfo++;
   $kfs = "BK/";
 }
 if( $main::value{'WK.F'} ne 'Closed' ){
   $kfo++;
   $kfs = $kfs."WK/";
 }
 if( $main::value{'VK.T'} ne "Closed" ){
   $kto++;
   $kts = "VK/";
 }
 if( $main::value{'WZ.T'} ne 'Closed' ){
   $kto++;
   $kts = $kts."WZ/";
 }
if( ($kfo >= 1) && ($kto == 0) ){
   $kfs = substr($kfs,0,-1);
   fhem("define TFOpen.delay at +00:00:30 set TFOpen.warn $kfs Fenster"); 
   fhem("define TFClose.delay at +00:00:30 set TFClose.warn no");
 }elsif( ($kfo == 0) && ($kto >= 1) ){
   $kts = substr($kts,0,-1);
   fhem("define TFOpen.delay at +00:00:30 set TFOpen.warn $kts Tür"); 
   fhem("define TFClose.delay at +00:00:30 set TFClose.warn no");
 }elsif( ($kfo >= 1) && ($kto >= 1)){
    $kts = substr($kts,0,-1);
    $kfs = substr($kfs,0,-1);
    $str = "$kts Tür + $kfs Fenster";
    fhem("define TFOpen.delay at +00:00:30 set TFOpen.warn $kts T / $kfs F");
    fhem("define TFClose.delay at +00:00:30 set TFClose.warn no");
 }else{
    fhem("set TFOpen.warn none");
    fhem("set TFClose.warn yes");
 }
return $str;
}

Batterie schwach bei FHEM-Devices

Dieser Sensor besteht aus einem notify und einem dummy, der bei einer 'battery low'-Meldung eines beliebigen FHEM-Device auf dessen Namen gesetzt wird. Der dummy wird als alarmDevice Sensor attributiert, so dass er in der Sensorenliste der Alarmanlage auftaucht.

define LBatt.N notify .*:[Bb]attery.*[Ll]ow.* set LBatt.warn $NAME
attr LBatt.N room Alarm
attr LBatt.N group deviceDetector

define LBatt.warn dummy
attr LBatt.warn alarmDevice Sensor
attr LBatt.warn room Alarm
attr LBatt.warn group deviceDetector

Auf einen Test, ob gleichzeitig bei anderen FHEM-Devices die Batterie ebenfalls schwach ist, wird hier verzichtet. Für diesen Sensor wird ein eigener Alarmlevel (niedriger Priorität) erzeugt. Bei einem beliebigen 'battery low' Event wird somit der STATE der Alarmanlage gesetzt auf Batt. <devicename> schwach. Dieser Alarm muss manuell zurückgesetzt werden (schließlich sollten die Batterien ja erst gewechselt werden...)

Aktoren

Aktoren können natürlich real existierende Devices sein. Man kann aber auch einfach Dummy-Devices anlegen und ihnen das Attribut alarmDevice Actor geben. Bei beiden Arten von Aktoren kann man dann als Aktion

real existierende Devices schalten,
ein Perl-Unterprogramm aufrufen oder
einen Dummy auf einen bestimmten Wert setzen. Das löst einen Event aus, den man z.B. mit einem notify abfangen kann (eher umständlich...), oder der auf einer entfernten FHEM-Instanz mit FHEM2FHEM registriert wird.

Nachfolgend drei Beispiele

Rauchmelder als Alarmsignal

Für Alarme, bei denen es wirklich auf schnelle Reaktionen ankommt, kann man auch Rauchdetektoren verwenden, die über Funk aktivierbar sind. Im Beispiel werden vernetzte Rauchmelder des Typs HM-SEC-SD verwendet.

Achtung: Es ist sehr empfehlenswert, diesen Alarm auch wieder automatisch auszuschalten.

Dazu wird ein dummy erzeugt und mit alarmDevice Actor attributiert, so dass er in der Aktorenliste auftaucht:

define SD.alarm dummy
attr SD.alarm alarmDevice Actor
attr SD.alarm alarmSettings alarm7,|set TH.SD0 alarmOn|set TH.SD0 alarmOff|30 (Vom Modul 95_Alarm.pm automatisch erzeugt)
attr SD.alarm group alarmActor
attr SD.alarm room Alarm

In der Alarmkonfiguration sieht das dann so aus:

Funk-Türgong / MP3-Türgong als Alarmsignal

Hier wird ein FS20-Türgong als akustisches Alarmsignal verwendet.

define WZ.Gong FS20 <adresse>
attr WZ.Gong IODev CUL
attr WZ.Gong alarmDevice Actor
attr WZ.Gong alarmSettings alarm5,alarm6,|set WZ.Gong on||30 (Vom Modul 95_Alarm.pm automatisch erzeugt)
attr WZ.Gong group alarmActor
attr WZ.Gong room Alarm,Erdgeschoss

In der Alarmkonfiguration sieht das dann so aus:

Bei Verwendung eines MP3-Funkgongs (z.B. aus dem Homematic-Programm) kann man auf diesem eine ganze Menge verschiedene MP3-Dateien speichern, die z.B. Stimmenmeldungen "Alarmanlage scharf geschaltet" abgeben. Zur Erstellung dieser Meldungen hat es sich bewährt, einen kostenlosen Online-TTS (Text-to-Speech) Service zu nutzen, z.B. Ivona.

Alarmierung per SMS

Für Alarme, die man auch im Urlaub auf das Handy bekommen möchte, bedarf es natürlich eines Providers, der eine bestimmte Mailadresse als SMS weiterleitet. Ferner einer FHEM-Konfiguration, die Mails versenden kann. Dann wird ein dummy erzeugt und mit alarmDevice Actor attributiert, so dass er in der Aktorenliste auftaucht. Die Abkürzung $SHORT wird vor der Ausführung durch die Kurzbeschreibung des Alarms ersetzt.

define Mail.alarm dummy
attr Mail.alarm alarmDevice Actor
attr Mail.alarm alarmSettings alarm6,alarm7,|{DebianMail(<mailadresse>,'Alarm','$SHORT'}||30 (Vom Modul 95_Alarm.pm automatisch erzeugt)
attr Mail.alarm group alarmActor
attr Mail.alarm room Alarm

In der Alarmkonfiguration sieht das dann so aus:

Links

Forenthread