Neues Modul für Alarmanlage

[jmike]

Das die arm-Action doppelt ausgeführt wird, habe ich auch.

Hab mal etwas rein geschaut. Bei dem AT alarm0.arm.dly welches die Aktionen ausführt, werden nicht nur die FHEM Befehle ausgeführt, sondern noch zusätzlich eine Perl Routine namens Alarm_Arm() ausgeführt.

Ich habe in meinem Playground mal zwei dummys befüllen lassen durch die Arm Aktion, da sieht das vollständige AT dann so aus:

Code Auswählen Erweitern

{Alarm_Arm("AAA",0,"web","delay","arm");fhem("set alarmStatus armed");fhem("set dummy good");}

Wenn ich nun

Code Auswählen Erweitern

{Alarm_Arm("AAA",0,"web","delay","arm");} in der FHEM Befehlszeile ausführe, werden wieder meine 2 Dummies gesetzt.
Also führt das AT die Aktionen 1x direkt aus und nochmals über die Alarm_Arm() Routine.

Ob nun die Routine oder die einzelnen FHEM Befehle korrigiert werden müssen, kann pah am besten sagen.
Fakt ist, wenn man jenes defmod, welches das AT erstellt, entsprechend manipuliert (entweder Alarm_Arm() oder $cmdactf rauswirft) läuft es nur 1x.

Lg
mike

[ChrisW]

sonst hat keiner ein Problem das die Alarmverzögerung der einzelnen Aktoren nicht funktioniert ? Ich habe rein gar nichts angepasst an meinen Einstelungen das lief nun seit ca. 1 Monat gleich.

[jmike]

@ChrisW.
Du meinst das, was derzeit unter "Verzögerung [hh:]mm:ss" eingetragen wird?
Das läuft bei mir wie erwünscht (4.01).

Beispiel aus dem Eventmonitor:

Code Auswählen Erweitern

2018-01-26 08:50:35 dummy alarmStatus armed                    << SCHARF
2018-01-26 08:51:42 dummy dummy on                             << Sensor löst Alarm Level 0 aus
2018-01-26 08:51:42 at alarm0dly1 Next: 08:51:57               << Modul erstellt AT zum auslösen des Aktors
2018-01-26 08:51:42 Global global DEFINED alarm0dly1
2018-01-26 08:51:57 dummy einbruch_d alaaaarm                  << Aktor wird ausgelöst, mit den definierten 15sek delay

[Prof. Dr. Peter Henning]

@jmike: Sieh an, da ist wirklich ein logischer Fehler, ich habe die FHEM-Kommandos wirklich 2x ausführen lassen.

Ist in der neuesten Version 4.02 behoben, wird in wenigen Minuten eingecheckt.

LG

pah

[jmike]

Gerade 4.02 vom SVN geholt. Confirmed, Arm Aktion wird nur noch 1x ausgeführt (@ Clyde12345, ChrisW, exciter).

Danke für den Instand-fix

@ChrisW, müssen wir noch rausfinden warum bei dir kein Delay geht.
Check doch mal deinen Eventmonitor und die erstellten AT devices und deren definition.

[ChrisW]

Hallo,
danke werde ich machen wenn ich heute abend zuhause bin.
Habe aber gerade folgende Warnungen keine Fehler im Log gefunden kann ich aber nicht viel mit anfangen

Code Auswählen Erweitern

