Neues Modul für Alarmanlage

[CoolTux]

Sollte sich keiner melden, kannst bitte noch versuchen ein verbose 5 Log hier ein zu stellen. Dann sollte alles zum helfen da sein.

[Prof. Dr. Peter Henning]

Lustigerweise wußte ich schon beim Schreiben der Fragen (nach Lektüre der 42 Seiten), dass ich eine Antwort, wie sie dann auch kam, zu erwarten habe. Und genau dieser Antwort galt meine Erwiderung. Entsprechend.

Na, wenn jemand hellseherische Fähigkeiten entwickelt, kann er vielleicht auch eine Glaskugel zur Suche nach seinen "Fehlern" betreiben.

LG

pah

[gamauf]

Hallo!
Für das Problem, daß nach FHEM Neustart die Alarmlevel in dem Zustand (scharf/unscharf) sind in dem sie beim letzten Speichern der FHEM Konfiguration waren (unabhängig davon ob Änderungen im Alarm-Modul oder wo anders vorgenommen wurden), habe ich folgend gelöst:

Ein notify speichert bei Änderung des Zustand (scharf/unscharf)  eines Alarmlevels den neuen Zustand als Reading "levelXlast " im Device AAA:

Code Auswählen Erweitern


define A_AlarmLevelsSave_N notify .*ATTR.*AAA.*level.*armed {my $x=$EVTPART2;; $x=~ s/xec/last/;; fhem("setreading AAA $x $EVTPART3")}
attr A_AlarmLevelsSave_N group alarmHelperDev
attr A_AlarmLevelsSave_N room Alarm

Ein Reading behält, im Gegensatz zu einem Attribut, seinen Wert bei einem Neustart auch ohne Speichern der Konfiguration

Ein zweites notify setzt nach Neustart von FHEM die "levelX" Attribute  aus den "levelXlast" Readings zurück:

Code Auswählen Erweitern


define A_AlarmLevelsReset_N notify A_AlarmLevelsReset_N:.*Server.started.* {AlarmLevelsReactivate('AAA');; Log 1, "Triggered: AlarmLevelsReactivate"}
attr A_AlarmLevelsReset_N group alarmHelperDev
attr A_AlarmLevelsReset_N room Alarm
attr A_AlarmLevelsReset_N readLog 1


dazu gehört sub in 99_myUtils.pm:

Code Auswählen Erweitern

######## Alarm Levels der Alarmanlage nach FHEM Neustart wieder auf den ursprünglichen Wert setzen. ##############
sub
AlarmLevelsReactivate
{
my $device = shift;
my $xec;
my $levelxec;
my $levellast;
for (my $i=0; $i <= 7; $i++)
{
    $levellast = "level$i"."last";
    $xec = ReadingsVal("$device", "$levellast", "disarmed");
    $levelxec = "level$i"."xec";
    fhem("attr $device $levelxec $xec");
}
}


Damit haben alle Alarmlevels nach einem Neustart wieder den Zustand den sie vor dem Neustart hatten, unabhängig davon was in der fhem.cfg gespeichert ist.


Will man statt dem Zustand vor dem Neustart einen default Zustand nach dem Neustart setzten, lässt man einfach das erste notify weg und setzt die "levelXlast " Readings manuell auf den gewünschten default Wert.
Eventuell würde ich dann diese Readings auf "levelXdefault"  (auch in der 99_myUtils.pm!) umbenennen.


Hoffe ihr könnt das gebrauchen.

LG
Rainer

[jmike]

Hi Rainer.

Interessant.
Habe bei mir dazu noch nichts umgesetzt aber könnte man nicht einfach ein save-config bei der arm- /disarm-action eintragen?
Dann wäre die config doch konsistent, auch bei Alarmlevel Änderung.

lg
mike

[gamauf]

Hi Mike!

...könnte man nicht einfach ein save-config bei der arm- /disarm-action eintragen?
...

ja, könnte man ... allerdings ziehe ich es vor Konfigurationsänderungen bewust, manuell zu speichern...

Aber das ist ja das schöne an open source Projekten, daß sich's jeder nach eigenem Geschmack und Vorlieben einrichten kann!

LG
Rainer

[my-engel]

Hallo pah,

