Modul 95_Alarm.pm

Begonnen von Prof. Dr. Peter Henning, 09 Januar 2021, 10:44:29

Vorheriges Thema - Nächstes Thema

dkalass

Hallo Herr Prof. Dr. Peter Henning,

mich überrascht der ungehörige Ton von Ihnen!
Diese Einträge stammen doch aus dem Modul, oder?

define alarm0.off.N notify (TFClose.warn:yes)|(Cancel:on) {main::Alarm_Exec("Alarmanlage",0,"$NAME","$EVENT","off")}
setuuid alarm0.off.N 63d2438a-f33f-24ff-b0d3-b1c6b008ba6d103b
attr alarm0.off.N group alarmNotifier
attr alarm0.off.N room Alarm
define alarm0.on.N notify (BK.F:open)|(HM_MOD_EM_8_PEQ1916517_1:open)|(HM_MOD_EM_8_PEQ1916517_2:open)|(HM_MOD_EM_8_PEQ1916517_3:open)|(HM_MOD_EM_8_PEQ1916517_4:open)|(HM_MOD_EM_8_PEQ1916517_5:open)|(HM_MOD_EM_8_PEQ1916517_6:open)|(HM_MOD_EM_8_PEQ1916517_7:open)|(HM_MOD_EM_8_PEQ1916517_8:open)|(TFOpen.warn:.*) {main::Alarm_Exec("Alarmanlage",0,"$NAME","$EVENT","on")}
setuuid alarm0.on.N 63d2438b-f33f-24ff-03a1-7a80436174c4a058
attr alarm0.on.N group alarmNotifier
attr alarm0.on.N room Alarm

Wenn man so schlau ist wie sie, könnte man das auch freundlich erklären, oder ist das in ihren Kreisen nicht mehr gang und gebe?

Prof. Dr. Peter Henning

#31
1. Keineswegs "schreibt das Modul in die fhem.cfg" - das ist die Aufgabe von FHEM, wenn man so will also von fhem.pl.
2. Woher soll FHEM (nicht etwa ein bestimmtes Modul) wissen, dass eine bestimmte Device-Definition in die ausgelagerte Konfigurationsdatei "meine_Alarmanlage.cfg" des Users xyz geschrieben werden soll? Edit: Wie Rudi unten anmerkt, weiß FHEM das sehr wohl. Da das Modul - in dem Fall 95_Alarm.pm - aber gar nicht in eine Konfigurationsdatei schreibt, sodern dies FHEM überlässt, ist das nicht relevant.

Ich habe hier nur einen Hinweis: Finger weg von manuell editierten Konfigurationsdateien (und damit auch vom Aufspalten derselben).

LG

pah

rudolfkoenig

Zitat2. Woher soll FHEM (nicht etwa ein bestimmtes Modul) wissen, dass eine bestimmte Device-Definition in die ausgelagerte Konfigurationsdatei "meine_Alarmanlage.cfg" des Users xyz geschrieben werden soll?
Das wird vom $hash->{CFGFN} abgeleitet.
Bei Include-Dateien wird das gesetzt, damit die aus dieser Datei gelesenen Definitionen auch dahin zurueckgeschrieben werden.

usm

Hallo,
ich hangel mich gerade durch die Wiki Beschreibung und versuche zu einem EnOcean windowHandle die unterschiedlichen Level zu definieren. Das Device meldet folgende vier Stati:
open, closed, tilted, open_from_tilted
Es bietet sich also an eine Warnung bei tilted (z.B. beim Verlassen) zu definieren und einen Einbruch zu melden wenn der windowHandle bei Abwesenheit den Status open_from_tilted meldet.

Ist so eine Konfiguration im Modul umsetzbar, oder können unterschiedliche Stati gar nicht definiert werden?

Lieben Dank
usm

Prof. Dr. Peter Henning

