Neues Modul für Alarmanlage

[Prof. Dr. Peter Henning]

Das Logging fehlt.

Mit dem Attributwert verbose=5 kommt da eigentlich eine ganze Menge Informationen...

LG

pah

[SGi]

Es ist das erste Mal, dass dieses Problem dabei auftaucht, insofern halte ich den Tonfall der Frage für nicht angemessen. Werde ich vielleicht irgendwann abfangen.

Ich halte den Tonfall nicht für unangemessener als Deinen - und demnach nicht für negativ, sondern wollte mir und allen anderen, denen es aufgefallen ist, mit dieser Frage unnötiges Testen und Überraschungen ersparen, falls dieses für den Endanwender inkonsistente Verhalten dem Entwickler in seiner Gänze bereits bekannt ist.

Danke.

Sven

[GG33]

Das Problem war die falsche Zeitangabe... 

Jetzt tut es! 

Hallo, ich habe versucht gemäss dem Wiki Eintag eine Alarmanlage einzurichten.
Dazu habe ich mir div. dummys erstellt und möchte dies jetzt mir den vorhanden Fensterkontakten testen. Leider funktioniert dies aber nicht!
Ich hoffe jemand kann mir auf die Sprünge helfen?! 

Grüsse
Björn

[Neitcom]

Hi,

ich verwende mehrere Sensoren auf einem gemeinsamen Alarmlevel.

Zwei Aktoren sind definiert:
a) Display (LED16): Über eine Subroutine wird  die dem Sensor zugeordnete LED aktiviert.
b) E-Mail / SMS Benachrichtigung

Dies funktioniert für die initiale Alarmauslösung gut. Wird dann aber bei bereits bestehendem Alarm eine weiterer Sensor ausgelöst, wertet das Modul dies leider nicht mehr aus.

In sub "Alarm_Exec" ist definiert:

Code Auswählen Erweitern

      #-- only if this level is armed and not yet active
      if( ($xec eq "armed") && ($xac eq "armed") )

Ich habe dies nun testweise geändert in:

Code Auswählen Erweitern

  if( ($xec ne "disarmed") && ($xac ne "disarmed") )


Damit scheine ich das gewünschte Verhalten zu erreichen:
Die Kenntnis weiterer Sensorauslösungen ist hilfreich um einen möglichen Fehleralarm einfacher als solchen zu erkennen, aber auch um die Wege eines Eindringlings nachvollziehen zu können.

Gibt es noch eine andere Lösung, ohne Änderung an der Modul-Datei? Dies ist unkomfortabel, da ich Updates künftig manuell mergen muss.

Ein Verbesserungsvorschlag:
Neue Selection-Box für jeden Alarmlevel mit zwei Optionen:
a) Auslösung der Aktoren nur bei initialem Sensor (heutiges Verhalten)
b) Auslösung der Aktoren auch bei jedem weiterem Sensor

Gruß,
Christian

[Klinki]

Hi,
Du könntest, verknüpft mit der Auslösung Deiner Alarme, dem Alarm-Anlagen-Modul ein "Cancel" schicken.

Ein Notity mit Zeitverzögerung oder so...

gruß
klinki

[Neitcom]

Hi klinki,
mit dem "cancel"  würde ich ja den Alarm beenden.  Damit würde dann leider auch die leuchtende, zum ersten Sensor gehörende LED zurückgesetzt.

Gruß,
Christian

[darkness]

Hallo,

ein einmal ausgelöster Alarmlevel wird nur durch einen höheren Alarmlevel überschrieben.

Du kannst dir ja vielleicht mal sequence anschauen.

Die Kenntnis weiterer Sensorauslösungen ist hilfreich um einen möglichen Fehleralarm einfacher als solchen zu erkennen, aber auch um die Wege eines Eindringlings nachvollziehen zu können.

Und dann?

Meiner Meinung nach solltest du Prüfen, ob der Sensor geeignet ist, diesen Alarm anzuzeigen. Ich habe z.B. einen Bewegungsmelder an der Treppe, welcher das Licht schaltet. Damit könnte ich ein Alarmlevel auslösen. Aber die Zuverlässigkeit ist eher nicht gegeben. Der arme Postbote mach ja schließlich auch nur seinen Job

Andererseits habe ich Bewegungsmelder innerhalb der Wohnung. Und wenn diese Auslösen, wenn niemand Zuhause ist, wird die Innensirene aktiviert und ich benachrichtigt.
Für mich bedeutet das dann nachschauen und weiteres veranlassen.


Sollte jemand in der Wohnung sein, wird er sich dort ja nicht lange aufhalten. Somit ist die Reaktionszeit jemanden direkt zu ertappen sehr gering.

Wenn jemand sich Zutritt verschafft hat, kannst du in der Regel den Weg auch ohne technische Hilfsmittel verfolgen...
Und du hast noch die Möglichkeit die LogFiles auszuwerten. Dann kannst du auch den Weg nachverfolgen


Änderungen am Code halte ich eher für die schlechtere Variante.

Nur so ein paar Gedanken...

