Neues Modul für Alarmanlage

[Mario67]

Ich möchte Euch nochmal (den bereits zuvor genannten) Vorschlag machen, die Anweisungen für die Aktionen besser in ein Modul auszulagern.
Ihr spart Euch sicher Einiges an Zeit und Frust. Anbei eine Art Template dafür, gefüllt mit einer Auswahl an Aktionen, welche bei mir sinnvoll sind (teilweise noch mit zusätzlichen Debug-Ausgaben).

1. Den Inhalt der Methoden ganz nach Belieben verändern.
2. Deren Namen evtl. für Euch lesbarer machen (z.B. aus "EinbruchAlarmFired_Actor" --> "Level_0_AlarmFired_Actor").
3. Das Modul unter /fhem/FHEM ablegen.
4. reload 99_myUtilsAlarm.pm nicht vergessen.
5. Wichtig: Zur Inbetriebnahme die Funktionen schon mal direkt aufrufen z.B.

Code Auswählen Erweitern

{EinbruchAlarmFired_Actor()}
6. Genau so sind dann auch die passenden "Action"-Felder zu füllen.

Gruß,
Mario

Edit: Bitte Post #554 beachten.

[Prof. Dr. Peter Henning]

Ich möchte Euch nochmal (den bereits zuvor genannten) Vorschlag machen, die Anweisungen für die Aktionen besser in ein Modul auszulagern.

Das kann ich nur aus voller Überzeugung unterstützen.
Lange und komplexe Aktionen haben aus Gründen der Wartbarkeit in einer Konfigurationsdatei nichts verloren.

LG

pah

[NilsB]

ps: Es ist ein Vorschlag, ein Beispiel oder ein Inspirationsanstoss - keine "Komplettlösung"

Hallo Mike,

vielen Dank für die ausführliche und hilfreiche Antwort! Tatsächlich hat mich das Stichwort dummy und deine Codeschnipsel hervorragend inspiriert!

Die checkArmState() hat mir schon gut gefallen, wurde nur noch an meine Sensoren angepasst und die $msg bzw. die 0 nicht in das Attribut "armError" des Dummys geschrieben sondern mittels set direkt in den State des Dummys - so sieht man die Fehlermeldung direkt im Webfrontend und kann außerdem leichter mit devStateIcons arbeiten.

Beim bauen des Notifys zur erneuten Überprüfung hatte ich so meine Probleme mit der RegExp.. Habe viel mit online-tools rumprobiert, es aber letztendlich nicht mit dem Operator + ans Laufen bekommen. Habe jetzt folgendes Notify:

Code Auswählen Erweitern

.*[fF]enster.*(open|closed)$ {checkArmState()}

(Türen sind bewusst nicht dabei, weil die Korredortür beim Scharfschalten meist noch offen ist und somit ohnehin keine Rolle in checkArmState() spielt). Übersehe ich irgendwas, wo der Notify bspw. "zu oft" getriggert wird?

Zum eigentlichen Scharfschalten gibt es bei mir ja keine Zeitsteuerung, sondern den Wandtaster, deshalb folgendes Notify zum Ausführen:

Code Auswählen Erweitern

define armAction notify EZ.vierfachTaster.Btn01:Long\s1_.* {
if(Value("ready2Arm") eq "0"){
fhem("set Alarmanlage armed 7");
}else{
fhem("set EZ.Sound playTone 003");
}
}

Momentan ist der Sound 003 noch eine allgemeingültige Fehlermeldung. Muss mal sehen ob ich das noch raumspezifisch mache Das ist bei einer Methode wie Pushover, welche Text als Argumente nimmt, natürlich praktisch.
EQ3 sollte sich mal überlegen ein Sound-Modul mit integrierter TTS-Engine rauszubringen, das wäre Luxus!

Habe im Alarm-Modul noch einen Backuplösung gelassen, falls trotz geöffneter Fenster scharf geschaltet werden soll:

Code Auswählen Erweitern

EZ.vierfachTaster.Btn01:Long\s15_.*
(erfordert dann nur "etwas" Geduld - sollte didaktisch also eher zum Schließen der Fenster motivieren, als zum ewigen Taster-Drücken )

Nochmal Danke und lieben Gruß
Nils

[Prof. Dr. Peter Henning]

