Modul 95_Alarm.pm

[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]

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]

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?

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]

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