Neues Modul für Alarmanlage

Begonnen von Prof. Dr. Peter Henning, 08 September 2014, 20:43:06

Vorheriges Thema - Nächstes Thema

mollo

Hallo Nils,
vielen Dank für Deine Links
Zitat
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

Ich habe versucht diese auf meine Installation anzupassen:

define ready2Arm dummy
define fensterKontaktNtfy notify .*[fF]enster.*(open|closed)$ {checkArmState()}
define SW_Alarm6_Armed dummy
attr SW_Alarm6_Armed setList on off
define armAction notify SW_Alarm6_Armed:on { if(Value("ready2Arm") eq "0"){fhem("set AAA armed ");;}else{fhem("set MyTTS tts Achtung keine Scharfschaltung");;}}


trigger fensterKontaktNtfy open zeigt im ready2Arm reading armError 0, wenn geschlossen oder  FK08_Haustuer ist offen!, wenn geöffnet.
Daraus schließe ich, das checkArmState in 99_myUtils.pm funktioniert.
Was nicht funktionier ist armAction, den hier wird immer nur FK08_ Haustür ist offen geliefert.

Wie muß hier ein Trigger aussehen oder wie könne ich das Ergebnis von read2Arm mit einem vereinfachten Notify testen?
Kar ist mir auch nicht, wie ich das Original Beispiel aus http://forum.fhem.de/index.php/topic,26893.msg410523.html#msg410523
in fhem.cfg übertrage (ich nutze unter Win 7 PUTTY, um auf meine Raspberry Pi FHEM Installation zuzugreifen).

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

Nochmal vielen Dank im Voraus für eine hilfreiche Antwort.

Grüße,
Thomas


seb

#556
Servus,

hat schon mal Jemand versucht den aktuellen Alarm als Jabber zu senden?
Per Mail geht bei mir einwandfrei, als Jabber-Message bekomme ich aber immer nur den Variablen-Name statt des Inhalts :(

{fhem 'set JabberClient1 msg bla@blub.de 'ALARM''}; : Bad name after ALARM' at (eval 546) line 1.
(gleiches fuer 'AAA')

EDITH: got it

{fhem('set JabberClient1 msg bla@blub.de ALARM: [AAA:short]')}

VG
//seb

jmike

@Mollo/Thomas:

Zitat von: mollo am 09 März 2016, 14:31:33
Was nicht funktionier ist armAction, den hier wird immer nur FK08_ Haustür ist offen geliefert.

Mir scheint als ist das Zusammenspiel aus den ganzen Code Schnipseln nicht ganz klar.

- Notify ready2Arm sollte bei jeder Fenster Aktion (auf|Zu) die Routine checkArmState ausführen.
- Routine checkArmState prüft alle definierten Aktoren und schreibt das Ergebnis zurück in ready2Arm.

Dadurch sollte sich ein konsistenter Zustand der Sensoren in ready2Arm befinden - oder eben 0 wenn alles zu ist.

- armAction ist ein Switch den Nils verwendet um scharf zu schalten - je nachdem was ready2Arm schlussendlich sagt.

Demzufolge soll armAction gar nichts liefern, sondern entweder scharf schalten oder den "Fehler" per Sprachausgabe übermitteln.

Wenn das nicht hilft (und ich mir geirrt habe ;) ) poste doch noch mal explizit wie es nun bei dir aussieht. Ich kann ehrlich gesagt nicht ganz unterscheiden was Beispiel ist und was nun bei dir läuft.

lg
mike

KölnSolar

#558
Nun bin auch ich (fast) zufriedener Anwender des tollen Alarmanlagenmoduls. Nach einiger Eingewöhnungszeit, die die Komplexität des Moduls mit sich bringt, funktionieren diverse Alarmierungen aufgrund von einfachen events perfekt.

Was mir fehlt bzw. wonach ich nun suche, ist, Zahlenwerte von Sensoren abzufragen. Golem hatte bereits eine ähnliche Anfrage in Post
https://forum.fhem.de/index.php/topic,26893.msg312649.html#msg312649 gestellt, die aber unbeantwortet blieb.

In meinem Fall habe ich einen Bewegungsmelder nebst Lampe über einen Stromsensor angeschlossen. Sobald der Bewegungsmelder(0,7 W standby) auslöst, steigt die Leistung und ich möchte alarmiert werden. Das Event sieht wie folgt aus:

2016-03-24 12:31:00 TRX_WEATHER Mess_4 energy_power: 50.2 W

Gelöst habe ich es vorerst mit dem regexp:      Mess_4:energy_power:.[1-9].*
um bei Werten größer 0.9 Watt einen Alarm auszulösen.

Nun möchte ich aber auch noch Sabotage einschließen, also 0 W und somit Auslösung bei 0 oder > 0.9 W, wobei nicht zur Auslösung führende Werte mit 0.x W ankommen. Das:

Mess_4:energy_power:.([1-9].*|0.W)

funktioniert schon mal nicht. Ein Perl-Kenner eine Idee, was daran falsch ist oder wie ich das sonst mit Regexp lösen kann ?