Zum Thema TTS habe ich ein ganzes Kapitel in DEM BUCH geschrieben. Ich gebe meine Sprachnachrichten entweder pre-recorded auf das Homematic-Teil aus, oder (mit der gleichen TTS-Engine Ivona) auf ein wandhängendes Tablet. Geht klasse - auch die wildesten Nachrichten...

LG

pah

[NilsB]

Hallo pah,

das Kapitel kenne ich
Nachdem ich für die pre-recordings auf dem HM-Gong mit der Mac on-board TTS nicht zufrieden war habe ich auf deinen Tip Ivona zurückgegriffen. Die Qualität dort ist wirklich überzeugend.

"Android Tablet" ist natürlich ein gutes Stichwort. Noch ist der WAF aber nicht bei einem adäquaten Level für "Tablet an der Wand" angelangt. Außerdem habe ich den HM-Gong Bausatz genommen und mit Einbau-Lautsprechern unauffällig in ein vorhandenes Deko-Möbelstück integriert. Deshalb der Wunsch...

Für interessierte mal ein Foto des unauffälligen Selbstbaus im Anhang (Diese Lautsprecher wurden mit dem HM-Bausatz verwendet).

Gruß
Nils

[Prof. Dr. Peter Henning]

Ich habe den HM-Bausatz noch herumliegen - derzeit steckt schon seit einem Jahr das Fertiggerät in der Steckdose.

Hat den Vorteil, dass auch Lichtsignale möglich sind.

LG

pah

[stefanm]

Für die Sprachausgabe verwende ich einfach Raspberry, auf dem fhem läuft. Aktivlautsprecher an die 3,5 Klinkenbuchse angeschlossen und fertig.

Ich habe , für mich auch eine Lösung der Bewegungserkennung gefunden.

Wieder ein Raspberry Pi mit opencv und fhem als Slave.

Wenn opencv eine Bewegung erkennt wird fhem getriggert und sendet den Befehl per fhem2fhem an die Zentrale. Das Bild wird gespeichert.
Die Cam wird von der Zentrale ebenfalls per fhem2fhem ein und ausgeschaltet.

Stefan

[NilsB]

@pah: Die Sache mit der LED ist kein Schlechter Punkt. Zum Visualisieren einer Scharfschaltung zB sehr gut geeignet Dafür musste ich extra noch LEDs in der Nähe der Korridortür anbringen und verkabeln.

@stefanm: Da läuft ja eine ganze raspi-farm. Insbesondere die Idee openCV dafür einzusetzen finde ich nicht schlecht. Schonmal an die Gesichtserkennung zur Unscharfschaltung gedacht?

Noch etwas in eigener Sache:
Ich bin heute angefangen einen room für die Alarm-Bedienung via Smartphone zu bauen. Wollte dafür ganz gerne die vorgesehene Anzeige des Moduls benutzen. Habe dementsprechend das Attribut statedisplay auf color gesetzt. Leider funktioniert das ganze noch nicht. Konkret werden immer die Level 1-5 rot angezeigt und 6-7 grün. Momentan nutze ich nur die Level 6 und 7, möchte die anderen zwecks Flexibilität aber eigentlich nicht im Modulcode wegrationalisieren (zumal ich mir unsicher bin was dann mit meinen bereits eingerichteten Levels passiert).

Ich könnte mir vorstellen, dass der Fehler in den ungenutzten Alarmlevels liegt (in der Alarms-Konfiguration sind alle Felder dieser Level leer). Denn ich erhalte auch nach jedem Set Alarms entsprechende Fehlermeldungen im Log:

Code Auswählen Erweitern

2016.02.25 20:30:14 1: [Alarm 0] Will not be executed due to wrong time spec 1 for level0start
2016.02.25 20:30:14 1: [Alarm 1] Will not be executed due to wrong time spec 1 for level1start
2016.02.25 20:30:14 1: [Alarm 2] Will not be executed due to wrong time spec 1 for level2start
2016.02.25 20:30:14 1: [Alarm 3] Will not be executed due to wrong time spec 1 for level3start
2016.02.25 20:30:14 1: [Alarm 4] Will not be executed due to wrong time spec 1 for level4start
2016.02.25 20:30:14 1: [Alarm 5] Will not be executed due to wrong time spec 1 for level5start
2016.02.25 20:30:15 3: [Alarm 6] Created disarm notifier
2016.02.25 20:30:16 3: [Alarm 7] Created arm notifier
2016.02.25 20:30:16 3: [Alarm 7] Created disarm notifier

Liegt es daran bzw. wie kann ich die Anzeige am besten zum Funktionieren bringen?