Edit: Noch was ergänzt.

[Klinki]

Das stimmt natürlich.
Als "Krücke": Du könntest Dir die Auslösung des Alarms in einem Dummy merken. Auf diesen regiert dann Dein LED_Leucht_Aktor.
Dann in einen zweiten Dummy die Auslösung "merken", als Text, z.B. "BM_Küche_20170127_10:22:23".
Jeder weitere Alarm wird dann auch dort gespeichert. Damit hättest Du auch den "Weg des Einbruchs".
Dann die Anlage Canceln.
Somit bleibt dann die LED an. Sie ändert sich erst, wenn mit einem Disarm die Anlage unscharf wird.

Das klingt recht umständlich. Ich mache bei meiner Anlage aber Ähnliches mit 3 Dummies. Funktioniert gut.

Meine Alarmanlage V1 bestand ausschließlich aus Dummies und Notifys. Dort etwas zu ändern war ein Graus. Man muss halt das Beste aus dem Modul nutzen und den Rest drum herum bauen 

Wobei ich Deinen Verbesserungsvorschlag grundsätzlich gut finde. Würde ich mich auch drüber freuen.

[gamauf]

...dann würde ich, das setzen der LEDs aber gleich am Alarmmodul vorbei machen. Etwa so:
wenn alarmlevel nicht "disarmed" und sensor lößt aus dann setze LED...
weiteres notify, das bei "cancel" LEDs wieder löscht.

[Prof. Dr. Peter Henning]

Ich sehe derzeit auch keinen Bedarf zu einer Code-Änderung - die Komplexität der Oberfläche ist schon groß genug, und das Problem ist auch ganz einfach mit dem jetzigen Modul lösbar.

Sagen wir, es soll Level 4 von verschiedenen Sensoren jeweils neu ausgelöst werden. Dann definiert man einen einfachen "AutoCancel"-Dummy. Das ist ein Dummy als Alarm-Aktor, der mit Verzögerung (sagen wir 2 Sekunden) geschaltet wird. Die Schaltaktion macht aber mit dem Dummy gar nichts - sondern cancelt den Alarm Level 4 wieder. Eingetragen wird in die Weboberfläche also als "Set Action für den AutoCancel-Dummy:

Code Auswählen Erweitern

{Alarm_Exec('AAA',4,'AutoAus','dummy','off')}
Das bedeutet: 2 Sekunden nach einer Auslösung ist der Level 4 wieder scharf. Ein weiterer Aktor übernimmt dann die dauerhafte Signalisierung (er wird eben durch den Cancel-Befehl NICHT sofort zurückgesetzt).

LG

pah

[Neitcom]

Hi,
vielen Dank für die vielen Lösungsansätze.
Falls es sich vermeiden lässt, möchte ich die LED Display Steuerung aus Gründen des Aufwands nicht "um die Alarmanlage herum" programmieren.

@pah: Dein Ansatz könnte hier die passende Lösung sein, ich habe dazu aber zwei Verständnisfragen:
1) Wenn ich den Alarm wie vorgeschlagen cancel, wird doch für alle Aktoren auf Level 4 die "unset action" ausgeführt? Somit würde auch der LED Display zurücksetzt und eine evtl. zusätzlich auf dem Level befindliche Sirene ebenfalls abgestellt.

2)

[..] Ein weiterer Aktor übernimmt dann die dauerhafte Signalisierung (er wird eben durch den Cancel-Befehl NICHT sofort zurückgesetzt). [..]

Ich habe noch nicht verstanden, wie dieser weitere Aktor eingerichtet werden soll. Warum wäre dieser Aktor nicht vom Cancel Befehl betroffen? Ich bin bisher immer davon ausgegangen, das ein "Cancel" alle auf dem Level befindlichen Aktoren zurücksetzt, also die Unset Aktion ausführt.

Gruß,
Christian

[Prof. Dr. Peter Henning]

Weil er keine "unset" action hat, sondern manuell zurückgesetzt werden muss...

LG

pah

[Neitcom]

Ah, ok. Verstanden. Dann mache ich mich mich mal an die Arbeit.
Nachteil der Lösung ist allerdings, dass die "DeviceOverview" der Alarmanlage den ausgelösten Alarm dann nicht mehr anzeigt.

Gruß,
Christian

[Prof. Dr. Peter Henning]

Ich denke, das reicht jetzt. Vielleicht einfach etwas mehr über FHEM lernen, und dann erst komplizierte Lösungen stricken ?

pah

[Neitcom]

Ich denke, das reicht jetzt. Vielleicht einfach etwas mehr über FHEM lernen, und dann erst komplizierte Lösungen stricken ?

Habe ich etwas falsches gesagt? Das war wirklich nicht meine Absicht.
Vielen Dank noch einmal an alle für die Unterstützung mit Lösungsansätzen.
Auch als Anfänger lernt es sich leichter mit einer konkreten Aufgabenstellung.
Insofern reicht es mir jetzt auch (um weiterzukommen).

Nichts für ungut,
Christian