Neues Modul für Alarmanlage

[AProfeta]

Hallo darkness,
wie hat Dir der Tipp genau weitergeholfen?

Gruß,
Adriano

Hey,

Code Auswählen Erweitern

list flur.bw.oben_Motion

hat mich auf die Richtige Spur gebracht. Ich habe den kompletten Bewegungsmelder als Sensor gesetzt. Nicht den jeweiligen Kanal. Daher wurden auch die Settings falsch befüllt.

Danke

[darkness]

Ich hatte dem Device (also dem Kompletten Bewegungsmelder) das Attribut alarmDevice Sensor zugewiesen. In dem Alarmmodul habe ich aber nur den Kanal "Motion" des Bewegungsmelders ausgewertet.
Das hat dazu geführt, dass das die alarmSettings für den Bewegungsmelder gesetzt wurden. Nicht aber für den jeweiligen Kanal.

Es muss also der jeweilige Kanal als Sensor eingerichtet werden (was im nachhinein auch logisch ist )

Aufgefallen ist mir dies, nachdem ich mit

Code Auswählen Erweitern

list flur.bw.oben_Motion gesehen habe, das die Attribute Sensor und AlarmSettings nicht vorhanden waren

[plin]

Kann ich nicht nachvollziehen, das sollte korrekt funktionieren.

LG

pah

Wie kann/muss ich denn die im Alarm-Interface eingegebenen Werte aus den Feldern "Message Part 1" und "Message Part 2" in meine Alarmmeldung einbauen? Das sind die Angaben die mir eigentlich fehlen.

VG Peter

[jmike]

Hi Peter.

Die Meldung in $EVENT wird aus den Texten aus Part1 und Part2 zusammengefügt.

Wenn also Level-n Message Part 2 "geöffnet" ist,
und Sensor-n Message Part 1 "Fenster" ist,

Dann wird "Sensor-n Fenster geöffnet" in $EVENT stehen.

Hilft das?

lg
mike

[plin]

Hallo Mike,

so hatte ich mir das auch gedacht. Folgende Ausgangssituation:

Devicename: "AlarmEinSchalter" (ist mein Sensor der den Alarm auslöst)
Message Part II: "Test1"
Message Part I: "Ein"
Set Section des Aktors: "set WhatsApp send 4916xxxxxxxx - $NAME - $EVENT - $EVTPART1 - $EVTPART2 -"

Wenn ich den Alarm auslöse kriege ich eine Whatsapp-Nachricht mit folgendem Inhalt
- AlarmSchalterEin - on - $EVTPART1 - $EVTPART2 -

Der Status der Alarmanlage wechselt schön brav nach "Ein Test1", also so wie ich es erwartet hätte.

Was läuft falsch?

VG Peter

[plin]

Wenn ich das Coding des 95_Alarm.pm wie folgt anpasse

Code Auswählen Erweitern


              $cmd = AttrVal($name, "level".$level."onact", 0);
              my @mgapart = split(" ",$mga);
              $cmd =~ s/\$NAME/$dev/g;
              $cmd =~ s/\$EVENT/$evt/g;
              for( my $i=1;$i<= int(@mgapart);$i++){
                 $cmd =~ s/\$EVTPART$i/$mgapart[$i-1]/g;
              }
              fhem($cmd);


kriege ich die richtige Meldung "AlarmEinSchalter on Ein Test1" geschickt.

$evt enthält nur "on", folglich ergibt das geparsed $EVTPART1="on" und $EVTPART2="".
In der Variable $mga stehen die beiden Teile Message Part I & II drin, also "Ein Test1".
Vielleicht wäre es sinnvoll die Variablen für den Actor-Command $MSGPART1 und $MSGPART2 zu benennen.

Nun ist der Autor gefragt...

VG Peter

[jmike]

Ah oke.

Ich schick mir eine iMessage aufs Handy mit Action: {imsgUs(ReadingsVal('AAA','short',''))}

korrektur:
Probier mal: {fhem("set WhatsApp send 4916xxxxxxxx -". ReadingsVal('AAA','short',''))}


Das $EVENT is natürlich das event dass vom Sensor geschickt und von der Alarmanlage ausgewertet wird - somit in meiner ersten Antwort falsch. Sorry für den Schnellschuss

[Prof. Dr. Peter Henning]

Der Autor ist hier gar nicht gefragt und mag diesen Tonfall auch nicht gerne hören. Im Reading "short" steht alles drin.

LG

pah

[plin]

Der Autor ist hier gar nicht gefragt und mag diesen Tonfall auch nicht gerne hören. Im Reading "short" steht alles drin.

LG

pah

Hallo Herr Henning,

das Statement "Nun ist der Autor gefragt..." war wohl etwas zu kurz ausgefallen und keineswegs negativ gedacht, sondern eher im Sinne von "fragen wir mal den Wissenden".

