Neues Modul für Alarmanlage

[NilsB]

Sehr gut, so kommt man tatsächlich in die richtige Richtung.. Ich habe jetzt mal folgende Parameter eingerichtet:
R-mininterval: 30 Sekunden (bei 15s habe ich Sorge wegen der Funklast und der Batterielebensdauer)
Verzögerung Alarm: 61s (so bleiben die bereits bekannten 30 Sekunden erhalten)

Danke für die Hilfe beim Denken

Melde mich, falls es neuen Stoff gibt

LG und einen guten Rutsch
Nils

[Prof. Dr. Peter Henning]

Neue Version eingecheckt, mit ein paar kleinen Fixes.

LG

pah

[plin]

Hallo pah,

unter 'Sensors' werden die Devices mit ihrem Device-Namen angezeigt. Die habe ich so belassen wie sie beim Pairen angelegt wurden (also z.B. HM_471111). Die sprechenden Namen habe ich über Aliase definiert. Lassen sich die Alias- statt der Devicenamen anzeigen (sofern definiert)?

LG Peter

[Prof. Dr. Peter Henning]

Kann ich - wenn ich dran denke - in einer der nächsten Versionen einbauen.

LG

pah

[birdy]

Hallo zusammnen

Eventuell kann mir hier jemand einen Tipp geben. Ich verwende einen HM-RC-Sec4-2 und versuche damit die Alarmanlege ein/aus bzw. scharf/unscharf zu schalten.

Das Ziel: Sowohl mit Button 1 wie auch mit Button 2 soll man die Anlage scharf schalten können.
,,Set Alarms" generiert mir dann den folgenden alarmNotifier

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        (HM_30634D_Btn_01:Shot)|(HM_30634D_Btn_02:Short) {main::Alarm_Arm("AA",6,"$NAME","$EVENT","arm")}
   NAME       alarm6.arm.N
   NOTIFYDEV  HM_30634D_Btn_01,HM_30634D_Btn_02
   NR         501
   NTFY_ORDER 50-alarm6.arm.N
   REGEXP     (HM_30634D_Btn_01:Shot)|(HM_30634D_Btn_02:Short)
   STATE      active
   TYPE       notify
   Readings:
     2017-01-07 21:51:13   state           active
Attributes:
   group      alarmNotifier
   room       Alarm


Das Problem: Die Alarmanlage lässt sich immer nur mit Button 1 scharf schalten.  Bei Button 2passiert einfach nichts.
Im Event_monior wird die Betätigung von Button 1 und 2 identisch angezeigt. Entferne ich das Häkchen bei Btn_02, und erzeuge die alarmNotifier neu, funktioniert Btn_01 immer noch.
Mache ich es umgekehrt und entferne das Häkchen bei Btn_01 bekomme ich die Alarmanlage nicht mehr scharf geschaltet....
Klar dass jetzt auf Btn_01 nicht mehr reagiert wird, aber Btn_02 welcher dann immer noch im alarmNotifier enthalten ist, funktioniert auch nicht..

Hat jemand eine Erklärung dazu, was mache ich falsch?

Gruss Birdy

[Neitcom]

Hallo zusammen,

ich habe einen Dummy als Actor erstellt, der als generische "Set Action" und auch als "Unset Action" eine Mail mit dem selben Befehl versenden soll:

Code Auswählen Erweitern

{ DebianMail('xx@yy.com','$SHORT', '$SHORT \n Auslösendes Device: $NAME \n Event: $EVENT','') }

Die Sensoren lösen die Aktionen wie gewünscht auf Basis des readings "susv powering_source" aus.
Im "Set Action" Fall werden die Variablen in der E-Mail dann auch korrekt aufgelöst, bei "Unset Action" leider nicht.

Auszug aus dem Event Log:

Code Auswählen Erweitern



###Trigger für Set Action: "Battery"###

2017-01-08 10:27:02 Alarm Alarm level2: susv
2017-01-08 10:27:02 Alarm Alarm short: Stromausfall - FHEM Alarm Level 2
2017-01-08 10:27:02 Alarm Alarm  0 1 2 3 4 5 6 7 Stromausfall - FHEM Alarm Level 2
2017-01-08 10:27:03 dummy susv powering_source: Battery

###Trigger für Unset Action "Primary"###

2017-01-08 10:27:10 Alarm Alarm level2: canceled
2017-01-08 10:27:10 Alarm Alarm level2: armed
2017-01-08 10:27:10 Alarm Alarm  0 1 2 3 4 5 6 7
2017-01-08 10:27:10 dummy susv powering_source: Primary


Im Fhem Log sieht das ganze dann so aus:

Code Auswählen Erweitern


