Globale und flexible Fenster- und TürüberwachungAus der Idee und Anregung aus folgendem Thread "Dynamischer Watchdog" (http://forum.fhem.de/index.php/topic,34482.msg268826.html#msg268826) habe ich für mich eine flexible Fenster und Türüberwachung aufgebaut, die mir entsprechende Meldungen auf mein Handy schickt (via Pushover), wenn ein Fenster, bzw. eine Tür bestimmte Mindest-Zeit lang offen ist.
Es kann (!) dabei variabel für jeden Fenster- (FK) und Türkontakt (TK) per Attribute festgelegt werden, nach welcher Zeit die Meldung erscheinen soll, bzw. nach welcher weiteren Zeit ggf. nochmals gewarnt werden soll und wie oft gewarnt werden soll.
Zusätzlich habe ich für die Verwendungen in den Meldungen zwei weitere Attribute in Verwendung, mit denen zum Einen eine sprechende Bezeichnung für das Fenster oder die Tür (Bspw. "Das Toilettenfenster im OG") und ein "Gerätetyp" (Bspw. "Fenster") angegeben werden können.
Bisher hatte ich dazu für jedes Fenster, bzw. für jede Tür entsprechend einen oder mehrere Watchdog-devices, die das übernommen haben.Jetzt gibt es dazu insgesamt für alles nur noch 2 Notifies, sowie 2 Funktionen in der
99_MyUtils.pm, die von den Notifies aufgerufen werden.
Soll nun für einen FK oder TK eine Überwachung eingerichtet werden, müssen nur noch die entsprechenden Attribute als userattr definiert und belegt werden. Im einfachsten muss lediglich das Attribut
winOpenMaxTrigger angegeben werden und das sollte größer 0 sein. Ist dieses Attribut größer als 1 angegeben, so werden entsprechend Wiederholungs-Meldungen ausgegeben (n-1 Wiederholungen).
Weitere mögliche Attribute, die (optional) beim auslösenden Device angegeben werden können sind folgende:
- winOpenName - Ein schöner Klartext-Name für das Device für die Meldung (Default ist alias, bzw. NAME)
- winOpenType - Eine Typbezeichnung für die Meldung (Bei mir quasi als Betreff)
- winOpenTimer - Die Zeit, die gewartet werden soll, bis die erste Offen-Meldung ausgegeben werden soll (Default 10 Minuten)
- winOpenTimer2 - Optinaler 2. Zeitraum für die Folgemeldung(en) (Default = winOpenTimer, bzw. 10 Minuten)
Die Attribute müssen beim Device (TK/FK) zuvor per userrattr definiert werden:
attr <device> userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
Als erstes mal die sub, die von einem notify aufgerufen wird, sobald ein FK oder TK diese durch einen 'open' oder '
tilted'-Event auslöst. Dazu wird von dieser Funktion ein entsprechender Timer (at) angelegt, das den selben Namen hat, wie das auslösende Device, mit angehängtem
_OpenTimer.
Kleiner Hinweis: Ich habe den verwendeten Code sehr ausführlich kommentiert, so dass möglichst jeder folgen kann, was in welcher Code-Zeile genau passiert.
sub winOpenStart($;$) {
#Als Parameter muss der device-Name übergeben werden
my $dev=shift(@_);
#Optional kann noch ein Zähler für das erneute Triggern übergeben werden,
#dieser ist per default 0
my $retrigger=shift(@_);
$retrigger=0 if (!$retrigger);
#Erst mal prüfen, ob das übergebene device überhaupt existiert
if ($defs{$dev}) {
#Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
#angibt, wie oft eine Meldung ausgegeben werden soll.
#Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
if($maxtrigger) {
#Festlegen des Namens für den Timer, der angelegt wird um die Meldung nach gewünschter
#Zeit auszugeben.
my $devtimer=$dev.'_OpenTimer';
#Sollte dieser Timer bereits existieren, so wird er zunächst gelöscht.
fhem("delete $devtimer") if ($defs{$devtimer});
#Holen von weiteren Attributen, sofern vorhanden:
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 10 Minuten, falls nicht angegeben
my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
#Zeit für die Folge-Meldungen, sofern abweichend angegeben
#Default ist die normale Zeit, die oben schon ermittelt wurde
my $devtimer2=AttrVal($dev,'winOpenTimer2',$waittime);
#Ein eventuell definierter "schöner" Name für das Device, der in der Meldung ausgegeben werden soll.
#Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
#device-Name genommen.
my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
#Eine Art Typ (Tür oder Fenster), der bei mir quasi im Betreff der Offen-Meldung angegeben wird
my $devtype=AttrVal($dev,'winOpenType','Fenster/Tür');
#Hier wandeln wir noch den state des devices in deutschen Klartext um
my $devstate='offen';
$devstate='gekippt' if (ReadingsVal($dev,'state','') eq 'tilted');
#Hier wird, sofern bereits eine Wiederholung der Offen-Meldung ausgegeben werden soll,
#dies textlich auch so berücksichtigt.
my $immer='noch ';
$immer='immer noch ' if ($retrigger>0);
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
# meine Meldungen über Pushover ausgibt)
my $pushcmd="PushInfo('$devtype','$devname ist $immer $devstate');;";
#Sind wir schon beim Einrichten einer Folgemeldung, muss die Wartezeit für die Folgemeldungen
#genommen werden.
$waittime=$devtimer2 if ($retrigger);
#Wir erhöhen hier den Trigger-Zähler um 1...
$retrigger+=1;
#... und fügen das Re-Triggern als weitere Code-Zeile für das at-DEF an.
#das sorgt dann dafür, dass diese Funktion hier nach Ablauf des Timers einfach wieder
#getriggert wird, um einen neuen Timer anzulegen für die Folgemeldung
$pushcmd.="winOpenStart('$dev','$retrigger');;" if($retrigger < $maxtrigger);
#Nachdem wir hier alles zusammen haben,
#legen wir den Timer (das at) an und legen ihn freundlicherweise in den, bzw. die
#selben Räumen ab, wie auch das auslösende device.
fhem("define $devtimer at +$waittime {$pushcmd}");
fhem("attr $devtimer room ".AttrVal($dev,'room','Unsorted'));
}
}
}
: Die in der
winOpenStart enthaltene Funktion "
PushInfo()" muss natürlich durch eine eigene Push oder E-Mail-Funktion ersetzt werden. Im einfachsten Fall und zum Testen kann man hier auch einfach mal einen Log-Eintrag mittels
Log3() erzeugen.
(Ein Beispiel (http://forum.fhem.de/index.php/topic,36504.msg288872.html#msg288872) dazu gibt's inzwischen ein paar Posts weiter unten in diesem Thread.)
Das Notify, das diese Funktion hier aufruft, ist bei mir relativ global gefasst, da alles andere direkt in der Funktion abgefragt, bzw. abgefangen wird:
define winOpen.OpenNotify notify .*:(open|tilted) {winOpenStart($NAME)}
Weiterhin gibt es noch ein 2. Notify, das auf den entsprechenden closed-Event triggert und den Timer auch wieder löscht, sofetn dieser noch aktiv ist. Dieses ist ebenso relativ global gefasst:
define winOpen.CloseNotify notify .*:closed {winOpenStop($NAME)}
sub winOpenStop($) {
#Dazu muss das entsprechende device (TK/FK) per Name hierher übergeben werden
#Den übergebenen device-Namen holen
my ($dev)=@_;
#Den Namen des Timers zusammenbauen
my $devtimer=$dev.'_OpenTimer';
#Existiert ein Timer diesen Namens, so wird er jetzt gelöscht und das war's auch schon.
if ($defs{$devtimer}) {
fhem("delete $devtimer");
}
}
Als Fensterkontakte habe ich bei mir übrigens von Homematic den
HM-SEC-SC-2 bzw. den
HM-SEC-RHS in Verwendung.
Beispiel:Als kleines Beispiel kann zum Testen ja mal ein einfacher Dummy definiert werden:
Zitat
Internals:
CFGFN
NAME FensterTestDummy
NR 7060
STATE closed
TYPE dummy
CHANGETIME:
Readings:
2015-04-19 22:24:51 state closed
Attributes:
room DEVELOP
setList open closed tilted
userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
webCmd closed:open:tilted
winOpenMaxTrigger 3
winOpenName Fenster Test-Dummy
winOpenTimer 00:00:15
winOpenTimer2 00:00:30
winOpenType Fenster
Update 08.05.2019: @flummy1978 hat in folgendem Beitrag (https://forum.fhem.de/index.php/topic,36504.msg929029.html#msg929029) seine Umsetzung mit sleep, statt at zur Verfügung gestellt. Ich selbst habe es nicht getestet, da bisher aber keine negativen Rückmeldungen gekommen sind, gehe ich davon aus, dass es funktioniert:
Zitat von: flummy1978 am 10 April 2019, 22:25:33
Ich habe das jetzt mit sleep & cancel sleep übernommen und umgesetzt.
Sehr Cool! Sowas habe ich schon lange gesucht!
Könnte man das Intervall noch an die Außentemperatur koppeln?
Je kälter, fest schneller kommt die Warnung.
Klar könnte man!
Man kann das ganze im Prinzip beliebig komplex stricken.
Man kann aber auch einfach das Intervall für die Meldung und ggf. die Wiederholungen relativ kurz setzen und dann einfach die erste Meldung ignorieren und erst nach der 2., 3. oder .... x-ten aufstehen und das Fenster wieder zu machen. ;)
Ob es kalt (oder zu warm) ist oder nicht, weiß man ja i.d.R. sowieso und wenn nicht, könnte man sich relativ einfach auch die aktuelle Außentemperatur in der Meldung mit anzeigen lassen.
Das macht einen sehr guten Eindruck.
Das global gehaltene gefällt mir und läßt sich sicher flexibel anpassen.
Kleine Anmerkung; müssen die beiden Notify (Notifies?) nicht anders definiert werden!?
define winOpen.OpenNotify notify .*:(open|tilted) {winOpenStart($NAME)}
define winOpen.CloseNotify notify .*:closed {winOpenStop($NAME)}
Hollo hat Recht ^^ danke! Hatte das garnicht gesehen, und mich über die Fehlermeldung gewundert ;)
Aber mit der Korrektur geht es ;)
Ups! Das passiert, wenn man mal was nicht per Copy&Paste übernimmt ;D
Ich habe das im ersten Post inzwischen korrigiert.
<klugscheissermodus>
Ach, übrigens gibt es zu notify eigentlich gar keinen Plural, da notify ein Verb ist. Das Substantiv dazu wäre notification und der Plural dann notifications
</klugscheissermodus>
:o
1.
also - obwohl alles richtig kopiert und subs abgelegt .. produziert keine at befehle im raum der Sensoren
(Raum heisst bei mir "Tuerschloss1")
2.
und die Ausgabe über
sub PushInfo($$$$$) {
my ($uebergabe) = @_;
fhem("set MyTTS tts hier die meldungen $uebergabe ");
}
klappt auch nicht ..
3.
und wie bitte kann man die die 10 Minuten in der sub für einzelne Sensoren übersteuern ?
bitte mal prüfen ob da nicht im Ablauf was fehlt oder falsch ist ...
MFG Harway
1. Wie sieht denn dein device für Tuerschloss1 aus? Gib mal bitte ein list des device an.
2. Wie sehen denn deine beiden notify aus? (jeweils noch ein list bitte) Meine PushInfo erwartet übrigens 2 Parameter und nicht 5, so wie deine. Steht irgendwas im Log?
3. Zum "übersteuern" der Zeiten gibt es die beiden Attribute winOpenTimer und winOpenTimer2.
Der Ablauf ist übrigens geprüft, getestet und bei mir Produktiv im Einsatz.
Bei mir funktioniert die Routine.
Ist doch alles im 1.Post erklärt.
Ich habe sie nachträglich auf einen Aufruf geschrumpft.
Ach ja im Start notify ist im 1.Post noch ein Fehler.
Zwischen open und tilted muss ein "|" und kein ":"
Da kann ich mich ja direkt nochmal selbst zitieren 8)
Zitat von: Benni am 21 April 2015, 10:25:49
Ups! Das passiert, wenn man mal was nicht per Copy&Paste übernimmt ;D
Den ersten Post habe ich dementsprechend nochmals korrigiert.
Zitat von: stromer-12 am 23 April 2015, 10:53:19
Ach ja im Start notify ist im 1.Post noch ein Fehler.
Zwischen open und tilted muss ein "|" und kein ":"
Darauf hatte ich als "Klugscheisser" ja schon direkt hingewiesen. ;D
Egal, solche Codeschnipsel sind Gold wert und kleine Tippfehler erkennt man meist duch aufmerksames Lesen der Fehlermeldung.
He das muss ich doch Test.
Mit Log3, ich habe noch nicht verstanden wie ich anstelle des Log ein Fhem befehl absetze?! Kann mir das einer sagen? (Set msg "test")
Das Log sieht so aus:
FensterTestDummy_OpenTimer: Not enough arguments for main::Log3 at (eval 6278) line 1, near "'Fenster Test-Dummy ist noch offen')"
Da stimmt doch irgendwas noch nicht?
Log3(undef,3,'blahblahblah');
http://forum.fhem.de/index.php?topic=14341.0 (http://forum.fhem.de/index.php?topic=14341.0)
Im Kontext von winOpenStart dann irgendwie so:
Log3($dev,1,"Fenster ist noch offen");
Alternativ geht hier natürlich auch immer noch problemlos das da
Log(1,'Fenster ist noch offen');
Hallo Benni,
danke sowas hab ich schon gesucht.
Da ich auch ein Meldung via Pushover senden will könntest du deine Sub dazu auch noch posten?
Denn das ganze ist noch eine nummer zu hoch für mich.
Danke
Danke für den Code.
Hab es mal schnell getestet, funktioniert prima.
Evtl. erweitere ich das noch um ei paar Dinge, die nicht Fenster oder Türe sind.
Dann hat man alles in einer Routine.
Zitat von: QuesT am 23 April 2015, 20:21:44
könntest du deine Sub dazu auch noch posten?
Denn das ganze ist noch eine nummer zu hoch für mich.
Könnte ich schon, allerdings würde dir das nicht wirklich weiterhelfen, denn meine PushInfo() macht etwas mehr, als einfach nur eine Meldung über Pushover abzusetzen. Es wird dort u.a. auch gleich noch geprüft, wer überhaupt alles eine Benachrichtigung bekommen soll (Anwesenheit) und über welchen Dienst, bzw. Dienste Meldungen ausgegeben werden sollen (Pushover, Pushbullet, E-Mail, Logfile ....).
Für die Pushover-Meldungen an sich verwende ich dabei übrigens auch einfach das Pushover-Modul.
Danke nur wie baue ich das heir um das ich eine nachricht per Pushover bekomme?
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
# meine Meldungen über Pushover ausgibt)
my $pushcmd="PushInfo('$devtype','$devname ist $immer $devstate');;";
Mein Pushover hast nur PO.
Und diesen Fehler bekomme ich auch noch:
2015.04.24 07:41:07 3: winOpen.CloseNotify return value: Global symbol "$MAX_xxxxx" requires explicit package name at (eval 979) line 1.
Damit hier jeder(!) auch mal was testen kann, ohne sich mit Pushover "rumschlagen" zu müssen kann einfach mal noch folgende sub in die 99_myUtils.pm einbauen:
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
Log3(undef,1,"winOpenMessage: $msgsubj - $msgtext");
}
Es wird dann statt einer Pushover-Nachricht eben eine Meldungszeile im Logfile eingetragen.
(Eventuelle Tipfehler möge man mir verzeihen, das habe ich jetzt einfach nur so auf die Schnelle hier reingetippt.)
Zitat von: QuesT am 24 April 2015, 08:23:27
Und diesen Fehler bekomme ich auch noch:
2015.04.24 07:41:07 3: winOpen.CloseNotify return value: Global symbol "$MAX_xxxxx" requires explicit package name at (eval 979) line 1.
Wie sieht denn dein winOpen.CloseNotify aus? Wieso verwendest du dort eine Variable $MAX_xxxxx?
Zitat von: Benni am 24 April 2015, 10:13:36
Wie sieht denn dein winOpen.CloseNotify aus? Wieso verwendest du dort eine Variable $MAX_xxxxx?
Sorry hat sich erledigt.
Hab einen dummy erstellt:
define FensterTestDummy dummy
attr FensterTestDummy userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
attr FensterTestDummy setList open closed tilted
attr FensterTestDummy webCmd closed:open:tilted
attr FensterTestDummy winOpenMaxTrigger 3
attr FensterTestDummy winOpenName Fenster Test-Dummy
attr FensterTestDummy winOpenTimer 00:00:15
attr FensterTestDummy winOpenTimer2 00:00:30
attr FensterTestDummy winOpenType FensterWenn ich nun den Dummy auf open stelle um 2015.04.24 10:48:48 sehe ich im Log folgendes:
2015.04.24 10:48:48 1: winOpenMessage: Fenster - Fenster Test-Dummy ist noch offen
2015.04.24 10:48:48 1: in DELETED
2015.04.24 10:48:48 1: in DELETED
2015.04.24 10:48:48 1: in DELETED
2015.04.24 10:48:48 1: in DEFINED
2015.04.24 10:48:48 1: in DEFINED
2015.04.24 10:48:48 1: in DEFINED
2015.04.24 10:48:48 1: in ATTR
2015.04.24 10:48:48 1: in ATTR
2015.04.24 10:48:48 1: in ATTR
2015.04.24 10:49:18 1: winOpenMessage: Fenster - Fenster Test-Dummy ist immer noch offen
2015.04.24 10:49:18 1: in DELETED
2015.04.24 10:49:18 1: in DELETED
2015.04.24 10:49:18 1: in DELETED
2015.04.24 10:49:18 1: in DEFINED
2015.04.24 10:49:18 1: in DEFINED
2015.04.24 10:49:18 1: in DEFINED
2015.04.24 10:49:18 1: in ATTR
2015.04.24 10:49:18 1: in ATTR
2015.04.24 10:49:18 1: in ATTR
2015.04.24 10:49:49 1: winOpenMessage: Fenster - Fenster Test-Dummy ist immer noch offen
2015.04.24 10:49:49 1: in DELETED
2015.04.24 10:49:49 1: in DELETED
2015.04.24 10:49:49 1: in DELETEDAlso alle drei meldungen in 1 Minute.
--
EDIT:
Lösche ich folgede Werte:
attr FensterTestDummy winOpenTimer 00:00:15
attr FensterTestDummy winOpenTimer2 00:00:30
geht es.
Liegt es daran das es die standart werte sind?
Wieso denn?
Es funktioniert alles doch korrekt:
winOpenTimer steht mit 00:00:15 auf 15 Sekunden(!)
winOpenTimer2 mit 00:00:30 auf 30 Sekunden(!)
Also kommt die erste Meldung nach 15 Sekunden, die 2. nach wieteren 30 Sekunden und die letzte nach nochmal 30 Sekunden.
Als Defaults sind mit 00:10:00 10 Minuten(!) hinterlegt.
Oh, wie immer ist das Problem vor dem Pc.
Sorry :'(
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
Log3(undef,1,"winOpenMessage: $msgsubj - $msgtext");
}
Wie bekomme ich die nachricht noch per Pushover?
Zitat von: QuesT am 24 April 2015, 11:34:23
Wie bekomme ich die nachricht noch per Pushover?
Damit bewegen wir uns jetzt in Richtun OT :)
http://fhem.de/commandref.html#Pushover
Wie ich Pushover verwende weis ich nur nicht wie in einer Sub / Perl.
Zitat von: QuesT am 24 April 2015, 11:58:46
Wie ich Pushover verwende weis ich nur nicht wie in einer Sub / Perl.
Das ist OT und das sind Grundlagen und gehört nicht in diesen Thread!
Ein letzter Tipp an dieser Stelle dazu: Schon mal was von der
fhem() - Funktion gehört/gelesen?
Ist auf jeden Fall eine sehr schöne Sache, dankeschön für das Bereitstellen :-)
Ich muss nur noch irgendwie bei mir den bzw. die notifies umstricken, da sie bei mir auch von den Heizkörper-Thermostaten ausgelöst werden (STATE last:eg.az.fenster :closed).
Für alle die es auch brauchen:
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
fhem("set <Pushover> msg 'winOpenMessage' '$msgsubj - $msgtext' ")
}
Weiter wenn man MAX ShutterContact einsetzt:
define winOpen.OpenNotify notify .*:(opened|tilted) {winOpenStart($NAME)}
Hallo in die Runde,
bin mal wieder am Raten, ich hätte die Ausgabe gerne auf meinem Mails. Leider mache ich bei der Syntax was falsch:
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
fhem ({DebianMail('XX@xx.com','winOpenMessage','$msgsubj - $msgtext')})
}schickt mir nämlich:
ZitatBetreff: winOpenMessage
Mail: $msgsubj - $msgtext
Vesuch es mal so:
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
fhem ({DebianMail('XX@xx.com','winOpenMessage',"$msgsubj - $msgtext")})
}
Denn sie wissen nicht, was sie tun ...
Zitat von: stromer-12 am 26 April 2015, 20:31:15
Vesuch es mal so:
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
fhem ({DebianMail('XX@xx.com','winOpenMessage',"$msgsubj - $msgtext")})
}
wie wäre es denn damit:
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
DebianMail('XX@xx.com',$msgsubj,$msgtext);
}Das ist übrigens schon wieder OT ;)
Danke erst mal für die Hilfe, nun komme ich schon wieder nicht weiter, auch wenn ich vielleicht OT bin damit.
Ziel ist es das notify so anzupassen, dass die Mail nur generiert wird, wenn im Modul Resident alle "Absent" sind, mag an der Uhrzeit liegen, aber bekomme ich nicht hin:
(Melder.*|Familie) if ((Value("Melder.*") eq "open") && (Value("Familie") eq "absent")) {winOpenStart($NAME)}
Bei mir Fangen alle Fesnter und Türen mit Melder an.
Hallo
ich wollte meinen watchdog zur Fensterüberwachung durch diese shr flexible Überwachung ersetzen, leider hat sich durch irgendetwas ein Fehler eingeschlichen. Ein Trigger2 scheint permanent zu laufen, obwohl ich ihn im System nicht finde.
Durch zusätzliche Log-Einträge versuche ich dem Übel auf den Grund zu gehen. Diese Logs entstehen, obwohl alle Fenster zu sind!
2015.12.05 10:59:55 1: sub winOpenStart Anfang Chr_Fenster
2015.12.05 10:59:55 1: sub winOpenStart Chr_Fenster
2015.12.05 10:59:55 1: sub winOpenStart Chr_Fenster
2015.12.05 10:59:55 1: timer 2 00:05:00
2015.12.05 11:00:00 1: trigger Chr_Fenster_OpenTimer PushInfo('Fenster','Fenster Christoph ist noch offen');;winOpenStart('Chr_Fenster','1');;
2015.12.05 11:00:00 1: sub winOpenStart Anfang Chr_Fenster
2015.12.05 11:00:00 1: sub winOpenStart Chr_Fenster
2015.12.05 11:00:00 1: sub winOpenStart Chr_Fenster
2015.12.05 11:00:00 1: timer 2 00:05:00
2015.12.05 11:00:01 1: trigger Chr_Fenster_OpenTimer PushInfo('Fenster','Fenster Christoph ist noch offen');;winOpenStart('Chr_Fenster','1');;
2015.12.05 11:03:59 1: sub winOpenStart Anfang Chr_Fenster
2015.12.05 11:03:59 1: sub winOpenStart Chr_Fenster
2015.12.05 11:03:59 1: sub winOpenStart Chr_Fenster
2015.12.05 11:03:59 1: timer 2 00:05:00
2015.12.05 11:04:00 1: trigger Chr_Fenster_OpenTimer PushInfo('Fenster','Fenster Christoph ist noch offen');;winOpenStart('Chr_Fenster','1');;
2015.12.05 11:08:03 1: sub winOpenStart Anfang Chr_Fenster
2015.12.05 11:08:03 1: sub winOpenStart Chr_Fenster
2015.12.05 11:08:03 1: sub winOpenStart Chr_Fenster
2015.12.05 11:08:03 1: timer 2 00:05:00
2015.12.05 11:08:04 1: trigger Chr_Fenster_OpenTimer PushInfo('Fenster','Fenster Christoph ist noch offen');;winOpenStart('Chr_Fenster','1');;
Meine Utils sieht wie folgt aus
###############################################################################
#
# Fenstersteuerung http://forum.fhem.de/index.php/topic,36504.0.html
#
# 1. Start
#
###############################################################################
sub winOpenStart($;$) {
#Als Parameter muss der device-Name übergeben werden
my $dev=shift(@_);
Log3($dev,1,"sub winOpenStart Anfang $dev");
#Optional kann noch ein Zähler für das erneute Triggern übergeben werden,
#dieser ist per default 0
my $retrigger=shift(@_);
Log3($dev,1,"sub winOpenStart $dev");
$retrigger=0 if (!$retrigger);
Log3($dev,1,"sub winOpenStart $dev");
#Erst mal prüfen, ob das übergebene device überhaupt existiert
if ($defs{$dev}) {
#Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
#angibt, wie oft eine Meldung ausgegeben werden soll.
#Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
# Log3($dev,1,"1. if $dev $maxtrigger");
if($maxtrigger) {
# Log3($dev,1,"2. if");
#Festlegen des Namens für den Timer, der angelegt wird um die Meldung nach gewünschter
#Zeit auszugeben.
my $devtimer=$dev.'_OpenTimer';
# Log3($dev,1,"2. if $devtimer");
#Sollte dieser Timer bereits existieren, so wird er zunächst gelöscht.
fhem("delete $devtimer") if ($defs{$devtimer});
#Holen von weiteren Attributen, sofern vorhanden:
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 10 Minuten, falls nicht angegeben
my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
# Log3($dev,1,"1. if $dev $waittime");
#Zeit für die Folge-Meldungen, sofern abweichend angegeben
#Default ist die normale Zeit, die oben schon ermittelt wurde
my $devtimer2=AttrVal($dev,'winOpenTimer2',$waittime);
Log3($dev,1,"timer 2 $devtimer2");
#Ein eventuell definierter "schöner" Name für das Device, der in der Meldung ausgegeben werden soll.
#Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
#device-Name genommen.
my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
#Eine Art Typ (Tür oder Fenster), der bei mir quasi im Betreff der Offen-Meldung angegeben wird
my $devtype=AttrVal($dev,'winOpenType','Fenster/Tür');
#Hier wandeln wir noch den state des devices in deutschen Klartext um
my $devstate='offen';
$devstate='gekippt' if (ReadingsVal($dev,'state','') eq 'tilted');
#Hier wird, sofern bereits eine Wiederholung der Offen-Meldung ausgegeben werden soll,
#dies textlich auch so berücksichtigt.
my $immer='noch ';
$immer='immer noch ' if ($retrigger>0);
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
# meine Meldungen über Pushover ausgibt)
my $pushcmd="PushInfo('$devtype','$devname ist $immer $devstate');;";
# Log3($dev,1,"push $pushcmd");
#Sind wir schon beim Einrichten einer Folgemeldung, muss die Wartezeit für die Folgemeldungen
#genommen werden.
$waittime=$devtimer2 if ($retrigger);
#Wir erhöhen hier den Trigger-Zähler um 1...
$retrigger+=1;
#... und fügen das Re-Triggern als weitere Code-Zeile für das at-DEF an.
#das sorgt dann dafür, dass diese Funktion hier nach Ablauf des Timers einfach wieder
#getriggert wird, um einen neuen Timer anzulegen für die Folgemeldung
$pushcmd.="winOpenStart('$dev','$retrigger');;" if($retrigger < $maxtrigger);
#Nachdem wir hier alles zusammen haben,
#legen wir den Timer (das at) an und legen ihn freundlicherweise in den, bzw. die
#selben Räumen ab, wie auch das auslösende device.
fhem("define $devtimer at +$waittime {$pushcmd}");
fhem("attr $devtimer room ".AttrVal($dev,'room','07 FensterSteuerung'));
fhem("attr $devtimer verbose ".AttrVal($dev,'verbose','5'));
Log3($dev,1,"trigger $devtimer $pushcmd");
}
}
}
###############################################################################
#
# 2. Stop
#
###############################################################################
sub winOpenStop($) {
#Dazu muss das entsprechende device (TK/FK) per Name hierher übergeben werden
#Den übergebenen device-Namen holen
my ($dev)=@_;
#Den Namen des Timers zusammenbauen
my $devtimer=$dev.'_OpenTimer';
# Log3($dev,1,"sub winOpenStop $dev $devtimer");
#Existiert ein Timer diesen Namens, so wird er jetzt gelöscht und das war's auch schon.
if ($defs{$devtimer}) {
fhem("delete $devtimer");
}
}
###############################################################################
#
# 3. Message
#
###############################################################################
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
# fhem("set <Pushover> msg 'winOpenMessage' '$msgsubj - $msgtext' ")
#}
# Log3(undef,1,"sub push winOpenMessage: $msgsubj - $msgtext"); #????
fhem ("set Juergens_TAB_S screen on;
set Juergens_TAB_S volume 10; sleep 2;
set pushMsg msg 'winOpenMessage' '$msgsubj - $msgtext' 'TabS-Juergen' 1 'climb'; sleep 8;
");
fhem ("set Juergens_TAB_S ttsMsg Achtung $msgtext !;
")
}
###############################################################################
Ursache liegt m.E bei dem $devtimer2. Ein restart habe ich durchgeführt. In der fhem.save finde ich auch nichts !
Ich hoffe, das mir einer helfen kan.
Jürgen
Kannst du mal bitte noch ein List des Device Chr_Fenster posten?
Hallo Benni
danke für die schnelle Reaktion
Internals:
CODE 51e996
CUL_0_MSGCNT 33
CUL_0_RAWMSG T51E99602
CUL_0_RSSI -71.5
CUL_0_TIME 2015-12-05 13:46:40
DEF 51e996
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 33
NAME Chr_Fenster
NR 168
OPEN 0
PREVSTATE Closed
PREVTIMESTAMP 1449319356
STATE Closed
TYPE CUL_FHTTK
CHANGETIME:
Helper:
Dblog:
Battery:
Mydblog:
TIME 1449317648.47355
VALUE ok
State:
Mydblog:
TIME 1449319600.03974
VALUE Closed
Prev:
STATE 02
TIMESTAMP 1449319600
Readings:
2015-12-05 13:46:40 Battery ok
2015-11-28 10:41:04 Previous Open
2015-12-05 13:46:40 Reliability ok
2015-12-05 13:46:40 Window Closed
2015-12-05 13:46:40 state Closed
Attributes:
DbLogExclude Reliability,Window,Battery:6000
IODev CUL_0
alias Fenster Christoph
devStateIcon Closed:signal_Fenster_Offen.off Open:signal_Fenster_Offen.on
group Fensterkontakte
icon fts_window_1w_open
model FHT80TF
room 00 Info,02 Devices,07 FensterSteuerung,Christoph
userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
winOpenMaxTrigger 10
winOpenTimer 00:15:00
winOpenTimer2 00:05:00
winOpenType Fenster
Im notify habe ich die Abfrage auf Open das FHT aktuell wieder raus.
Sorry,
auf die Schnelle kann ich erst mal nichts erkennen.
Ich werde es morgen mal auf meinem Testsystem so einbauen und schauen, was dann dabei raus kommt.
Kannst du mir bis dahin auch noch ein list der zugehörigen notify geben?
Das kriegen wir schon hin :)
Bis dahin mal noch 2 Dinge zum Ausprobieren: Den Device-Namen ohne Unterstriche gestalten und für das Device mal das attribut event-on-change-reading auf .* oder auf state setzen.
Hallo Benni
zum einen hat tatsächlich attribut event-on-change-reading auf .* dafür gesorgt, das hier das Chr_Fenster nicht irgendwie reinfunkt.
Zum anderen hatte ich nach dem ersten Test mit deinem Code in das Notify eine if-Abfrage auf Temeratur aus meinem watchdog eingefügt.
--> Diese Abfrage war mit le und wurde nie ausgeführt ! Nach langem rumdoktern habe ich die Abfrage auf < umgestellt. Siehe da, dass funktioniert!!!!
Danke Dir für die schnelle und gute Unterstützung sowie für das super Coding.
Jürgen
Hallo Jürgen,
super! 8)
Freut mich, dass es nun bei dir läuft!
Und danke für die Lorbeeren :)
Hallo
auch ich möchte gerne diese super flexible Meldung nutzen.
Ich habe alle so wie im ersten Thread beschrieben installiert.
Jedoch funktioniert der Timer2 nicht es wird immer nur der Timer ausgeführt.
Im Log steht folgendes:
define Fenster1_OpenTimer at +00:00:30 {PushInfo('Fenster','Fenster1 ist immer noch offen');;winOpenStart('Fenster1','2');;} : Fenster1_OpenTimer already defined, delete it first
Ein List Fenster1 ergibt folgendes:
Internals:
CFGFN ./FHEM/Raspberry.cfg
DEF RPI_PiFace:in1
DEVICE RPI_PiFace
NAME Fenster1
NR 348
NTFY_ORDER 50-Fenster1
READING in1
STATE closed
TYPE readingsProxy
Content:
RPI_PiFace 1
Readings:
2016-01-10 17:05:25 state 0
Attributes:
devStateIcon closed:fts_window_1w open:fts_window_1w_tilt
eventMap 0:closed 1:open
getFn 1
getList 1:noArg
room Flur
userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
valueFn ""
winOpenMaxTrigger 3
winOpenName Fenster1
winOpenTimer 00:01:00
winOpenTimer2 00:00:30
winOpenType Fenster
Was mach ich falsch? Kann mir jemand hierbei helfen?
Vielen Dank
Entweder wird das Event open mehrfach hintereinander ausgelöst. Das wird im Moment nicht abgefangen, es wird einfach davon ausgegangen, dass nach einem open für ein Device nicht nochmal ein open kommen kann.
Stichwort hier evtl. noch event-on-change-reading
Oder Problem liegt irgendwo in deiner sub winOpenStart deiner 99_myUtils.pm.
eventuell wird dort der Timer als periodischer Timer definiert (*)
kannst du die beiden Dinge mal prüfen und ggf. deine sub mal hier posten?
Aber bitte in Code-Tags!
Hallo Benni,
vielen Dank für die schnelle Antwort hier ist meine Sub.
Ein event-on-change-reading hab ich nicht, allerdings schreib ich mit addlog alle 5 Min. den state dieses events ins Log.
Ist dies evtl. das Problem?
Viele Grüße
Harald
sub winOpenStart($;$) {
#Als Parameter muss der device-Name �bergeben werden
my $dev=shift(@_);
#Optional kann noch ein Z�hler f�r das erneute Triggern �bergeben werden,
#dieser ist per default 0
my $retrigger=shift(@_);
$retrigger=0 if (!$retrigger);
#Erst mal pr�fen, ob das �bergebene device �berhaupt existiert
if ($defs{$dev}) {
#Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
#angibt, wie oft eine Meldung ausgegeben werden soll.
#Fehlt dieses Attribut oder ist 0, dann wird f�r das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
if($maxtrigger) {
#Festlegen des Namens f�r den Timer, der angelegt wird um die Meldung nach gew�nschter
#Zeit auszugeben.
my $devtimer=$dev.'_OpenTimer';
#Sollte dieser Timer bereits existieren, so wird er zun�chst gel�scht.
fhem("delete $devtimer") if ($defs{$devtimer});
# fhem("delete $devtimer");
#Holen von weiteren Attributen, sofern vorhanden:
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 10 Minuten, falls nicht angegeben
my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
#Zeit f�r die Folge-Meldungen, sofern abweichend angegeben
#Default ist die normale Zeit, die oben schon ermittelt wurde
my $devtimer2=AttrVal($dev,'winOpenTimer2',$waittime);
#Ein eventuell definierter "sch�ner" Name f�r das Device, der in der Meldung ausgegeben werden soll.
#Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
#device-Name genommen.
my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
#Eine Art Typ (T�r oder Fenster), der bei mir quasi im Betreff der Offen-Meldung angegeben wird
my $devtype=AttrVal($dev,'winOpenType','Fenster/T�r');
#Hier wandeln wir noch den state des devices in deutschen Klartext um
my $devstate='offen';
$devstate='gekippt' if (ReadingsVal($dev,'state','') eq 'tilted');
#Hier wird, sofern bereits eine Wiederholung der Offen-Meldung ausgegeben werden soll,
#dies textlich auch so ber�cksichtigt.
my $immer='noch ';
$immer='immer noch ' if ($retrigger>0);
#Jetzt wird der Ausgabebefehl f�r die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erh�lt und aktuell
# meine Meldungen �ber Pushover ausgibt)
my $pushcmd="PushInfo('$devtype','$devname ist $immer $devstate');;";
# my $pushcmd="Log3();;";
#Sind wir schon beim Einrichten einer Folgemeldung, muss die Wartezeit f�r die Folgemeldungen
#genommen werden.
$waittime=$devtimer2 if ($retrigger);
#Wir erh�hen hier den Trigger-Z�hler um 1...
$retrigger+=1;
#... und f�gen das Re-Triggern als weitere Code-Zeile f�r das at-DEF an.
#das sorgt dann daf�r, dass diese Funktion hier nach Ablauf des Timers einfach wieder
#getriggert wird, um einen neuen Timer anzulegen f�r die Folgemeldung
$pushcmd.="winOpenStart('$dev','$retrigger');;" if($retrigger < $maxtrigger);
#Nachdem wir hier alles zusammen haben,
#legen wir den Timer (das at) an und legen ihn freundlicherweise in den, bzw. die
#selben R�umen ab, wie auch das ausl�sende device.
fhem("define $devtimer at +$waittime {$pushcmd}");
fhem("attr $devtimer room ".AttrVal($dev,'room','Unsorted'));
}
}
}
sub winOpenStop($) {
#Dazu muss das entsprechende device (TK/FK) per Name hierher übergeben werden
#Den übergebenen device-Namen holen
my ($dev)=@_;
#Den Namen des Timers zusammenbauen
my $devtimer=$dev.'_OpenTimer';
#Existiert ein Timer diesen Namens, so wird er jetzt gelöscht und das war's auch schon.
if ($defs{$devtimer}) {
fhem("delete $devtimer");
}
}
Zitat von: Camper am 10 Januar 2016, 21:46:04
allerdings schreib ich mit addlog alle 5 Min. den state dieses events ins Log.
Ist dies evtl. das Problem?
Ja! Siehe entsprechenden Artikel im Wiki (http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden#Nebeneffekte)
Hi zusammen,
finde die Idee von Benni auch super und würde diese Lösung etwas abgeändert auch gerne bei mir verwenden.
Ich habe zunächst einmal alles 1:1 übernommen (beide winopen Routinen, die notify's und die PushInfo, die einfach nur ins Log schreibt) und das User Attribut folgendermaßen hinzugefügt:
attr eg_gb_fenster userattr winOpenMaxTrigger winOpenTimer:1 winOpenTimer2 winOpenType:Fenster,Türe winOpenName:Gaestebad
Die Beiden notify's funktionieren, beim Öffnen/Schließen bekomme ich bei log Level 5 angezeigt, dass gestartet/beendet wird. Allerdings gibt es weder eine Meldung ins Log, noch eine Whatsapp message (hatte ichvorher in der PushInfo).
Habe den winOpenTimer mal auf 1 gesetzt zum testen, aber auch wenn ich ihn weglasse passiert nach 10 Minuten nichts...Hat noch jemand eine Idee?
Gruß,
Tobi
Hallo Tobi,
gib mal bitte ein list von deinem eg_gb_fenster
wenn ich das richtig sehe hast du userattr nicht richtig verstanden.
Damit werden die zusätzlich möglichen Attribute für das device lediglich definiert.
gesetzt werden müssen sie natürlich mit ganz normal mit
attr <device> <attribut> <attributvalue>
Schau dir auch bitte nochmal im ersten Post (http://forum.fhem.de/index.php/topic,36504.msg287778.html#msg287778) den list des Beispiel-Dummys an. Dort siehst du, wie die Attribute bspw. zu setzen sind.
Gruß Benni.
Hi Benni,
danke Du lagst völlig richtig.
Nun sieht es so aus:
Attributes:
IODev HMLAN_AZ
IOgrp vccu:HMLAN_AZ
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 2.4
model HM-SEC-SC-2
peerIDs 00000000,
room CUL_HM
serialNr LEQ1243614
subType threeStateSensor
userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
winOpenName Gästebad
winOpenTimer 00:00:01
winOpenType Fenster
Scheine aber dann noch was falsch zu machen? Erstelle gerade mal einen Dummy und teste damit weiter.
Gruß,
Tobi
Hi,
habe es leider nicht hinbekommen...
Hat noch wer einen Tipp für mich?
Gruß,
Tobi
Zitat von: onkel-tobi am 28 Januar 2016, 14:08:29
habe es leider nicht hinbekommen...
das bedeutet jetzt was?
Was hast du versucht?
Was funktioniert und was nicht?
Am besten ist es wirklich, das ganze wie oben beschrieben einmal komplett 1:1 so durchzumachen (ja, mit den dummies), auch erst mal ohne eigene Anpassungen. Um zu sehen und zu verstehen, was wie funktioniert und zusammenspielt.
Hi Benni,
erst mal vielen Dank für deine Geduld ;)
Ich habe es inzwischen hinbekommen. Das korrekt gesetzte Attribut maxtrigger (wer lesen kann ist klar im Vorteil) hat zum Erfolg geführt.
Vielen Dank für die Arbeit und die Denkanstöße...
Gruß,
Tobi
Hallo Tobi,
freut mich zu hören!
Dann viel Freude damit!
Gruß Benni.
Hallo,
ich wollte mich ganz herzlich für deinen Code bedanken. Da ich genau so etwas haben wollte und immer wieder daran "herumgedoktert" habe, aber ich komme mit der FHEM-Syntax irgendwie noch nicht klar (peinlich eigentlich als Informatiker :'(), habe ich doch mal einen genaueren Blick ins Forum geworfen und siehe da... Und deinen Perl-Code kann man auch als Perl-Neuling sehr gut verstehen.
Also danke noch mal.
Lui.G
Hallo Benni,
vielen Dank für deinen Code. Hab es bei mir eingebaut und funktioniert auf anhieb auch ohne Perl Kentnisse :)
Eine Frage in die Runde:
Ist schon jemand dabei, das ganze mit Bezug zur Temperatur / Luftfeuchtigkeit (Taupunkt https://de.wikipedia.org/wiki/Taupunkt (https://de.wikipedia.org/wiki/Taupunkt)) je Raum zu erweitern?
Dabei wäre zu beachten, es gibt ggf. je Raum mehr als ein Fenster / Tür und man muss sowohl die im Raum gemessenen Werte mit den Werten außen vergleichen.
Es gibt da eine nicht so elegante Lösung auf meintechblog.de (http://www.meintechblog.de/2015/08/raumklima-im-smart-home-mit-fhem-verbessern-taupunktoptimiertes-lueften/ (http://www.meintechblog.de/2015/08/raumklima-im-smart-home-mit-fhem-verbessern-taupunktoptimiertes-lueften/)) aber das ist mir nicht generisch genug bei über 15 Fenster und Tür Kontakten sowie 7 überwachten Räumen.
Mir würde auch schon weiterhelfen, nur ein min Temperatur im Raum mit einzubauen.
Wenn ich irgendwann mal (kann auch Wochen dauern) dazu komme, dann fange ich damit mal an.
Grüße
Christian
ZitatIst schon jemand dabei, das ganze mit Bezug zur Temperatur / Luftfeuchtigkeit (Taupunkt https://de.wikipedia.org/wiki/Taupunkt) je Raum zu erweitern?
Dabei wäre zu beachten, es gibt ggf. je Raum mehr als ein Fenster / Tür und man muss sowohl die im Raum gemessenen Werte mit den Werten außen vergleichen.
Es gibt da eine nicht so elegante Lösung auf meintechblog.de (http://www.meintechblog.de/2015/08/raumklima-im-smart-home-mit-fhem-verbessern-taupunktoptimiertes-lueften/) aber das ist mir nicht generisch genug bei über 15 Fenster und Tür Kontakten sowie 7 überwachten Räumen.
Hallo Christian,
ich weiß zwar nicht genau, was Du willst, aber ich habe bei mir eine recht komplexe, aber sehr gut arbeitende Taupunkt-Lüftungssteuerung zusammengebaut, die im Keller 2 Lüfter synchron steuert (Ab- und Zuluft). Geht es Dir um sowas? In normalen Wohnräumen ist der Taupunkt ja eigentlich kein so großes Problem.
VG Yil
Hallo Benni,
erst mal vielen Dank für den Code.
Leide funktioniert dieser bei mir nicht so wie man (ich) es erwarten würde.
Ich verwende Fensterkontakte von MAX, und habe diese mittels MAXLAN an FHEM angebunden. Den MAX Cube polle ich alle 60 Sekunden. Den winOpenTimer habe ich auf 00:05:00 gesetzt.
Das Problem: Ich bekomme nie eine Benachrichtigung. Es scheint als würde der Timer alle 60 Sekunden wieder neu gesetzt mit 5 Minuten in die Zukunft. Das Timerende wird so also nie erreicht - > keine Benachrichtigung.
Wenn der Pollinterval grösser als den winOpenTimer gesetzt wird funktioniert das Ganze wieder. Trotzdem erachte ich nicht als geeignete Möglichkeit wenn Pollinterval > winOpenTimer gesetzt werden muss.
Gib es eine Möglichkeit den Code mit geringem Aufwand so anzupassen dass der auch zusammen mit MAXLAN Fensterkontakten funktioniert?
Gruss birdy
Hallo birdy,
keine Ahnung!
Ich habe keine MAX-Kontakte. Bei mir läuft derzeit ausschließlich Homematic.
Eventuell kannst du aber bei deinen MAX-Kontakten mit dem event-on-change Attribut was ausrichten.
Gruß Benni.
Zitat von: birdy am 02 Mai 2016, 17:13:26
Leide funktioniert dieser bei mir nicht so wie man (ich) es erwarten würde.
Ich verwende Fensterkontakte von MAX, und habe diese mittels MAXLAN an FHEM angebunden. Den MAX Cube polle ich alle 60 Sekunden. Den winOpenTimer habe ich auf 00:05:00 gesetzt.
Das Problem: Ich bekomme nie eine Benachrichtigung. Es scheint als würde der Timer alle 60 Sekunden wieder neu gesetzt mit 5 Minuten in die Zukunft. Das Timerende wird so also nie erreicht - > keine Benachrichtigung.
Wenn der Pollinterval grösser als den winOpenTimer gesetzt wird funktioniert das Ganze wieder. Trotzdem erachte ich nicht als geeignete Möglichkeit wenn Pollinterval > winOpenTimer gesetzt werden muss.
Gib es eine Möglichkeit den Code mit geringem Aufwand so anzupassen dass der auch zusammen mit MAXLAN Fensterkontakten funktioniert?
Du musst für den Kontakt event-on-change setzen.
OK, danke. Das werde ich gleich mal ausprobieren.
Zitat von: Benni am 02 Mai 2016, 18:25:42
Eventuell kannst du aber bei deinen MAX-Kontakten mit dem event-on-change Attribut was ausrichten.
Das Attribut heißt natürlich
event-on-change-reading (http://fhem.de/commandref_DE.html#readingFnAttributes) ::)
Zitat von: Benni am 02 Mai 2016, 21:10:30
Das Attribut heißt natürlich event-on-change-reading (http://fhem.de/commandref_DE.html#readingFnAttributes) ::)
Ja genau, dieses habe ich verwendet und jetzt funktioniert es perfekt. Minimale Anpassung maximale Wirkung.
Vielen Dank für diesen Tipp.
Zitat von: slor am 20 April 2015, 22:30:30
Sehr Cool! Sowas habe ich schon lange gesucht!
Könnte man das Intervall noch an die Außentemperatur koppeln?
Je kälter, fest schneller kommt die Warnung.
Ich habe mir noch einen Codeschnipsel zur grundsätzlichen Meldung bei niedriger Aussentemperatur eingebaut, damit setze ich eine Temperaturgrenze für jedes Fenster. Ist die Aussentemperatur unter diesem Wert, erfolgt eine Meldung... darüber eben nicht. Eingesetzt ist der Block unter der Prüfung, ob das device existiert. Die geschweifte Klammer an geeigneter Stelle muss natürlich auch gesetzt werden.
Den devices habe ich noch eine Userattribut winOpenTemp mitgegeben und standardmäßig mal für alle auf 15 gesetzt. Bei Garage und Tür existiert das winOpenTemp nicht, daher erfolgt dort immer eine Meldung.
#Erst mal prüfen, ob das übergebene device überhaupt existiert
if ($defs{$dev})
#Erst mal auslesen, ob es kalt genug ist, damit eine Meldung ausgegeben werden muss
my $tempdev=AttrVal($dev,'winOpenTemp',99);
my $tempthreshold=ReadingsVal('MeinWetter','temperature',14);
if ($tempdev > $tempthreshold){
Sehr gut, die Temperatur-Erweiterung! Danke.
Guten Abend,
ich habe den Dummy eingerichtet und die Subs in die myUtils kopiert, aber wenn ich den Dummy auf open setze passiert gar nichts, weder mit Loglevel 1 oder 3. Was kann ich noch einstellen, um dem Fehler auf die Schliche zu kommen?
Internals:
CFGFN
NAME FensterTestDummy
NR 234
STATE open
TYPE dummy
Readings:
2016-05-18 21:16:48 state open
Attributes:
setList open closed tilted
userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
webCmd closed:open:tilted
winOpenMaxTrigger 3
winOpenName Fenster Test-Dummy
winOpenTimer 00:00:15
winOpenTimer2 00:00:30
winOpenType Fenster
Was ist mit den beiden notify?
omfg...ich hatte irgendwie gelesen, dass die automagisch gebaut werden.....eieieiei..... thx :)
jetzt wo es die Notifies gibt, werde ich auch genotified :)
2016.05.18 22:10:48 1: winOpenMessage: Fenster - Fenster Test-Dummy ist noch offen
das bastel ich mir jetzt in die jabber-Benachrichtigung und werde deinen sehr coolen Code dann mit Freude nutzen :)
Ich habe auch diese HM-SEC-SC Kontakte und würde diese nun gerne als Alarmanlage in Fhem integrieren. Hat jemand eine Idee, wie man das am sinnvollsten realisieren könnte ? Mail senden halte ich für denkbar wenn man außer Haus ist. Wenn man jedoch nachts schläft und so ein Bösewicht steigt, in die Wohnung ein, möchte ich dies gerne angezeigt bekommen.
Cool wäre es direkt übers Handy was dann entweder klingelt und vielleicht noch wie irre dabei blinkt. Oder ginge dies nur über eine Funkklingel ?
Hallo en-trust,
das ist aber was anderes, als das was hier erreicht werden soll.
Hier geht es darum, daran erinnert zu werden, dass man Fenster und/oder Türen, die bspw. zum Lüften geöffnet werden auch nach einer gewissen Zeit wieder schließen soll.
Du könntest aber evtl. mal das Forum nach dem Stichwort Alarmanlage oder Einbruch o.ä. Durchsuchen, da gibt's bestimmt auch schon was ;)
Und für die akustisch Alarmierung an sich gibt es glaube ich von Homematic sogar speziell was und auch deren Rauchmelder lassen sich hervorragend für so was "missbrauchen"
Gruß Benni.
Suche ich nach Alarmanlage bekomme ich nur meine beiden Einträge ;D
Zitat von: en-trust am 01 Juni 2016, 09:28:54
...
Cool wäre es direkt übers Handy was dann entweder klingelt ...
Ich lasse mich von meinem RPi mittels FB_SIP Modul (https://forum.fhem.de/index.php/topic,40219.0.html)anrufen.
Zitat von: en-trust am 01 Juni 2016, 11:14:28
Suche ich nach Alarmanlage bekomme ich nur meine beiden Einträge ;D
Auch wenn es immer noch nicht in diesen Thread gehört, weil es völlig off-topic ist: https://www.google.de/search?q=site%3Aforum.fhem.de&rct=j#q=site:forum.fhem.de+alarmanlage
und auch über die Forums-Suche bekomme ich unzählige Threads aufgelistet!
Wichtig zu wissen ist das man sich auf oberste Ebene im Forum befinden muss. Ist man in einem Unterforum so wird nur das Unterforum durchsucht.
Zitat von: Fritz!Maxi am 01 Juni 2016, 11:18:54
Ich lasse mich von meinem RPi mittels FB_SIP Modul (https://forum.fhem.de/index.php/topic,40219.0.html)anrufen.
OT on:Da danach gefragt wurde hier kurz mein Ansatz mit Hilfe von DOIF und FB_SIP. Das DOIF ist wie folgt definiert:
(["HM_Sec_SC.*:open"] and [Alarm_an] eq "on" and [myPhone] eq "absent")
({ DebianMail('vorname.name@mail.com', 'Tuer-Fenster Meldung', '$DEVICE wurde geoeffnet!')})
(set HomePi_SIP call 0891235678 20)
Zitat von: Fritz!Maxi am 01 Juni 2016, 17:16:04
OT on:
Da danach gefragt wurde ...
Auch wenn hier fälschlicherweise danach gefragt wurde gehört es nicht hier hin!
Hallo,
bin gerade dabei das ganze bei mir einzubauen und habe ein Problem mit dem Timer. Die Nachrichten kommen sofort hintereinander und nicht im angegebenen Intervall. Z.Bsp. soll die erste Nachricht nach 00:00:01 kommen und die folgenden Meldungen nach 00:00:30.
Jedoch kommen die Nachrichten direkt hintereinander und ich weiß nicht woran es liegen könnte.
Inhalt der myutils (verändert habe ich nur den Teil mit der Benachrichtigung)
package main;
use strict;
use warnings;
use POSIX;
sub
myUtils_Initialize($$)
{
my ($hash) = @_;
}
# Enter you functions below _this_ line.
sub winOpenStart($;$) {
#Als Parameter muss der device-Name übergeben werden
my $dev=shift(@_);
#Optional kann noch ein Zähler für das erneute Triggern übergeben werden,
#dieser ist per default 0
my $retrigger=shift(@_);
$retrigger=0 if (!$retrigger);
#Erst mal prüfen, ob das übergebene device überhaupt existiert
if ($defs{$dev}) {
#Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
#angibt, wie oft eine Meldung ausgegeben werden soll.
#Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
if($maxtrigger) {
#Festlegen des Namens für den Timer, der angelegt wird um die Meldung nach gewünschter
#Zeit auszugeben.
my $devtimer=$dev.'_OpenTimer';
#Sollte dieser Timer bereits existieren, so wird er zunächst gelöscht.
fhem("delete $devtimer") if ($defs{$devtimer});
#Holen von weiteren Attributen, sofern vorhanden:
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 10 Minuten, falls nicht angegeben
my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
#Zeit für die Folge-Meldungen, sofern abweichend angegeben
#Default ist die normale Zeit, die oben schon ermittelt wurde
my $devtimer2=AttrVal($dev,'winOpenTimer2',$waittime);
#Ein eventuell definierter "schöner" Name für das Device, der in der Meldung ausgegeben werden soll.
#Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
#device-Name genommen.
my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
#Eine Art Typ (Tür oder Fenster), der bei mir quasi im Betreff der Offen-Meldung angegeben wird
my $devtype=AttrVal($dev,'winOpenType','Fenster/Tür');
#Hier wandeln wir noch den state des devices in deutschen Klartext um
my $devstate='offen';
$devstate='gekippt' if (ReadingsVal($dev,'state','') eq 'tilted');
#Hier wird, sofern bereits eine Wiederholung der Offen-Meldung ausgegeben werden soll,
#dies textlich auch so berücksichtigt.
my $immer='noch ';
$immer='immer noch ' if ($retrigger>0);
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
# meine Meldungen über Pushover ausgibt)
my $pushcmd=fhem( "set pushmsg msg '$devtype' '$devname ist $immer $devstate' '' 1 ''" );
#Sind wir schon beim Einrichten einer Folgemeldung, muss die Wartezeit für die Folgemeldungen
#genommen werden.
$waittime=$devtimer2 if ($retrigger);
#Wir erhöhen hier den Trigger-Zähler um 1...
$retrigger+=1;
#... und fügen das Re-Triggern als weitere Code-Zeile für das at-DEF an.
#das sorgt dann dafür, dass diese Funktion hier nach Ablauf des Timers einfach wieder
#getriggert wird, um einen neuen Timer anzulegen für die Folgemeldung
$pushcmd.="winOpenStart('$dev','$retrigger');;" if($retrigger < $maxtrigger);
#Nachdem wir hier alles zusammen haben,
#legen wir den Timer (das at) an und legen ihn freundlicherweise in den, bzw. die
#selben Räumen ab, wie auch das auslösende device.
fhem("define $devtimer at +$waittime {$pushcmd}");
fhem("attr $devtimer room ".AttrVal($dev,'room','Unsorted'));
}
}
}
sub winOpenStop($) {
#Dazu muss das entsprechende device (TK/FK) per Name hierher übergeben werden
#Den übergebenen device-Namen holen
my ($dev)=@_;
#Den Namen des Timers zusammenbauen
my $devtimer=$dev.'_OpenTimer';
#Existiert ein Timer diesen Namens, so wird er jetzt gelöscht und das war's auch schon.
if ($defs{$devtimer}) {
fhem("delete $devtimer");
}
}
Hier ein Beispielfensterkontakt
CFGFN
DEF 43B9B7
HMUSB_MSGCNT 37
HMUSB_RAWMSG E43B9B7,0000,05E6112F,FF,FFBA,5FA61043B9B732107206010000
HMUSB_RSSI -70
HMUSB_TIME 2016-06-02 14:00:52
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 37
NAME EG.TK.01.ZR
NR 27
NTFY_ORDER 50-EG_TK_01_ZR
STATE closed
TYPE CUL_HM
lastMsg No:5F - t:10 s:43B9B7 d:321072 06010000
protLastRcv 2016-06-02 14:00:52
protSnd 37 last_at:2016-06-02 14:00:52
protState CMDs_done
rssi_at_HMUSB min:-80 lst:-70 cnt:37 avg:-63.86 max:-59
Readings:
2016-06-01 15:23:32 Activity alive
2016-05-27 10:46:46 D-firmware 1.0
2016-05-27 10:46:46 D-serialNr MEQ1834041
2016-05-30 17:05:32 PairedTo 0xXXXXXX
2016-05-30 17:05:32 R-cyclicInfoMsg on
2016-05-30 17:05:32 R-eventDlyTime 0 s
2016-05-30 17:05:32 R-pairCentral 0xXXXXXX
2016-05-30 17:05:32 R-sabotageMsg on
2016-05-30 17:05:32 R-sign on
2016-05-30 17:05:32 RegL_00. 02:01 09:01 0A:32 0B:10 0C:72 10:01 14:06 00:00
2016-05-30 17:05:32 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2016-06-02 14:00:52 alive yes
2016-06-02 14:00:52 battery ok
2016-06-02 14:00:52 contact closed (to vccu)
2016-06-02 14:00:52 recentStateType info
2016-06-02 14:00:52 sabotageError off
2016-06-02 14:00:52 state closed
2016-06-02 13:59:58 trigDst_vccu noConfig
2016-06-02 13:59:58 trigger_cnt 75
Helper:
HM_CMDNR 95
mId 00C7
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +43B9B7,00,00,00
nextSend 1464868853.04892
rxt 2
vccu vccu
p:
43B9B7
00
00
00
Mrssi:
mNo 5F
Io:
HMUSB -68
Prt:
bErr 0
sProc 0
sleeping 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMUSB
flg A
ts 1464868852.96699
ack:
HASH(0x17e85e8)
5F800232107243B9B700
Rssi:
At_hmusb:
avg -63.8648648648649
cnt 37
lst -70
max -59
min -80
Tmpl:
Attributes:
IODev HMUSB
IOgrp vccu
Structure_Fenster_EG Fenster_EG
actCycle 001:05
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:rc_RED closed:rc_GREEN
event-on-change-reading .*
event-on-update-reading .*
expert 2_raw
firmware 1.0
model HM-SEC-SCo
peerIDs 00000000,
room CUL_HM
serialNr MEQ1834041
subType threeStateSensor
userattr Structure_Fenster_EG Structure_Fenster_EG_map structexclude winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
winOpenMaxTrigger 3
winOpenName EG_TK_01_ZR
winOpenTimer 00:00:01
winOpenTimer2 00:01:00
winOpenType Türe
Dir ist klar, dass 00:00:01 nach 1 Sekunde ist und 00:00:30 nach 30 Sekunden?
Weiterhin fällt auf, dass du bei deinem Fensterkontakt sowohl event-on-change-reading, als auch event-on-update-reading auf .* gesetzt hast. Das ergibt keinen Sinn, denn das hat den selben Effekt, wie wenn keins der beiden Attribute gesetzt ist. Lösche mal das event-on-update-reading, könnte sein dass dir das hier in die Suppe spuckt!
Und... auch deine Anpassung der Push-Meldung kann so m.E. nicht funktionieren, denn diese wird ja Teil der gesamten AT-Definition. Bei dir fehlen am Ende mindestens 2 Semikolons ( ;; ) die die spätere Verekettung der FHEM-Befehle ermöglicht. Schau dir da bitte nochmal das "Original" an.
Wenn du die Zeiten mal etwas verlängerst, vor allem die für die erste Benachrichtigung, dann kannst du dir das erzeugte AT ja ebenfalls mal anzeigen, bzw. mit list zur Überprüfung auflisten lassen.
Gruß Benni.
Danke für die Hinweise und ich denke es lag an meinem Versuch die Pushnachricht zu integrieren.
Habe jetzt den Originalcode verwendet und folgende Zeilen für die Pushnachricht ergänzt.
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
fhem( "set pushmsg msg '$msgsubj' '$msgtext' '' 1 ''" );
}
Jetzt kommen die Nachrichten wie gewünscht.
Das ist natürlich auch eine Möglichkeit! 8)
Freut mich, wenn's funktioniert! :D
Hallo Benni,
hab jetzt auch deine Lösung implementiert, hab den original Code verwendet.
Nun habe ich aber noch das Problem, wenn das Fenster gewünscht länger offen ist,
dass sporadisch immer wieder ein Timer erstellt wird und ich dann nat. auch wieder benachtrichtigt werde,
obwohl ich schon die 3 Mails erhalten habe.
Mir ist aufgefallen, dass sich der Timer immer wieder aktiviert sobald im Log vom Fensterkontakt das hier auftaucht:
2016-06-23_12:54:49 Fenster_Schlafzimmer alive: yes
2016-06-23_12:54:49 Fenster_Schlafzimmer battery: ok
2016-06-23_12:54:49 Fenster_Schlafzimmer contact: open (to VCCU1)
2016-06-23_12:54:49 Fenster_Schlafzimmer sabotageError: off
2016-06-23_12:54:49 Fenster_Schlafzimmer open
2016-06-23_13:54:51 Fenster_Schlafzimmer alive: yes
2016-06-23_13:54:51 Fenster_Schlafzimmer battery: ok
2016-06-23_13:54:51 Fenster_Schlafzimmer contact: open (to VCCU1)
2016-06-23_13:54:51 Fenster_Schlafzimmer sabotageError: off
2016-06-23_13:54:51 Fenster_Schlafzimmer open
2016-06-23_14:08:16 Fenster_Schlafzimmer Activity: alive
2016-06-23_14:08:31 Fenster_Schlafzimmer Activity: alive
2016-06-23_14:53:32 Fenster_Schlafzimmer alive: yes
2016-06-23_14:53:32 Fenster_Schlafzimmer battery: ok
2016-06-23_14:53:32 Fenster_Schlafzimmer contact: open (to VCCU1)
2016-06-23_14:53:32 Fenster_Schlafzimmer sabotageError: off
2016-06-23_14:53:32 Fenster_Schlafzimmer open
Wie hast du das gelöst? Ich verwende auch den HM Fensterkontakt.
lg
Stiff
event-on-change-reading .*
oder Du machst es gleich so wie Du die Events brauchst.
Ich brauche nur
event-on-change-reading state,battery,sabotageError,alive
Hast du die anderen readings einfach gelöscht?
Oder hast du das "event-on-change-reading .*" ins notify eingebaut?
stiff
Zitat von: stiffmeister am 23 Juni 2016, 15:25:56
Hast du die anderen readings einfach gelöscht?
Oder hast du das "event-on-change-reading .*" ins notify eingebaut?
Zeit sich mal mit ein paar Grundlagen zu beschäftigen: ;)
http://fhem.de/commandref_DE.html#readingFnAttributes
Hallo,
ja das ist wohl war...
Danke nun hab ich's ;)
stiff
Hallo,
danke nochmals dafür.
Würde nun gerne die Benachrichtigung in der Zeit von 13:00 bis 18:00 Uhr abschalten.
Wer eine idee wie ich das machen kann?
Danke
Folgende Idee:
Ich verwende ja bei mir eine Funktion (sub in 99_MyUtils.pm) PushInfo() die im erzeugten at zum eigentlichen Versand der Nachricht aufgerufen wird (eine Beispiel-Implementation zum Testen findet sich in diesem Post (https://forum.fhem.de/index.php/topic,36504.msg288872.html#msg288872)).
Genau in dieser Funktion könnte man jetzt vor dem eigentlichen Absetzen der Nachricht Prüfen, ob es aktuell nicht zw. 13 und 18 Uhr ist.
Weiter Idee:
Es gibt aber bei einigen Messaging-Diensten (ich glaube auch bei Pushover) s.g. "Do-not-disturb"-Zeiten ("Bitte nich stören!"), die man einstellen kann und zu denen man dann keine Benachrichtigungen erhält.
Zitat von: QuesT am 03 Juli 2016, 21:38:08
...Würde nun gerne die Benachrichtigung in der Zeit von 13:00 bis 18:00 Uhr abschalten.
Wer eine idee wie ich das machen kann?
Ich "disable" einfach automatisch das entsprechende notify, wenn ich die Laberei nicht möchte; z.B. wenn im Sommer ständig die Fenster auf und zu gemacht werden.
Zitat von: Hollo am 04 Juli 2016, 09:09:27
Ich "disable" einfach automatisch das entsprechende notify, wenn ich die Laberei nicht möchte; z.B. wenn im Sommer ständig die Fenster auf und zu gemacht werden.
Auch noch 'ne Idee! (so viele Möglichkeiten :) )
Das könnte man auch mit
at automatisieren 13:00 Uhr dsable und 18:00 enable (noch besser ist dann aber
set inactive bzw.
set active da das keine strukturellen Änderungen an der Config vornimmt, die gespeichert werden wollen.
Zitat von: Hollo am 04 Juli 2016, 09:09:27
Ich "disable" einfach automatisch das entsprechende notify, wenn ich die Laberei nicht möchte; z.B. wenn im Sommer ständig die Fenster auf und zu gemacht werden.
Genau das wollte ich auch machen nur bin ich zu blöd dazu.
Nur wie disable ich das zeitgesteuert=?
Zitat von: QuesT am 05 Juli 2016, 19:55:59
Nur wie disable ich das zeitgesteuert=?
Mir ist gerade eingefallen, dass
notify ja auch das Attribut
disabledForIntervals kennt.
Das macht es jetzt ganz einfach:
attr winOpen.OpenNotify disabledForIntervals 13:00-18:00
Damit wird das
notify automatisch im Zeitraum zw. 13:00 und 18:00 Uhr deaktiviert (wie mit
disable).
Danke Benni das kannte ich auch noch nicht! Zwei ATs weniger! ;-)
Hallo Benni,
ich versuche seit gestern deinen Code ans Laufen zu bekommen und habe verschiedene Fehler die ich ursprünglich verbrochen hatte, gefunden aber es will noch nicht.
Die Attribute sind gesetzt, die notifys sind angelegt und eine Pushinfo für pushsafer habe ich wie folgt angehängt (von Hand gepusht geht):
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
#fhem("set pjost message 'winOpenMessage' '$msgsubj - $msgtext' ");
fhem("set pjost message TEST");
}
Leider kommt nix an. Statt dessen finde ich im log:
2016.10.20 21:48:03 3: winOpen.OpenNotify return value: Global symbol "$Haustuer" requires explicit package name at (eval 268) line 1.
Haustuer ist der Kontakt.
Hast du evtl. einen Tip für mich?
Vielen Dank :)
Tja, ziemlich wenig Informationen, wo sind die lists zu den beteiligten devices?
Aber, wenn dein Kontakt Haustuer heißt, solltest du schätzungsweise nicht $Haustuer verwenden, wo auch immer das ist?
Das war der richtige Ansatzpunkt, vielen Dank!
Ich habe im Notify $Gerät statt "Gerät" übergeben, das kommt halt wenn man sich was zusammenklickt ohne zu wissen was man da macht. Wenn ich jetzt darüber nachdenke, dann war ersteres eine leere Variable und zweites halt das Gerät ;)
nu lüppt es, feine Sache das! Damit überwache ich jetzt, ob die lieben Mitbewohner wieder ewig die Haustür offen stehen lassen.
Hi Benni,
mir gefällt deine flexible Fenster-Türüberwachung sehr gut ! :)
sie ermöglicht bei den HM-FKTK eine wiederholung der Benarichtigung.
hatte Probleme damit bei meiner Lösung, daher würde ich gerne deine verwenden
habe alles so eingerichtet wie von dir beschrieben:
die zwei Notifys
define winOpen.OpenNotify notify F.Sensor.*:open {winOpenStart($NAME)}
define winOpen.CloseNotify notify F.Sensor.*:closed {winOpenStop($NAME)}in der 99_myUtils.pm habe ich
############################# test #############################
sub winOpenStart($;$) {
#Als Parameter muss der device-Name übergeben werden
my $dev=shift(@_);
#Optional kann noch ein Zähler für das erneute Triggern übergeben werden,
#dieser ist per default 0
my $retrigger=shift(@_);
$retrigger=0 if (!$retrigger);
#Erst mal prüfen, ob das übergebene device überhaupt existiert
if ($defs{$dev}) {
#Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
#angibt, wie oft eine Meldung ausgegeben werden soll.
#Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
if($maxtrigger) {
#Festlegen des Namens für den Timer, der angelegt wird um die Meldung nach gewünschter
#Zeit auszugeben.
my $devtimer=$dev.'_OpenTimer';
#Sollte dieser Timer bereits existieren, so wird er zunächst gelöscht.
fhem("delete $devtimer") if ($defs{$devtimer});
#Holen von weiteren Attributen, sofern vorhanden:
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 10 Minuten, falls nicht angegeben
my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
#Zeit für die Folge-Meldungen, sofern abweichend angegeben
#Default ist die normale Zeit, die oben schon ermittelt wurde
my $devtimer2=AttrVal($dev,'winOpenTimer2',$waittime);
#Ein eventuell definierter "schöner" Name für das Device, der in der Meldung ausgegeben werden soll.
#Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
#device-Name genommen.
my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
#Hier wird, sofern bereits eine Wiederholung der Offen-Meldung ausgegeben werden soll,
#dies textlich auch so berücksichtigt.
my $immer='noch ';
$immer='immer noch ' if ($retrigger>0);
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
# meine Meldungen über Pushover ausgibt)
my $pushcmd="Wecken()";
#Sind wir schon beim Einrichten einer Folgemeldung, muss die Wartezeit für die Folgemeldungen
#genommen werden.
$waittime=$devtimer2 if ($retrigger);
#Wir erhöhen hier den Trigger-Zähler um 1...
$retrigger+=1;
#... und fügen das Re-Triggern als weitere Code-Zeile für das at-DEF an.
#das sorgt dann dafür, dass diese Funktion hier nach Ablauf des Timers einfach wieder
#getriggert wird, um einen neuen Timer anzulegen für die Folgemeldung
$pushcmd.="winOpenStart('$dev','$retrigger');;" if($retrigger < $maxtrigger);
#Nachdem wir hier alles zusammen haben,
#legen wir den Timer (das at) an und legen ihn freundlicherweise in den, bzw. die
#selben Räumen ab, wie auch das auslösende device.
fhem("define $devtimer at +$waittime {$pushcmd}");
fhem("attr $devtimer room ".AttrVal($dev,'room','Unsorted'));
}
}
}
sub winOpenStop($) {
#Dazu muss das entsprechende device (TK/FK) per Name hierher übergeben werden
#Den übergebenen device-Namen holen
my ($dev)=@_;
#Den Namen des Timers zusammenbauen
my $devtimer=$dev.'_OpenTimer';
#Existiert ein Timer diesen Namens, so wird er jetzt gelöscht und das war's auch schon.
if ($defs{$devtimer}) {
fhem("delete $devtimer");
}
}Attrib. am F.Sensor (den ich zum testen verwende sind gesetzt)
ZitatwinOpenMaxTrigger 3
winOpenTimer 00:00:15
winOpenTimer2 00:00:30
ich möchte aber statt der Pushover Funktion gerne eine akustische Ansage (Sonos)
daher wollte ich zum testen die Ansage von meinem "Wecker" nutzen
eine sub dafür hatte ich schon:
sub
Wecken()
{
fhem("set Sonos_Schlafzimmer PlayURITemp \\\\192.168.xxx.xxx\\SonosSpeak\\Morgen.mp3 20");
} ich habs leider nicht so mit'm Perlsyntax
bei dir wird ja auch eine weitere sub gestartet und Parameter übergeben wenn ich das richtig sehe
my $pushcmd="PushInfo('$devtype','$devname ist $immer $devstate');;";ich wollte jetzt eifach meine wecken sub starten
my $pushcmd="Wecken()";und genau hier hänge ich jetzt
Log:
2016.11.17 14:35:41 1: PERL WARNING: Bareword found where operator expected at (eval 29209) line 1, near ")winOpenStart"
2016.11.17 14:35:41 3: eval: {Wecken()winOpenStart('F.SensorSchlaf2','1');}
2016.11.17 14:35:41 1: PERL WARNING: (Missing operator before winOpenStart?)
2016.11.17 14:35:41 3: F.SensorSchlaf2_OpenTimer: syntax error at (eval 29209) line 1, near ")winOpenStart"
bitte um Hilfe
Da fehlen 2 Semikolons:
my $pushcmd="Wecken();;";
Die sind wichtig, da der Aufruf ja nachher im erzeugten at zusammengebaut wird.
Hi Benni,
ZitatDa fehlen 2 Semikolons:
:o ups
Vielen Dank !
super Support !!!
Hi Benni,
habs jetzt mal ne Zeit getestet
funktioniert super :)
besten Dank dafür !
ein/ausschalten wäre jetzt noch die Perfektion
hast du da eine Idee ? evtl. mit attrib ?
mfg. m311331
Danke für die Blumen! :D
Was meinst du mit ein-/ausschalten?
Du kannst ja einfach die beiden notify bei bedarf deaktivieren, entweder über das Attribut disable oder über set active, bzw. set inactive
Hi Benni,
ZitatWas meinst du mit ein-/ausschalten?
ja das hätte ich besser erläutern müssen :-\
eigentlich wollte ich das so machen das die Ansage der Fenster
abhängig vom akt. Monat kommt.
kurz gesagt: Ansage nur in den Monaten: 11 - 04, von 04 - 11 keine Ansage
mein Ansatz kurz und knap war aber mist ;D habs nicht hin bekommen
define BadezimmerFensterAuf watchdog F.SensorBad.:open 00:15 F.SensorBad.:closed if (($month > 9 || $month < 4)){fhem ("set Sonos_Buero,Sonos_Bad,Sonos_Waschkueche,Sonos_Flur,Sonos_Wohnzimmer PlayURITemp \\IP.zum.Ser.ver\SonosSpeak\Badezfopen.mp3 30 )}} trigger BadezimmerFensterAuf .perl ist einfach nicht meins ???
letztändlich habe ich google bemüht für mich im Forum zu suchen, da die Forensuche vom SMF aus meiner sicht hmm .... nicht so dolle ist
... und durch einen link der wiederum in nem Beitrag hier im Forum war, bin ich auf deinen Beitrag gekommen :)
mfg. m
Wie gesagt, ich würde das über ein deaktivieren, bzw. aktivieren der beteiligten nortify lösen.
Am einfachsten legst du dir ein at dafür an, das einmal am Tag ausgeführt wird (irgendwann kurz nach Mitternacht).
Im Ausführungsteil des at kannst du nun den aktuellen Monat prüfen und je nach dem die beiden notify mit set inactive deaktivieren oder mit set active wieder aktivieren. Diesen Teil lagerst du dann idealerweise noch in deine 99_myUtils aus.
Zitat von: m311331 am 24 November 2016, 19:21:47
...
kurz gesagt: Ansage nur in den Monaten: 11 - 04, von 04 - 11 keine Ansage
...
kurz gesagt: eine Möglichkeit steht eine Seite vorher... https://forum.fhem.de/index.php/topic,36504.msg469018.html#msg469018 (https://forum.fhem.de/index.php/topic,36504.msg469018.html#msg469018) ;D
Zitat von: Hollo am 25 November 2016, 20:52:21
kurz gesagt: eine Möglichkeit steht eine Seite vorher... https://forum.fhem.de/index.php/topic,36504.msg469018.html#msg469018 (https://forum.fhem.de/index.php/topic,36504.msg469018.html#msg469018) ;D
Stimmt! Offensichtlich war das schon mal Thema :D
Hi Benni,
ich bin auf der Suche nach einer Möglichkeit bei meinem Fensterstatus eine genauere Nachricht zu bekommen.
Ich habe eine structure gebildet. Dort habe ich alle Fenster drin. Wenn ich das Haus verlasse und die Tür mit dem automatischen Türschloss verriegelt wird, bekomme ich eine Nachricht "Alle Fenster geschlossen". Wenn noch ein Fenster geöffnet ist, bekomme ich eine Nachricht "Fenster noch geöffnet".
Ich würde das nun gerne verbessern, in dem ich auch angezeigt bekomme, WELCHES Fenster noch geöffnet ist.
Nach dem Motto "Fenster Küche und Fenster Esszimmer noch offen". Damit ich nicht lange suchen muss.
Ist sowas mit deinem Modul auch möglich ?
Grüße,
Visionsurfer
So ohne weiteres ist das mit meinem Code nicht möglich, der dient ja eigentlich nur dazu die vergesslichen Stoßlüfter daran zu erinnern, Fenster, bzw. Türen auch zu schließen. Dabei meldet sich quasi jedes Fenster selbst, so nach dem Motto "Hey, ich bin noch offen, mach mal zu!" und "Halloooo, ich bin immer noch offen, mach mich doch endlich zu!"
Was du möchtest, sollte mit etwas Perl-Code zu bewerkstelligen sein. Dazu kannst du bspw. alle Fenster, die in der besagten Structure sind (devspec2array <- funktioniert aber nur, wenn structures nicht geschachtelt sind) prüfen, die offenen sammeln und dann in deiner Meldung ausgeben.
Ich habe beim Stöbern im Forum mal noch folgenden Thread gefunden:
https://forum.fhem.de/index.php/topic,56393.0.html
Dort sind übrigens mehrere Möglichkeiten beschrieben.
Hi Benni,
ZitatWie gesagt, ich würde das über ein deaktivieren, bzw. aktivieren der beteiligten nortify lösen.
besten Dank nochmal ! :)
mfg. m
@visionsurfer:
a) bei mir haben Fenster einen Device-Namen "Fenster_"... (hier irrelevant, aber das macht Attribut-Setzen einfacher, z.B. für die Icons)
b) und einen comment mit dem "lesbaren" Namen.
Dann z.B.:
define Fenster_wohnzimmer_balkon MAX ShutterContact 0a4c4b
attr Fenster_wohnzimmer_balkon comment Wohnzimmer zum Balkon
...
define Fenster_wohnzimmer_gaube MAX ShutterContact 0a4bf2
attr Fenster_wohnzimmer_gaube comment Wohnzimmer Gaube
...
In den myUtils:
sub Window_status {
my $resultstring='';
my @fhttks = devspec2array("DEF=ShutterContact .+");
my @wopen = ();
foreach(@fhttks) {
my $fhttk_window = ReadingsVal($_, "state", "?");
push (@wopen,AttrVal($_, "comment", "?")) if ($fhttk_window =~ m/open/ );
}
my $num_wopen = @wopen;
if ( $num_wopen gt 0 ) {
$resultstring="folgende Fenster sind noch offen:\n\n";
foreach(@wopen) {
$resultstring.="- ".$_."\n";
Log 4, "FHTTK_status: ". $_. "noch offen";
}
} else {
$resultstring.="alle Fenster sind geschlossen.";
}
return $resultstring;
}
und auf Tastendruck wird aufgerufen:
set MyTTS tts {Window_status()}
Und dann wird genau das vorgelesen, was Du haben möchtest.
Hi c2j2,
tausend Dank. Ich versuche gerade den Code zu verstehen. Ich hab bisher noch nie mit der 99_myUtils.pm gearbeitet. Die hab ich nun erst mal richtig angelegt.
Ich habe KNX Fenstersensoren. Das müsste aber keine Rolle spielen.
Bei mir sind alle Devicenamen so aufgebaut: fensterstatus_buero, fensterstatus_kueche, fensterstatus_esszimmer_rechts, fensterstatus_esszimmer_links usw.
Mein State liefert immer nur closed oder open.
Jetzt kann ich ja noch das Command einfügen als attr.
Diese Zeile muss ich dann aber ändern, oder ?
Zitatmy @fhttks = devspec2array("DEF=ShutterContact .+");
Weil ich habe ja kein "ShutterContact".
Meine Definition für ein Gerät sieht so aus:
define fensterstatus_buero KNX 6/1/3:dpt1.009Bei den anderen Fenstern einfach nur eine andere Gruppenadresse.
Kann ich deinen Code trotzdem verwenden ?
Grüße,
Visionsurfer
Bitte den Thread hier nicht mehr oder weniger als allgemeinen Perl-Lern-Thread mißbrauchen.
Danke! :)
Hallo Benni,
erstmal großen Dank an den tollen Code-Schnipsel.
Ich bin noch blutiger Anfänger und habe deine Fenstermeldung 1:1 kopiert und lasse mich mit PushOver benachrichtigen.
Ich habe allerdings ein kleines Problem, ein öffnen des Fensters bewirkt sofort, dass in die zweite Schleife des Timers gegangen wird. Ich bekomme also nicht 3 sondern nur 2 Nachrichten und die erste beinhaltet sofort "immer noch".
Das passiert sowohl beim "echten" HM Fensterkontakt als auch beim Testfenster.
Hat jemand eine Idee?
Zitat von: bastelfeak am 29 November 2016, 21:51:39
Hat jemand eine Idee?
Mit so wenig Information wirds schwierig!
Lass doch mal wenigstens ein list deines Fensters sehen.
Zitat von: bastelfeak am 29 November 2016, 21:51:39
...Ich habe allerdings ein kleines Problem, ein öffnen des Fensters bewirkt sofort, dass in die zweite Schleife des Timers gegangen wird. Ich bekomme also nicht 3 sondern nur 2 Nachrichten und die erste beinhaltet sofort "immer noch"...
Beobachte das mal im Eventmonitor.
Kann es evtl. sein, dass Dein "Öffnen des Fensters" direkt 2x den Trigger auslöst?
Ich hatte einen ähnlichen Fall, da ich mir eine Ansage eingebaut hatte, die dann immer gleich 2x hintereinander erfolgte.
Durch Filtern bzw. event-on-change-reading liess sich das beheben.
Ich bin noch zweimal alles durchgegangen und habe den Fehler gefunden:
Ich habe die Zeile etwas zu frei verändert ::)
#Optional kann noch ein Zähler für das erneute Triggern übergeben werden,
#dieser ist per default 0
my $retrigger=shift(@_);
$retrigger=0 if (!$retrigger);
Dort habe ich eine "1" eingetragen, was dazu führt, dass er von Anfang an sich im Zählstatus "1" befindet und nicht, dass er einmal wiederholt, wie ich anfangs dachte. Das macht ja später $maxtrigger
Immerhin: Wieder was gelernt.
Zitat von: bastelfeak am 30 November 2016, 13:13:08
Immerhin: Wieder was gelernt.
Sehr gut! Und Danke für die Rückmeldung! 8)
Zitat von: c2j2 am 27 November 2016, 20:10:56
a) bei mir haben Fenster einen Device-Namen "Fenster_"... (hier irrelevant, aber das macht Attribut-Setzen einfacher, z.B. für die Icons)
b) und einen comment mit dem "lesbaren" Namen.
...
In den myUtils:
sub Window_status {
my $resultstring='';
my @fhttks = devspec2array("DEF=ShutterContact .+");
my @wopen = ();
foreach(@fhttks) {
my $fhttk_window = ReadingsVal($_, "state", "?");
push (@wopen,AttrVal($_, "comment", "?")) if ($fhttk_window =~ m/open/ );
}
my $num_wopen = @wopen;
if ( $num_wopen gt 0 ) {
$resultstring="folgende Fenster sind noch offen:\n\n";
foreach(@wopen) {
$resultstring.="- ".$_."\n";
Log 4, "FHTTK_status: ". $_. "noch offen";
}
} else {
$resultstring.="alle Fenster sind geschlossen.";
}
return $resultstring;
}
Da bei mir die Balkontüren und die Fenster neben closed/open noch tilted sein können und ich den sprechenden Namen im alias und nicht im comment hinterlegt habe, habe ich dieses schöne script (Danke @c2j2) für mich angepasst:
################################################################
### Status der Türen und Fenster für Sprachausgabe ###
################################################################
sub win_Status {
my $resultstring = '';
my @fenster_tuer = devspec2array("Fenster.*|Tuer.*|Balkontuer.Wohnzimmer|Balkontuer.Schlafzimmer|Garagentorsensor");
Log 4, "Überwachte Fenster und Türen: @fenster_tuer";
my @wopen = ();
foreach(@fenster_tuer) {
my $status = ReadingsVal($_, "state", "?");
push (@wopen,AttrVal($_, "alias", "?")) if (! ($status =~ m/closed/ ));
}
my $num_wopen = @wopen; # Anzahl der offenen Fenter und Türen
if ( $num_wopen > 0 ) {
$resultstring = latin1ToUtf8("Folgende Fenster und Türen sind nicht geschlossen: ");
my $i;
for ($i=1;$i<=$num_wopen;$i++) {
$resultstring .= $wopen[$i-1];
if ($i==$num_wopen-1) {$resultstring .= " und ";}
elsif ($i==$num_wopen) {$resultstring .= ".";}
else {$resultstring .= ", ";}
}
} else {
$resultstring = latin1ToUtf8("Alle Fenster und Türen sind geschlossen.");
}
return $resultstring;
}
Edit: Da bei meiner Ausgabe auf Sonos die Zeilenumbrüche \n Probleme gemacht haben, habe ich das ganze noch einmal etwas überarbeitet und so für die Sprachausgabe noch besser angepasst.
Sowohl der tilted-Status, als auch der sprechende Name aus alias werden auch in meiner ursprünglichen Lösung korrekt berücksichtigt. ???
Zitat von: Benni am 30 November 2016, 22:25:49
Sowohl der tilted-Status, als auch der sprechende Name aus alias werden auch in meiner ursprünglichen Lösung korrekt berücksichtigt. ???
Das ist richtig! Es war aber in dieser Ergänzung von c2j2, die eine Sprachausgabe erlaubt, bislang nicht der Fall. Nun passt die Ergänzung aus meiner Sicht besser dazu.
Hallo erst mal vielen Dank für das tolle Modul.
Ich habe das genau so umgesetzt wie hier beschrieben. Lediglich lasse ich mir keine Pushmeldung, schicken sondern die Meldung per MyTTS ausgeben.
Ein Problem habe ich allerdings: Wenn ich ein Fenster öffne kommt sofort danach die erste Meldung das ein Fenster noch offen ist und danach dann im richtigen Zeitintervall die weiteren Meldungen.
Das ist natürlich nicht so schön wenn jedes mal wenn Jemand kurz eine Türe öffnet um raus zu gehen eine Durchsage kommt.
Bin mir jetzt nicht sicher ob es so gewollt ist das direkt beim öffnen schon eine Meldung kommt, aber kann man das ändern?
Hier mal den Code welchen ich benutze:
##################################################
########### Fenster Überwachung ##############
##################################################
sub winOpenStart($;$) {
#Als Parameter muss der device-Name übergeben werden
my $dev=shift(@_);
#Optional kann noch ein Zähler für das erneute Triggern übergeben werden,
#dieser ist per default 0
my $retrigger=shift(@_);
$retrigger=0 if (!$retrigger);
#Erst mal prüfen, ob das übergebene device überhaupt existiert
if ($defs{$dev}) {
#Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
#angibt, wie oft eine Meldung ausgegeben werden soll.
#Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
if($maxtrigger) {
#Festlegen des Namens für den Timer, der angelegt wird um die Meldung nach gewünschter
#Zeit auszugeben.
my $devtimer=$dev.'_OpenTimer';
#Sollte dieser Timer bereits existieren, so wird er zunächst gelöscht.
fhem("delete $devtimer") if ($defs{$devtimer});
#Holen von weiteren Attributen, sofern vorhanden:
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 10 Minuten, falls nicht angegeben
my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
#Zeit für die Folge-Meldungen, sofern abweichend angegeben
#Default ist die normale Zeit, die oben schon ermittelt wurde
my $devtimer2=AttrVal($dev,'winOpenTimer2',$waittime);
#Ein eventuell definierter "schöner" Name für das Device, der in der Meldung ausgegeben werden soll.
#Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
#device-Name genommen.
my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
#Eine Art Typ (Tür oder Fenster), der bei mir quasi im Betreff der Offen-Meldung angegeben wird
my $devtype=AttrVal($dev,'winOpenType','Fenster,Türe');
#Hier wandeln wir noch den state des devices in deutschen Klartext um
my $devstate='offen';
$devstate='gekippt' if (ReadingsVal($dev,'state','') eq 'tilted');
#Hier wird, sofern bereits eine Wiederholung der Offen-Meldung ausgegeben werden soll,
#dies textlich auch so berücksichtigt.
my $immer='noch ';
$immer='immer noch ' if ($retrigger>0);
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
# meine Meldungen über Pushover ausgibt)
my $pushcmd=fhem( "set MyTTS tts ('$devname ist $immer $devstate');;" );
#Sind wir schon beim Einrichten einer Folgemeldung, muss die Wartezeit für die Folgemeldungen
#genommen werden.
$waittime=$devtimer2 if ($retrigger);
#Wir erhöhen hier den Trigger-Zähler um 1...
$retrigger+=1;
#... und fügen das Re-Triggern als weitere Code-Zeile für das at-DEF an.
#das sorgt dann dafür, dass diese Funktion hier nach Ablauf des Timers einfach wieder
#getriggert wird, um einen neuen Timer anzulegen für die Folgemeldung
$pushcmd.="winOpenStart('$dev','$retrigger');;" if($retrigger < $maxtrigger);
#Nachdem wir hier alles zusammen haben,
#legen wir den Timer (das at) an und legen ihn freundlicherweise in den, bzw. die
#selben Räumen ab, wie auch das auslösende device.
fhem("define $devtimer at +$waittime {$pushcmd}");
fhem("attr $devtimer room ".AttrVal($dev,'room','Unsorted'));
}
}
}
sub winOpenStop($) {
#Dazu muss das entsprechende device (TK/FK) per Name hierher übergeben werden
#Den übergebenen device-Namen holen
my ($dev)=@_;
#Den Namen des Timers zusammenbauen
my $devtimer=$dev.'_OpenTimer';
#Existiert ein Timer diesen Namens, so wird er jetzt gelöscht und das war's auch schon.
if ($defs{$devtimer}) {
fhem("delete $devtimer");
}
}
und so sind die Aktoren angelegt:
defmod MAX_11fea5 MAX ShutterContact 11fea5
attr MAX_11fea5 userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
attr MAX_11fea5 IODev ml
attr MAX_11fea5 alarmDevice Sensor
attr MAX_11fea5 alarmSettings alarm0,|MAX_11fea5:opened|Kueche Tür|on
attr MAX_11fea5 alias Fenster Küche Balkontür
attr MAX_11fea5 devStateIcon closed:10px-kreis-gruen opened:10px-kreis-rot
attr MAX_11fea5 event-on-change-reading state
attr MAX_11fea5 fp_Erdgeschoss 414,83,0, ,MAX_11fea5
attr MAX_11fea5 fp_Terminal_test 221,51,0, ,MAX_11fea5
attr MAX_11fea5 group Heizung
attr MAX_11fea5 room 03_Küche,C_MAX
attr MAX_11fea5 winOpenMaxTrigger 3
attr MAX_11fea5 winOpenName Die Terrassentüre in der Küche
attr MAX_11fea5 winOpenTimer 00:10:00
attr MAX_11fea5 winOpenTimer2 00:05:00
attr MAX_11fea5 winOpenType Türe
setstate MAX_11fea5 closed
setstate MAX_11fea5 2016-12-16 15:39:51 MAXLAN_error 0
setstate MAX_11fea5 2016-12-16 15:39:51 MAXLAN_errorInCommand
setstate MAX_11fea5 2016-12-16 15:39:51 MAXLAN_initialized 1
setstate MAX_11fea5 2016-12-16 15:39:51 MAXLAN_isAnswer 0
setstate MAX_11fea5 2016-12-16 15:39:51 MAXLAN_valid 1
setstate MAX_11fea5 2016-12-16 15:39:51 battery ok
setstate MAX_11fea5 2016-12-16 13:54:30 firmware 1.0
setstate MAX_11fea5 2016-12-16 13:54:30 groupid 2
setstate MAX_11fea5 2016-12-16 15:39:51 onoff 0
setstate MAX_11fea5 2016-12-16 15:39:51 state closed
setstate MAX_11fea5 2016-12-16 13:54:30 testresult 2
Hat niemand eine Idee warum die erste offen Meldung sofort kommt und nicht wie eingestellt nach 10 Minuten?
So ist das echt nervig wenn jedes mal beim raus und rein gehen die Meldung kommt.
Hallo zusammen
Ich verwende seit längerem die flexible Fenster-/Tür-Offen Überwachung, welche ich für meine Bedürfnisse etwas angepasst habe.
Das funktioniert soweit ganz gut. Der Lösung von Benni war eine tolle Vorlage und hat mir sehr viel geholfen.
Ich verwende MAX Fensterkontakte, die erzeugen den STATE opened.
Darum habe ich den Notify wie folgt erweitert.
Internals:
DEF .*:(open|opened|tilted) {winOpenStart($NAME)}
NAME winOpen.OpenNotify
NR 54
NTFY_ORDER 50-winOpen.OpenNotify
REGEXP .*:(open|opened|tilted)
STATE 2016-12-20 09:49:34
TYPE notify
Readings:
2016-12-20 00:27:27 state active
Attributes:
soweit ist noch alles ok.
Inzwischen habe ich mir einen HM-SCI-3-FM (3-Kanal-Funk-Schließerkontakt-Interfac) gekauft. Der erzeugt den STATE open und läuft somit in den oben definierten Notify. Dieser offene Schalter hat natürlich nichts mit einem offenen Fenster zu tun, und soll nicht in die Fensterüberwachung laufen. Ich habe also für den HM-SCI-3-FM via eventMap "offen" für open definiert.
Das scheint gem. Event monitor auch zu funktionieren, und wird dort auch wie folgt ausgewiesen.
2016-12-20 09:41:12 CUL_HM HM_3A8ED3_Sw_01 offen
Trotzden wird der oben definierte Notify ausgelöst. Obwohl der doch eigentlich auf "offen" gar nicht anspringen sollte ...!?
Wo ist meine Fehlüberlegung. Was ist die Erklärung dazu?
Gruss birdy
Zitat von: birdy am 20 Dezember 2016, 10:39:25
Dieser offene Schalter hat natürlich nichts mit einem offenen Fenster zu tun, und soll nicht in die Fensterüberwachung laufen.
Das Problem ist in meiner ursprünglichen Methode bereits berücksichtigt:
...
#Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
#angibt, wie oft eine Meldung ausgegeben werden soll.
#Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
if($maxtrigger) {
...
Danke Benni
Da hast Du natürlich recht.
Meine Frage bezieht sich ja nicht direkt auf Deinen Code, der ist absolut ok.
Ich verstehe in diesem Zusammenhang einfach nicht warum mit "offen" der auf "open" definierte Notify ausgelöst wird?
Gruss birdy
Hallo birdy,
ich kann dir bei deinem Problem leider nicht helfen.
Du schreibst aber das du auch die Max! Sensoren verwendest.
Ist es bei dir auch so das die erste Meldung offen sofort nach dem öffnen kommt und nicht erst nach der eingestellten Zeit?
Ps.: Hat sich erledigt, ich habe das winOpen.Open Notify mit einem sleep ergänzt:
.*:(opened) sleep 120; {winOpenStart($NAME)}
Hallo marty29ak
Ja an den Fenstern verwende ich MAX! Sensoren.
Ist aber bezüglich meinem "Problem" nicht von Bedeutung.
Ok, mein Problem hat nichts direkt mit Benni's Code zu tun. Werde meine Frage in einem andren Bereich stellen ???
Zitat von: marty29ak am 20 Dezember 2016, 12:04:09
Ps.: Hat sich erledigt, ich habe das winOpen.Open Notify mit einem sleep ergänzt:
.*:(opened) sleep 120; {winOpenStart($NAME)}
Hallo Martin,
sorry, dass ich mich bisher nicht dazu gemeldet habe, aber für ausführliche Analysen fehlt mir derzeit leider etwas die Zeit (kurz vor Weihnachten halt ;) )
Das was du jetzt gebaut hast, dürfte dazu führen, dass wenn du das Fenster innerhalb der 120 Sekunden schließt, die dein Sleep wartet, trotzdem die winOpenStart-Routine nach Ablauf der 120 Sekunden aufgerufen wird. Das würde bedeuten, das Fenster ist längst wieder geschlossen, es wird aber so behandelt, als wäre es noch offen und die entsprechenden Meldungen gehen raus.
Warum bei dir der erste Trigger sofort kommt, ist mir leider auch noch nicht klar.
Kannst du mal bitte ein list des notify zeigen, so wie ein List des Fensterkontaktes (nicht der Auszug aus der fhem.cfg, sondern die Ausgabe des list-Befehls für das device).
Beim Code für die sub, gehe ich mal davon aus, dass du den 1:1 übernommen hast?
Gruß Benni.
Hallo Benni,
erst mal vielen Dank das du mir helfen möchtest.
Ja das musste ich dann leider auch feststellen, das der Eintrag mit dem Sleep nicht wie gewünscht funktioniert.
Aber auch gut zu wissen das es nicht normal ist, das direkt eine Meldung kommt. Habe schon des Hausfriedens wegen die Kontakte an den Türen deaktiviert.
Also hier dann die List-Ausgaben:
das Notify
Internals:
DEF .*:(opened) {winOpenStart($NAME)}
NAME winOpen.OpenNotify
NR 190
NTFY_ORDER 50-winOpen.OpenNotify
REGEXP .*:(opened)
STATE active
TYPE notify
Readings:
2016-12-20 17:56:49 state active
Attributes:
und hier der Fensterkontakt
Internals:
CHANGED
DEF ShutterContact 11fea5
IODev ml
LASTInputDev ml
MSGCNT 2372
NAME MAX_11fea5
NR 80
STATE closed
TYPE MAX
addr 11fea5
backend ml
ml_MSGCNT 2372
ml_TIME 2016-12-20 18:36:02
rferror 0
serial MEQ0376573
type ShutterContact
Readings:
2016-12-20 18:36:02 MAXLAN_error 0
2016-12-20 18:36:02 MAXLAN_errorInCommand
2016-12-20 18:36:02 MAXLAN_initialized 1
2016-12-20 18:36:02 MAXLAN_isAnswer 0
2016-12-20 18:36:02 MAXLAN_valid 1
2016-12-20 18:36:02 battery ok
2016-12-20 11:41:29 firmware 1.0
2016-12-20 11:41:29 groupid 2
2016-12-20 18:36:02 onoff 0
2016-12-20 18:36:02 state closed
2016-12-20 11:41:29 testresult 2
Internals:
interfaces switch_active;battery
Attributes:
IODev ml
alarmDevice Sensor
alarmSettings alarm0,|MAX_11fea5:opened|Kueche Tür|on
alias Fenster Küche Balkontür
devStateIcon closed:10px-kreis-gruen opened:10px-kreis-rot
event-on-change-reading state
fp_Erdgeschoss 414,83,0, ,MAX_11fea5
fp_Terminal_test 221,51,0, ,MAX_11fea5
group Heizung
room 03_Küche,C_MAX
userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
winOpenMaxTrigger 3
winOpenName Die Terrassentüre in der Küche
winOpenTimer 00:10:00
winOpenTimer2 00:05:00
winOpenType Türe
In dem Modul habe ich lediglich die Ausgabe nicht als Pushmail, sondern als TTS Meldung. Und daher diesen Absatz entsprechend umgeändert:
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
# meine Meldungen über Pushover ausgibt)
my $pushcmd=fhem( "set MyTTS tts ('$devname ist $immer $devstate');;" );
Zitat von: marty29ak am 20 Dezember 2016, 18:38:49
In dem Modul habe ich lediglich die Ausgabe nicht als Pushmail, sondern als TTS Meldung. Und daher diesen Absatz entsprechend umgeändert:
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
# meine Meldungen über Pushover ausgibt)
my $pushcmd=fhem( "set MyTTS tts ('$devname ist $immer $devstate');;" );
Da haben wir doch schon das Problem! :)
$pushcmd soll hier den Befehl, bzw. den Perl-Teil als String erhalten.
So wie du es machst, wird direkt das fhem-Kommando ausgeführt und $pushcmd erhält das Ergebnis der fhem()-Aufrufes.
Es muss hier ungefähr so heißen (ungetestet):
my $pushcmd="fhem(\"set MyTTS tts ('$devname ist $immer $devstate')\");;";
Zitat von: birdy am 20 Dezember 2016, 10:39:25
Inzwischen habe ich mir einen HM-SCI-3-FM (3-Kanal-Funk-Schließerkontakt-Interfac) gekauft. Der erzeugt den STATE open und läuft somit in den oben definierten Notify. Dieser offene Schalter hat natürlich nichts mit einem offenen Fenster zu tun, und soll nicht in die Fensterüberwachung laufen. Ich habe also für den HM-SCI-3-FM via eventMap "offen" für open definiert.
Das scheint gem. Event monitor auch zu funktionieren, und wird dort auch wie folgt ausgewiesen.
2016-12-20 09:41:12 CUL_HM HM_3A8ED3_Sw_01 offen
Trotzden wird der oben definierte Notify ausgelöst. Obwohl der doch eigentlich auf "offen" gar nicht anspringen sollte ...!?
Ich bin nicht sicher wie intern in fhem die Verarbeitung der Events genau passiert und hatte da auch schon meine Probleme. Eventuell greift das eventMap erst später, d.h. der Schließerkontakt meldet das Event "open", und das triggert dann sofort Dein notify, dann greift das eventMap und macht aus "open" ein "offen" aber da ist es eben schon geschehen. Ich würde das notify so definieren, dass es nicht auf beliebige "open"-Meldungen triggert sondern nur auf Meldungen von Fenster-/Türkontakten oder ggf. auch negativ, also auf alle "open", aber nicht auf die "open" von einem Schließerkontakt.
Hallo Benni,
Habe mich heute auch mal bediehnt, nach dem meine andere Lösung über diff Feuchtigkeit nicht so toll lief. Danke Dir fürs teilen.
Grüße
Leon
:) Vielen Dank Benni!!
Das war mein Fehler. Jetzt kommt die Meldung wie gewünscht.
Ich habe bei mir noch ein paar Sachen eingebaut. So wird die Zeit automatisch gekürzt je kälter es draußen ist.
Meine default Zeit ist 20 min und steht in den Fensterdevices als winOpenTimer aber nur bei >7 Grad bis 0 Grad sind es nur noch 1/2 und kleiner 0 Grad 1/4.
Wer es brauchen kann, kann sich ja melden.
Grüße
Zitat von: CoolTux am 21 Dezember 2016, 22:08:33
Ich habe bei mir noch ein paar Sachen eingebaut. So wird die Zeit automatisch gekürzt je kälter es draußen ist.
Meine default Zeit ist 20 min und steht in den Fensterdevices als winOpenTimer aber nur bei >7 Grad bis 0 Grad sind es nur noch 1/2 und kleiner 0 Grad 1/4.
Wer es brauchen kann, kann sich ja melden.
Die Warnzeit von der Aussentemperatur abhängig zu machen, das macht Sinn! Gute Idee! Wo genau hast Du was geändert?
Zitat von: hartenthaler am 22 Dezember 2016, 00:02:03
Die Warnzeit von der Aussentemperatur abhängig zu machen, das macht Sinn! Gute Idee! Wo genau hast Du was geändert?
#Holen von weiteren Attributen, sofern vorhanden:
my $waittime;
my $devtimer2;
if( ReadingsVal("TempFeuchtSensorAussen","temperature","-1") > 7 ) {
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 20 Minuten, falls nicht angegeben
$waittime = AttrVal($dev,'winOpenTimer','00:20:00');
#Zeit für die Folge-Meldungen, sofern abweichend angegeben
#Default ist die normale Zeit, die oben schon ermittelt wurde
$devtimer2 = AttrVal($dev,'winOpenTimer2',$waittime);
}
### Ist die Aussentemperatur unter 8 aber über 0 Grad wird die waittime und devtime2 durch 2 geteilt. Also nur noch die hälfte der Zeit.
elsif( ReadingsVal("TempFeuchtSensorAussen","temperature","-1") > 0 ) {
$waittime = sec2time(time2sec(AttrVal($dev,'winOpenTimer','00:20:00')) /2 );
$devtimer2 = sec2time(time2sec(AttrVal($dev,'winOpenTimer2',$waittime)) /2 );
} else {
### Liegt die Aussentemperatur unter 0.1 Grad wird die waittime und devtime2 durch 4 geteilt.
$waittime = sec2time(time2sec(AttrVal($dev,'winOpenTimer','00:20:00')) /4 );
$devtimer2 = sec2time(time2sec(AttrVal($dev,'winOpenTimer2',$waittime)) /4 );
}
#Ein eventuell definierter "schöner" Name für das Device, der in der Meldung ausgegeben werden soll.
#Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
#device-Name genommen.
my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
Die zwei zusätzlichen Funktionen sec2time und time2sec habe ich in eine myUtils_Helper welche noch andere Helferlein beinhaltet. Kann man aber auch in die selbe myUtils stecken wie die Fenster offen Funktion.
sub time2sec($) {
my ($timeString) = @_;
my @time = split /:/, $timeString;
return $time[0] * 3600 + $time[1] * 60;
}
sub sec2time($) {
my ($sec) = @_;
# return human readable format
my $hours = ( abs($sec) < 3600 ? 0 : int( abs($sec) / 3600 ) );
$sec -= ( $hours == 0 ? 0 : ( $hours * 3600 ) );
my $minutes = ( abs($sec) < 60 ? 0 : int( abs($sec) / 60 ) );
my $seconds = abs($sec) % 60;
$hours = "0" . $hours if ( $hours < 10 );
$minutes = "0" . $minutes if ( $minutes < 10 );
$seconds = "0" . $seconds if ( $seconds < 10 );
return "$hours:$minutes:$seconds";
}
Hoffe man kann erkennen wo ich was angepasst habe. Ich habe da noch andere Sachen drin. Zum Beispiel ist das ganze bei mir nur Interessant wenn mein Heizungsdummy NICHT auf Sommer oder HeizungAus steht. Das frage ich dann aber schon im Notify ab.
Ausserdem schlafen die Kinder immer bei Fenster offen. Ich würde also 3 mal eine Nachricht bekommen wenn die Kinder Abends das Fenster zum schlafen aufmachen. Also habe ich es so gemacht das die at's nicht erstellt werden wenn die Kinder auf asleep (Roommate) stehen.
Grüße
Leon
Hallo Leon,
schöne Erweiterung, danke!
Ich plane inzwischen bereits, das ganze demnächst mal in ein anständiges Modul zu packen. 8)
Habe mal wieder Lust ein größeres Stück Code zu programmieren ;D
Gruß Benni.
Morgen Benni,
Das kenne ich ich, manchmal will man einfach mal wieder etwas kreatives machen.
An ein Modul hatte ich auch schon gedacht, fand dann aber das der Code noch zu klein ist für ein Modul. Allerdings habe ich da noch ein paar Ideen die mit einfließen könnten.
Ich schreibe nachher mal ein Brainstorming und Du kannst ja dann entscheiden ob es in Deinen Augen sinnvoll ist oder nicht :)
Grüße
Leon
Hallo Leon,
klar! Gerne!
Ich habe da auch noch ein paar Ideen im Hinterkopf :)
Gruß Benni.
So Benni,
Dann wollen wir mal.
- flexible Zeiten anhand der Außentemperatur, die default Zeit für die höchste Temperaturvorgabe, danach mit Teilern arbeiten
- Abhängigkeit zur desired-temp des Leaderthermostates (der die gemessene Temperatur an gibt) des Fensterraumes, ich empfehle nicht mehr wie 3 Grad Differenz
- Schlafräume außen vorlassen wenn der Raumbesitzer auf asleep steht.
Das wären meine Ideen. Ich fand die Idee mit dem Humidity diff auch ganz interessant. Aber bei mir im Badezimmer hat das nicht wirklich Sinnvoll geschalten.
Grüße
Ich sehe hier zwei grundsätzliche Richtungen:
- Sicherheit
- Komfort/Luftgüte
Bei ersterem steht es im Vordergrund, dass man informiert ist, falls Fenster/Balkontüren/Türen länger offen stehen, insbesondere wenn man weggeht (Einbruchschutz). Hier ist es wichtig, ob jemand zu Hause ist oder nicht. Falls jemand da ist, dann sind manche Fenster/Türen unkritisch und können ohne Warnung beliebig lange offen stehen. Andere, etwa die Wohnungstür, sind auch dann kritisch und sollten überwacht werden. Wenn niemand zu Hause ist, dann sollte die Überwachung der Außenhaut scharf sein, ein Fenster zum Innenhof oder eine innere Tür sind dann aber auch nicht so wichtig. Geht also in Richtung Alarmanlage.
Bei zweiterem ist es wichtig, dass insbesondere Fenster nicht länger als nötig offen stehen, damit es vor allem im Winter nicht zu kalt im Raum wird. Das geht dann auch in Richtung "Taupunkt optimiertem Lüften" (siehe http://www.meintechblog.de/2015/08/raumklima-im-smart-home-mit-fhem-verbessern-taupunktoptimiertes-lueften/ (http://www.meintechblog.de/2015/08/raumklima-im-smart-home-mit-fhem-verbessern-taupunktoptimiertes-lueften/)), wobei ich das dann noch mit den CO2-Werten in den Räumen verknüpfen würde. Hier geht es in die Richtung: "bitte Fenster jetzt öffnen" und "bitte Fenster jetzt schliessen", was aber beides auch nur Sinn macht, wenn jemand zu Hause ist, der auf eine solche Nachricht reagieren kann. Hier ist es wichtig diese Nachricht "bitte öffnen/schließen" so auszugeben, dass es für die Bewohner optimal ist (eventuell per msg und damit flexibel per Telegram/Pushover/Sonos/Lampe blinkt/...).
Gruß Hermann
Zitat von: hartenthaler am 20 Dezember 2016, 22:46:52
Ich bin nicht sicher wie intern in fhem die Verarbeitung der Events genau passiert und hatte da auch schon meine Probleme. Eventuell greift das eventMap erst später, d.h. der Schließerkontakt meldet das Event "open", und das triggert dann sofort Dein notify, dann greift das eventMap und macht aus "open" ein "offen" aber da ist es eben schon geschehen. Ich würde das notify so definieren, dass es nicht auf beliebige "open"-Meldungen triggert sondern nur auf Meldungen von Fenster-/Türkontakten oder ggf. auch negativ, also auf alle "open", aber nicht auf die "open" von einem Schließerkontakt.
Hallo hartenthaler,
Ja muss wohl so sein. Die einzige logische Erklärung. Dem widerspricht allerdings die commandref ein Stück weit, denn darin wird empfohlen für die Definition der Notifys sich an den im Eventmonitor ersichtlichen Events zu orientieren.
Zitat von: Benni am 22 Dezember 2016, 08:26:03
Hallo Leon,
klar! Gerne!
Ich habe da auch noch ein paar Ideen im Hinterkopf :)
Gruß Benni.
Mein Ideen welche ich bereits für mich umgesetzt habe sind. Ich versende die Mitteilungen direkt aus dem Code. Abhängig von den in diesen Moment vorherrschenden Einflussfaktoren (für das Konzept jetzt via AT Befehl eine Meldung in die Queue zu stellen welche dann z.B. in 30 Minuten versendet wird, konnte ich mich nicht begeistern). Zu den Einflussfaktoren gehört z.B. die Aussentemperatur, später soll dann auch noch ein Regensensor dazu kommen. Sobald ein Fenster offen ist wird der Code zyklisch alle paar Minuten gestartet und prüft die relevanten Einflussfaktoren. Wie lange ist das Fenster schon offen, wann wurde die letzte Meldung verschickt usw. Fällt z.B. die Temperatur steil ab wird die nächste Meldung evtl. ,,sofort" fällig. Damit das Ganze so läuft wie gewollt, musste ich div. weitere Attribute definieren. So auch eines für den Zeitpunkt wann das Fenster geschlossen wurde. Da ich keine Globalen Attribute wollte, und es mir zu umständlich war für jedes Fenster die Attribute einzeln zu definieren, kümmert sich jetzt der Code selbstständig darum. Was benötigt wird und noch fehlt wird automatisch angelegt.
Wie gesagt, das waren meine persönlichen Ideen, jeder kann damit anfangen was er will
Gruss birdy
Hallo Benni,
ich habe die grundlegende Idee Deiner hier erstellten Automatik in mein gerade entstehendes Modul rund um den "Zuhause Status" einfliessen lassen.
Das Konzept finde ich sehr gut und habe es fast 1:1 übernommen. Der Code ist allerdings für das Modul ein anderer geworden. ;)
Da mein Modul alle möglichen allgemeinen Readings haben soll, eben auch für die Jahreszeit, überlege ich Attribute für mögliche ReTriggerTimer-Teiler anhand der Jahreszeit einzuführen!
Grundlegend ist die Jahreszeit doch schon erst mal ein recht guter Indikator für die mögliche Öffnungszeit.
Also z.B. Sommer Teiler 1 und Winter Teiler 3. Herbst und Frühling könnten Teiler 2 bekommen.
Muss man es wirklich noch genauer haben anhand von weiteren Sensoren?
Wir sprechen hier von einfachen Offen-Warnungen bzw. von automatisch öffnenden/schliessenden Fenstern!?
Gruß
Dan
Zitat von: DeeSPe am 30 Dezember 2016, 21:45:56
Das Konzept finde ich sehr gut und habe es fast 1:1 übernommen. Der Code ist allerdings für das Modul ein anderer geworden. ;)
Hallo Dan,
das klingt ja sehr interessant! Das muss ich mir demnächst mal anschauen. Verfolgt habe ich die Entstehung hier im Forum schon flüchtig 8)
Da bin ich ja gerade mal froh, dass ich noch mit nichts angefangen habe, was das geplante Modul betrifft. Habe mir gerade noch eine andere Baustelle ans Bein gebunden und bin im Moment Dabei mein komplette Haus mit anständigem LAN und WLAN auszurüsten.
Der Code wäre bei mir als Modul sicher auch etwas anders geworden, als er bisher ist. ;)
Ich glaube übrigens auch nicht, dass man die Öffnungsregelung noch genauer machen muss, v.a. unter dem Aspekt, dass man das als Modul relativ breit einsetzen können soll. Irgendwann wird es einfach zu speziell. Außerdem muss man ja eine gewisse Mindestdauer auch unabhängig von der Temperatur lüften, um überhaupt einen vernünftigen Luftaustausch zu haben und ebenso bringt eine zu lange Dauer letztendlich auch keinen Mehrgewinn, selbst wenn's draußen warm genug ist.
Gruß Benni.
Und nicht vergessen das Fenster zum schlafen eventuell auch dauerhaft über Nacht aufbleiben ;D
Zitat von: CoolTux am 30 Dezember 2016, 22:34:15
Und nicht vergessen das Fenster zum schlafen eventuell auch dauerhaft über Nacht aufbleiben ;D
Für sowas habe ich die ursprüngliche Lösung bei mir so erweitert, dass ich auf meinem Tablet einen Button (für einen Dummy) habe, mir dem ich die noch ausstehenden Meldungen auf einen Schlag alle Löschen kann. Wenn ich im ganzen Haus gleichzeitig alle Fenster zum Lüften Aufreiße will ich nicht x Meldungen bekommen.
Den kann ich bei mir dann auch vor dem Schlafengehen nochmal drücken ;)
Ich wollte bei mir auch mal noch ein Sammeln einbauen, sobald mehrere Fenster (>3 oder so) gleichzeitig offen sind und jeweils eine Meldung anstünde, so dass eben nur noch eine kommt, die angibt dass derzeit noch 3 (oder mehr) Fenster geöffnet sind.
Zitat von: CoolTux am 30 Dezember 2016, 22:34:15
Und nicht vergessen das Fenster zum schlafen eventuell auch dauerhaft über Nacht aufbleiben ;D
Stimmt!
Das hatte ich auch schon bedacht, aber bisher mein Schlafzimmerfenster einfach keinen Trigger gegeben! 8)
Also noch ein Attribut ala "DontTriggerInMode" wo man dann den RESIDENTS State angeben kann in dem keine Erinnerung getriggert werden soll! Das setzt man dann ala Regex auf z.B. "gotosleep|asleep|awoken".
Gruß
Dan
Genau. Ich verwende gotosleep und asleep fur meinen Sohn. Da bei asleep nach 10s das Licht aus geht, Stelle ich ihn lieber auf gotosleep und öffne dann in Ruhe das Fenster.
Falls jemand Interesse hat, ich habe Bennis Code in etwas abgewandelter Form in mein neues Modul (https://forum.fhem.de/index.php?topic=64317) integriert. 8)
Gruß
Dan
Hallo zusammen!
danke für den Code. Es ist eigentlich genau das was ich suche. Brauche jedoch noch eine Idee. Ich möchte nur die Fenster etc in einem bestimmten überwachen. Funktioniert soweit indem ich disableforintervals in dem Open notify entsprechend setze. Event on Change readings habe ich auch für die Fenster gesetzt, da diese sonst jedesmal das notify neu triggern. Das funktioniert alles soweit wenn Fenster in dem Zeitraum geöffnet werden. Wenn allerdings Fenster vorher geöffnet worden sind, wird das notify ja nie getriggert,da Event on Change reading das blockt. Hat hier jemand eine Idee?
Hallo zusammen,
Vorab vielen Dank für dein Script :) gefällt mir sehr... wenn ich es den bloß zum laufen kriegen würde :)...
Folgende Fehlermeldung habe ich...
2017.02.27 14:11:40 1: define WC.Fenster_OpenTimer at +1 {PushInfo('Fenster','WC.Fenster ist noch offen');winOpenStart('WC.Fenster','1');}: Wrong timespec 1: either HH:MM:SS or {perlcode}
2017.02.27 14:11:40 3: define WC.Fenster_OpenTimer at +1 {PushInfo('Fenster','WC.Fenster ist noch offen');;winOpenStart('WC.Fenster','1');;} : Wrong timespec 1: either HH:MM:SS or {perlcode}
2017.02.27 14:11:40 3: Please define WC.Fenster_OpenTimer first
2017.02.27 14:11:40 3: attr WC.Fenster_OpenTimer room Toilette : Please define WC.Fenster_OpenTimer first
2017.02.27 14:11:40 3: winOpen.OpenNotify return value: Please define WC.Fenster_OpenTimer first
2017.02.27 14:11:41 1: define WC.Fenster_OpenTimer at +1 {PushInfo('Fenster','WC.Fenster ist noch offen');winOpenStart('WC.Fenster','1');}: Wrong timespec 1: either HH:MM:SS or {perlcode}
2017.02.27 14:11:41 3: define WC.Fenster_OpenTimer at +1 {PushInfo('Fenster','WC.Fenster ist noch offen');;winOpenStart('WC.Fenster','1');;} : Wrong timespec 1: either HH:MM:SS or {perlcode}
2017.02.27 14:11:41 3: Please define WC.Fenster_OpenTimer first
2017.02.27 14:11:41 3: attr WC.Fenster_OpenTimer room Toilette : Please define WC.Fenster_OpenTimer first
2017.02.27 14:11:41 3: winOpen.OpenNotify return value: Please define WC.Fenster_OpenTimer first
list
Attributes:
IODev HMLAN1
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 2.4
model HM-SEC-SC-2
peerIDs 00000000,22E34A03,
room Toilette
serialNr LEQ0404274
subType threeStateSensor
userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
winOpenMaxTrigger 10
winOpenTimer 1
winOpenTimer2 2
winOpenType Fenster
Grüße
Thomas
EDIT : Fehler gefunden
winOpenTimer 00:01:00
winOpenTimer2 00:02:00
Ich verwende für unterschiedliche Fenster frei definierbare, TEMPERATURABHÄNGIGE Meldezeiten.
Dazu habe ich mir das Attribut ""winOpenTempArray" gebaut. Vielleicht kann's ja wer brauchen:
# Außentemperatur ermitteln. Hier Wetterservice via 'openweathermap'
# Kann natürlich auch ein lokaler Temperatursensor sein
sub getTemperature
{
my $temperature=ReadingsVal('owo','c_temperature',0);
return $temperature;
}
Und untenstehenden Code direkt einfügen hinter
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 10 Minuten, falls nicht angegeben
my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
# Temperaturabhaengige Erstalarmierungszeiten verwenden
#
# und ggf die Wartezeit ueberschreiben, wurde ein Temperatur-Array definiert.
# Wird in den definierten Intervallen nicht die passende Temperatur gefunden, dient 'winOpenTimer' als default
#
# Ein Temperaturintervall wird im Device-Attribut "winOpenTempArray" angegeben und mit "<MIN> <MAX> <DAUER>" definiert.
# Mehrere Intervalle koennen mit ";" aneinander gefuegt werden.
#
# Beispiel: -99 -1 00:05:00;-1 5 00:10:00;5 10 00:15:00;10 15 00:30:00;15 99 0
# Zwischen 5 und 10 Grad Celsius wird die Erstalarmierungszeit auf 15 Minuten gesetzt.
#
my $tempArray=AttrVal($dev,'winOpenTempArray',0);
if($tempArray) {
my @temperatures = split /;/, $tempArray;
foreach (@temperatures)
{
my ($minTemp, $maxTemp, $dauer) = split / /, $_;
# die Funktion "getTemperature" muss definiert sein, welche die zu pruefende Temperatur liefert.
if ($minTemp < getTemperature && $maxTemp >= getTemperature) {
$waittime=$dauer;
last;
}
}
}
#################### ENDE Temperaturabhaengige Erstalarmierungszeiten verwenden
Ich bin gestern endlich mal dazu gekommen eine Raummeldung bei mehr wie einem geöffneten Fenster pro Raum zu erstellen. Mir war das zu nervig das wenn ich 2 Fenster in einem Raum öffne alle x Minuten kurz hintereinander 2 Meldungen bekam.
Sollte es von Interesse sein stelle ich den Code mit Erklärung gerne ein.
Grüße
Zitat von: CoolTux am 25 April 2017, 06:46:28
Ich bin gestern endlich mal dazu gekommen eine Raummeldung bei mehr wie einem geöffneten Fenster pro Raum zu erstellen. Mir war das zu nervig das wenn ich 2 Fenster in einem Raum öffne alle x Minuten kurz hintereinander 2 Meldungen bekam.
Das Problem der "zu vielen Meldungen" beim Lüften habe ich bei mir mit einem Dummy gelöst, der auf on gesetzt wird und bleibt, so lange es aktive Timer (bei mir inzwischen mittels sleep gelöst) gibt.
Wird dieser Dummy auf off gesetzt, werden alle noch aktiven Timer (resp. sleep) gelöscht und Ruhe ist :)
Auch eine gute Lösung. Und so viel einfacher ;D
Guten Abend Forum!
diese tolle Lösung mag bei mir nur mit dem Dummy Fenster funktionieren, mit den echten Fenstersensoren klappt es leider nicht. Den Code habe ich von Seite 1 kopiert, bestimmt passt nur eine Kleinigkeit nicht, vielleicht kann mir jemand von Euch helfen, die Tomaten von den Augen zu entfernen.
Notify
Internals:
DEF .*:(open|tilted) {winOpenStart($NAME)}
NAME winOpen.OpenNotify
NR 162
NTFY_ORDER 50-winOpen.OpenNotify
REGEXP .*:(open|tilted)
STATE active
TYPE notify
Readings:
2017-04-26 19:48:41 state active
Attributes:
room FHT,Zentral
Fenster
Internals:
CODE 1d1d
DEF 1d1d
FHZ_0_MSGCNT 15
FHZ_0_RAWMSG 810c04f20909a0011d1d7e006720
FHZ_0_TIME 2017-04-26 20:40:25
LASTInputDev FHZ_0
MSGCNT 15
NAME Temp.KG.Buero
NR 33
STATE measured-temp: 20.9
TYPE FHT
Readings:
2017-04-26 20:40:25 ack 32
2017-04-26 20:39:33 actuator 92%
2017-04-26 20:40:25 battery ok
2017-04-26 20:40:24 desired-temp 12.0
2017-04-26 20:40:25 end-xmit 32
2017-04-26 20:40:25 lowtemp ok
2017-04-26 20:30:34 measured-temp 20.9
2017-04-25 21:03:54 mode auto
2017-04-26 20:30:34 state measured-temp: 20.9
2017-04-26 20:30:34 temperature 20.9
2016-07-10 14:02:27 tue-from1 09:00
2016-07-10 14:02:28 tue-from2 24:00
2016-07-10 14:02:28 tue-to1 21:00
2016-07-10 14:02:28 tue-to2 24:00
2017-04-26 20:40:25 warnings Window open
2017-04-26 20:40:25 window open
2017-04-26 20:40:25 windowsensor ok
Attributes:
room FHT
userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
winOpenMaxTrigger 3
winOpenName KGfenster
winOpenTimer 00:00.10
winOpenTimer2 00:00:30
winOpenType Fenster
Wenn ich wenigstens einen Hinweis im Log sehen würde, aber da kommt einfach gar nichts. Wenn ich ein Fenster öffne, ändert sich das Reading "Window closed" zu "Window open", doch das Notify springt nicht an.
Bin für jeden Tipp dankbar!
Dirk
Dein Fensterkontakt zeigt Temperatur an. Scheint eher ein Thermostat zu sein. Hast du keine reinen Fensterkontakte?
Hallo CoolTux,
ich würde schon sagen, dass es reine Fensterkontakte sind.
FS20 Fensterkontakt
https://www.elv.de/fs20-tfk-2-kanal-tuer-fenster-kontakt-fertiggeraet.html
FHT 80b Regeleinheit
https://www.elv.de/Funk-Heizk%C3%B6rperthermostat-FHT-80B/x.aspx/cid_726/detail_34945
FS20 Fensterkontakt --> FHT 80b Regeleinheit --> USB-FHZ an FHEM
Deine Frage hat mich aber auf eine Idee gebracht. Da ich über so einen selbst zusammengebauten NanoCUL verfüge, war ich auf der Suche, ob man mit diesem vielleicht das Funksignal des Fensterkontakt direkt empfangen kann. Und ja - man kann.
Internals:
CODE 46c493
DEF 46c493
IODev nanoCUL868
LASTInputDev nanoCUL868
MSGCNT 3
NAME FHTTK.Buero
NR 139
OPEN 1
PREVSTATE Closed
PREVTIMESTAMP 1493241834
STATE Open
TYPE CUL_FHTTK
nanoCUL868_MSGCNT 3
nanoCUL868_RAWMSG T46C49301
nanoCUL868_RSSI -65
nanoCUL868_TIME 2017-04-26 23:24:56
Prev:
STATE 01
TIMESTAMP 1493241896
Readings:
2017-04-26 23:24:56 Battery ok
2017-04-26 23:24:56 Previous Closed
2017-04-26 23:24:56 Reliability ok
2017-04-25 19:39:05 Sync Syncing
2017-04-26 23:24:56 Window Open
2017-04-26 23:24:56 state Open
Attributes:
IODev nanoCUL868
room CUL_FHTTK
userattr winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
winOpenMaxTrigger 3
winOpenName CulBueroFenster
winOpenTimer 00:00:13
winOpenTimer2 00:00:34
winOpenType Fenster
Allerdings juckt dieser Weg das Notify auch nicht - es wird einfach nicht getriggert. In der Datei 99_Utils.pm, in der sich die zwei Subfunktionen winOpenStart und winOpenStop befinden, habe ich noch eine Zeile fürs logging ergänzt
sub winOpenStart($;$) {
#Als Parameter muss der device-Name übergeben werden
my $dev=shift(@_);
Log3(undef,1,"winOpenDevice: $dev");
Aber es wird leider nichts geloggt, die Funktion wird für meine Begriffe nicht aufgerufen. Wenn ich nur wüsste warum :-\
Zitat von: dhupfer am 26 April 2017, 23:56:43
In der Datei 99_Utils.pm ...
Achtung! Nicht die 99_Utils.pm dafür verwenden.
Dazu erstellt man sich eine 99_
myUtils.pm
s.a. https://wiki.fhem.de/wiki/99_myUtils_anlegen
Das hat zwar nicht direkt was mit der Problemlösung zu tun, aber die 99_Utils.pm gehört zur FHEM Standardauslieferung und wird ggf. bei einem update auch wieder überschrieben.
Zur Problemlösung:
Bleibe bei deinem Fensterkontakt. Setze dort mal das Attribut
event-on-change-reading auf
.* und dann schau dir mal im Eventmonitor an, wie die Events des Fensterkontaktes beim Öffnen, bzw. Schließen des Fensters aussehen. Ausgabe ggf. hier mal posten. Wahrscheinlich braucht es eine Anpassung der regex bei den notify.
Ok dann also Fensterkontakte. Allerdings wird die hier verwendete RegEx für das Notify wie Benni schon so treffend sagte nicht passen.
.*:(open|tilted) {winOpenStart($NAME)}
Das geben Deine Fensterkontakte so sicherlich nicht her. Also befolge Mal bitte Bennis Bitte.
Servus Benni,
das Attribut event-on-change-reading habe ich auf .* gesetzt. Allerdings erscheint da bei mir auch nicht entscheidet mehr im Event Monitor als sonst. Aber beim direkten Empfangsweg über CUL ist mir doch aufgefallen, dass das Wörtchen "Open" und "Closed" einen großen Anfangsbuchstaben hat. Und tatsächlich, mit
.*:(Open|tilted) {winOpenStart($NAME)}
wird das Notify aktiv :-)
Der Weg über das Raumthermostat geht nach wie vor nicht, hier wird open und closed kleingeschrieben:
2017-04-27 10:53:22 FHT Temp.KG.Buero actuator: 0%
2017-04-27 10:53:23 FHT Temp.KG.Buero desired-temp: 12.0
2017-04-27 10:53:23 FHT Temp.KG.Buero ack: 24
2017-04-27 10:53:24 readingsGroup ZE.Fenster Temp.KG.Buero.window: open
2017-04-27 10:53:24 FHT Temp.KG.Buero window: open
2017-04-27 10:53:24 FHT Temp.KG.Buero warnings: Window open
2017-04-27 10:53:24 FHT Temp.KG.Buero ack: 32
2017-04-27 10:53:24 FHT Temp.KG.Buero end-xmit: 32
2017-04-27 10:57:17 FHT Temp.KG.Buero actuator: 100%
2017-04-27 10:57:18 FHT Temp.KG.Buero desired-temp: 30.0
2017-04-27 10:57:18 FHT Temp.KG.Buero ack: 60
2017-04-27 10:57:19 readingsGroup ZE.Fenster Temp.KG.Buero.window: closed
2017-04-27 10:57:19 FHT Temp.KG.Buero window: closed
2017-04-27 10:57:19 FHT Temp.KG.Buero warnings: none
2017-04-27 10:57:19 FHT Temp.KG.Buero ack: 0
2017-04-27 10:57:19 FHT Temp.KG.Buero end-xmit: 0
Falls noch jemand einen Geistesblitz hat - gerne, ansonsten bin ich so auch zufrieden. Klasse Funktion!
Danke auch für den Hinweis mit der Datei 99_Utils.pm.
Danke CoolTux für die Nachfrage, so war die Idee über CUL geboren ;)
Grüße aus Ottobrunn,
Dirk
.*:window:.(open|tilted) {winOpenStart($NAME)}
So sollte es auch mit den Thermostaten gehen.
Zitat von: CoolTux am 27 April 2017, 11:30:38
.*:window:.(open|tilted) {winOpenStart($NAME)}
So sollte es auch mit den Thermostaten gehen.
Sollte klappen, ansonsten kann man auch um die Groß-/Kleinschreibung abzufangen die Regex auch noch so anpassen:
.*:([Oo]pen|[Tt]ilted) {winOpenStart($NAME)}
So wird "Open", "open", "Tilted" und "tilted" abgefangen.
die Vorschläge von CoolTux und Benni fruchten - RESPEKT!
Da ich ja zwei Wege habe, die Fensterkontakte abzufragen, habe ich noch eine Weile getestet. Der Knackpunkt scheint der Doppeltpunkt in der RegExp zu sein...
geht mit CUL
.*:(Open|tilted) {winOpenStart($NAME)}
geht mit FHZ
.*:window:.(open|tilted) {winOpenStart($NAME)}
geht mit CUL und FHZ
.*([Oo]pen|[Tt]ilted) {winOpenStart($NAME)}
geht mit CUL und FHZ
.*\s([Oo]pen|[Tt]ilted) {winOpenStart($NAME)}
Diese Variante habe ich nun in Verwendung. \s steht für 1x Whitspace
Zitat von: dhupfer am 27 April 2017, 17:08:19
die Vorschläge von CoolTux und Benni fruchten - RESPEKT!
Da ich ja zwei Wege habe, die Fensterkontakte abzufragen, habe ich noch eine Weile getestet. Der Knackpunkt scheint der Doppeltpunkt in der RegExp zu sein...
geht mit CUL
.*:(Open|tilted) {winOpenStart($NAME)}
geht mit FHZ
.*:window:.(open|tilted) {winOpenStart($NAME)}
geht mit CUL und FHZ
.*([Oo]pen|[Tt]ilted) {winOpenStart($NAME)}
geht mit CUL und FHZ
.*\s([Oo]pen|[Tt]ilted) {winOpenStart($NAME)}
Diese Variante habe ich nun in Verwendung. \s steht für 1x Whitspace
Die beiden letzten Varianten sind im Prinzip identisch, da .* auch \s mit abdeckt!
Gruß
Dan
Zitat von: dhupfer am 27 April 2017, 17:08:19
Der Knackpunkt scheint der Doppeltpunkt in der RegExp zu sein...
Ja! Das ist quasi eine Spezialität der Events, bzw. wie sie von notify (https://fhem.de/commandref_DE.html#notify) eingefangen werden können:
Zitat von: https://fhem.de/commandref_DE.html#notify
<Suchmuster> ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) Gerätename:Event.
Das <Suchmuster> muss exakt (!) entweder dem Gerätenamen entsprechen oder der Zusammenfügung aus Gerätename:Event. Events lassen sich mit "inform" in Telnet oder durch Beobachtung des "Event-Monitors" in FHEMWEB ermitteln.
Hallo zusammen,
ich mache anscheinend etwas falsch beim Anlegen des UserAttr. Ich setzte den MaxTrigger auf 10 aber wenn ich Logge dann ist der immer 0.
attr Bad_Fensterkontakt_Dach userattr winOpenMaxTrigger:10 winOpenTimer:00:15:00 winOpenTimer2:00:10:00 winOpenTemp:10 winOpenType:Fenster winOpenName:Badezimmer
Hier das List zum Fensterkontakt
Internals:
CFGFN /usr/local/FHEM/etc/MyCfg/20_Bad.cfg
DEF ShutterContact 0f094d
IODev cm
LASTInputDev cm
MSGCNT 15
NAME Bad_Fensterkontakt_Dach
NR 137
RSSI -70
STATE opened (rf error)
TYPE MAX
addr 0f094d
cm_MSGCNT 15
cm_TIME 2017-04-30 20:42:58
rferror 1
type ShutterContact
Readings:
2017-04-30 20:42:58 RSSI -70
2017-04-30 20:42:58 battery ok
2015-01-24 23:02:41 msgcnt 13
2017-04-30 20:42:58 onoff 1
2017-04-30 20:42:58 state opened (rf error)
Internals:
interfaces switch_active;battery
Attributes:
IODev cm
devStateIcon closed:signal_Fenster_Offen.off opened:signal_Fenster_Offen.on
group Bad
room Bad
userattr winOpenMaxTrigger:10 winOpenTimer:00:15:00 winOpenTimer2:00:10:00 winOpenTemp:10 winOpenType:Fenster winOpenName:Badezimmer
Hier der Code aus der winOpenStart()
#Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
Log3(undef,1,"winOpenMessage: Ich bin an der zweiten Stelle Wert aus MaxTrigger $maxtrigger");
if($maxtrigger) {
Log3(undef,1,"winOpenMessage: Ich bin an der dritte Stelle");
Da der MaxTrigger immer 0 ist komme ich auch nicht weiter. Was mache ich hier falsch?
Danke für eure Hilfe
Gruß
Thomas
userattr
FensterSuedWest FensterSuedWest_map FensterWohnzimmer FensterWohnzimmer_map structexclude winOpenMaxTrigger winOpenName winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe
Und dann die Werte bei den Attributen angeben.
Danke jetzt klappts
Ahh wichtig die timer zeit mit 00:00:10 anzugeben :)
Wie funzt das mit Pushinfo? Nutze Telegram
"teleBot message BLAA BLAAA "
Will so eine Push senden
Das "funzt" in dem Du den Befehl in die Msg Meldung der Sub ein bindest.
pushcmd
Zitat von: ChrisW am 03 Dezember 2017, 21:46:13
Wie funzt das mit Pushinfo? Nutze Telegram
"teleBot message BLAA BLAAA "
Will so eine Push senden
Weiter vorne in diesem Thread (https://forum.fhem.de/index.php/topic,36504.msg288872.html#msg288872) habe ich doch ein Beispiel für eine
sub Pushinfo gepostet.
Dort musst du doch nur statt ins Log zu schreiben eben deinen Telegram-Bot benutzen.
Also statt
Log3 ... irgendwie sowas:
fhem("teleBot message BLAA BLAAA");
Statt "Blablabla", kannst du ja bei bedarf die Variablen verwenden, die im Beispiel schon vorhanden sind.
gb#
Ja danke das mit dem Log hatte ich schon drin aber klar so einfach geht es :) Funktioniert auch Danke.
Kann man das auch ganz Simpel nutzen um eine Push zu senden wenn die Fenster Offen sind und der Status abwesend sich ändert ?
Quasi eine Warnung wnen ich Weg bin das Fneste rnoch offen sind. Unabhänig der opentime .
Gibt einige Lösungen aber wäre ja schon dies hier quasi dafür zu benutzen.
Nein. Das hier vorgestellte Konzept basiert darauf das die Fenster getriggert werden. Du kannst es natürlich erweitern.
Zitat von: ChrisW am 04 Dezember 2017, 11:31:10
Kann man das auch ganz Simpel nutzen um eine Push zu senden wenn die Fenster Offen sind und der Status abwesend sich ändert ?
Quasi eine Warnung wnen ich Weg bin das Fneste rnoch offen sind. Unabhänig der opentime .
Gibt einige Lösungen aber wäre ja schon dies hier quasi dafür zu benutzen.
Das habe ich mit einem DOIF und der Zusammenfassung aller Fensterkontakte als structure gelöst.
In einem structure werden alle Fensterkontakte zusammengefasst und mit dem Attribut
clientstate_priority open closed ist die structure auf "open" wenn mind. ein Fenster geöffnet ist.
Das DOIF hat dann beispielhaft folgenden Code:
(([Fk.FensterkontaktAlle] eq "open") and
([Anwesenheitsstatus] eq "abwesend"))
(set PushMsg msg 'Unser Haus' 'Ein Fenster ist noch offen und es ist niemand zu Hause!' '' 1 'siren')
Ich habe das ganze mit dem Modul Residents verknüpft. Sobald absent gemeldet wird, wird eine Funktion gestartet welche unter anderem nach schaut ob und wo Fenster auf sind und meldet das.
Zitat von: CoolTux am 05 Dezember 2017, 08:54:39
Ich habe das ganze mit dem Modul Residents verknüpft. Sobald absent gemeldet wird, wird eine Funktion gestartet welche unter anderem nach schaut ob und wo Fenster auf sind und meldet das.
Es ist ja auch ein ganz anderer Fall, wenn das Fenster geöffnet wird und zu dem Zeitpunkt schon gar keiner mehr zuhause ist (Einbruch!) ;D
Zitat von: Benni am 05 Dezember 2017, 09:11:42
Es ist ja auch ein ganz anderer Fall, wenn das Fenster geöffnet wird und zu dem Zeitpunkt schon gar keiner mehr zuhause ist (Einbruch!) ;D
Ja das ist wohl war. Aber da ich Dachgeschoß wohne habe ich mir hier noch keine großen Gedanken dazu gemacht :D
Zitat von: CoolTux am 05 Dezember 2017, 09:13:58
Ja das ist wohl war. Aber da ich Dachgeschoß wohne habe ich mir hier noch keine großen Gedanken dazu gemacht :D
Sorry, das hast du falsch verstanden!
Dein Ansatz ist schon der richtige!
Ich meinte das oben gepostete DOIF (https://forum.fhem.de/index.php/topic,36504.msg726139.html#msg726139). Das deckt nämlich den, von mir genannten Einbruchsfall ab und gibt dann eine falsche, bzw. ungenügende Meldung raus.
Ah jetzt verstehe ich was Du meinst.
Besser wäre hier wohl
(([?Fk.FensterkontaktAlle] eq "open") and
([Anwesenheitsstatus] eq "abwesend"))
(set PushMsg msg 'Unser Haus' 'Ein Fenster ist noch offen und es ist niemand zu Hause!' '' 1 'siren')
Und das do always nicht vergessen sollte nichts weiter hinzu kommen.
Habe gerade im Log folgendes gefunden für eine Türe. Fenster und Test dummy scheinen zu funktionieren:
2017.12.06 09:19:42 1: ERROR evaluating my $NAME='hm.tur.hof';my $EVENT='closed';my $SELF='winOpen.CloseNotify';my $EVTPART0='closed';my $TYPE='CUL_HM';{winOpenStop($NAME)}: Undefined subroutine &main::winOpenStop called at (eval 3237) line 1.
2017.12.06 09:19:42 3: winOpen.CloseNotify return value: Undefined subroutine &main::winOpenStop called at (eval 3237) line 1.
Fehler gefunden
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
Log3(undef,1,"winOpenMessage: $msgsubj - $msgtext");
fhem("set teleBot message Erinnerung: $msgsubj - $msgtext");
fhem("set teleBot message @Tanja Erinnerung: $msgsubj - $msgtext");
}
Er nimmt das @Tanjja nicht ... jemand eine Idee ??
fhem("set teleBot message \@Tanja Erinnerung: $msgsubj - $msgtext");
oder
@@
Danke klappt aber die @@ leider nicht :) Zwar keine Fehlermeldung aber Nachricht kommt nicht an. Problem ist aber gelöst :)
Ich habe die beschriebene Lösung schon länger erfolgreich im Einsatz.
Jetzt habe ich die Heizperiode wieder aktiviert und warum auch immer läuft es nicht mehr.
Es werden kein "AT" erzeugt, ich habe aber auch keinen Ansatz wo ich nach dem Fehler suchen soll.
Kann jemand helfen?
Wird denn das Notify getriggert und die Funktion in der myUtils gestartet?
Internals:
DEF .*:(open|tilted) {winOpenStart($NAME)}
NAME winOpen.OpenNotify
NR 344
NTFY_ORDER 50-winOpen.OpenNotify
REGEXP .*:(open|tilted)
STATE 2018-11-04 21:03:28
TRIGGERTIME 1541361808.94891
TYPE notify
READINGS:
2018-11-04 20:44:57 state active
Attributes:
DbLogExclude .*
comment nutzt winOpenStart in myUtils
room Steuerung
scheint erstmal zu passen.
Dann gib mal bitte Deine Funktion.
Ich habe die Ursache gefunden, ich frage einen zusätzlichen Parameter ab:
my $Heizung=ReadingsVal('Heizperiode','STATE','');
In "Heizperiode" steht "on" oder "off" drin.
Leider liefert mein "ReadingsVal" nichts zurück, warum?
Zitat von: Fredi69 am 04 November 2018, 21:36:03
Ich habe die Ursache gefunden, ich frage einen zusätzlichen Parameter ab:
my $Heizung=ReadingsVal('Heizperiode','STATE','');
In "Heizperiode" steht "on" oder "off" drin.
Leider liefert mein "ReadingsVal" nichts zurück, warum?
Weil Du ein nicht existierendes Reading ab fragst. STATE ist ein Internal kein Reading. Nimm state
Zitat von: CoolTux am 04 November 2018, 21:42:53
Weil Du ein nicht existierendes Reading ab fragst. STATE ist ein Internal kein Reading. Nimm state
Das war es, herzlichen Dank.
Ich gehe davon aus das wenn Heizperiode off ist keine Fenster offen Meldung kommen soll, oder?
Dann würde ich die Abfrage in eine Bedingung ins Notify ein bauen.
Ich habe bei mir übrigens inzwischen längst von at (http://commandref.fhem.de/commandref_DE.html#at) auf benanntes sleep (http://commandref.fhem.de/commandref_DE.html#sleep) und cancel (http://commandref.fhem.de/commandref_DE.html#cancel) umgestellt.
relevanter Auszug aus der sub winOpenStart():
#Namen für das benannte sleep bauen
my $sleepId='sleep.'.$dev;
#Nachdem wir hier alles zusammen haben,
#legen wir den Timer (das benannte sleep) an
fhem("sleep $sleeptime $sleepId;{$pushcmd}");
Passend dazu der entsprechende Auszug aus der sub winOpenStop():
#Namen für das benannte sleep bauen
my $sleepId='sleep.'.$dev;
#Abbrechen des entsprechenden sleep
fhem("cancel $sleepId");
gb#
Hallo Benni,
Hast Du den in Post 172 erwähnten Einbruchsfall bereits bei Dir irgendwie eingebaut und kannst das für programmiertechnische Blindgänger zur Verfügung stellen? Da bei Deiner Lösung die Auswahl der Device, welche erfasst werden sollen sehr einfach ist und die Device in der Telegramm Meldung auch noch sinnvoll benannt werden können, wäre das m.mn eine prima Erweiterung.
Zitat von: det. am 12 November 2018, 16:37:43
Hast Du den in Post 172 erwähnten Einbruchsfall bereits bei Dir irgendwie eingebaut ...
Äh, nö! Hatte ich eigentlich auch nicht vor.
In dem genannten Post habe ich ja auf einen weiteren Post verwiesen, der den Fall mit einem DOIF bereits abdeckt:
https://forum.fhem.de/index.php/topic,36504.msg726139.html#msg726139
gb#
Ok, da ich die sofortige Meldung ,,Tür geöffnet" bei Abwesenheit mit Auswahl der Device, welche für Benni's window.Open Routine mit userAttr benannt und festgelegt werden unbedingt haben wollte, hab ich den Programmierschweinehund in mir besiegt und es selbst hinbekommen. Danke für den Anstoß und den Code vom Anfang dieses Themas, den ich dazu als Grundgerüst verwendet habe.
Vielen Dank! Läuft prima.
Habe die UserAttribute noch um winOpenAlexaDevice ergänzt.
Da meine Echos mit 37_Echodevice.pm integriert habe, gebe ich nun, je nach dem welches Echo als Attribut dort angegeben ist, dort eine Sprachmeldung aus.
Also genauer gesagt:
Standardmäßig wird immer im Wohnzimmer ausgegeben und wenn das Attribut ungleich dem Wohnzimmer Echo ist, dann wird auch zusätzlich an dem angegebenen Echo ausgegeben.
Zitat von: Benni am 05 November 2018, 08:24:59
Ich habe bei mir übrigens inzwischen längst von at (http://commandref.fhem.de/commandref_DE.html#at) auf benanntes sleep (http://commandref.fhem.de/commandref_DE.html#sleep) und cancel (http://commandref.fhem.de/commandref_DE.html#cancel) umgestellt.
Würdest du eventuell deinen aktuellen Code nochmal vollständig posten?
Vielen Dank.
Zitat von: willib am 13 Februar 2019, 16:11:52
Würdest du eventuell deinen aktuellen Code nochmal vollständig posten?
Vielen Dank.
Mich würde interessieren ob sleep/cancel einen Vorteil gegenüber at bringen?
Zitat von: KyleK am 13 März 2019, 22:14:07
Mich würde interessieren ob sleep/cancel einen Vorteil gegenüber at bringen?
Hauptvorteil für mich war, dass keine Devices erzeugt und wieder gelöscht werden.
Ich führe u.a. bei global:DEFINED events Aktionen aus.
gb#
Zitat von: willib am 13 Februar 2019, 16:11:52
Würdest du eventuell deinen aktuellen Code nochmal vollständig posten?
Vielen Dank.
Den Code müsste ich erst mal wieder etwas vereinfachen (bei mir passiert da noch mehr) um ihn hier in verständlicher Weise zu präsentieren.
Mal sehen, ob und wann ich dafür mal Zeit und Muse habe? Im Moment leider nicht, sorry! :-[
gb#
Hallo zusammen,
zunächst einmal @Benni:
Vielen Dank für die Erweiterung. Es ist wieder ein kleiner (Anfänger)schritt, der mich wieder voran gebracht hat. Vor allem aber, ist Deine Erweiterung einfach so genial beschrieben und dokumentiert dass sogar der größte Depp (ich :D) sie verstehen kann, wenn man sich ein wenig hinein versetzt und liest, was dort steht. Einfach nur genial gemacht !!!! Fettes
DANKE Dafür !!
@willib:
Ich weiss nicht ob das noch aktuell ist....
Zitat von: willib am 13 Februar 2019, 16:11:52
Würdest du eventuell deinen aktuellen Code nochmal vollständig posten?
Vielen Dank.
Nachdem ich das heute erst zusammengebaut habe, ist es recht jungfräulich und daher gut zu kopieren:
Ich habe das jetzt mit sleep & cancel sleep übernommen und umgesetzt. Oben im Beispiel war noch ein kleiner Fehler im cancel Befehl. ALLE Texte / Kommentare inkl. Originalcode (at Timer) als Kommentar drin gelassen, damit man sieht was geändert wurde. Pushinfo als Log Datei Eintrag ist auch noch drin.
Vier Änderungen gegenüber dem Original sind bei mir: (Wenn ich keine vergessen hab ::) )
- Zusätzlicher Text: 1. Meldung: wurde hinzugefügt.
- Meine Tür & Fenster Kontakte haben / werden das Präfix _TK_ haben. Daher taucht das im notify auf
- Jeweiliges notify für den Aufruf ist als Kommentar zu Begin der Subroutine
- Man muss die Attribute winOpenTimer und winOpenTimer2 natürlich auf XXX Sek Anzahl ändern (mit 00:00:10 kann sleep nix anfangen)
####################################
# Überwachung offene Tür / Fenster #
####################################
sub winOpenStart($;$) {
# Notify dafür
# define winOpen_noti notify .*TK.*:(open|tilted) {winOpenStart($NAME)}
#Als Parameter muss der device-Name übergeben werden
my $dev=shift(@_);
#Optional kann noch ein Zähler für das erneute Triggern übergeben werden,
#dieser ist per default 0
my $retrigger=shift(@_);
$retrigger=0 if (!$retrigger);
#Erst mal prüfen, ob das übergebene device überhaupt existiert
if ($defs{$dev}) {
#Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
#angibt, wie oft eine Meldung ausgegeben werden soll.
#Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
if($maxtrigger) {
#Festlegen des Namens für den Timer, der angelegt wird um die Meldung nach gewünschter
#Zeit auszugeben.
#my $devtimer=$dev.'_OpenTimer';
my $sleepId='sleep.'.$dev;
#Sollte dieser Timer bereits existieren, so wird er zunächst gelöscht.
#fhem("delete $devtimer") if ($defs{$devtimer});
fhem("cancel $sleepId") if ($defs{$sleepId});
#Holen von weiteren Attributen, sofern vorhanden:
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 10 Minuten, falls nicht angegeben
my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
#Zeit für die Folge-Meldungen, sofern abweichend angegeben
#Default ist die normale Zeit, die oben schon ermittelt wurde
my $devtimer2=AttrVal($dev,'winOpenTimer2',$waittime);
#Ein eventuell definierter "schöner" Name für das Device, der in der Meldung ausgegeben werden soll.
#Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
#device-Name genommen.
my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
#Eine Art Typ (Tür oder Fenster), der bei mir quasi im Betreff der Offen-Meldung angegeben wird
my $devtype=AttrVal($dev,'winOpenType','Fenster/Tür');
#Hier wandeln wir noch den state des devices in deutschen Klartext um
my $devstate='offen';
$devstate='gekippt' if (ReadingsVal($dev,'state','') eq 'tilted');
#Hier wird, sofern bereits eine Wiederholung der Offen-Meldung ausgegeben werden soll,
#dies textlich auch so berücksichtigt.
my $immer='noch ';
$immer='immer noch ' if ($retrigger>0);
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
my $pushcmd="PushInfo('$devtype','";
$pushcmd.=$retrigger+1;
$pushcmd.=".Meldung: $devname ist $immer $devstate');;";
#my $pushcmd="PushInfo('$devtype', ' $devname ist $immer $devstate');;";
#Sind wir schon beim Einrichten einer Folgemeldung, muss die Wartezeit für die Folgemeldungen
#genommen werden.
$waittime=$devtimer2 if ($retrigger);
#Wir erhöhen hier den Trigger-Zähler um 1...
$retrigger+=1;
#... und fügen das Re-Triggern als weitere Code-Zeile für das at-DEF an.
#das sorgt dann dafür, dass diese Funktion hier nach Ablauf des Timers einfach wieder
#getriggert wird, um einen neuen Timer anzulegen für die Folgemeldung
$pushcmd.="winOpenStart('$dev','$retrigger');;" if($retrigger < $maxtrigger);
#Nachdem wir hier alles zusammen haben,
#legen wir den Timer (das at) an und legen ihn freundlicherweise in den, bzw. die
#selben Räumen ab, wie auch das auslösende device.
#fhem("define $devtimer at +$waittime {$pushcmd}");
#fhem("attr $devtimer room ".AttrVal($dev,'room','Unsorted'));
fhem("sleep $waittime $sleepId;{$pushcmd}");
}
}
}
sub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
Log3(undef,1,"winOpenMessage: $msgsubj - $msgtext");
}
sub winOpenStop($) {
#Notify dafür:
#define winOpen.CloseNotify notify .*:closed {winOpenStop($NAME)}
#Dazu muss das entsprechende device (TK/FK) per Name hierher übergeben werden
#Den übergebenen device-Namen holen
my ($dev)=@_;
#Den Namen des Timers zusammenbauen
#my $devtimer=$dev.'_OpenTimer';
my $sleepId='sleep.'.$dev;
#Existiert ein Timer diesen Namens, so wird er jetzt gelöscht und das war's auch schon.
# if ($defs{$sleepId}) {
#fhem("delete $devtimer");
fhem("cancel $sleepId");
Log3(undef,1,"SleepID: $sleepId");
# }
}
Hoffe das hilft.
Grüße
Andreas
# Edith sagt: In der Timer-löschen Routine, musste noch die Abfrage entfernt werden
# Ediths Schwester sagt: Wenn das für alle anderen so funtioniert, wie für mich könntest Du das auch im ersten Beitrag mit anpinnen, als Option oder Benni?
Zitat von: flummy1978 am 10 April 2019, 22:25:33
Wenn das für alle anderen so funtioniert, wie für mich könntest Du das auch im ersten Beitrag mit anpinnen, als Option oder Benni?
Erledigt!
Und ebenfalls Danke! ;)
Gruß Benni.
Hallo, hoffentlich liest hier noch Jemand.....
Bisher hatte ich mit dieser Zeile die Meldungen über einen Echo ausgegeben:
my $pushcmd="fhem(\"set ECHO_GxxxxxxxxxxxQ speak ('$devname ist $immer $devstate')\");;";
Da ich die Meldung aber jetzt gerne über ein Terminal mit Fully ausgeben möchte, habe ich die Zeile in:
my $pushcmd="fhem(\"set terminal_unten speak ('$devname ist $immer $devstate')\");;";
umgestellt. Leider liest er mir nur "klammerauf S devname" vor also nicht den Inhalt der Variable. Den Rest "ist $immer $devstate" garnicht.
Hat Jemand eine Idee wie ich die Zeile ändern muss?
Holla,
Wenn es sich um den Inhalt der myUtils handelt, dann hast Du da ganz viele (vor)Zeichen durcheinander gebracht, beim hin und her kopieren:
Wenn Du Dir anschaust, was in meinem (durchaus nicht unkompliziertem) Beispiel mit der $pushcmd gemacht wurde und was in deinem Fall passiert ist, sollte Dir der Unterschied auffallen.
my $pushcmd="PushInfo('$devtype','";
$pushcmd.=$retrigger+1;
$pushcmd.=".Meldung: $devname ist $immer $devstate');;";
my $pushcmd="fhem(\"set terminal_unten speak ('$devname ist $immer $devstate')\");;";
Zitat (Quelle: https://de.wikibooks.org/wiki/Perl-Programmierung:_Variablen#Zeichenketten_(Strings) (https://de.wikibooks.org/wiki/Perl-Programmierung:_Variablen#Zeichenketten_(Strings))
Skalarvariablen können auch Zeichenketten (Strings) enthalten. Diese werden, von einfachen (') oder doppelten (") Anführungszeichen umschlossen, der Variablen zugewiesen. Der Unterschied zwischen einfachen und doppelten Anführungszeichen besteht in der sogenannten Variableninterpolation. Dazu ein Beispiel:
#!/usr/bin/perl
use strict;
use warnings;
my $var = 5;
my $text = "Variable enthält: $var";
my $text2 = 'Variable enthält: $var';
print $text;
print "\n";
print $text2;
print "\n";
erzeugt folgende Ausgabe:
Variable enthält: 5
Variable enthält: $var
Bedeutet in Deinem Fall, dass Du die Variablen außerhalb der einzelnen ' ' aufführen musst:
my $pushcmd="fhem(\"set terminal_unten speak ('".$devname." ist $immer $devstate"."')\");;";
................................................................................^ Mit diesen " beendest Du die umschlossene Variable und hängst mit .$devname direkt den Inhalt der $devname an .... danach folgt der Rest und in doppelten " " kann man Variablen benutzen, deren Inhalt (und nicht name) auch wiedergeben wird.
( Ich bin mir sicher, dass die laienhafte Erklärung fachlich vielleicht nicht perfekt erklärt ist, aber ich hoffe verständlich. Und mit der Doku oben, hast Du noch mal andere Erklärungen dazu ;) )
Hoffe das hilft
Grüße
Andreas
Vielen Dank, für deine Hilfe!!!
Ich werde mich das heute mal in ruhe durchlesen und hoffentlich dann verstehen.
Trotzdem sehr komisch, da ich nur das Device von Amazon Echo auf den Fully gewechselt habe.
So, mit dieser Zeile funktioniert es jetzt wie gewünscht:
my $pushcmd="fhem(\"set terminal_unten speak '$devname ist $immer $devstate' \");;";
Fhem erstellt auch wie gewollt das richtige "at"
defmod MAX_11fdd0_OpenTimer at 2019-10-27T14:12:59 {fhem("set terminal_unten speak 'Das linke Fenster im Wohnzimmer ist noch offen' ");;winOpenStart('MAX_11fdd0','2');;}
Wichtig beim Fully Browser sind die zwei ' , da er sonst nur das erste Wort ausgibt.
Hallo Benni,
ich hoffe Dein Modul wird noch supported ;-)
Gerne würde ich Deine Funtion nutzen, habe aber das Problem, dass scheinbar der Event Trigger schon nicht funktioniert.
Hier mal ein list meines Device:
Internals:
DEF c1aa9dda 17
FUUID 5ddb935d-f33f-8212-587c-a5ecfd591e77da1b
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 6
NAME ZWave_SENSOR_NOTIFICATION_17
NR 99
STATE closed
TYPE ZWave
ZWDongle_0_MSGCNT 6
ZWDongle_0_RAWMSG 00040011097105000000ff061700
ZWDongle_0_TIME 2020-03-02 18:03:52
ZWaveSubDevice no
homeId c1aa9dda
isWakeUp 1
nodeIdHex 11
READINGS:
2019-11-23 17:21:45 alarm AccessControl: Window/Door is closed
2020-03-02 18:03:52 alarm_AccessControl Window/Door is closed, notificationIsOn
2020-03-02 08:30:28 battery 80 %
2020-03-02 08:30:28 batteryPercent 80
2020-03-02 08:30:28 batteryState ok
2019-11-23 17:14:18 model FIBARO System FGDW002 Door Opening Sensor 2
2019-11-23 17:14:18 modelConfig fibaro/fgdw2.xml
2019-11-23 17:14:18 modelId 010f-0702-1000
2019-11-23 17:14:16 state wakeupInterval 86400 1
2020-03-02 14:10:39 temperature 21.6 C
2020-03-02 08:30:30 timeToAck 0.023
2020-03-02 08:30:30 transmit OK
2020-03-02 08:30:28 wakeup notification
Attributes:
IODev ZWDongle_0
alias Sensor_Buero_rechts
classes ZWAVEPLUS_INFO ASSOCIATION ASSOCIATION_GRP_INFO APPLICATION_STATUS BATTERY CONFIGURATION CRC_16_ENCAP DEVICE_RESET_LOCALLY FIRMWARE_UPDATE_MD MANUFACTURER_SPECIFIC MULTI_CHANNEL_ASSOCIATION ALARM POWERLEVEL SECURITY SENSOR_MULTILEVEL VERSION WAKE_UP
extendedAlarmReadings 1
room ZWave
stateFormat {(split(/,|is /, ReadingsVal($name,"alarm_AccessControl","")))[1]}
userattr winOpenMaxTrigger:1 winOpenName:rechts winOpenTimer:00:00:20 winOpenTimer2:00:01:00 winOpenType:Fenster
vclasses ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:4 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SECURITY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2
Hier meine 99_myUtils:
ub PushInfo($$) {
my ($msgsubj,$msgtext) = @_;
Log3(undef,1,"winOpenMessage: $msgsubj - $msgtext");
# fhem("set pushmsg msg 'winOpenMessage' '$msgsubj - $msgtext' ")
}
sub winOpenStart($;$) {
#Als Parameter muss der device-Name übergeben werden
my $dev=shift(@_);
#Optional kann noch ein Zähler für das erneute Triggern übergeben werden,
#dieser ist per default 0
my $retrigger=shift(@_);
$retrigger=0 if (!$retrigger);
#Erst mal prüfen, ob das übergebene device überhaupt existiert
if ($defs{$dev}) {
#Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
#angibt, wie oft eine Meldung ausgegeben werden soll.
#Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
if($maxtrigger) {
#Festlegen des Namens für den Timer, der angelegt wird um die Meldung nach gewünschter
#Zeit auszugeben.
my $devtimer=$dev.'_OpenTimer';
#Sollte dieser Timer bereits existieren, so wird er zunächst gelöscht.
fhem("delete $devtimer") if ($defs{$devtimer});
#Holen von weiteren Attributen, sofern vorhanden:
#Zeit, nach der die Meldung ausgegeben werden soll
#Default sind 10 Minuten, falls nicht angegeben
my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
#Zeit für die Folge-Meldungen, sofern abweichend angegeben
#Default ist die normale Zeit, die oben schon ermittelt wurde
my $devtimer2=AttrVal($dev,'winOpenTimer2',$waittime);
#Ein eventuell definierter "schöner" Name für das Device, der in der Meldung ausgegeben werden soll.
#Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
#device-Name genommen.
my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
#Eine Art Typ (Tür oder Fenster), der bei mir quasi im Betreff der Offen-Meldung angegeben wird
my $devtype=AttrVal($dev,'winOpenType','Fenster/Tür');
#Hier wandeln wir noch den state des devices in deutschen Klartext um
my $devstate='offen';
#$devstate='gekippt' if (ReadingsVal($dev,'state','') eq 'tilted');
$devstate='gekippt' if (ReadingsVal($dev,'alarm_AccessControl','') eq 'Window/Door is open, notificationIsOn');
#Hier wird, sofern bereits eine Wiederholung der Offen-Meldung ausgegeben werden soll,
#dies textlich auch so berücksichtigt.
my $immer='noch ';
$immer='immer noch ' if ($retrigger>0);
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
#(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
# meine Meldungen über Pushover ausgibt)
my $pushcmd="PushInfo('$devtype','$devname ist $immer $devstate');;";
#Sind wir schon beim Einrichten einer Folgemeldung, muss die Wartezeit für die Folgemeldungen
#genommen werden.
$waittime=$devtimer2 if ($retrigger);
#Wir erhöhen hier den Trigger-Zähler um 1...
$retrigger+=1;
#... und fügen das Re-Triggern als weitere Code-Zeile für das at-DEF an.
#das sorgt dann dafür, dass diese Funktion hier nach Ablauf des Timers einfach wieder
#getriggert wird, um einen neuen Timer anzulegen für die Folgemeldung
$pushcmd.="winOpenStart('$dev','$retrigger');;" if($retrigger < $maxtrigger);
#Nachdem wir hier alles zusammen haben,
#legen wir den Timer (das at) an und legen ihn freundlicherweise in den, bzw. die
#selben Räumen ab, wie auch das auslösende device.
fhem("define $devtimer at +$waittime {$pushcmd}");
fhem("attr $devtimer room ".AttrVal($dev,'room','Unsorted'));
}
}
}
sub winOpenStop($) {
#Dazu muss das entsprechende device (TK/FK) per Name hierher übergeben werden
#Den übergebenen device-Namen holen
my ($dev)=@_;
#Den Namen des Timers zusammenbauen
my $devtimer=$dev.'_OpenTimer';
#Existiert ein Timer diesen Namens, so wird er jetzt gelöscht und das war's auch schon.
if ($defs{$devtimer}) {
fhem("delete $devtimer");
}
}
Es wird weder ein Log eintrag erzeugt, noch ein notify angelegt.
Wo ist mein Fehler?
Danke
Gruss
Dennis
Hast du denn ein notify, das die myutils Funktion aufruft?
So ungefähr:
defmod winOpen.OpenNotify notify .*:(open|tilted) {winOpenStart($NAME)}
attr winOpen.OpenNotify room Logik
defmod winOpen.CloseNotify notify .*:closed {winOpenStop($NAME)}
attr winOpen.CloseNotify room Logik
Bei mir läuft das mittlerweile ganz gut.
Gruß Timo
Gesendet von meinem MI 9 mit Tapatalk
Hi,
ja klar. Die beiden notify habe ich auch angelegt.
Irgendwie habe ich das Gefühl, dass es am trigger für open liegt.
Denn bei den Fibaro Sensoren wird das Reading "alarm_AccessControl" mit den Werten "Window/Door is closed, notificationIsOn" oder "Window/Door is open, notificationIsOn" belegt.
Das eigentliche state Reading verändert sich nicht.
Könnte es daran liegen?
Gruss
Dennis
Zitat von: dennis_n am 02 März 2020, 22:54:04
Hi,
ja klar. Die beiden notify habe ich auch angelegt.
Irgendwie habe ich das Gefühl, dass es am trigger für open liegt.
Denn bei den Fibaro Sensoren wird das Reading "alarm_AccessControl" mit den Werten "Window/Door is closed, notificationIsOn" oder "Window/Door is open, notificationIsOn" belegt.
Das eigentliche state Reading verändert sich nicht.
Könnte es daran liegen?
Gruss
Dennis
Du solltest vielleicht nicht versuchen 1 zu 1 ab zu schreiben sondern versuchen zu verstehen was genau passiert und gebraucht wird. Deswegen ist das ja auch kein Modul sondern eine Beispiellösung für eine Anforderung.
Du musst natürlich das RegEx des Notify entsprechend des Events anpassen. Leider bist Du kein list vom Notify. Und am besten noch ein Eventlogauszug mit geben damit man Sich unterstützen kann.
Guten Abend,
besteht die Möglichkeit beim Auslösen der zweiten Erinnerung (winOpenTimer2) meine Lüftungsanlage (existiert bereits als Device) vorübergehend auszuschalten?
Sobald die Tür bzw. das Fenster dann nach der "Overtime Warnung" wieder geschlossen wurde, soll die Lüftungsanlage wieder eingeschaltet werden...
Danke vorweg für eure Mühe / Ideen!
Gruß Christian
Guten Morgen,
die Frage ist ob du komplett kopiert hast, oder Dir auch selbst Gedanken dazu gemacht hast / machen möchtest. Ersteres macht das Ganze mit Sonderwünschen auszustatten schwierig, weil Dir immer jemand etwas vorkauen müsste, bis man an der richtigen Lösung ist. Zweiteres ist wiederum möglich:
Du musst an der Stelle:
#Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
my $pushcmd="PushInfo('$devtype','";
$pushcmd.=$retrigger+1;
$pushcmd.=".Meldung: $devname ist $immer $devstate');;";
#my $pushcmd="PushInfo('$devtype', ' $devname ist $immer $devstate');;";
#####<----HIER---->
prüfen ob:
- $devname das betroffenne Fenster ist, dass die Lüftungsanlage ausschalten soll
- Deine Lüftungsanlage läuft oder bereits ausgeschaltet wurde
- es andere Widersprüche gegen das Ausschalten gibt
- und und und
- ... + zusätzlich noch wo anders im Code die Prüfung einbauen, ob das Fenster geschlossen wurde und die Lüftung wieder eingeschaltet werden kann
In meinen Augen verlierst Du hier aber die "globalität" der Fenstermeldung, Du hättest dann eine Besonderheit für (ein?) bestimmtes Fenster z.B.....
Ich würde es mit einem "lüftungsanlage" notify machen, das explizit auf ALLE Meldungen achtet die die Lüftungsanlage betrifft und diese dann schaltet. Sonst hast Du mal das Fenster, mal manuell, dann wieder durch einen Raumluftsensor ......... geschaltet und weisst nicht, wer jetzt eigentlich der Ausschlaggebende zum Schalten war.
In einem "Überwachungsgerät" hast Du eine bessere Möglichkeit das zu kontrollieren
Ich habe mittlerweile die Fenster Meldung nicht mehr drin, sondern eine eigene Geschichte gebaut, die meldet wenn was passiert UND / ODER die etwas schaltet wenn eine gewisse Zeit etwas nicht passiert. Das könnte man bsw für Deine Bedürfnisse umbauen / anpassen.
Viele Grüße
Andreas
Vielen Dank erstmal für deine Antwort.
Ich habe das Beispiel aus diesem Beitrag zunächst komplett übernommen und mit dem Dummy getestet --> funktioniert!
Danach habe ich den Part Pushover auf meine Bedürfnisse angepasst --> funktioniert!
Danach habe ich das Dummy gelöscht und einer meiner Magnetkontakte (Typ=IT) mit den erforderlichen Attributen bestückt --> funktioniert!
Danach habe ich die beiden notify so umgebogen, dass sie nicht auf "open,tilted,closed" reagieren, sondern nur auf "offen,geschlossen" und die entsprechenden Magnetkontakte ebenfalls angepasst --> funktioniert!
Soviel zur groben Beschreibung, was ich übernommen bzw. angepasst habe. :)
Nun möchte ich die Lüftungsanlage automatisiert schalten lassen. Wie gesagt, die KWL lese ich über HTTPMOD aus und habe die Möglichkeit die unterschiedlichen Leistungsstufen 0,1,2 und 3 anzusteuern.
Jetzt soll die Lüftungsanlage aber nur ausgeschaltet werden wenn mindestens einer von zwei bestimmten Magnetkontakten öffnet. Als Beispiel, ich habe 4 Magnetkontakte (2x Fenster und 2x Tür) und ich möchte lediglich beim triggern der Türen über "winOpenTimer2" die KWL ausschalten.
Die Idee mit dem separaten notify auf die KWL führt hier bestimmt eher zum Ziel. Evtl. probiere ich noch ein Dummy (a la Lüften aktiv / nicht aktiv) als Schnittstelle zwischen dem Notify und der KWL, mal schauen.
Will den Beitrag hier aber auch nicht in die falsche Richtung lenken (OT)...
Hallo, vielen Dank für die Hinweise hier, meine Fensterüberwachung funtioniert sehr gut mit den sleep Timern.
Allerdings suche ich jetzt eine Möglichkeit, bereits laufende Fenster-sleeps mit einem Schlag zu löschen.
cancel HMFen.* funktioniert leider nicht, da cancel kein RegEx bei den Namen kann.
siehe auch https://forum.fhem.de/index.php?topic=135359.0 (https://forum.fhem.de/index.php?topic=135359.0)
Wie müsste eine for-Schleife in Perl aussehen, die alle sleeps mittels cancel ausliest, entsprechend dem RegEx filtert und dann die betreffenden sleeps löscht ?
Bin leider auch alles anders als ein Perl-Guru :(
Vielen Dank für Eure Unterstützung.
Hast du es mal mit delete statt cancel versucht?
Gruß
Frank
Hi,
ich habe eine Frage:
sub winOpenStart($;$) {
my $dev=shift(@_)
entspricht Übergabe Device? ($;$) es wird aber nur ein Device übergeben.
ich habe dazu auch nichts bei Tante Google gefunden.
sub winOpenStop($) {
my ($dev)=@_;
entspricht Übergabe Device? ($) es wird ein Device übergeben.
So mache ich das seit Jahren.
Was ist der Unterschied zwischen den beiden Aufrufen?
Ich suche auch schon seit tagen nach einer Möglichkeit, meine Fensterprozedur zu verbessern.
Z.z. mache es mit mehreren Watchdog.
bisher bin ich dabei an zwei punkten gescheitert.
Watchdog mit flexibler Zeit. (aus einem Reading)
Device während der Laufzeit anlegen. (Es wird immer ein save verlangt)
gruss
@eisman Von meiner Seite ein kleines Sorry - hatte hier keine Benachrichtigungen mehr aktiv und betraf mich auch nicht, aber denoch habe ich hier ja auch einigen gern helfen wollen:
Zitat von: eisman am 26 Oktober 2023, 09:32:43sub winOpenStart($;$) {
my $dev=shift(@_)
entspricht Übergabe Device? ($;$) es wird aber nur ein Device übergeben.
sub winOpenStop($) {
my ($dev)=@_;
entspricht Übergabe Device? ($) es wird ein Device übergeben.
Was ist der Unterschied zwischen den beiden Aufrufen?
Es ist richtig, dass in beiden Fällen das Device übergeben wird, ABER:
winOpenStart($;$)Übergibt einen Parameter und einen OPTIONALEN Parameter - Die zweite Variante übergibt eben nur den einen. Hab es nicht mehr im Kopf, ob es da genutzt wurde, weil ich mittlerweile eine andere Funktion nutze, aber zum Verständnis hilft das sicher.
ZitatIch suche auch schon seit tagen nach einer Möglichkeit, meine Fensterprozedur zu verbessern.
Z.z. mache es mit mehreren Watchdog.
bisher bin ich dabei an zwei punkten gescheitert.
Watchdog mit flexibler Zeit. (aus einem Reading)
Device während der Laufzeit anlegen. (Es wird immer ein save verlangt)
Falls das noch aktuell ist und Du es immernoch ändern möchtest, kann ich meine Sache vorzeigen - muss allerdings dazu sagen, dass diese "etwas" ausgeartet ist. Dementsprechend ist auch der Perl Teil recht umfangreich.
Es ist eine "eierlegende" Zeitschaltuhr geworden, die sowohl Geräte als auch Fenster überwacht. Bei den meisten Geräten, geht es nach Zeit X aus (Garage,Abstellkammer etc). Bei einigen ist das Ausschalten an eine Bedingung geknüpft (z.B. damit das Kellerlicht ausgeschaltet wird, muss die Tür auch zu sein (sprich es ist keiner im Keller).
Bei Fenstern ist jeweils die Einschränkung Temperatur drin (d.h. es gibt nur eine Meldung wenn XX Grad unterschritten wurden) ABER es gibt für jedes Fenster / Gerät / Überwachung einen eigenen Timer - der als Attribut im Gerät gespeichert wird. Somit entfällt das ständige neue Geräte speichern.
VG
Andreas
Hi,
danke für die INFO, nein ich habe es jetzt geschafft,
das nach 30min eine Meldung kommt. Ich passe die Zeit
nicht an.
dennoch danke
gruss
Zitat von: flummy1978 am 13 Januar 2024, 16:12:37Falls das noch aktuell ist und Du es immernoch ändern möchtest, kann ich meine Sache vorzeigen - muss allerdings dazu sagen, dass diese "etwas" ausgeartet ist. Dementsprechend ist auch der Perl Teil recht umfangreich.
Es ist eine "eierlegende" Zeitschaltuhr geworden, die sowohl Geräte als auch Fenster überwacht. Bei den meisten Geräten, geht es nach Zeit X aus (Garage,Abstellkammer etc). Bei einigen ist das Ausschalten an eine Bedingung geknüpft (z.B. damit das Kellerlicht ausgeschaltet wird, muss die Tür auch zu sein (sprich es ist keiner im Keller).
Bei Fenstern ist jeweils die Einschränkung Temperatur drin (d.h. es gibt nur eine Meldung wenn XX Grad unterschritten wurden) ABER es gibt für jedes Fenster / Gerät / Überwachung einen eigenen Timer - der als Attribut im Gerät gespeichert wird. Somit entfällt das ständige neue Geräte speichern.
VG
Andreas
Hallo Andreas,
ich bin an deiner Lösung interessiert.
Danke im Voraus,
Matthias
Holla,
Zitat von: MDietrich am 23 Januar 2024, 12:51:22ich bin an deiner Lösung interessiert.
Ich weiss nicht wie fit Du in Perl bist, ich versuchs mal im Schnellformat (was hier nicht gelingen wird) aber in Anbetracht dessen, dass das sehr sehr individuell für mich und sicher nicht auf dem höchsten Level programmiert:
Zunächst einmal muss im global device das Attr userattr um die Einträge: TIMER_announce TIMER_announcecond TIMER_announcemsg TIMER_announcetarget TIMER_set TIMER_setcond erweitert werden. Diese benötigt man später im Device. Codeauszüge der einzelnen Beispiel (hab alles unwichtige für die Übersichtlichkeit gelöscht):
1. Einfach nur nach Zeit ausschalten (in dem Beispiel ist noch ne Meldung drin, falls das Teil länger an ist als gewollt)
define EG_WZ_SD_03_infrarot MQTT2_DEVICE WZ_SD_Infrarot_B97CFE
attr EG_WZ_SD_03_infrarot TIMER_announce 1200
attr EG_WZ_SD_03_infrarot TIMER_announcemsg Infrarotheizung ist seit 20 Min an?
attr EG_WZ_SD_03_infrarot TIMER_set 900
2. Schaltet nach Zeit aus, nut Bedingung (Kellertür ist zu) define Licht_KG_Decke MQTT2_DEVICE Shelly6_Kell_E2D78C
attr Licht_KG_Decke TIMER_announce 1800
attr Licht_KG_Decke TIMER_announcemsg Kellerlicht ist seit einer halben Stunde eingeschaltet, Absicht?
attr Licht_KG_Decke TIMER_set 2700
attr Licht_KG_Decke TIMER_setcond Licht_KG_Decke,off,TK_EG_FL_tuerkeller_innen,contact,true
attr Licht_KG_Decke alias Licht Keller
3. Schlafzimmerfenster (wird nur überwacht wenn Temperaturbedingungen unterschritten sind, in dem Fall mind. 19°)define TK_OG_SZ_fenster1 MQTT2_DEVICE zigbee_TK_SZ_Fenster1
attr TK_OG_SZ_fenster1 TIMER_announce 1200
attr TK_OG_SZ_fenster1 TIMER_announcecond temperatur,dev_OG_SZ_Temp_Sensor,temperature,19
attr TK_OG_SZ_fenster1 TIMER_announcemsg Schlafzimmerfenster ist seit 30 Min offen (Sollte geschlossen werden)
attr TK_OG_SZ_fenster1 TIMER_announcetarget home
Diese geräte lösen ein notify aus, in dem dann my_Utils Routine ausgelöst wird:
(Hab nur die 3 Beispiele im Notify gelassen)
EG_WZ_SD_03_infrarot:state:.*|Licht_KG_Decke:POWER1:.*|TK_OG_GZ_fenster:state:.* {
# Fensterkontakte in on / off simulieren
$EVTPART1 = "on" if $EVTPART1 eq "open";
$EVTPART1 = "off" if $EVTPART1 eq "closed";
auto_onfortimer($NAME,$EVTPART1);
}
auto_onfortimer in MyUtils
############################
# On-for-Timer Automatik #
############################
sub auto_onfortimer ($$){
my ($dev,$EVTPART0) = @_;
##########################################
# Abbrechen wenn Gerät über
# on-for-timer oder über on / off - till
# geschaltet wurde
RemoveInternalTimer($dev."_set");
RemoveInternalTimer($dev."_announce");
if (($defs{$dev."_set"}) or ($defs{$dev."_till"}) or ($defs{$dev."_intervalFrom"}) or ($defs{$dev."_intervalNext"}) or ($defs{$dev}->{TIMED_OnOff}->{CMD}))
{
fhem ("cancel $dev"."_set quiet");
fhem ("cancel $dev"."_announce quiet");
return undef;
}
# Notwendige Angaben prüfen ( $mainbutton ist für Push MSGs )
my $settimer=AttrVal($dev,'TIMER_set',0);
my $announcetimer=AttrVal($dev,'TIMER_announce',0);
my $mainbutton = " ( .MENUE. ) ";
# Bedingungen für Timer aufteilen
my @announcecondition = split(",", AttrVal($dev,'TIMER_announcecond',0));
return return undef if (($settimer == 0) && ($announcetimer == 0));
# Vorhandene Timer für das Device abbrechen
fhem ("cancel $dev"."_set quiet");
fhem ("cancel $dev"."_announce quiet");
if (($EVTPART0 eq "on") && ($announcetimer != 0))
{
# Zeitumrechnung auf Minuten und Stunden
# Diese sind nur für Benachrichtigungen
my $tmp=();
$tmp =($announcetimer/3600)." Stunden" if ($announcetimer>3600);
$tmp =sprintf("%.2f", ($announcetimer/60))." Minuten" if ($announcetimer<3600);
# Nachrichtemempfänger vorbereiten
my $destination ="@".ReadingsVal("RESIDENT_ALL", "residentsHomeNames", 'null');
$destination =~ s/,\s/ @/gi; # @Zeichen voranstellen bei mehr als einem anwesenden
# Ausschaltbutton in die Nachricht mit anhängen, wenn es sich nicht um ein Fenster handelt
$mainbutton .= '( ❌ '.AttrVal($dev,'alias','0').' AUSSCHALTEN ❌:'.$dev.') ' if ($dev !~ /TK_/);
# Wenn Bedingungen eingetragen sind, prüfen ob es eine Temperatur-Bedingung ist
if (!$announcecondition[0])
{
fhem ("sleep $announcetimer $dev"."_announce; { addmsg('".AttrVal($dev,'TIMER_announcemsg','home')."','residentsHomeNames','$mainbutton','".AttrVal($dev,'TIMER_announcemsg',$dev)."') } ");
}
elsif (($announcecondition[0] eq "temperatur") && ((ReadingsVal($announcecondition[1], $announcecondition[2], '0') <= $announcecondition[3])))
{
fhem ("sleep $announcetimer $dev"."_announce; { addmsg('".AttrVal($dev,'TIMER_announcemsg','home')."','residentsHomeNames','$mainbutton','".AttrVal($dev,'TIMER_announcemsg',$dev)."') } ");
}
}
if (($EVTPART0 eq "on") && ($settimer != 0))
{
my %h = (dev => $dev, name => "_set", );
InternalTimer( gettimeofday()+$settimer, 'settimer_option', $dev."_set");
}
}
# Timer die optional verlängert werden können
# zb bei Lichtmeldungen die ein Türkontakt beinhalten
# So wird das Kellerlicht z.B. verlängert
sub settimer_option($) {
my $dev = shift;
$dev =~ s/_set//;
my @setcondition = split(",", AttrVal($dev,'TIMER_setcond',0));
my $cond = ReadingsVal($setcondition[2], $setcondition[3], "false");
my $settimer=AttrVal($dev,'TIMER_set',0);
my $off_cmd = "$dev off";
$off_cmd = $setcondition[0]." ".$setcondition[1] if (($setcondition[0] ne "") && ($setcondition[1] ne ""));
if ((!$setcondition[0]) || ($cond eq $setcondition[4])) { CommandSet(undef,$off_cmd); }
else { InternalTimer( gettimeofday()+$settimer, 'settimer_option', $dev."_set"); }
}
Hab es versucht soweit wie möglich zu kommentieren und so viel wie möglich raus zu löschen, was nicht gebraucht wird (ungetestet).
Bei Fragen, fragen, ansonsten viel Spaß mit der Lösung ;D
VG
Andreas
Danke, ich werde mich am Wochenende daran setzen.
Gruß,
Matthias