Das Modul ist so aufgebaut, dass ein (logisches) Gerät mit einem Event zwar verschiedene Alarmlevel auslösen kann. Aber nicht mit verschiedenen Events verschiedene Alarmlevel.

Hier müsste man (das halte ich auch für sauberer) zu einem physisch vorhandenen Gerät mehrere logische Geräte (z.B. als Dummy, oder mit CustomReadings) definieren - deren Events dann unterschiedliche Level auslösen.

LG

pah

P.S.: Die Mehrzahl von Status ist Status.

87insane

#35
Hallo zusammen,

ich würde hier gerne nochmal auf die Messageparts zu sprechen kommen (siehe Seite 2). Wie kann man diese "umdrehen"? Wenn ich $SHORT verwende kommt immer zuerst PART I und dann PART II. Mag in der Reihenfolge logisch klingen aber ich finde es falsch herum. Ich würde mir gerne Nachrichten senden in denen z.B. steht:
Zugang Fenster XY nicht aber wie es in $SHORT steht: Fenster XY Zugang.

Innerhalb des Wikis findet man die Message Parts nicht einzeln. $SHORT beinhaltet schon beide.

Zweites Thema:
Wenn ich z.B. weg gehe und den Alarm (Einbruch) scharf schalte, habe ich einen delay, damit ich es auch bis zur Tür schaffe und nicht direkt einen Alarm auslöse. Nun suche ich einen Weg um den delay NUR auf die Türe zu schalten. Alles andere soll sofort scharf sein. Denn ich benutze immer nur die Türe und gehe nie durchs Fenster hinaus. Die Wahrscheinlichkeit dass ein Einbrecher am Fenster wartet ist natürlich gering aber rein logisch wäre für mich:
1. Alarm scharf stellen
2. Alle Fenster und ggf. sonstige Türen sind scharf
3. Delay auf Türe (z.B. 10 Sekunden) aktiv
4. Nach den 10 Sekunden ist dann auch die Türe aktiv / scharf geschaltet

Gruß,
87Insane

Prof. Dr. Peter Henning

Die Reihenfolge der Message Parts werde ich nicht ändern, weil die Semantik so herum korrekt ist. Wer das haben möchte, kann ja Zeile 709 des Moduls umstellen.

Betreffend die unterschiedlichen Delays: Auch das wird nicht im Modul geändert. Man kann in wenigen Zeilen ein DOIF erstellen, das die Scharfstellung der Tür verzögert, und alle anderen Alarme sofort scharf macht. Dazu muss dann aber natürlich der "allgemeine" Delay in der Weboberfläche auf Null gesetzt werden.

LG

pah


87insane

Schade, dann baue ich mir das direkt selber. Die Zeilen für die Befehle sind z.b. auch relativ klein. Ich dachte das "Verbesserungen" ggf. sinnig sind. Aber wenn ich drumherum alles mögliche anpassen muss, kann ich lieber direkt einen großen MSwitch bauen oder DOIF.

Betreffend der Message Parts müsste man ja nichtmal etwas umdrehen aber du könntest einfach zwei Variablen dafür belegen. Einfach sowas wie $SHORT1 und $SHORT2 und die Welt wäre ok. Wenn wirklich mal einer einbricht, will ich nicht zuerst die Info lesen was passiert ist sondern wo. Das ist in meinen Augen wichtig. Gleiches bei Brand oder sonst was.

Gruß,
87Insane

mfeske