2018.01.26 10:38:09 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/95_Alarm.pm line 1138.
2018.01.26 10:38:09 3: eval: {Alarm_Html("AAA")}
2018.01.26 10:38:09 1: PERL WARNING: Use of uninitialized value $sizep in concatenation (.) or string at ./FHEM/95_Alarm.pm line 1138.
2018.01.26 10:38:09 3: eval: {Alarm_Html("AAA")}
2018.01.26 10:38:09 1: PERL WARNING: Use of uninitialized value $name in substitution (s///) at ./FHEM/95_Alarm.pm line 1140.
2018.01.26 10:38:09 3: eval: {Alarm_Html("AAA")}
2018.01.26 10:38:09 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4178.
2018.01.26 10:38:09 3: eval: {Alarm_Html("AAA")}
2018.01.26 10:38:09 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/95_Alarm.pm line 1163.
2018.01.26 10:38:09 3: eval: {Alarm_Html("AAA")}
2018.01.26 10:38:09 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/95_Alarm.pm line 1164.
2018.01.26 10:38:09 3: eval: {Alarm_Html("AAA")}
2018.01.26 10:38:09 1: PERL WARNING: Use of uninitialized value $val in string eq at ./FHEM/95_Alarm.pm line 1189.
2018.01.26 10:38:09 3: eval: {Alarm_Html("AAA")}
2018.01.26 10:38:09 1: PERL WARNING: Use of uninitialized value $val in string eq at ./FHEM/95_Alarm.pm line 1191.
2018.01.26 10:38:09 3: eval: {Alarm_Html("AAA")}
2018.01.26 10:38:09 1: PERL WARNING: Use of uninitialized value $val in string eq at ./FHEM/95_Alarm.pm line 1193.
2018.01.26 10:38:09 3: eval: {Alarm_Html("AAA")}
2018.01.26 10:38:10 1: Error: >< has no TYPE, but following keys: >READINGS<

[jmike]

Hallo,
danke werde ich machen wenn ich heute abend zuhause bin.
Habe aber gerade folgende Warnungen keine Fehler im Log gefunden kann ich aber nicht viel mit anfangen

Check mal ob du einen Aktor oder einen Sensor definiert hast, der in keinem Level aktiv ist.

[ChrisW]

Ne überall ist etwas ausgewählt. Diese meldung kann ich bisher auch nicht reproduzieren.. komisch

[Prof. Dr. Peter Henning]

Ich tippe mal, dass bei der Transformation des alten Speicherformates in das neue Speicherformat etwas schiefgelaufen ist.

Bitte

a.) alle Parameter im Webinterface überprüfen und
b.) "Parameter setzen"

LG

pah

[jmike]

Ich habe mir den Logeintrag " Error: >< has no TYPE, but following keys: >READINGS<" mal genauer angesehen.

Der Eintrag wird direkt aus der fhem.pl gemacht. Ursache dafür ist ein Devices ohne Namen und TYPE, welches aber Readings hat.
Auf meiner Suche habe ich mir das Device ($hash) mal genauer angesehen.

Inhalt (direkt in der fhem.pl):

Code Auswählen Erweitern

$VAR1 = \{
            'READINGS' => {
                            'level0' => {},
                            'level1' => {},
                            'level2' => {},
                            'level3' => {},
                            'level4' => {},
                            'level5' => {},
                            'level6' => {},
                            'level7' => {}
                          }
          };

=> 95_Alarm.pm

Habe mich dann durchs Modul gehangelt und die Ursache gefunden.
In Alarm_widget() verbleibt $name leer. In $FW_webArgs ist nur der room drin und der anschliessende deconstruct aus $arg klappt nicht.

$arg hat bei mir:

Code Auswählen Erweitern

2018.01.26 14:21:48 1: arg $VAR1 = \'name=AAA&gstate=mixed&dstate=&size=60x80';

Damit gibt die Regex (v4.02 Line 1118) ^name=(\w*)&gstate=(.+)&dstate=(.+)&size=(\d+x\d+) leider gar keine matches zurück.
Grund dafür ist offensichtlich dass dstate im $arg leer ist.

Ändere ich die Regex auf ^name=(\w*)&gstate=(.+)&dstate=(.*)&size=(\d+x\d+) klappt auch der Rest.


Lustig ist, nun wird auch die kleine Glocke gelb. Das leere Device und die Fehlermeldung sind bei mir nun weg.

Ich weiß allerdings nicht warum dstate anscheinend bei manchen leer ist, und ob gstate auch besser auf (.*) matchen sollte.
Hoffentlich kann @pah damit was anfangen und diese Art des Input nicht gänzlich unerwünscht

Lg
mike



edit: Wo ich gerade dabei bin @pah auf die Nerven zu gehen..
Ich habe die Ursache für die merkwürdige Javascript Meldung gefunden.
Wenn ich in der alarm.js auf Zeile 13 anstatt

Code Auswählen Erweitern

areq.open('GET', document.location, false);
=>

Code Auswählen Erweitern

areq.open('GET', document.location.href, false);

verwende, bekomme Ich keine Fehlermeldung.
Bin mir unsicher ob an der Stelle wirklich das ganze Objekt benötigt wird oder nur das href, document.location scheint mir allerdings eh deprecated zu sein.
Ob und wie das ins SVN wandert bleibt natürlich Ihnen überlassen. Im Zweifel passe ich nach updates halt meine alarm.js an.