Ein vorgeschaltetes Dummy-Device als Lösung fände ich unschön, da damit die schöne Übersichtlichkeit/Transparenz durch das Alarmanlagenmodul meines Erachtens "zerstört" würde.

Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

jmike

Hi Markus.

Zeig mal ein Event bei 0 Watt bzw probier mal:

Mess_4:energy_power:.([1-9]0*\.[1-9]|0\.0)\sW.*


Das wird auf "0.0 W" als auch alles oberhalb 1.0 W greifen, aber eben nicht 0.7 W

KölnSolar

Danke für die superschnelle Antwort. Wie Du schon schriebst:

0 W  ;D  also eben ohne Dezimalpunkt, leider. Und somit dürfte Dein Lösungsvorschlag nicht funktionieren.

wenn ich es richtig verstehe machst Du mit \. eine Maskierung, um aus dem Punkt im Sinne eines Platzhalters einen "echten" Punkt abzufragen, oder ? (nur um off-Topic die wilde Welt der regexp zu verstehen)

Und außerdem geht wahrscheinlich irgendetwas mit einem | sowieso nicht, weil das Alarmanlagen-Modul das Zeichen als Trenner in den alarmSettings benutzt wird und eine Eingabe, Dein Vorschlag, mit einem | verworfen bzw. nicht gespeichert  wird. Gab da ja auch mal eine Wunschäußerung zu, die von pah abgelehnt wurde. Ich hatte nur gedacht, dass man das dann wenigstens mit den Klammern umgehen kann oder lässt sich da auch was maskieren ?

Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

jmike

Hi Markus.

Hm, sehr kniffelig zumal der ODER Operant, wie du richtig gesagt hast, nicht erlaubt ist. Da war ich etwas zu "Zielorientiert" unterwegs und hab die Umgebung vergessen ;)

Ich bastel mal noch etwas weiter und vielleicht findet ja ein anderes Mitglied noch eine Lösung.

Eine Alternative ohne Dummy wäre auch als "Action" eine perl sub auszuführen, welche die Auswertung übernimmt und dann entsprechend reagiert.


KölnSolar

Du sagst es: echt knifflig unter den Voraussetzungen. Vielleicht lässt Pah sich ja mal erweichen, das ODER in Form Maskierung, Klammerung .... irgendwie zuzulassen.

Und den Ansatz es über die Action zu realisieren hatte ich auch schon. Hat auch prima funktioniert, ABER das macht einem die Logs dicht, weil ja (sinnvollerweise) das notify des Sensors zu einem Event führt  :-\

Aber prima, dass Du versuchst zu helfen, zumal ich bei Perl, insbesondere Klammern, Kommas, Strichpunkte, Anführungszeichen, Regexp, immer wieder an meine Grenzen stoße
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

wenn ich auf Glühbirnen mit Leistung < 10 W verzichte, funktioniert für meine Zwecke dieser regexp

energy_power:..[^\.].*

