Neues Modul für Alarmanlage

[Prof. Dr. Peter Henning]

Womit wieder bewiesen wäre: Wer lesen kann, ist klar im Vorteil.
Ich kann schließlich nicht an allen Stellen noch einmal hinzuschreiben: "Bitte genau so verfahren, wie hier beschrieben".

pah

[Prof. Dr. Peter Henning]

Hohe Trolldichte.

pah

[Damu]

Das Modul sieht eigentlich gut aus und würde mich auch Interesieren.

Aber die Antworten vom Prof. Dr. Peter Henning finde ich manchmal total schräg.

Ich bin leider kein Prof. Dr.

Da kann ich leider nicht mithalten.

Und ich glaube es geht hier vielen Anderen auch so...

Finde ich schade.

[roli]

Ich kann dies nachvollziehen und verstehe beide Seiten. FHEM ist for free und deshalb ist es sicher super, dass hier immer wieder neue Dinge entwickelt und bereitgestellt werden. Ich hatte ursprünglich eine eigene WEB Oberfläche entwickelt - die schöner war, aber halt nicht so flexibel und ausbaufähig. Deshalb mache ich dann doch eher Abstriche und versuche mich durch FHEM zu kämpfen - was nicht ganz einfach ist. Manche Beispiele sind zu trivial und schlimmer noch ist die Tatsache, dass vieles alt und nicht kompatibel zu der heutigen Version ist. Hier ändert sich oft zuviel ohne dass man dies erst mal realisiert. Meine Fehler waren ebenfalls durch den
Unterschied von Version 1.9 --> 2.1 verursacht und dann steht man erst mal ratlos da. Mittlerweile glaube ich die Funktion zu verstehen - ohne den code zu studieren. Ich hatte leider bis jetzt auch schon Anfragen an Herrn Henning und hatte zu den Fragen nie eine Antwort bekommen - außen dass ich die Doku lesen soll. Teilweise wäre es wohl einfacher gewesen eine Tipp zu geben, da nicht alles in der Doku beschrieben ist - was ich auch verstehe. Ich hätte, wie es bei einem Forum üblich ist, eventuell auch einen Tipp von anderen Usern erwarten können.
Also lasst uns so kurz vor Jahresende die Stimmung hoch halten und manchmal ist es besser für H. Henning nichts zu antworten, wenn es nicht wirklich einen Value hat.   


Zu "Raimundl" -- Save Config ...

Ich hatte/habe ähnliche Probleme, stelle aber fest, dass es teilweise recht lange dauert bis  die  Meldung kurz oben erscheint, dass
die Config gesichert wurde. 
Ich würde auf jeden Fall mal in aktuellen LogFile nachschauen, ob Fehler vorhanden sind und sicherstellen dass dort alles fehlerfrei ist. Dann sollte es schon funktionieren. Wie gesagt ist auch mit 2.1 meine Config Anzeige anders als im WIKI dargestellt  --
Tabellen Formatierung.  Werde dies sicher auch noch rausfinden.  Da ich aber eine Hardware Alarmanlage habe  und FHEM lediglich
dazu verwende eine Einbindung zusätzlicher Funk-Melder zu realisieren, bzw. die  zeitgesteuerte Aktivierung - so kann sein dass
ich das sauer lauffähige Module mich mich einfriere - anderer Name um Probleme mit neuen Version zu verhindern.

[roli]

Habe noch etwas getestet und folgendes festgestellt, was eventuell so nicht gewollt ist.
* Arm/Disarm/Cancel actions.
    dies wird ausgeführt, wenn ich über die Sensoren die jeweilige action veranlasse - Ist also OK.  Wenn man jedoch die
    Checkbox  im Settingsbereich verwendet, so hat dies zwar die gewünschte Auswirkung - aber
    die Actions werden nicht ausgeführt. Nun kann dies gewollt sein - aber ist nicht unbedingt intuitiv. Wie gesagt sieht man
    den Erfolg der aktion auch erst wenn man den Raum/view durch verlassen und neu anwählen wieder aktualisiert.
     -- ich denke dass dies nicht so gewollt ist. 
    Der CANCEL button  löst die Cancel action aus, falls ein Alarm angestanden ist - jedoch ist dies in der Status-tabelle nicht
    geändert und erst sichbar nach refresh oder kurzzeitiges Raum wechseln.
   

[Prof. Dr. Peter Henning]

Das ist nur halb richtig.

Selbstverständlich wird die Cancel-Action ausgeführt, wenn man den Button betätigt. Bei mir ist das eine Stimmenmeldung "Alarm widerrufen", siehe Anlage.

