Neues Modul für Alarmanlage

Begonnen von Prof. Dr. Peter Henning, 08 September 2014, 20:43:06

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Wird das AlarmFile korrekt gespeichert ?

LG

pah

knuthildebrandt

#1066
Hallo pah,

danke für den schnellen Hinweis. Das AlarmFILE ist leer. Ich habe auch gerade im Code die Stelle gefunden, die bei mir Probleme macht: Zeile 612, da ist die Variable $xec nicht initialisiert. Das scheint in der Zeile 595 schief zu gehen, wohl weil AlarmFILE leer ist. Ich habe gerade die Rechte auf dem AlarmFILE auch mal geändert auf 777, das bewirkt leider nichts.

Wenn ich in 612 die zweite Bedingugn $xec eq "armed" herausnehme, dann funktioniert es.
Woran könnte es liegen, dass das AlarmFILE nicht geschrieben wird?

Danke
Knut

BTW: Noch ein Nachtrag: Das FILE wird angelegt, auch wenn ich es manuell lösche. Es ist halt nur leer :-(

knuthildebrandt

Hallo pah,

ich bin wirklich nicht sehr bewandert in PERL, daher sorry, wenn das jetzt nicht wirklich korrekt ist... Ich habe aber einen Verdacht, warum das AlarmFILE leer ist:

Ich habe mit die Methode Alarm_save($) einmal angeschaut. Da wird ein $jhash0 erzeugt (JSONExport des Hashes). Der funktioniert meiner Ansicht nach nicht korrekt. Wenn ich in der Zeile das eval() weglasse, sodass Fehler durchkommen, dann erhalte ich den Fehler:

encountered object 'Sun Feb 25 18:09:21 2018', but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at ./FHEM/95_Alarm.pm line 520.

Das hört sich so an, dass auf dem Objekt die Methode TO_JSON nicht definiert ist, daher eine Umwandlung der Onjekte (Serialisierung nach JSON) nicht stattfinden kann. Warum das aber nur bei mir knallt... weiß ich nicht.

Viele Grüße
Knut

knuthildebrandt

So nun ein weiteres, letztes Mal zu dem Thema:

Ich denke ich habe den vermeintlichen Fehler gefunden. Zumindest funktioniert der JSON-Export jetzt bei mir.  Ich nutze dafür in der Funktion Alarm_save($) die FHEM-Funktion toJSON und die Datumsfunktion TimeNow(). Dann werden die Alarmzustände korrekt gespeichert und übernommen. Die Funktion sieht dann bei mir so aus:

sub Alarm_save($) {
  my ($hash) = @_;
  my $date = TimeNow();
  $hash->{DATA}{"savedate"} = $date;
  readingsSingleUpdate( $hash, "savedate", $hash->{DATA}{"savedate"}, 1 );
  my $jhash0 = toJSON($hash->{DATA});
  my $error  = FileWrite("AlarmFILE",$jhash0);
  #Log 1,"[Alarm_save] error=$error";
  return;
}


Viele Grüße
Knut

Prof. Dr. Peter Henning

ZitatWarum das aber nur bei mir knallt... weiß ich nicht.

Es steht jedem frei, seine eigene gepatchte Version zu verwenden. Allerdings werde ich keinen Code ins Modul übernehmen, um unverstandene Probleme zu lösen.

LG

pah

knuthildebrandt

Hmm, was soll ich dazu sagen. Natürlich steht es jedem frei seine Version zu patchen. Ich wollte eigentlich nur einen Beitrag leisten, um den Fehler einzugrenzen/zu analysieren.
Dass ich jetzt so abgebügelt werde... gut, dann soll das so sein. Ich bin immer noch der Ansicht, dass das der Datumswert nicht in JSON umgewandelt werden kann... daher sollte es nicht nur bei mir Probleme geben. Aber gut, wenn das nicht gewollt ist, halte ich mich zurück und patche halte meine Installation.

Beste Grüße
Knut


Prof. Dr. Peter Henning

Der "Datumswert" ist bei ca. 300 anderen Nutzern einfach ein String in einem Hash, und selbstverständlich kann dieser Hash normalerweise in eine JSON-Struktur umgewandelt werden. Wie man übrigens wunderbar an diesem frischen Beispiel sieht:
{"armstate":{"level2":"armed","level4":"disarmed","level7":"armed","level5":"disarmed","level1":"disarmed","level0":"disarmed","level6":"disarmed","level3":"armed"},"savedate":"Fri Feb 23 17:34:23 2018"}
Gerade eben erstellt mit
configDB fileshow AlarmFILE

LG

pah

mumpitzstuff

Ich habe bezüglich meines Problems mit dem offenen Fenster noch mal etwas rumprobiert und hoffe das Folgendes funktioniert:

Ich habe in der myUtils eine Funktion erstellt, die mir hoffentlich die Notifications für vergessene Fenster temporär deaktiviert, so dass meine Sirene nicht unbeabsichtigt los geht. Ich hab's bisher nur kurz getestet und bin noch nicht ganz sicher ob es im realen Betrieb funktioniert.

sub alarmSuppression($)
{
  my ($param) = @_;
 
  foreach my $device (devspec2array("FENSTER_.*"))
  {
    if (('enable' eq $param) && ('open' eq ReadingsVal($device, 'state', '')))
    {
      fhem("attr $device do_not_notify 1");
    }

    if (('disable' eq $param) && (1 == AttrVal($device, 'do_not_notify', 0)))
    {
      fhem("deleteattr $device do_not_notify");
    }
  }
}


Bei der Warteaktion trage ich dann folgendes ein und warte danach 5 Sekunden:

{alarmSuppression('enable')}

Bei der Unscharf Aktion dann noch folgendes eintragen:

{alarmSuppression('disable')}

Dadurch ist dann nur der Alarm des einen Fensters deaktiviert, welches ich eventuell vergessen habe. Bewegungsmelder usw. werden dann trotzdem scharf geschaltet.

Depechem

Eine Frage,
ich nutze Alarm 7 als Rauchalarm.

Dieser soll natürlich immer aktiv sein.
Alle HM-Rauchmelder sind als Sensoren mit Wirkung "Auslösen" im Modul eingebunden Rauch_Thomas_Buero:smoke-Alarm_.*
weiterhin ist ein Sensordummy für Alarm7 als Alarmwiderruf aktiv.

Bis jetzt habe ich den Alarm7 immer auf der Modulseite einmalig im Button (Schärfen / Armed) aktiviert und das Häkchen war eigentlich immer drin.
Nun ist mir mal aufgefallen das der Haken nach einem "Sve fhem.cfg raus ist.

wie kann ich sicher gehen das der Alarm7 immer aktiv ist?
Meine Alarmanlage dagegen wird per HM-Schlüsselschalter aktiviert/deaktivert.

LG Thomas
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...

oldman

Auch eine Frage:
Nach Betätigen des 'Set Parameters'-Buttons hat die Sensor-/Aktor-Tabelle das Aussehen von Bild1.
Nach Seitenrefresh oder Raumwechsel ist alles ok entsprechend Bild2.
Stört nicht weiter. Meine Frage ist nur, ob ich evtl. etwas falsch eingetragen habe.
Es gibt Einträge im Logfile, die ich mir nicht erklären kann:
2018.03.03 17:08:53 1: [Alarm_widget] name= gstate=disarmed dstate=-------- sizep=
2018.03.03 17:08:54 1: [Alarm_widget] name= gstate=disarmed dstate=-------- sizep=
2018.03.03 17:08:55 1: Error: >< has no TYPE, but following keys: >READINGS<

oder so etwas nach Server-Neustart:
2018.03.03 12:31:52 3: [MeineAlarmanlage V3.12] Added hidden room 'AlarmRoom' to WEB_192.168.178.22_51789
2018.03.03 12:31:52 3: [MeineAlarmanlage V3.12] Added hidden room 'AlarmRoom' to WEB_192.168.178.22_51791
2018.03.03 12:31:52 3: CUL_HM set Gong statusRequest
2018.03.03 12:31:53 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/95_Alarm.pm line 1087.
2018.03.03 12:31:53 1: PERL WARNING: Use of uninitialized value $sizep in concatenation (.) or string at ./FHEM/95_Alarm.pm line 1087.
2018.03.03 12:31:53 1: [Alarm_widget] name= gstate=disarmed dstate=-------- sizep=
2018.03.03 12:31:53 1: PERL WARNING: Use of uninitialized value $name in substitution (s///) at ./FHEM/95_Alarm.pm line 1089.
2018.03.03 12:31:53 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4154.
2018.03.03 12:31:53 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/95_Alarm.pm line 1112.
2018.03.03 12:31:53 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/95_Alarm.pm line 1113.
2018.03.03 12:31:53 1: PERL WARNING: Use of uninitialized value $val in string eq at ./FHEM/95_Alarm.pm line 1138.
2018.03.03 12:31:53 1: PERL WARNING: Use of uninitialized value $val in string eq at ./FHEM/95_Alarm.pm line 1140.
2018.03.03 12:31:53 1: PERL WARNING: Use of uninitialized value $val in string eq at ./FHEM/95_Alarm.pm line 1142.
2018.03.03 12:31:53 3: CUL_HM set HM_Empf11 statusRequest
2018.03.03 12:31:54 1: [Alarm_widget] name= gstate=disarmed dstate=-------- sizep=
2018.03.03 12:31:54 1: Error: >< has no TYPE, but following keys: >READINGS<

Depechem

#1075
Hi, ich muss noch einmal Fragen da ich große Probleme mit dem scharfschalten des Moduls habe.

nach einem "shutdown restart" sind alle eigentlich vorher scharfgeschalteten Level wieder unscharf.
Ich dachte mal gelesen zu haben das in einer Modul Version mal etwas eingebaut wurde das die Levels nach dem Neustart beibehalten werden.

Jetzt habe ich etwas von einem "AlarmFile" gelesen. Scheinbar wird in dieses der letzte Stand vor dem restart gespeichert. Richtig!?
Das Alarm Modul lief jetzt 2 Jahre lang und ich habe nichts außer die Updates verändert.

Im Forum finde ich auch keine Anleitung oder Infos zu dem "AlarmFile"

folgende Fehlermeldungen fliegen bei mir im Log ein.
2018.03.06 10:25:13.644 1: PERL WARNING: Use of uninitialized value $xec in string eq at ./FHEM/95_Alarm.pm line 612, <GEN329> line 1.
2018.03.06 10:25:13.753 1: PERL WARNING: Use of uninitialized value $xval in string eq at ./FHEM/95_Alarm.pm line 1356, <GEN329> line 1.
2018.03.06 10:25:15.076 1: PERL WARNING: Use of uninitialized value $xval in string eq at ./FHEM/95_Alarm.pm line 1356, <GEN347> line 1.
2018.03.06 10:25:20.096 1: PERL WARNING: Use of uninitialized value $xec in string eq at ./FHEM/95_Alarm.pm line 612, <GEN379> line 1.
2018.03.06 10:25:20.208 1: PERL WARNING: Use of uninitialized value $xval in string eq at ./FHEM/95_Alarm.pm line 1356, <GEN379> line 1.
2018.03.06 10:30:22.114 1: PERL WARNING: Use of uninitialized value $xval in string eq at ./FHEM/95_Alarm.pm line 1356, <GEN863> line 1.
2018.03.06 10:30:22.820 1: PERL WARNING: Use of uninitialized value $xval in string eq at ./FHEM/95_Alarm.pm line 1356, <GEN866> line 1.
2018.03.06 10:33:39.557 1: PERL WARNING: Use of uninitialized value $xec in string eq at ./FHEM/95_Alarm.pm line 612, <GEN28> line 2.


LG Thomas
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...

knuthildebrandt

Hallo Thomas,

willkommen im Club. Leider sind wir keine 300, sondern nur 2. Du scheinst ähnliches "Problem", wie ich zu haben.

Du kannst ja mal den Code-Vorschlag von mir vom 25.02. 20:21 ausprobieren. In der Funktion Alarm_save($) einfach die Zuweisung für my $date ändern in
my $date = TimeNow();

Das AlarmFile befindet sich im fhem-Verzeichnung bzw. in der configDB. Bei mir war das leider immer leer (habe keine ConfigDB). Korrekt sollte das ein JSON-String drin stehen.

Viele Grüße
Knut

Depechem

Zitat von: knuthildebrandt am 06 März 2018, 10:43:37
Hallo Thomas,

willkommen im Club. Leider sind wir keine 300, sondern nur 2. Du scheinst ähnliches "Problem", wie ich zu haben.

Du kannst ja mal den Code-Vorschlag von mir vom 25.02. 20:21 ausprobieren. In der Funktion Alarm_save($) einfach die Zuweisung für my $date ändern in
my $date = TimeNow();

Das AlarmFile befindet sich im fhem-Verzeichnung bzw. in der configDB. Bei mir war das leider immer leer (habe keine ConfigDB). Korrekt sollte das ein JSON-String drin stehen.

Viele Grüße
Knut

Hallo Knut,
vielen Dank dafür nun geht es alles wieder.
- in das AlarmFile wird geschrieben
- nach einem restart bleiben alle Level jetzt scharf

Zitat von: Prof. Dr. Peter Henning am 26 Februar 2018, 11:41:16
Allerdings werde ich keinen Code ins Modul übernehmen, um unverstandene Probleme zu lösen.

LG

pah

Hallo pah,
kannst du bitte noch eine Hilfelstellung geben, zwar funktioniert es jetzt mit Knut seiner .pm Änderung aber nach einem Modul Update wäre das Problem wieder das gleiche.
Was mache ich als Laie falsch?

LG Thomas
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...

Wetterhexe

ZitatLeider sind wir keine 300, sondern nur 2.
tja, dann heb ich auch mal die Hand, als zumindest teilweise Betroffene.

Die armed/disarmed settings der Alarmlevel werden bei mir nach "shutdown restart" zwar wiederhergestellt.
Das AlarmFILE ist allerdings leer, und in der "Alarm System" view sind die checkboxen unchecked (obwohl sie eigentlich checked sein müßten!)
In den level1-7 readings des Alarm Objekts steht jedoch der korrekte Zustand wie vor dem restart.

Ich habe Knut's Änderung an der Alarm_save eingebaut, damit funktionierts wunderbar.
Bei mir gibts auch keine configDB, möglicherweise hängts ja damit zusammen.

Depechem

Zitat von: Wetterhexe am 06 März 2018, 14:15:53
Die armed/disarmed settings der Alarmlevel werden bei mir nach "shutdown restart" zwar wiederhergestellt.
In den level1-7 readings des Alarm Objekts steht jedoch der korrekte Zustand wie vor dem restart.

Ja die sind optisch wiederhergestellt, aber wenn du mal einen Alarm getestet hast, hast du gemerkt das kein Alarm ausgelößt wird, auch wenn es in den settings steht!

Zitat von: Wetterhexe am 06 März 2018, 14:15:53
Das AlarmFILE ist allerdings leer, und in der "Alarm System" view sind die checkboxen unchecked (obwohl sie eigentlich checked sein müßten!)

Genau wie bei mir.
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...