#38
Ich bin ganz neu mit dem Modul unterwegs dank mehrerer Hinweise das das was ich vor habe ja eigentlich schon als fertiges Modul existiert. Ich habe das Wiki auch durchgearbeitet, aber es ist für mich an einigen Stellen leider nicht ganz verständlich. Ich habe es erstmal in meiner Testinstallation angelegt.
Den Vorgang schärfen / entschärfen über set AAA armed 0 / set AAA disarmed 0 habe ich verstanden und auch die Meldungen die ich jetzt erstmal testweise per push raussende kommen wie erwartet an. Ich würde das gerne auch über Alarm_Taster und Alarm_Status machen, weiss aber zum Beispiel nicht was ich bei Aktion setzen / Aktion rücksetzen dabei eintragen muss. Auch die Auswertung des Sensors ist mir noch ein Rätsel. Die Bedeutungen AutoWiderruf,Nachrichtenteil II,Widerruf bzw. Auslösung durch RegExp, Nachrichtenteil I, Wirkung; RegExp ist für mich ein Buch mit vielen Siegeln.
Ich wollte eigentlich auch einen Screenshot dazu einbinden, das ist mri aber nicht gelungen. Bei mir scheinen die Zahlen nicht korrekt bei den checkboxen zu stehen.
Gruß
Micha

list
Internals:
   CFGFN     
   FUUID      6955a2e5-f33f-be1a-991e-70d29527bc7d2d4c
   NAME       AAA
   NR         143
   STATE       0
   TYPE       Alarm
   VERSION    5.0
   eventCount 72
   DATA:
     savedate   2026-01-01 00:36:18
     armstate:
       level0     armed
       level1     disarmed
       level2     disarmed
       level3     disarmed
       level4     disarmed
       level5     disarmed
       level6     disarmed
       level7     disarmed
   READINGS:
     2026-01-01 00:09:31   level0          armed
     2026-01-01 00:36:18   level1          disarmed
     2025-12-31 23:25:46   level2          disarmed
     2025-12-31 23:25:46   level3          disarmed
     2025-12-31 23:25:46   level4          disarmed
     2025-12-31 23:25:46   level5          disarmed
     2025-12-31 23:25:46   level6          disarmed
     2025-12-31 23:25:46   level7          disarmed
     2025-12-31 23:27:59   lockstate       0
     2026-01-01 00:36:18   savedate        2026-01-01 00:36:18
     2025-12-31 23:27:59   short           0
     2026-01-01 00:36:18   state            0
   hmccu:
Attributes:
   armact     set pushmsg msg 'Alarmanlage ist scharf gestellt'
   armdelay   0:15
   armwait    set pushmsg msg 'Alarmanlage wird in 15 Sekunden scharf gestellt'
   cancelact  set pushmsg msg 'Alarm Widerrufen'
   disarmact  set pushmsg msg 'Alarmanlage ist unscharf gestellt'
   level0autocan 0:00
   level0cond 1
   level0end  23:59
   level0msg  Einbruch
   level0start 0:00
   level1autocan 0:00
   level1cond 1
   level1end  23:59
   level1msg  --
   level1start 0:00
   level2autocan 0:00
   level2cond 1
   level2end  23:59
   level2msg  --
   level2start 0:00
   level3autocan 0:00
   level3cond 1
   level3end  23:59
   level3msg  --
   level3start 0:00
   level4autocan 0:00
   level4cond 1
   level4end  23:59
   level4msg  --
   level4start 0:00
   level5autocan 0:00
   level5cond 1
   level5end  23:59
   level5msg  --
   level5start 0:00
   level6autocan 0:00
   level6cond 1
   level6end  23:59
   level6msg  --
   level6start 0:00
   level7autocan 0:00
   level7cond 1
   level7end  23:59
   level7msg  --
   level7start 0:00
   room       AlarmRoom