Allerdings habe ich das bei den Checkboxen fürs Scharfschalten nicht vorgesehen, das soll auch so bleiben und ist gewollt. Denn mit den Checkboxen  kann ich_alle_ Level beeinflussen und habe sofort eine visuelle Rückmeldung.

LG

pah

P.S.: Wenn ich nicht antworte, kann das zwei Gründe haben. Erstens könnte ich nicht verfügbar sein - das kann sich bei mir durchaus über Wochen erstrecken. Zweitens kann es sein, dass ich die Frage durch eigenes Recherchieren für lösbar halte. Dann interessiert es mich auch oft nicht, eine Antwort zu geben, weil ich sonst zu nichts Anderem mehr käme. Die Vorstellung, dass es doch so schön einfach wäre, wenn ich in diesen Fällen außer "Doku lesen" noch Tipps geben würde, lasse ich mir nicht servieren - dazu ist meine Zeit wirklich zu kostbar.

Das betrifft, wohl gemerkt, nicht sinnvolle und kniffelige Fragen - bei denen helfe ich durchaus gerne.

Das betrifft schon gar nicht Leute die glauben, auf meine Arbeitskraft ein moralisches Recht zu haben, oft, ohne selbst irgendetwas zu FHEM beigetragen zu haben.  Und die dann irgendetwas Beleidigendes konstruieren, wenn man sie nicht bedient- und die dann plötzlich feststellen müssen, dass sie hier doch nicht so anonym sind, wie sie glauben.

[DerFrickler]

Hallo,

ist es vorgesehen von diesem Modul nur eine Instanz in FHEM zu nutzen? Ich habe zum Testen eine zweite Instanz definiert und musste feststellen dass Änderungen in einer Instanz auch in der zweiten Instanz mit übernommen wurden.

Grundsätzlich währe es sicherlich aber auch interessant zwischen der ordinären Alarmanlage und z.B. einer Art Mitteilungszentrale zu unterscheiden. D.h., das Wiki Beispiel mit der schwachen Batterie würde ich dann unter der Mitteilungszentrale einrichten... dazu gehören dann auch andere Szenarien wie z.B. der Ausfall von Netzwerkkomponeten sowie Sensoren und Aktoren... gewisse Stati von Sensoren wie z.B. Tür oder Fenster und auch Bewegungsmelder im Alarmzustand bzw. Scharfschaltung dann der Alarmanlage selbst zuordnen.

Gruß und schöne Feiertage!

[Prof. Dr. Peter Henning]

Hm,

sehr aufwändig, weil dann zwei verschiedene globale Attribute für die alarmsettings bei jedem Sensor/Aktor auftauchen müssten.

Aus genau diesem Grund habe ich doch ganz unterschiedliche Alarmlevel zugelassen - die Level 0-4 sind bei mir genau die Mitteilungslevel, die z.B. im Wohnzimmer eine angenehme Frauenstimme sagen lassen: "Achtung, Systemstörung". Oder "Das Badezimmerfenster steht schon zehn Minuten offen".

Level 5 ist bei mir ein Warnlevel - etwa, wenn in der Nacht eine Tür geöffnet wird, obwohl ich daheim bin. Könnte auch eines meiner Kinder sein, das spät nach Hause kommt.

Level 6 ist der Einbruchlevel - und der einzige, der manuell scharf oder unscharf gestellt wird.

Level 7 ist der Gefahrenlevel, z.B. Wasserschaden oder Raum., der wird niemals unscharf gestellt.

Ebenfalls frohe Festtage

LG

pah

[DerFrickler]

Danke für die Antwort! Mit etwas Hirnschmalz wird man sicherlich ein Konzept zusammen stellen können welches mit 8 Leveln auskommt.

Ein erster Gedanke:

0 Batteriewarnung                                (Komponente könnte in naher Zukunft ausfallen)
1 Komponentenausfall                           (Komponente ist ausgefallen)
2 Systemstörung                                   (Switch, Router, CUL o.ä. ist ausgefallen)
3 Schwellwert überschritten                   (irgendwelche Sensormeldungen außerhalb der Toleranzbereiche)

dazu hätte ich schon einen wunderbaren Anwendungsfall zur Kombination mehrerer Sensoren: hohe Aussentemperatur, kombiniert mit einer hohen Luftfeuchtigkeit und einem geöffneten Kellerfenster; die Raumtemperatur im Kellerraum ist natürlich relativ niedrig (bezogen auf die Aussentemperatur). Der Spass hat mich mehrere Stunden und einige Flaschen Schimmelentfernter gekostet.

4 Warnung beim Verlassen des Hauses    (z.B. offene Terrassentür, offenes Fenster oder die Heizung läuft noch auf Volllast)

