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

@DK8JV:

' statt " verwenden.

LG

DF5FR aka pah

PSI69

#1321
Hallo pah,

ich habe mit dem Hinzufügen eines Aktors ('AlarmLevel3Actor2') derzeit ein Problem, es geht um Level 3, in der cfg erfolgt beim 'Parameter setzen' unter 'level3onact' kein defmod Eintrag (mit dem at und den 30 Minuten Verzögerung) für selbigen, er wird sozusagen bei Eintritt in den Level ohne Verzögerung ausgeführt:


Internals:
   FUUID      5c433c81-f33f-739f-f717-38d63708c7e9c0ed
   NAME       AAA
   NR         479
   STATE       0 1 2 3 4 5 6 7
   TYPE       Alarm
   VERSION    5.0
   DATA:
     savedate   2020-09-19 13:56:20
     armstate:
       level0     disarmed
       level1     disarmed
       level2     armed
       level3     armed
       level4     armed
       level5     armed
       level6     disarmed
       level7     armed
   READINGS:
     2016-12-09 20:12:12   level           0
     2020-09-22 15:19:42   level0          disarmed
     2020-09-22 15:19:42   level1          disarmed
     2020-09-22 15:19:42   level2          armed
     2020-09-22 15:19:42   level3          armed
     2020-09-22 15:19:42   level4          armed
     2020-09-22 15:19:42   level5          armed
     2020-09-22 15:19:42   level6          disarmed
     2020-09-22 15:19:42   level7          armed
     2016-12-09 20:28:59   lockstate       unlocked
     2020-09-22 15:19:24   savedate        2020-09-19 13:56:20
     2020-09-22 15:05:47   short           
     2020-09-22 15:20:23   state            0 1 2 3 4 5 6 7
Attributes:
   alias      Alarmanlage
   armact     {Alarm_Arm_Action()}
   armdelay   0:30
   armwait    {Alarm_Wait_Action()}
   cancelact  {Alarm_Cancel_Action()}
   disarmact  {Alarm_DisArm_Action()}
   icon       security
   level0autocan 0:00
   level0cond 1
   level0end  23:59
   level0msg  NICHT DEFINIERT
   level0offact 1
   level0onact 1
   level0start 00:00
   level1autocan 0:00
   level1cond 1
   level1end  23:59
   level1msg  NICHT DEFINIERT
   level1offact 1
   level1onact 1
   level1start 00:00
   level2autocan 0:00
   level2cond 1
   level2end  23:59
   level2msg  schwach
   level2offact
   level2onact {Level_2_AlarmFired_Actor()};defmod alarm2dly1 at +00:05:00 {Level_2_AlarmFired_Actor_AutoCancel()};
   level2start 00:00
   level3autocan 0:00
   level3cond 1
   level3end  23:59
   level3msg  offen
   level3offact
   level3onact defmod alarm3dly1 at +00:15:00 {Level_3_AlarmFired_Actor()};{Level_3_AlarmFired_Actor2()};defmod alarm3dly2 at +00:45:00 {Level_3_AlarmFired_Actor3()};
   level3start 00:00
   level4autocan 0:00
   level4cond 1
   level4end  23:59
   level4msg  offen
   level4offact
   level4onact defmod alarm4dly1 at +00:15:00 {Level_4_AlarmFired_Actor()};{Level_4_AlarmFired_Actor_AutoCancel()};
   level4start 22:00
   level5autocan 0:00
   level5cond 1
   level5end  05:00
   level5msg  Zugang
   level5offact {Level_5_AlarmFired_Actor_Unset()};
   level5onact defmod alarm5dly1 at +00:01:10 {Level_5_AlarmFired_Actor()};defmod alarm5dly2 at +00:04:00 {Level_5_AlarmFired_Actor_AutoCancel()};defmod alarm5dly3 at +00:00:03 {Level_5_AlarmFired_PreActor()};
   level5start 00:00
   level6autocan 0:00
   level6cond 1
   level6end  23:59
   level6msg  Einbruch
   level6offact {Level_6_AlarmFired_Actor_Unset()};
   level6onact defmod alarm6dly1 at +00:01:10 {Level_6_AlarmFired_Actor()};defmod alarm6dly2 at +00:04:00 {Level_6_AlarmFired_Actor_AutoCancel()};defmod alarm6dly3 at +00:00:03 {Level_6_AlarmFired_PreActor()};defmod alarm6dly4 at +00:00:55 {Level_6_AlarmFired_PreActor2()};defmod alarm6dly5 at +00:01:30 {Level_6_AlarmFired_Sirene_Actor()};
   level6start 00:00
   level7autocan 0:00
   level7cond 1
   level7end  23:59
   level7msg  Gefahr! ⚠
   level7offact {Level_7_AlarmFired_Actor_Unset()};
   level7onact {Level_7_AlarmFired_Actor()};defmod alarm7dly1 at +00:02:30 {Level_7_AlarmFired_Actor_AutoCancel()};
   level7start 00:00
   lockstate  unlocked
   room       Infrastruktur->Alarmanlage
   statedisplay color
   verbose    4