Danke erst einmal für dein Modul Alarmanlage.
habe es vor einigen Tagen installiert und es funktioniert soweit, bis auf eine Kleinigkeit.
In den Settings konfiguriert man ja die Button´s:
Arm Button, Disarm Button, Cancel Button
mit den zugehörigen Aktionsfeldern:
Wait Action, Arm Action, Disarm Action, Cancel Action.
Ich habe die Felder belegt mit einer Funktion um eine Mail zu verschicken.
Da bei mir alles auf einer Fritzbox läuft, lautet hierfür der Befehl:
{ FB_mail('test@web.de','Meldung der Alarmanlage','Alarmanlage wird scharf geschaltet') }
dieses funktioniert auch in allen Feldern, bis auf das Feld "Arm Action".
Wenn die Alarmanlage unscharf ist und soll nun scharf geschaltet werden
versendet das Modul noch die Mail des Feldes "Wait Action" fehlerfrei und nach Ablauf des Timers
bleibt die Anlage "unscharf" und es erscheint im Log die Fehlermeldung:

Code Auswählen Erweitern

2016.09.09 12:54:49 3: [Alarm 0] will be armed from device web with event button, delay 03:00
2016.09.09 12:57:47 1: PERL WARNING: Possible unintended interpolation of @web in string at (eval 198) line 1.
2016.09.09 12:57:47 3: eval: {fhem("attr Alarmanlage level0xec armed");fhem("{ FB_mail('test@web.de','Meldung der Alarmanlage','Alarmanlage scharf geschaltet') }");}
2016.09.09 12:57:47 3: alarm0.arm.dly: Global symbol "@web" requires explicit package name at (eval 198) line 1.

das Modul stört sich im Feld "Arm Action" am "@" Zeichen der Mailadresse.
Wenn ich dieses @ weglasse geht die Alarmanlage ohne Fehlermeldung auf "scharf"
aber die Fritzbox bringt natürlich eine Unzustellbarkeitsnachricht zurück.
alle anderen "Action" Felder funktionieren mit dem Code.

vielleicht kannst du mir einen Tipp geben....

lg Uwe

[jmike]

Hi.

Hast du das @ escaped in deiner definition?

fhem("{ FB_mail('test\@web.de','Meldung der Alarmanlage','Alarmanlage scharf geschaltet') }");

[my-engel]

Hallo jmike,

danke für deine Antwort das ist die Lösung,
jetzt funktioniert es.
Ich kannte die Definition bis jetzt noch nicht.
Aber erklären kann ich es mir nicht,
dass es nur in diesem "Action Feld" so ist und nicht in den anderen...

vg Uwe

[Prof. Dr. Peter Henning]

Das halte ich auch für eine Nebelkerze, denn die Felder Wait, Arm, Disarm, Cancel werden exakt gleich behandelt.

Außerdem stört sich an dem @ nicht das Modul, sondern der Perl-Interpreter.

LG

pah

[MaxAut]

Hallo!

Gibt es eine Möglichkeit unterschiedliche Wait-, Arm- und Disarm Actions pro Level zu definieren? Ich möchte unterscheiden um beispielsweise auf einem Display die Art der Scharfschaltung (intern/extern) anzeigen zu können, oder entsprechend unterschiedliche MP3s wiedergeben ...

Liebe Grüße,
Max

[Prof. Dr. Peter Henning]

Nein, wird es auch nicht in diesem Modul.

Da die Perl-Funktionen aber jederzeit von außen aufrufbar sind, kann man das problemlos mit entsprechenden notify- oder DOIF-Devices von außen lösen. Die "internen" actions sind dann irgendetwas simples - beispielsweise Setzen eines dummies.

LG

pah

[MaxAut]

Verstanden. Schade! Danke für die Info.

Liebe Grüße,
Max

[Prof. Dr. Peter Henning]

Ich glaube, wir reden aneinander vorbei: Natürlich kann man mit unterschiedlichen Sensoren unterschiedliche Level mit Arm/Disarm/Cancel beschicken. Außerdem wird ein entsprechendes Event ausgelöst, das den Alarmlevel enthält - kann man problemlos auswerten, um eine spezifische Nachricht auszugeben.

LG

pah

[MaxAut]

Ja, tun wir, denn Deine letzte Antwort hat nichts mit meiner Frage zu tun, in welcher es um die Wait-, Arm- und Disarm- Actions, nicht aber um das Beschicken der einzelnen Level mittels Sensoren oder die ausgelösten Events ging. Die Möglichkeit das sehr einfach außerhalb des Moduls zu lösen war mir bereits vor meinem ersten Post in diesem Thread klar.

[Prof. Dr. Peter Henning]

Aber sehr wohl hat das miteinander zu tun.

LG

pah