für all diejenigen, die nach halber Fahrtstrecke von der Frau gefragt werden ob denn auch alle Fenster geschlossen sind und der Herd ausgeschaltet wurde.

die weiteren Level dann ähnlich wie im vorangegangenen Beitrag von `pah`.

Einen schönen Abend noch!

[Prof. Dr. Peter Henning]

Der Aufwand zur Erhöhung der Anzahl der Alarmlevel ist minimal - aber dann wird es schnell unübersichtlich.

Aus dem Grund gibt es ja die Möglichkeit, den auslösenden Sensor mit in die "Message" aufzunehmen - dann kann man noch feiner unterscheiden, wenn diese Message über einen Dummy abgearbeitet wird. Bei mir wird beispielsweise eine jeweils andere MP3-Meldung ausgelöst, je nachdem welches Fenster etc. geöffnet wird.

LG

pah

[mirgehtsgut]

Jorge, "mirgehtsgut":

Scheint der gleiche Konfigurationsfehler zu sein. Wirklich alle Schritte hier beachtet ? => http://www.fhemwiki.de/wiki/Modul_Alarmanlage#Erste_Schritte

Barracus:

1.9 ist eine Uraltversion des Moduls.

LG

pah

Ich habe alles neu aufgesetzt, dann war das Problem behoben. Könnte es daran liegen, dass ich zuvor selbst einen Raum Alarm erzeugt hatte?

Nun eine neue Frage: Ich schicke mir die Alarmmeldungen per Pushover zu. Ich habe dazu die am Anfang vorgeschlagene Routine {Push('Alarm','AAA')} genutzt. Ich würde nun noch gerne den auslösenden Level in die Meldung einbauen und wäre über einen Vorschlag dankbar.

[jorge]

Jorge, "mirgehtsgut":

Scheint der gleiche Konfigurationsfehler zu sein. Wirklich alle Schritte hier beachtet ? => http://www.fhemwiki.de/wiki/Modul_Alarmanlage#Erste_Schritte

Barracus:

1.9 ist eine Uraltversion des Moduls.

LG

pah

Das Problem und dessen Lösung besteht darin: Der Sensor bzw. Actor darf nicht dem Hiddenroom AlarmRoom zugeordnet werden... warum auch immer.

[Prof. Dr. Peter Henning]

Das ist dann irgendein Spezialeffekt des FHEMWEB Frontends.

LG

pah

[jorge]

Ich habe die folgende Testkonfiguration aufgesetzt:
Je ein Dummys für arm/disarm/raise/cancel als Ersatz für Sensoren
Je 1 Actor auf level 0 und 1
Signalsierung des Alarmzustands über gpio

Das 'Alarmieren' der Aktoren über die Dummies klappt auch gut.
Auch das 'disarm' funktioniert, unter Alarms erscheinen die Checkboxen danach ohne Haken, es wird kein Alarm mehr ausgelöst

Logfile:
2015.01.03 13:19:21 3: alarm1.disarm.N return value: [Alarm 1] disarmed from device AlarmDummyDisarm with event on
2015.01.03 13:19:21 3: alarm0.disarm.N return value: [Alarm 0] disarmed from device AlarmDummyDisarm with event on

ein 'arm'  ist allerdings über den dafür vorgesehenen Dummy nicht möglich

Logfile:
2015.01.03 13:30:03 3: alarm1.arm.N return value: [Alarm 1] armed from device AlarmDummyArm with event on, delay 0 s
2015.01.03 13:30:03 3: [Alarm 1] armed from device AlarmDummyArm with event on, delay 0 s
2015.01.03 13:30:03 3: define alarm1.arm.dly at +00:00:00 attr AAA level1xec armed : alarm1.arm.dly already defined, delete it first
2015.01.03 13:30:03 3: alarm0.arm.N return value: [Alarm 0] armed from device AlarmDummyArm with event on, delay 0 s
2015.01.03 13:30:03 3: [Alarm 0] armed from device AlarmDummyArm with event on, delay 0 s
2015.01.03 13:30:03 3: define alarm0.arm.dly at +00:00:00 attr AAA level0xec armed : alarm0.arm.dly already defined, delete it first

Die Checkboxen in der Alarmsübersicht sind leer, eine Alarm wird über die Dummys nicht mehr ausgelöst.
Erst nach erneutem Aktivieren der Checkboxen und SetAlarms ist ein Alarmauslösen wieder möglich.

Neuestes Update V 2.1

LG

Jorge

[HolyMoly]

Gibt es eigentlich einen speziellen Grund warum es sowohl einen Alarm als auch einen Alarms Room gibt?
Leider kann ich die notifies aus Alarm nicht in Alarms verschieben da sie immer neu geschrieben werden...