List vom Aktor:
Internals:
   FUUID      5f69f86f-f33f-d09e-531b-d013713dd023e330
   NAME       AlarmLevel3Actor2
   NR         715
   STATE      ???
   TYPE       dummy
Attributes:
   alarmDevice Actor
   alarmSettings alarm3,|{Level_3_AlarmFired_Actor2()}||30:00
   alias      Alarm Level 3 Actor 2 (F Bad Offen)
   group      alarmActor
   room       Infrastruktur->Alarmanlage


Deaktiviere ich Level 3 für den Aktor, wird 'level3onact' für die anderen beiden Aktoren des Levels korrekt erzeugt:

level3onact defmod alarm3dly1 at +00:15:00 {Level_3_AlarmFired_Actor()};defmod alarm3dly2 at +00:45:00 {Level_3_AlarmFired_Actor3()};


Die Anzahl der Attoren kann es ja nicht sein - mit Level 6 überschreite ich die 3 vom Level 3 ja deutlich... Besagten Aktor habe ich schon mehrfach neu erstellt und konfiguriert - selbes Ergebnis. FHEM ist aktuell.

Habe ich Tomaten auf den Augen?

Danke Peter

[EDIT]
Ich bin noch einmal durch die einzelnen Level gegangen; auch der hier passt nicht - es fehlt das 'at' vor meinem AutoCancel - Aufruf:

level4onact defmod alarm4dly1 at +00:15:00 {Level_4_AlarmFired_Actor()};{Level_4_AlarmFired_Actor_AutoCancel()};


Hier der Aktor:

Internals:
   FUUID      5f3cf212-f33f-d09e-0b98-02ac182dedf52709
   NAME       AlarmLevel4ActorAutoCancel
   NR         713
   STATE      ???
   TYPE       dummy
Attributes:
   alarmDevice Actor
   alarmSettings alarm4,|{Level_4_AlarmFired_Actor_AutoCancel()}||02:00:00
   alias      Alarm Level 4 Actor AutoCancel (F/T Offen)
   group      alarmActor
   room       Infrastruktur->Alarmanlage


Bug oder Fehler meinerseits? Ich sehe nur keinen, leider...
Peter

[EDIT2]
Es sind die Zeitangaben, trage ich beim 2.Aktor von Level 3 ebenfalls '15:00' statt '30:00' ein, erfolgt dies hier:

defmod alarm3dly1 at +00:15:00 {Level_3_AlarmFired_Actor()};defmod alarm3dly2 at +00:15:00 {Level_3_AlarmFired_Actor2()};defmod alarm3dly3 at +00:45:00 {Level_3_AlarmFired_Actor3()};


Bei Änderung in 30 Minuten, dann wieder das hier:

defmod alarm3dly1 at +00:15:00 {Level_3_AlarmFired_Actor()};{Level_3_AlarmFired_Actor2()};defmod alarm3dly2 at +00:45:00 {Level_3_AlarmFired_Actor3()};


Ich habe mir jetzt geholfen, indem ich nach dem Setzen der Parameter manuell die beiden Attribute für die Level 3 und 4 auf die richtigen Werte setze.