Lg^2

[Prof. Dr. Peter Henning]

Oh, ich habe gar keine Probleme damit, dass jemand meinen manchmal etwas genialischen Code verbessert (Fußnote: Auf den Keks gehen mir nur feature requests von Leuten, die selber noch nichts geleistet haben...)


Die Lösung mit document.location habe ich hierher: https://stackoverflow.com/questions/220231/accessing-the-web-pages-http-headers-in-javascript

Bevor ich die vorgeschlagene Änderung übernehme, würde mich interessieren, ob es bei anderen immer noch funktioniert, wenn wir in Codezeile 13  einsetzen

Code Auswählen Erweitern

req.open('HEAD', document.location.href, false);

Betreffend die Regexp: Die wird ja gar nicht benötigt, wenn das nicht ohne webargs aufgerufen wird. Ist mir nicht klar, wieso das zu einer solchen Fehlermeldung führt - aber gut, ich probiers mal aus, das ist auch unschädlich (wobei ich diese Fehlermeldung gar nicht habe ...)

Ach ja: Die "lustige kleine Glocke" soll dann gelb sein, wenn nicht alle im Attribut iconmap aufgelisteten Alarmlevel scharf sind. Sonst ist sie weiß (unscharf), grün (scharf) oder rot blinkend (alarmiert). Das Attribut iconmap regelt also, welchen Alarmleveln die "lustige kleine Glocke" folgt. Ich seh schon, ich muss dringend mal an der Wiki-Doku arbeiten.


LG

pah

[jmike]

Hallo.

Hört sich alles gut an.
Wie gesagt, warum in den $FW_webArgs keine "name" drin ist, ist mir auch unklar. Dennoch scheint es ja bei mehreren so zu sein.

Zu der Glocke, die war bisher bei mir nur Grau - bis zum fix von $name bzw. der Regex. Die dürfte also bei den Usern mit "no TYPE" Logeinträgen auch Grau sein.
Lustig fand auch nur die Verkettung von Logeintrag->namenloses-device->Glocke - nicht die Glocke selbst
Seit dem Fix war sie Gelb - weil 1 Level bei mir immer scharf ist nehme ich an.
Dank dem Tip mit dem iconmap, welches Ich nun auf die Level für Haustüre & Fenster gelegt habe, macht die Glocken Farbe nun richtig Sinn


Zum document.location noch, der Beitrag ist ja schon etwas älter.
Knapp 2 Jahre später (immer noch 7 Jahre alt) reden sie von deprecated: https://stackoverflow.com/questions/2652816/what-is-the-difference-between-document-location-href-and-document-location

...aber ich kann das selber auch nicht wirklich bewerten, Javascript ist nicht wirklich eine "Kompetenz".

Lg

[Prof. Dr. Peter Henning]

Es geht jedenfalls auch mit href, und es geht auch mit HEAD statt GET.

Der leere Name wundert mich immer noch - Zeile 1307 ruft das nämlich mit nichtleerem Namen auf.

LG

pah

[jmike]

Moment...

Zeile 1307 ruft Alarm_widget() auf, der übergeben Parameter wird ja als $arg innerhalb der Sub genutzt.
$arg ist bei mir ja auch mit name=AAA befüllt, siehe Post von 14:37.
Soweit also alles korrekt.

Alarm_widget() holt sich $name ja erst mal aus den webArgs.

Code Auswählen Erweitern

  my $name   = $FW_webArgs{name};

$FW_webArgs hat aber (bei mir) keinen key names "name". Daher ist $name danach noch leer.

Dann macht Alarm_widget() ja weiter und holt sich den Namen aus $arg. Da wäre name=AAA drin aber er scheitert an der Regex.
Also ist $name danach immer noch leer.


Entweder hatte ich das missverständlich formuliert, oder  $FW_webArgs{name} enthält bei Ihnen den Devicename - zumindest verstehe ich so ihre letzte Antwort.

[Prof. Dr. Peter Henning]

Ah, ok, da habe ich mich falsch ausgedrückt. Die RegExp geht nur dann schief, wenn $detailstate leer ist. Und $detailstate kann nur leer sein, wenn das Attribut iconmap nicht gesetzt ist.
Werde ich versuchen, abzufangen - allerdings ist das mit dem geänderten regulären Ausdruck auch in Ordnung.

LG

pah