2017.01.08 10:27:02 1: sendEmail RCP: xx@yy.com
2017.01.08 10:27:02 1: sendEmail Subject: Stromausfall - FHEM Alarm Level 2
2017.01.08 10:27:02 1: sendEmail Text: Stromausfall - FHEM Alarm Level 2 \n Auslösendes Device: susv \n Event: powering_source: Battery
2017.01.08 10:27:02 1: sendEmail Anhang:
2017.01.08 10:27:03 1: sendEmail returned: Jan 08 10:27:03 raspberrypi sendEmail[9178]: Email was sent successfully!
2017.01.08 10:27:03 3: [Alarm 2] raised from device susv with event powering_source: Battery

###Strom wieder da###

2017.01.08 10:27:03 1: SUSV Status: Primary Power returned.
2017.01.08 10:27:08 1: sendEmail RCP: xx@yy.com
2017.01.08 10:27:08 1: sendEmail Subject: $SHORT
2017.01.08 10:27:08 1: sendEmail Text: $SHORT \n Auslösendes Device: $NAME \n Event: $EVENT
2017.01.08 10:27:08 1: sendEmail Anhang:
2017.01.08 10:27:10 1: sendEmail returned: Jan 08 10:27:10 raspberrypi sendEmail[9181]: Email was sent successfully!
2017.01.08 10:27:10 3: 1 : Unknown command 1, try help.
2017.01.08 10:27:10 3: [Alarm 2] canceled from device susv



Stehen die Variablen $SHORT, $NAME und $EVENT im "Unset Action"-Fall nicht zur Verfügung?

Falls dies zutreffen sollte, wie kann ich das Problem anders lösen? Ich würde die unset-Meldung gerne dynamisch der set-Meldung zuordnen können. Hintergrund: Auf allen Alarmleveln soll der gleiche Aufruf zum Mailversand im Set und Unset Fall verwendet werden.

[XXL-Wing]

Hallo zusammen,

ich versuche mich aktuell mit dem Alarmanlagen Modul und dieses in meine bestehende FHEM Landschaft zu integrieren.

Zum Umfeld:

• Ich habe Fenstersensoren (Homematic), die an Türen und Fenstern für die Auslösung des Alarmes sorgen sollen.
• Ich habe diese Sensoren in Gruppen je Raum zusammengefasst (structures), um damit eine Anzeige zu realisieren.
• Ich habe alle Türen und alle Fenster jeweils in eine Structure gepackt um eine globale Sicht zu haben ob im Haus eine Türe oder ein Fenster offen ist (benütze ich für die Anzeige bei der Eingangstüre und beim Zugang zur Garage, um mittels eines HM-Dis-EP-WM55 EPaper Displays den Zustand anzuzeigen.
• Ich betreibe ein Zipato WT-RFID RFID-Pad, um mittels "Buchung" mit Chip an diesem Gerät die An/Abwesenheit der Bewohner zu registrieren. Jeder Bewohner ist ein Dummy-Device, das durch entsprechende Buchungsmeldung auf den Anwesenheitszustand gesetzt wird.
• Es gibt eine structure, die aus den Anwesenheiten der Personen eine Gesamtsicht erzeugt, ob irgendjemand anwesend ist oder nicht.

Soweit klappt alles wunderbar.

Mit dem Alarmanlagenmodul hab ich jetzt aber ein paar Probleme....

• Ich schaffe es irgendwie nicht, dass Alarmanlagen Levels je nach Zustand der structure der Gesamtanwesenheit scharf oder unscharf geschaltet wird. Idee: bei der ersten gültigen "Heimkehrerbuchung" wird die Alarmanlage unscharf geschaltet, sobald alle ausgebucht haben und dis structure damit auf absent ist, soll die Alarmanlage mit Verzögerung scharf schalten
• Wenn man eine structure als Sensor einsetzt, übernimmt das System alle in der structure vorhandenen Elemente zusätzlich!? Dadurch kommt ein ziemliches Durcheinander zustande, da dann sowohl die Änderung des Zustands der structure als auch die Änderung eines Elements der structure Scharf- oder Unscharfschaltungen auslöst. Irgendwie das Gegenteil dessen was ich erreichen wollte

Gibt's eine Idee wie ich das lösen könnte oder ists einfach so komplett verkehrt (obwohl es sich richtig anfühlt)?

Kleine Unschönheit am Rande: Wenn man für Zustände von Sensoren Icons definiert hat dann sieht man bei Änderung des state des Sensors das Bild statt dem Text und keine Anzeige dahinter. Ein Reload der Seite behebt das Problem. Ist nicht "betriebsverhindernd" aber unschön Screeny siehe Anhang.

danke für Ideen,
lG
Mike

[birdy]

Mit dem Alarmanlagenmodul hab ich jetzt aber ein paar Probleme....

Hallo XXL-Wing

Ich beschäftige mich auch seit ein paar Tagen mit diesem Modul, es mach oft nicht das was ich von ihm erwarten würde. Ich musste feststellen, dass dieses Modul nichts das ist was ich suche. Ich hatte mir erhofft damit ein wenig Arbeit zu sparen.
Ich habe auch beinahe die ganzen 50 Seiten durchgearbeitet, und dabei oft Unsinn gelesen. Trotzdem konnte ich aber ein paar wertvolle Ideen für meine eigene Lösung finden.   
Ich denke ich werde nun meine eigene Lösung stricken, u.U. werde ich aber vorgängig noch dieses Modul hier https://forum.fhem.de/index.php/topic,64317.html ausprobieren.

Gruss birdy

[Prof. Dr. Peter Henning]

Wenn man eine structure als Sensor einsetzt, übernimmt das System alle in der structure vorhandenen Elemente zusätzlich!? Dadurch kommt ein ziemliches Durcheinander zustande, da dann sowohl die Änderung des Zustands der structure als auch die Änderung eines Elements der structure Scharf- oder Unscharfschaltungen auslöst. Irgendwie das Gegenteil dessen was ich erreichen wollte

Das liegt an den "inner workings" der structure, die beim Setzen globaler Attribute diese an die Unterdevices weiterreicht. Das ist so gewollt, und deshalb auch nicht zu verhindern. Das Alarm-Modul müsste sonst alle Sensoren und Aktoren durchgehen und die globalen AlarmSettings bei den Unterdevices löschen - und doch wären sie beim nächsten Neustart wieder da.

Die Lösung ist ganz einfach: Zwei Dummy-Devices, die über ein DOIF oder notifies auf Zustandsänderungen der structure reagieren und selber Alarmsensoren sind.

@birdy:

und dabei oft Unsinn gelesen

Soso, ich würde eher mal vermuten: Die Anleitungen und Fragen nicht verstanden - deswegen sind sie aber noch lange kein Unsinn.

LG

pah

[birdy]

Sehr geehrter Herr Prof. Dr. Henning

@birdy:Soso, ich würde eher mal vermuten: Die Anleitungen und Fragen nicht verstanden - deswegen sind sie aber noch lange kein Unsinn.

Jeder darf vermuten was er möchte, Sie auch. Ich bin aber mit Sicherheit nicht der Einzige der hier nicht alles verstanden hat.



Hier überall habe ich Unsinn gelesen 

Edit: Da habe ich mal Unsinn geschrieben. Habe ich August 2014 so gelöst, dass nur in Message Part I eine Substitution vorgenommen wird. Wird auch so bleiben.

Das ist einfach Unsinn.

Unsinn, aber hoch drei. Man kann doch keinem Anfänger empfehlen, manuell in der Konfiguration herumzueditieren !!!

@Octopyrox: Pardon, aber das ist Unsinn. Selbstverständlich kann man auch ohne Verzögerung scharf schalten.

Unsinn, natürlich geht das 

Gruss birdy

[Prof. Dr. Peter Henning]

Sage ich doch, vermutlich nicht verstanden.

LG

pah

[justme1968]

damit attribute nicht von der structure an die beteiligten devices durchgereicht werden gibt es das structexclude atribut.

gruss
  andre

[Prof. Dr. Peter Henning]

Hm, ich dachte, das wirke sich nur auf die "set"-Befehle aus. Das es auf attribute auch wirkt, taucht in der Commandref erst später auf.

Also: I stand corrected, es geht doch mit dem Attribut structexclude=<structureName>:alarmDevice

LG

pah

[Klinki]

Hallo,

Seit einem der letzten Updates (welches, kann ich nicht genau sagen), funktioniert das Auslösen eines Alarms nicht mehr. Version des Moduls ist 2.84.
Es werden bei "raise" auch keine Einträge im Log erzeugt.

Ich habe eben die Version 2.82 wieder eingespielt und die Alarmierung funktioniert wieder wie gewünscht.

Hier die Definition des Sensors:

Code Auswählen Erweitern


define alarm0.on.N notify (HM_45B816:motion:.*on.*) {main::Alarm_Exec("AlarmModul",0,"$NAME","$EVENT","on")}
attr alarm0.on.N group alarmNotifier
attr alarm0.on.N room Alarm


gruß
klinki

[Prof. Dr. Peter Henning]

Kann ich nicht nachvollziehen, ich habe gerade eben eine Alarmierung ausprobiert. Geht bestens.

LG

pah