@pah
Das sollte doch bis zum nächsten Setzen der Parameter ohne Nebenwirkungen funktionieren?

Peter
FHEM auf RPi 5 unter Bookworm mit inzwischen einem ganzen Zoo von Geräten...

Prof. Dr. Peter Henning

Hmm. Schwer nachzuvollziehen - was sagt die Kiste denn, wenn eine nur minimal abweichende Zeitangabe, sagen wir 15:01 eingesetzt wurde?

LG

pah

PSI69

#1323
15:01 klappt:

defmod alarm3dly1 at +00:15:00 {Level_3_AlarmFired_Actor()};defmod alarm3dly2 at +00:15:01 {Level_3_AlarmFired_Actor2()};defmod alarm3dly3 at +00:45:00 {Level_3_AlarmFired_Actor3()};


20:00 wiederum nicht, dito 02:00:00:

defmod alarm3dly1 at +00:15:00 {Level_3_AlarmFired_Actor()};{Level_3_AlarmFired_Actor2()};defmod alarm3dly2 at +00:45:00 {Level_3_AlarmFired_Actor3()};


Peter

[EDIT]
Falls relevant: bei mir läuft Buster mit den Patches Stand 04.09.20...

[EDIT2]
... Patches Stand Heute jetzt - Problem besteht weiter.
FHEM auf RPi 5 unter Bookworm mit inzwischen einem ganzen Zoo von Geräten...

Fillip

Ich habe da auch noch mal eine Frage zu dem Modul. Wie ist es denn möglich, das ich ein Gerät / Device mehrfach verwende? Bsp habe ich einen Taster, der mehrere Werte liefert, ich aber so ja nur einen abfragen kann im Modul. Oder auch, habe ich ein dummy zum aktivieren des Alarmes bsp über das Pinpad in FTUI, kann ich von dem dummy ja nur einen Wert abfragen, geht das irgendwie anders noch?

PSI69

Zitat von: Fillip am 23 September 2020, 16:15:32
Ich habe da auch noch mal eine Frage zu dem Modul. Wie ist es denn möglich, das ich ein Gerät / Device mehrfach verwende? Bsp habe ich einen Taster, der mehrere Werte liefert, ich aber so ja nur einen abfragen kann im Modul. Oder auch, habe ich ein dummy zum aktivieren des Alarmes bsp über das Pinpad in FTUI, kann ich von dem dummy ja nur einen Wert abfragen, geht das irgendwie anders noch?
Jedes FHEM Device kann etweder Sensor oder Aktor für AAA sein - ist es Sensor gibt es nur eine RegEx. Leg einfach beliebig viele Dummys an, konfiguriere sie als Sensor und lege die RegEx so, dass sie auf das Event reangiert, auf das Du wartest...

Peter
FHEM auf RPi 5 unter Bookworm mit inzwischen einem ganzen Zoo von Geräten...

Fillip

Bei einem dummy mag das ja gehen, nur bei bsp einem Hue Taster ist es etwas komplizierter :o

Prof. Dr. Peter Henning

ZitatBei einem dummy mag das ja gehen, nur bei bsp einem Hue Taster ist es etwas komplizierter
Sorry, aber das ist einfach Quatsch.

Der Dummy dient nur dazu, einen zusätzlichen Eintrag in der Sensoren- bzw. Aktorentabelle von Alarm zu schaffen - das Device selbst ist bedeutungslos.

pah

Fillip

Das heißt dann, wenn ich das so richtig versteh, habe ich bsp einen Hue Taster der den State 1001, 2001, 3001 und 4001 beim tippen haben kann, das ich mir einmal das Gerät selbst als Sensor definiere, darauf dann auf das 1001 reagiere, für die anderen states dann jeweils ein dummy erstellen muss welches dann über ein notify getriggert wird, welche dann auch jeweils als Sensoren eingebunden werden?

Esjay

Bitte readingsProxy anschauen, dann kann alles vom Original Device übernommen werden.

Grüße

Fillip