also alle events, die keinen Punkt an der 2. Stelle haben: xy.z W und 0 W nicht aber x.y W
Ziel erreicht. Nur in 3 Tagen verstehe ich das selber nicht mehr ;-(
Frohe Ostern
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

mollo

Hallo Nils und Mike,
nachdem ich begriffen habe, dass
fensterKontact notyfy bei jedem Öffnen und Schließen eines Alarmkontaktes über
checkArmState in
ready2Arm über setReading armError  den Status der Alarmkontakte speichert,
funktioniert alles, nachdem ich resdy2Arm richtig in armAction notify abfrage:
define armAction notify SW_Alarm6_Armed:on { if(ReadingsVal("ready2Arm","armError","") eq "0")...............................}

Vielen Dank für die hilfreichen Tipps.
Grüße,
Thomas

jmike

Hallo.

Ich habe eine Frage an Prof. Dr. Henning.

Ich nutze das Modul schon eine ganze Weile und bin sehr zufrieden. Nur die Sache mit dem ? nach jedem Arm/Disarm juckt mich etwas, da dadurch auch echte Konfigänderungen untergehen und man dazu neigt einfach "blind" auf "save config" zu klicken.

Das Feature kam mit 5.7 wenn ich mich recht erinnere, also nach der Entwicklung des Moduls.
Ich verstehe auch warum hier grundsätzlich Attribute für die meisten Konfigurationswerte Sinn ergeben und dies nicht geändert wird.

Nur bei den "levelNxec" konnte ich keinen Grund finden warum diese nicht in den Readings abgebildet werden könnten - ausser dass man es nicht mischen möchte.

Das ist kein direkter RFE sondern mehr eine Verständnisfrage, zumal das Problem ja eher kosmetischer Natur ist.

Sollte dies doch potential haben in Version 2.7 zu kommen wäre ich auch bereit die Änderungen (sub Alarm_Exec, #-- compose commands, CommandAttr soweit ich gesehen habe) umzusetzen / zu testen soweit erwünscht.

Danke & viele Grüße,
Mike




Prof. Dr. Peter Henning

Äh - so ganz verstehe ich die Frage nicht.

Das nervige "?" kann auch ausgeschaltet werden - ist eine Frage des Webfrontends, nicht des Alarm-Moduls.

Die "levelNexec" sind bewusst als Attribute angelegt, damit sie in der Konfigurationsdatei gespeichert werden. Readings sind immer "flüchtig".

LG

pah

Tommy5

#567
Hallo,
zunächst herzlichen Dank für dieses Modul.
Nach einigen Schwierigkeiten habe ich das Modul zum Laufen gebracht und es funktioniert mit 1 Sensor, 1 Fernbedienung und 1 Funkgong.
Vor dem weiteren Ausbau möchte ich aber noch einen Fehler beseitigen den ich einfach nicht lokalisieren kann. Vielleicht weiss jemand Rat.
Nach einem "Neustart" oder "Restart" des Rasperry 2 (Wheezy) und nach jedem "Shutdown restart" von FHEM kommen immer Fehlermeldungen:

2016.04.23 16:01:58 1: configfile: Cannot load module Alarm
statefile: Please define AAA first
12 mal Please define AAA first

2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_Initialize redefined at ./FHEM/95_Alarm.pm line 53, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_Define redefined at ./FHEM/95_Alarm.pm line 81, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_Undef redefined at ./FHEM/95_Alarm.pm line 105, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_Attr redefined at ./FHEM/95_Alarm.pm line 121, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_CreateEntry redefined at ./FHEM/95_Alarm.pm line 134, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_Set redefined at ./FHEM/95_Alarm.pm line 169, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_Get redefined at ./FHEM/95_Alarm.pm line 207, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_getstate redefined at ./FHEM/95_Alarm.pm line 227, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_Exec redefined at ./FHEM/95_Alarm.pm line 279, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_Arm redefined at ./FHEM/95_Alarm.pm line 404, <$fh> line 17.
2016.04.23 16:02:19 1: PERL WARNING: Subroutine Alarm_CreateNotifiers redefined at ./FHEM/95_Alarm.pm line 475, <$fh>

und der "Raum" Alarms ist verschwunden!

Wenn ich jetzt mit "Edit files" die fhem.cfg aufrufe und "Save fhem.cfg" drücke, erscheint der Raum "Alarms" und alles funktioniert wieder!
Nach einem Stromausfall würde also das Modul nicht automatisch starten?

Wer weiss Rat?

Vielen Dank,
Frank

PS. vom 27.4.2016
Mit einem "rereadcfg" funktioniert es ebenfalls!


NilsB

Hallo pah,
Hallo Mike,

Zitat von: Prof. Dr. Peter Henning am 19 April 2016, 15:50:08
Äh - so ganz verstehe ich die Frage nicht.

Das nervige "?" kann auch ausgeschaltet werden - ist eine Frage des Webfrontends, nicht des Alarm-Moduls.
(...)
Ich übernehme mal die Antwort für Mike hier im Thread - gesetzt der Annahme, dass ihr so noch nicht weiter gesprochen habt. Ich befinde mich mit meinem Verständnis in einer ganz ähnlichen Situation wie Mike.

Zuerst sollte wahrscheinlich gesagt sein, dass Mike in seinem Post voraussetzt, dass das ?-Feature erstmal gut und erwünscht ist. Insofern ist es etwas schade, wenn das ? (wegen täglicher Alarmanlagen-Schaltungen) eigentlich immer angezeigt wird.

Zum Thema der konsistenten Speicherung der "levelNExec". Ich verstehe, was du sagst, pah. Aber mir ist nicht ganz klar warum die aktuellen Zustände der Alarmlevel nicht nur zur Laufzeit FHEMs gespeichert werden sollten (also als Readings). Nach einem Neustart würde ich es absolut begrüßen, wenn erstmal alles "unscharf" ist. Mit dem momentanen Stand habe ich nämlich immer Angst, mir einen Alarmlevel als aktiv in der Config zu speichern und beim nächsten Neustart zu Wartungszwecken die Alarmanlage unbewusst scharf zu schalten (was dann in hektischem Gerenne endet, wenn der nächste ein Fenster aufmacht...).

Eventuell liegt der Ursprung aber auch in unterschiedlichen Anwendungen des Moduls - wenn ich deine (pah) Anwendungsbeispiele nochmal reflektiere, hast du sehr viele Alarmlevel zeitbasiert gesteuert, oder? Wenn man dann noch einen geplanten Neustart in einem solchen Zeitfenster hat, wäre das Bevorzugen der konsistenten Speicherung der Zustände natürlich auch nachvollziehbar.

Ich würde mich über ein bisschen "Erleuchtung" freuen.

Danke,
Nils

Prof. Dr. Peter Henning

Derzeit habe ich keine persönlichen Kapazitäten für irgendwelche Änderungen an dem Alarm-Modul frei.

Komplexe Bedigungen werde ich sowieso nicht implementieren - die gehören in ein vorgelagertes userreading oder dummy, bei mir beispielsweise für eine abendliche Überprüfung aller Fenster.

Das Verhalten beim Neustart werde ich mir durch den Kopf gehen lassen. Kann man aber auch derzeit schon durch eine kleine externe Routine abfangen.

LG

pah