list Aktoren
Internals:
   APP_TOKEN  amfefhxr9x2vneytzy37z2nmor3t9p
   DEF        amfefhxr9x2vneytzy37z2nmor3t9p uj4exw6khYXtfr42xHo3LDKWyYaFAJ
   FUUID      678d174c-f33f-be1a-37d0-ebe22658cf92262f
   FVERSION   70_Pushover.pm:v2.2.0-s27466/2023-04-20
   NAME       pushmsg
   NR         73
   STATE      connected
   TYPE       Pushover
   USER_KEY   uj4exw6khYXtfr42xHo3LDKWyYaFAJ
   VALIDATION_TIMER 1767245784.10373
   eventCount 24
   READINGS:
     2025-12-31 17:13:33   apiLimit        10000
     2026-01-01 00:36:24   apiRemaining    9906
     2025-12-31 17:13:33   apiReset        1767247200
     2025-12-31 12:24:20   available       1
     2025-01-19 16:16:35   devices         iphonemf
     2025-01-19 16:16:35   group           0
     2026-01-01 00:36:24   lastAction      -
     2026-01-01 00:36:24   lastDevice      iphonemf
     2026-01-01 00:36:24   lastMessage     Alarmanlage ist unscharf gestellt
     2026-01-01 00:36:24   lastRequest     edbbad7b-9ca6-4be3-b1f3-f308112c1288
     2026-01-01 00:36:24   lastResult      ok
     2026-01-01 00:00:05   lastTitle       Allmendeweg 116
     2025-12-31 12:24:20   state           connected
     2025-01-19 16:16:35   tokenState      valid
     2025-01-19 16:16:35   userState       valid
   hmccu:
Attributes:
   alarmDevice Actor
   alarmSettings alarm0,|set pushmsg msg 'Alarm ausgelöst'|set pushmsg msg 'Alarm widerruf'|0:00
   icon       pushover
   room       Alarmanlage,Haus

list Sensoren
Internals:
   FUUID      67807828-f33f-be1a-6f3e-56d9bde8e61ee267
   NAME       Alarm_Status
   NR         68
   STATE      1
   TYPE       dummy
   eventCount 33
   READINGS:
     2026-01-01 00:00:57   state           1
   hmccu:
Attributes:
   alarmDevice Sensor
   alarmSettings alarm0,|||on
   room       AppleWatch,Alarmanlage

Internals:
   FUUID      67816ae7-f33f-be1a-7c06-39d56c9a9d1ba135
   NAME       Alarm_Taster
   NR         69
   STATE      off
   TYPE       dummy
   eventCount 32
   READINGS:
     2026-01-01 00:00:57   state           off
   hmccu:
Attributes:
   alarmDevice Sensor
   alarmSettings alarm0,|||on
   alexaName  Alarmanlage Taster
   devStateIcon on:15px-red off:15px-green
   room       Alexa,Alarmanlage,AppleWatch
   setList    on off

Internals:
   FUUID      67807443-f33f-be1a-9c37-ef525a4666948874
   NAME       Fenster_Garten_Alarm
   NR         66
   STATE      closed
   TYPE       dummy
   READINGS:
     2025-02-26 20:38:42   state           closed
   hmccu:
Attributes:
   alarmDevice Sensor
   alarmSettings alarm0,||set pushmsg msg 'Fenster Alarm'|on
   devStateIcon opened:fts_window_2w_open_l@red closed:fts_window_2w@green
   room       Alarmanlage,AppleWatch
   verbose    0

In meiner Produktivumgebung wäre die für die Alarmgebung set Rauchmelder_Team alarmOn zuständig bzw. es würde auch optisch über set FHEM_gong_Led on gehen; hier habe ich leider noch nicht rausgefunden wie ich die Farbe ggf. mit einem Befehl für den HM-OU-CFM-PL ändern kann ich würde ja gerne über grün / gelb / rot den Zustand der AAA anzeigen.

Hardware:
1 x Raspberry Pi Mod. B 512 MB
eq-3 2 x MAX! eTRV Heizungssteller, 1 x MAX! Fensterkontakt, 1 x MAX! Cube - LAN Gateway (ausser Betrieb)
Intertechno 1x ITZ-500, 3x ITT-1500, 9x ITR-1500, 3 x ITDL-1000, 2 x ITL-500
1 x CC1101-USB-Lite 433MHz (CUL433)  V3 1 x CC1101-USB-Lite 868MHz (CUL868)