Zitat von: Esjay am 23 September 2020, 20:20:41
Bitte readingsProxy anschauen, dann kann alles vom Original Device übernommen werden.

Grüße
Super danke, das war der Denkanstoß  ;D

gamauf

Nein!
Weder notify, noch readingsproxy!
Das dummy device dient nur als Speicherplatz für das regex!
Das device, auf das getriggert wird, steht im regex!
Dummy ist nur der "container" fürs regex!

Prof. Dr. Peter Henning


timtom

Hallo zusammen,

ich habe mich jetzt intensiv in das Modul Alarm eingelesen, z.B. Wiki, Forum. Ich tue mich jedoch noch etwas schwer zu verstehen, für welche Anwendungsfälle das Modul geeinget ist.

Derzeit habe ich etliche DOIF, die Devices überwachen und nach bestimmten Kriterien dann etwas auslösen, z.B. folgende
Wenn Abwesend -> Lichter zufällig schalten.
Wenn Abwesend und Haustüre geöffnet -> Flurlicht an und Telegram Nachricht (später soll dann der Rauchmelder Alarm geben)
Wenn Wassersensor warnt -> Telegram Nachricht
Wenn Rauchmelder warnt -> Telegram Nachricht
Wenn Batteriestand von diversen Geräten low -> Telegram Nachricht
Jeden Tag 0:05 -> Config speichern
Bei Abwesenheit jeden Tag 0:05 -> alle Lichter aus
Bei Anwesenheit und Nachts und Bewegungsmelder aktiv -> Licht 2 Minuten an

Jetzt Frage ich mich, ob ich lieber das Alarm-Modul nutzen oder meine alte "Strategie" über einzelne DOIF weiterverfolgen soll?

Um das Modula mal zu testen, hatte ich mir den Batterie-Check als Use Case vorgenommen, für den ich aktuell das folgende DOIF nutze:
define di_batt_chk DOIF ([":battery: low"] and [?$SELF:B_$DEVICE] ne "low")\
   (set teleBot message Batterie leer: $DEVICE, setreading $SELF B_$DEVICE low)\
DOELSEIF ([":battery: ok"] and [?$SELF:B_$DEVICE] ne "ok")\
   (setreading $SELF B_$DEVICE ok)
setuuid di_batt_chk xxxxxx
attr di_batt_chk do always


Dabei habe ich mir die Frage gestellt, wie ich am Besten vorgehe: (1) das Notify-Bsp aus dem Wiki (2) mein DOIF einbauen oder (3) alles über das Alarmmodul.

zu 3) Ich würde einfach jedes Device mit einem Batteriestatus als Sensor anlegen und auf ein niedriges Batterielevel checken lassen. Bei Alarm würde ich per Actor den Telebot ansteuern, eine Nachricht schicken und den Alarm wieder automatisch canceln, damit eine neue Meldung kommt, falls gleichzeitig ein anderer Sensor einen niedrigen Batteriestand hat.

Jetzt meine Frage. (3) sind zwar viele manuelle Schritte, aber im Alarm Modul sehr transparent und auch noch 1 Jahr später schnell nachvollziehbar.
Wofür benötige ich denn überhaupt das Alarm Modul, wenn ich (1) oder (2) nehme? Wäre das nicht überflüssig? Oder was ist der Vorteil?

einen Schönen Sonntag noch
derTim

Prof. Dr. Peter Henning

Ob jemand das Modul nutzen will, muss er selbst entscheiden - dazu werde ich mich nicht äußern.

Zitatzu 3) Ich würde einfach jedes Device mit einem Batteriestatus als Sensor anlegen und auf ein niedriges Batterielevel checken lassen. Bei Alarm würde ich per Actor den Telebot ansteuern, eine Nachricht schicken und den Alarm wieder automatisch canceln, damit eine neue Meldung kommt, falls gleichzeitig ein anderer Sensor einen niedrigen Batteriestand hat.
Das ist Käse. Das geht nämlich für alle Devices gemeinsam mit einer Instanz von monitoring:
define Devices.battery monitoring .*:battery:.low .*:battery:.ok
Das Alarm-Modul überwacht nur Devices.battery.

LG

pah