Globale, flexible Fenster-/Tür-Offen-Meldungen

Begonnen von Benni, 20 April 2015, 20:19:31

Vorheriges Thema - Nächstes Thema

seb

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

Benni


seb

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 :)

en-trust

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 ?

Benni

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.

en-trust

Suche ich nach Alarmanlage bekomme ich nur meine beiden Einträge  ;D

Fritz!Maxi

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 anrufen.
FHEM im Debian Container uaf QNAP, diverse Homematic Komponenten

Benni

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!


CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Fritz!Maxi

Zitat von: Fritz!Maxi am 01 Juni 2016, 11:18:54
Ich lasse mich von meinem RPi mittels FB_SIP Modul 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)

OT off.
FHEM im Debian Container uaf QNAP, diverse Homematic Komponenten

Benni

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!

devil77

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

Benni

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.

devil77

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.

Benni

Das ist natürlich auch eine Möglichkeit!   8)

Freut mich, wenn's funktioniert!  :D