Ich taste mich langsam an das Alarm-Modul heran und habe auch nach Studium des Wikis noch keine Idee was ich beim Aktor konkret unter "Set Action" angeben muss, um die Nachricht mit detailliertem Meldungstext per WhatsApp zu versenden.

Ich hatte meinen Ansatz "set WhatsApp send 4916xxxxxxxx $NAME $EVENT $EVTPART2 $EVTPART1 $STATE" als Antwort #505 gepostet zu der Ihre Aussage im Post #506 war: "Kann ich nicht nachvollziehen, das sollte korrekt funktionieren."

Meine weiteren Versuche zeigten dann, dass im Modul zwischen dem abgreifen der "Set Action"-Variable und der Übergabe an fhem keine weitere Variablenauflösung mehr stattfindet. Das war für mich der Anlass den Autor zu fragen. Die Fragen wären

• Was sieht das Konzept vor?
• Kann/darf ich unter "Set Action" noch Variablen angeben?

Der Hinweis auf das Reading "short" mag eine Lösung sein, beantwortet aber nicht die Frage an welchen Stellen ich überhaupt eine Auflösung der Variablen $NAME, $EVENT etc. erwarten darf.

Ich habe eben die von jmike vorgeschlagene Lösung "{fhem("set WhatsApp send 4916xxxxxxxx -". ReadingsVal('AAA','short',''))}" unter "Set Action" eingetragen, die scheint aber nicht zu funktionieren. Zumindest wird das Statement nach der Speicherung nur noch verstümmelt angzeigt und es geht keine Alarmmeldung raus.

Deshalb auch hier wieder die Frage an den Autor:

• Was muss ich unter "Set Action" angeben, um das Reading "short" abzugreifen.

Falls das Coding dahingehend erweitert wird, dass auch unter "Set Action" Variablen aufgelöst werden, wäre es schön auch auf Message Part I & II zurückgreifen zu können.

VG plin

[NilsB]

@Ralli & Mike:

Vielen Dank - der Tip mit long release haut zwar für den HM-PBI-4-FM nicht hin, weil dieser kein long release sendet, aber das hat mich auf die richtige Spur gebracht: Der Sensor inkrementiert einen Counter mit zunehmender Zeit beim gedrückt halten. Somit triggere ich jetzt einfach auf folgende RegExp: EZ.vierfachTasterTuer.Btn01:Long\s1.* (Long 2, Long 3, usw. werden somit ignoriert).

Dein erstes Anliegen wird von Herrn Henning auch im Wiki behandelt, Du brauchst eine Routine die deine Sensoren prüft.

Ich habe es so gehandelt dass die Sensoren selbst eine Routine anstarten (notify) die wiederum alle Sensoren prüft.
Sollte alles zu sein, ist der Wert des Readings "armError" 0. Ansonsten steht eben drin was noch offen ist, dann darf jedoch gar nicht scharf geschaltet werden.

Zum dem Thema bin ich allerdings noch nicht weiter gekommen. Das Kapitel über Routinen im Wikieintrag von pah habe ich schon gelesen, konnte es aber vorher auch nicht auf meine Problemstellung übertragen. Zwar verstehe ich das Auslagern in die 99_myUtils.pm. Aber pah nutzt dieses Konstrukt meinem Verständnis nach, um ein eigenes Alarmlevel auszulösen, welches dann eine entsprechende Warnung für geöffnete Fenster ausgibt. Das ändert aber doch erstmal nichts am Verhalten eines anderen (höheren) Alarmlevels, oder?

Die Beschreibung deines Setups klingt genau nachdem was ich möchte, jmike. Aber woher stammt das Reading "armError"? Und wie wird von diesem die Scharfschaltung der Alarmanlage nach Druck einer Taste abhängig gemacht?

Besten Gruß
Nils

[Prof. Dr. Peter Henning]

Die Event-Variablen werden nur in der "Message Part I" ersetzt. Das wird auch so bleiben - denn nur diese Message ist vor dem zentralen "Switchboard" des Moduls angeordnet.

Meinen Post

Kann ich nicht nachvollziehen, das sollte korrekt funktionieren

muss ich demnach berichtigen - das stimmt so nicht. Ich hatte nicht mehr in Erinnerung , wie und warum ich das so gelöst hatte.

Zum "nicht funktionierenden Beispiel": Das ist eine Frage der Anführungszeichen.

Last: zusätzliche Variablen für Substitutionen sind nicht geplant.

Mein Tipp also: Komplexe Aktionen in einem eigenen Perl-Unterprogramm ablegen.

LG

pah

[plin]

Zum "nicht funktionierenden Beispiel": Das ist eine Frage der Anführungszeichen.

Nicht nur. Es gibt noch mehr Klippen:

• Das Leerzeichen zwischen dem Punkt und ReadingsVal
• 'AAA' als Name bedingt, dass die Alarmanlage auch unter diesem Namen angelegt wurde

VG plin

[jmike]

Es gibt noch mehr Klippen...

@plin:
Bin mir nicht sicher wo dein Post hingehen soll. Sollen wir das als Beschwerde auffassen? Oder vielleicht besser, geht nun alles bei dir?

Das Leerzeichen

Code Auswählen Erweitern

". ReadingVal ist sicher kein Problem. Du könntest auch

Code Auswählen Erweitern

" . ReadingVal oder

Code Auswählen Erweitern

".ReadingVal ausführen.
Alles das gleiche Ergebnis, siehe perl concatenation.

Zum Device Namen "AAA" im Beispiel... Das obliegt wohl deiner Fähigkeit jegliches Wissen im Netz umzusetzen.

Als Tip zum weiterkommen falls es noch nicht geht:
Schreibe doch den Befehl einfach mal ins Logfile mit

Code Auswählen Erweitern

{Log 1, "hier ist mein Befehl" . ReadingsVal(...)}
und poste den Output hier.

Denn noch wissen wir überhaupt nicht was tatsächlich bei dir ausgeführt wird bzw was/wo verstümmelt wird.


Grüße
Mike

[jmike]

Die Beschreibung deines Setups klingt genau nachdem was ich möchte, jmike. Aber woher stammt das Reading "armError"? Und wie wird von diesem die Scharfschaltung der Alarmanlage nach Druck einer Taste abhängig gemacht?

Hi Nils.

Uh da hat wohl ein kleines Zauberwort in meinem vorherigen Post gefehlt, nämlich "Dummy"

Also, hier ein konkreter Vorschlag:

Dummy Device anlegen:

Code Auswählen Erweitern

define ready2Arm dummy


Notify anlegen (alles was auf tuer oder fenster endet und open oder closed events schreibt):

Code Auswählen Erweitern

define fensterKontaktNtfy notify .*(tuer|fenster)+\S(open|closed)$ {checkArmState();}

checkArmState Sub in 99_myUtils bauen:

Code Auswählen Erweitern

sub checkArmState{
    my @sensors = ("Kuechenfenster","Terassentuer","GaesteWCfenster","ArbeitsZimmerfenster");
    my $msg;

    foreach my $sensorName (@sensors){
        if( ReadingsVal($sensorName,"state","unkown") eq "closed"  ){
            # Log 1, "CAS: sensor $sensorName is - ".ReadingsVal($sensorName,"state","unkown")."(closed)";
        }else{
            Log 1, "CAS: sensor $sensorName is - ".ReadingsVal($sensorName,"state","unkown");
            $msg .= "$sensorName ist offen!\n";
        }
    }
    if($msg){
         fhem("setReading ready2Arm armError $msg");
         Log 1, "CAS: not read to arm - $msg";
    }else{
         fhem("setReading ready2Arm armError 0");
         Log 1, "CAS: ready to arm..";
    }
}


Den Code habe ich etwas zurechtgeschnitten (dead-device check z.b.) um ihn auf das wesentliche zu beschränken und so Sachen wie das Array mit der "hardcoded" Devicelist kann man sicherlich besser machen (z.b. mit Attributen pro Device).

Aber nun sollte dir das Reading armError vom Device ready2Arm immer sagen was alles offen ist - oder 0 sein wenn alls zu ist.

Und jetzt kannst du dann switches, at's, Anwesenheitschecks usw. drum rum bauen.

Da ich keinen Wandtaster zum Scharf Schalten nutze (sondern eine jquery WebApp) hier als Inspiration eine Auto-Scharfschaltung für 22:00
(pushlow/pushhigh ist was selbstgebautes für pushover.)

Code Auswählen Erweitern


define autoArmAtNight at *22:00 {
    if(AttrVal("AAA","level3xec","") eq "armed"){
        pushlow('A: remain armed');
    }else{
        if(ReadingsVal("ready2Arm","armErroR","") eq "0"){
            fhem("set AAA armed 3");
            pushlow('A: autoarmed');
        }else{
            pushhigh('A: cannot arm because '.ReadingsVal("ready2Arm","armErroR",""));
        }
    }
}


Ich bin sicher dass du daraus was bauen kannst damit dein EZ.Sound dich entsprechend informiert. Auch mal einen Blick auf device type "sequence" werfen

lg
Mike
ps: Es ist ein Vorschlag, ein Beispiel oder ein Inspirationsanstoss - keine "Komplettlösung"

[Prof. Dr. Peter Henning]

Sollen wir das als Beschwerde auffassen?

Ich fasse es zumindest so auf, und sage deshalb an der Stelle nur noch: Wir sind eine freie Welt, jeder kann sich die Software schreiben, die ihm gefällt.

LG

pah