Grüße
Nils

[stefanm]

An die Gesichtserkennung hab ich auch schon gedacht.

Jetzt verwede ich einen RFID Reader mit Zahlenschloß( falls der Anhänger verloren geht)

Mit der Gesihterkennug hab ich gerade im Winter die Befürchtung, das es Probleme gibt. Ab er testen könnte man das ja mal

[Prof. Dr. Peter Henning]

Davon kann ich nur abraten. Gegenwärtige Gesichtserkennungssysteme sind nicht nur bei Teilverdeckung des Gesichtes unzuverlässig, sondern können auch problemlos durch eine vorgebundene Pappmaske mit dem Foto des Betreffenden ausgetrickst werden.

Stand der Technik bei der Zugangskontrolle ist die Kombination von Besitz und Wissen - also z.B. eines iButton oder RFID-Chip und der Kenntnis einer Codenummer (PIN).

LG

pah

[NilsB]

Nun gut, an dem Thema mit der Pappmaske ist wohl was dran. Dann müssen wir eben bei der NFC-Lösung bleiben (läuft bei mir auch). Denke die Usability ist auch absolut zufriedenstellend, da der Schlüsselbund ohnehin in der Hand ist

Darf ich nochmal fragen, ob jemand eine Idee bzgl. meines Problems hat? Komme in der Angelegenheit leider nicht weiter.

Noch etwas in eigener Sache:
(...) Konkret werden immer die Level 1-5 rot angezeigt und 6-7 grün (...)

Bin für jede Hilfe dankbar!
Mit bestem Gruß
Nils

[mollo]

Nach vergeblichen Versuchen für den Level 4 die Zustandsprüfung ohne größere FHSM und Perl Kenntnisse zum Laufen zu bringen, habe ich mich erst mal auf den Level 6 Einbruch konzentriert.
Ich nutze HM Fensterkontakte zur Absicherung und schalte den Level 6 per TabletUi scharf.
Mein Problem ist die Erkennung eines offenen Fensters, wenn Level 6 scharf geschaltet wird.
Wie bekomme ich eine Nachricht und wie muß der Handlungablauf dann aussehen?
Dies sollte über TabletUi steuerbar sein, damit auch der Nachbar, bei meiner Abwesenheit,
den Level  6 steuern kann (Blumen gießen).
Ich wäre für Tipps, über die Vorgehensweise zur Lösung, sehr dankbar.

Grüße,
Thomas

[NilsB]

Mein Problem ist die Erkennung eines offenen Fensters, wenn Level 6 scharf geschaltet wird.
Wie bekomme ich eine Nachricht und wie muß der Handlungablauf dann aussehen?

Hallo Thomas,
wenn ich recht verstehe möchtest du eine Kontrolle auf verschlossene Fenster vor Scharfschaltung durchführen und dann ggf. scharf schalten (alle Fenster zu) oder eben nicht (>= 1 Fenster geöffnet).

Hierzu kann ich nur auf die jüngst exerzierte Diskussion dieses Threads verweisen - jmike hat hervorragende Hilfe geleistet, welche spätestens in Kombination mit meiner Lösungspräsentation zum gewünschten Ergebnis führen sollte.
Hier die relevantesten Posts:

http://forum.fhem.de/index.php/topic,26893.msg406786.html#msg406786
http://forum.fhem.de/index.php/topic,26893.msg408550.html#msg408550
http://forum.fhem.de/index.php/topic,26893.msg410523.html#msg410523

Gruß
Nils

[tpm88]

Anbei eine Art Template dafür, gefüllt mit einer Auswahl an Aktionen, welche bei mir sinnvoll sind (teilweise noch mit zusätzlichen Debug-Ausgaben).

Hmmm - geht es nur mir so? Jedenfalls kann ich kein Template / Attachment finden??

[Mario67]

Ich könnte schwören...
Keine Ahnung wo das Attachment hin ist. Nun nochmal ein passender Auszug aus dem Modul 99_myUtilsAlarm.pm.

Die dummy AlarmFired, AlarmDisplayFired, AlarmCancel, AlarmArm, sowie der readingsProxy AlarmDisarm (einfache Negation des Zustandes von AlarmArm) werden in der Konfiguration des Alarm-Device verwendet.

Ich hoffe ich habe beim Ausdünnen nicht zuviel entfernt. Ist ja auch mehr als Anregung gedacht.

Grüße,
Mario