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

[Benni]

Ps.: Hat sich erledigt, ich habe das winOpen.Open Notify mit einem sleep ergänzt:

Code Auswählen Erweitern

.*:(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.

[marty29ak]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

#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');;" );

[Benni]

In dem Modul habe ich lediglich die Ausgabe nicht als Pushmail, sondern als TTS Meldung. Und daher diesen Absatz entsprechend umgeändert:

Code Auswählen Erweitern

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

Code Auswählen Erweitern


my $pushcmd="fhem(\"set MyTTS tts ('$devname ist $immer $devstate')\");;";


[hartenthaler]

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.

Code Auswählen Erweitern

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.

[CoolTux]

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

[marty29ak]

  Vielen Dank Benni!!
Das war mein Fehler.  Jetzt kommt die Meldung wie gewünscht.

[CoolTux]

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

[hartenthaler]

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?

[CoolTux]

Die Warnzeit von der Aussentemperatur abhängig zu machen, das macht Sinn! Gute Idee! Wo genau hast Du was geändert?

Code Auswählen Erweitern


            #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.

Code Auswählen Erweitern


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

[Benni]

Hallo Leon,

schöne Erweiterung, danke!

Ich plane inzwischen bereits, das ganze demnächst mal in ein anständiges Modul zu packen.
Habe mal wieder Lust ein größeres Stück Code zu programmieren

Gruß Benni.

[CoolTux]

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

[Benni]

Hallo Leon,

klar! Gerne!
Ich habe da auch noch ein paar Ideen im Hinterkopf

Gruß Benni.

[CoolTux]

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

[hartenthaler]

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/), 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

[birdy]

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.   

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