Autor Thema: umgekehrten watchdog  (Gelesen 569 mal)

Offline tom44

  • Full Member
  • ***
  • Beiträge: 115
  • newbie - novice ;-)
umgekehrten watchdog
« am: 11 Oktober 2018, 22:38:22 »

Hallo Miteinander,

ich möchte folgendes umsetzen. Sobald die Haustür geöffnet wurde, soll ein watchdog 3 Minuten überwachen, ob ein Smartphone sich im WLAN eingeloggt hat, um mir eine Nachricht zu übersenden, dass jemand zuhause angekommen ist. Leider passiert es, dass innerhalb der drei Minuten dieses Smartphone zwischen dem Status present und absent wechselt und nicht zuverlässig auf present bleibt.
Zitat
define jemand.zuhause watchdog [tuersensor:state]="open" 00:03:00 [smartphone:state]="present" (set Push msg 'Jemand ist zuhause angekommen')
In der FHEM Referenz steht:
Startet einen beliebigen FHEM Befehl wenn nach dem Empfang des Ereignisses <regexp1> nicht innerhalb von <timespec> ein <regexp2> Ereignis empfangen wird.
Ich möchte aber, dass der FHEM Befehl startet, wenn nach dem Empfang des Ereignisses <regexp1> UND innerhalb von <timespec> ein <regexp2> Ereignis empfangen wird.
Ist sowas mit dem watchdog möglich? Oder gibt es hierfür eine andere Lösung? Mit DOIF habe ich leider keine Zeitverzögerung gefunden.
Ich freue mich für eine Antwort, die mir auf die Sprünge hilft  :)
Tom
FHEM 17762 auf Raspberry Pi 3 Model B Rev | nanoCUL868, CUL 868 MhZ, Rolladen- Aktoren, Heizung | Z-Wave, FIBARO FGD211 Universal Dimmer 500W, Popp Plug-in Dimmer, FIBARO Wall Plug, Everspring PIR Motion Sensor, FIBARO Door Opening Sensor | Netatmo

Offline bartman121

  • Full Member
  • ***
  • Beiträge: 210
Antw:umgekehrten watchdog
« Antwort #1 am: 12 Oktober 2018, 07:09:06 »
Zitat
Leider passiert es, dass innerhalb der drei Minuten dieses Smartphone zwischen dem Status present und absent wechselt und nicht zuverlässig auf present bleibt.

Wenn dem so ist, dann solltest du dieses Problem erstmal beseitigen.

Zitat
Sobald die Haustür geöffnet wurde, soll ein watchdog 3 Minuten überwachen, ob ein Smartphone sich im WLAN eingeloggt hat, um mir eine Nachricht zu übersenden, dass jemand zuhause angekommen ist.
Zitat
define jemand.zuhause watchdog [tuersensor:state]="open" 00:03:00 [smartphone:state]="present" (set Push msg 'Jemand ist zuhause angekommen')
Hier steht aber was anderes, mal davon abgesehen, dass [tuersensor:state]="open" wohl eher aus der DOIF-Welt stammt.

du musst folgendes noch abklären:
Bleibt der Tuersensor:state wirklich auf "open" stehen?...
üblich wäre doch: open und dann wieder closed.
Wenn es tatsächlich nur zwei Zustände (open und closed) gibt, dann kann man das mit ReadingsAge leicht lösen:

defmod n_presence_xxx notify smartphone:present {\
#wird ausgelöst, wenn smartphone auf present geht\
if ((ReadingsAge("Tuersensor","state","")<180) {\
#wenn der Türstatus sich innerhalb der letzten 180Sekunden geändert hat\
#hier deine Befehle\
}\
}

Damit mein Code sinnvoll funktioniert, musst du zwingend im presence-device das Attribut "event-on-change-reading"  nutzen.


Ich bitte aber darum diese Form der Bewohner-Überwachung (Nachrichten bei "kommt_geht") nicht zu implementieren. Sowas hat einen sehr schlechten WAF.








« Letzte Änderung: 15 Oktober 2018, 18:06:05 von bartman121 »

Offline tom44

  • Full Member
  • ***
  • Beiträge: 115
  • newbie - novice ;-)
Antw:umgekehrten watchdog
« Antwort #2 am: 14 Oktober 2018, 10:14:22 »
Hallo bartman121,

Leider passiert es, dass innerhalb der drei Minuten dieses Smartphone zwischen dem Status present und absent wechselt und nicht zuverlässig auf present bleibt.
Zitat
Wenn dem so ist, dann solltest du dieses Problem erstmal beseitigen.
Das geht leider nicht, da die Smartphones sich in unregelmäßigen Abständen am WLAN an- und abmelden (Stand-By).


Zitat
Wenn dem so ist, dann solltest du dieses Problem erstmal beseitigen.
Hier steht aber was anderes, mal davon abgesehen, dass [tuersensor:state]="open" wohl eher aus der DOIF-Welt stammt.
Ja, Du hast Recht. Ich verwende meistens Versatzstücke von bereits funktionierenden FHEM Befehlen ....

Zitat
du musst folgendes noch abklären:
Bleibt der Tuersensor:state wirklich auf "open" stehen?...
üblich wäre doch: open und dann wieder closed.

Ja, auch hier hast Du Recht. Ich wollte, nachdem die Tür auf open stand, eine Prüfung innerhalb von 180 sek., in der das Handy sich am WLAN anmeldet erstellen, um erst dann eine Nachricht zu versenden (es geht hier nur darum, sicherzustellen, dass unser Sohn gut nach der Schule zuhause angekommen ist ... ist zwar auch eine Überwachung aber keine Bespitzelung, was ich auch ablehne).

Wenn es tatsächlich nur zwei Zustände (open und closed) gibt, dann kann man das mit ReadingsAge leicht lösen:
defmod n_presence_xxx notify smartphone:present {
#wird ausgelöst, wenn smartphone auf present geht
if ((ReadingsAge("Tuersensor","state","")<180) {
#wenn der Türstatus sich innerhalb der letzten 180Sekunden geändert hat
#hier deine Befehle
}
}

Damit mein Code sinnvoll funktioniert, musst du zwingend im presence-device das Attribut "event-on-change-reading"  nutzen.

ich habe das jetzt so versucht:
defmod n_presence_test notify smartphone:present {if ((ReadingsAge("tuersensor","state","")<180) { fhem("set licht on")}}Allerdings bekomme ich eine Fehlermeldung
Zitat
        syntax error at (eval 72744) line 1, near ") {"
        syntax error at (eval 72744) line 1, near "}}"
Es ist doch richtig, im perl Befehl einen fhem Befehl (hier set licht on) dezidiert mit fhem beginnend einzubauen?
Darf man defmod am Beginn eigentlich verwenden?
In der FHEM Referenz habe ich gerade gelernt, das zuerst etwas definiert wird und defmode als Folge temporär verwendet wird:
    define mdNtfy notify motionDetector defmod mdOff at +00:10 set lamp off
Zitat
Ich bitte aber darum diese Form der Bewohner-Überwachung (Nachrichten bei "kommt_geht") nicht zu implementieren. Sowas hat einen sehr schlechten WAF.
Ja, auch hier hast du Recht. Es ist in dieser Form keine Bewohner-Überwachung geplant. Ich möchte nur sicherstellen, dass unser Sohn nach der Schule gut zuhause angekommen ist.
LG Tom
FHEM 17762 auf Raspberry Pi 3 Model B Rev | nanoCUL868, CUL 868 MhZ, Rolladen- Aktoren, Heizung | Z-Wave, FIBARO FGD211 Universal Dimmer 500W, Popp Plug-in Dimmer, FIBARO Wall Plug, Everspring PIR Motion Sensor, FIBARO Door Opening Sensor | Netatmo

Offline roedert

  • Sr. Member
  • ****
  • Beiträge: 648
Antw:umgekehrten watchdog
« Antwort #3 am: 14 Oktober 2018, 12:49:08 »
Die beste und auch am schnellsten reagierende "Smartphone-Ankommen-Erkennung" ist ein eigener DHCP-Server. Wenn das Smartphone sich im WLAN anmeldet, fragt es zuerst den DHCP-Server - diese Abfrage kann der DHCP-Server dann an FHEM melden.

Außerdem ist evtl. auch noch ein grundsätzlicher Fehler in deinem Gedankengang - das Smartphone kann durchaus auch schon vor der Haustür sich mit dem WLAN connecten und "present" sein.
« Letzte Änderung: 14 Oktober 2018, 12:50:51 von roedert »

Offline Hollo

  • Hero Member
  • *****
  • Beiträge: 1288
Antw:umgekehrten watchdog
« Antwort #4 am: 14 Oktober 2018, 13:22:18 »
Das wollte ich auch gerade anmerken; es sind zunächst 2 vollkommen unabhängige Dinge.

Vergiss zunächst die Haustür und den watchdog, und mach die Smartphone-Erkennung robust.
Wenn WLAN unzuverlässig ist, könntest Du vielleicht auf bluetooth umsteigen.
Das hätte evtl. den Zusatznutzen, dass eine Erkennung aufgrund der Reichweite erst INNERHALB der Wohnung stattfindet.
Damit wäre Deine Türüberwachung direkt unnötig.
FHEM 5.9 auf BananaPro Jessie
Protokolle: Homematic, Z-Wave, 433Mhz-Sender
Temp/Feuchte: JeeLink-Clone mit LaCrosse/IT
sonstiges: Linux-Server, dBox2, Dreambox, "RSS-Tablet"

Offline tom44

  • Full Member
  • ***
  • Beiträge: 115
  • newbie - novice ;-)
Antw:umgekehrten watchdog
« Antwort #5 am: 14 Oktober 2018, 15:38:03 »
Zitat
Zitat
Die beste und auch am schnellsten reagierende "Smartphone-Ankommen-Erkennung" ist ein eigener DHCP-Server. Wenn das Smartphone sich im WLAN anmeldet, fragt es zuerst den DHCP-Server - diese Abfrage kann der DHCP-Server dann an FHEM melden.
Genau das habe ich ja gebaut. DHCP hat aber nichts damit zu tun, ich habe dem Smartphone eine fixe Adresse zugewiesen, dass es auch über diese Adresse erkennbar ist.
Zitat
Vergiss zunächst die Haustür und den watchdog, und mach die Smartphone-Erkennung robust. Wenn WLAN unzuverlässig ist, könntest Du vielleicht auf bluetooth umsteigen.
Auch mit Bluetooth kann die Verbindung abbrechen, wenn man den Raum wechselt. Das die Smartphones sich am WLAN oder über Bluetooth immer wieder neu am Rooter anmelden, kann man das nur dann nutzen, wenn es mit einem zuverlässigen einmaligen Ereignis (die Wohnungstür) verknüpft wird. Oder?





FHEM 17762 auf Raspberry Pi 3 Model B Rev | nanoCUL868, CUL 868 MhZ, Rolladen- Aktoren, Heizung | Z-Wave, FIBARO FGD211 Universal Dimmer 500W, Popp Plug-in Dimmer, FIBARO Wall Plug, Everspring PIR Motion Sensor, FIBARO Door Opening Sensor | Netatmo

Online frank

  • Hero Member
  • *****
  • Beiträge: 7044
Antw:umgekehrten watchdog
« Antwort #6 am: 14 Oktober 2018, 16:13:51 »
wenn es dir "nur" wichtig ist, dass dein sohn gut angekommen ist, sollte doch auch ein kurzzeitiges present ausreichen.
FHEM: 5.8(SVN) => Pi3(jessie)
IO: CUL433_V3.3(1.00.01B53)|CUL868_V3.3(1.58)|HMLAN(0.965)|HMUSB2(0.967)|HMUART(1.4.1)
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500

Offline tom44

  • Full Member
  • ***
  • Beiträge: 115
  • newbie - novice ;-)
Antw:umgekehrten watchdog
« Antwort #7 am: 14 Oktober 2018, 17:48:45 »
Zitat
wenn es dir "nur" wichtig ist, dass dein sohn gut angekommen ist, sollte doch auch ein kurzzeitiges present ausreichen.
Ja, nur das ist mir wichtig. Nur: Das Smartphone wechselt ständig zwischen present und absent, wenn es nicht durchgehend verwendet wird (und das ist zum Glück der Fall wenn der Schulaufgaben macht  :) :) )
Die Folge: Ich bekomme ständig Nachrichten auf mein Handy, dass er da ist .... Stabil ist meiner Meinung nach nur die Verknüpfung mit der einmalig geöffneten Tür.
FHEM 17762 auf Raspberry Pi 3 Model B Rev | nanoCUL868, CUL 868 MhZ, Rolladen- Aktoren, Heizung | Z-Wave, FIBARO FGD211 Universal Dimmer 500W, Popp Plug-in Dimmer, FIBARO Wall Plug, Everspring PIR Motion Sensor, FIBARO Door Opening Sensor | Netatmo

Online frank

  • Hero Member
  • *****
  • Beiträge: 7044
Antw:umgekehrten watchdog
« Antwort #8 am: 15 Oktober 2018, 12:54:30 »
ich meine wirklich nur auf das erste present vom presence device reagieren. absent muss dann anders festgelegt werden. zb auf feste zeiten, da dein sohn mo-fr ab 8:00 garantiert absent ist.

so könnte man ein notify zu diesen zeiten aktivieren (attr disable), welches dann durch present getriggert wird. beim triggern wird erstens die mail gesendet und zweitens das notify wieder deaktiviert.
FHEM: 5.8(SVN) => Pi3(jessie)
IO: CUL433_V3.3(1.00.01B53)|CUL868_V3.3(1.58)|HMLAN(0.965)|HMUSB2(0.967)|HMUART(1.4.1)
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500

Offline bartman121

  • Full Member
  • ***
  • Beiträge: 210
Antw:umgekehrten watchdog
« Antwort #9 am: 15 Oktober 2018, 17:51:21 »
wie man leicht sieht war hier: ((ReadingsAge("Tuersensor","state","")<180) ein ( zu viel :)
defmod n_presence_xxx notify smartphone:present {\
#wird ausgelöst, wenn smartphone auf present geht\
if (ReadingsAge("Tuersensor","state","")<180) {\
#wenn der Türstatus sich innerhalb der letzten 180Sekunden geändert hat\
#hier deine Befehle\
}\
}

Dieses Notify reagiert immer, wenn das Smartphone "present" wird, und die Tür vor weniger als 3 Min getriggert wurde. Schön ist das aber auch noch nicht. Wenn das nächste mal die Tür geöffnet wurde und das Smartphone present kommt, dann kriegst du wieder eine Meldung. Du brauchst noch eine sinnvolle Logik, die das notify inactive/active setzt.

Am Einfachsten kann man den Code über "raw definition" reinhauen: https://wiki.fhem.de/wiki/Import_von_Code_Snippets


-------------------------

so könnte man ein notify zu diesen zeiten aktivieren (attr disable), welches dann durch present getriggert wird. beim triggern wird erstens die mail gesendet und zweitens das notify wieder deaktiviert.
Bitte Attribute nicht dynamisch setzen, das ist immer einer Änderung an der Config.
Wenn es um Zeiten geht, dann ist dieses Attribut hilfreich:
Zitat
disabledForIntervals HH:MM-HH:MM HH:MM-HH:MM...
Optionales Attribut zur Deaktivierung innerhalb von bestimmten Zeitintervallen. Das Argument ist eine Leerzeichen-getrennte Liste von Minuszeichen-getrennten HH:MM Paaren (Stunde : Minute). Falls die aktuelle Uhrzeit zwischen diese Werte fällt, dann wird die Ausführung, wie bei disable gleich 1, ausgesetzt. Statt HH:MM kann man auch HH oder HH:MM:SS angeben.

Um einen Intervall um Mitternacht zu spezifizieren, muss man zwei einzelne Intervalle angeben, z.Bsp.:
23:00-24:00 00:00-01:00

Wenn das noch nicht sinnvoll genug erscheint, dann kann man ein notify mittels "set <notifyname> inactive" temporär deaktivieren. Mittels "set <notifyname> active" wird es wieder aktiviert. siehe hier


Grüße
« Letzte Änderung: 15 Oktober 2018, 18:07:53 von bartman121 »

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5837
Antw:umgekehrten watchdog
« Antwort #10 am: 15 Oktober 2018, 19:32:43 »
Mit DOIF habe ich leider keine Zeitverzögerung gefunden.

Warum nicht

DOIF ([smartphone:state] eq "present") (IF (ReadingsAge("Tuersensor","state","")<180) (set ....))DOELSE
attr do resetwait
attr wait 180


mit resetwait wird gleichzeitig das Toggeln des Smartphones berücksichtigt, d. h. nur wenn das Smartphone mindestens 180 Sekunden present war, wird geprüft, ob die Tür geöffnet wurde.

« Letzte Änderung: 15 Oktober 2018, 19:35:03 von Damian »
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline tom44

  • Full Member
  • ***
  • Beiträge: 115
  • newbie - novice ;-)
Antw:umgekehrten watchdog
« Antwort #11 am: 19 Oktober 2018, 21:24:05 »
Zitat
wie man leicht sieht war hier: ((ReadingsAge("Tuersensor","state","")<180) ein ( zu viel
defmod n_presence_xxx notify smartphone:present {\
#wird ausgelöst, wenn smartphone auf present geht\
if (ReadingsAge("Tuersensor","state","")<180) {\
#wenn der Türstatus sich innerhalb der letzten 180Sekunden geändert hat\
#hier deine Befehle\
}\
}
Dieses Notify reagiert immer, wenn das Smartphone "present" wird, und die Tür vor weniger als 3 Min getriggert wurde. Schön ist das aber auch noch nicht. Wenn das nächste mal die Tür geöffnet wurde und das Smartphone present kommt, dann kriegst du wieder eine Meldung. Du brauchst noch eine sinnvolle Logik, die das notify inactive/active setzt.

Herzlichen Dank bartman123 für deine ausführliche Antwort.
Ich habe die Klammer gelöscht (die Fehlermeldung habe ich noch immer nicht interpretieren können ...) und habe dann notify und defmode vertauscht (so wie ich es in der FHEM Referenz gerade gelesen habe.  Leider habe ich noch immer keinen Erfolg  :P
define n_tom.zuhause.test1 notify defmod smartphone:present {if (ReadingsAge("tuersensor","state","")<180) {fhem("set ... on")}}
Durch deine Antwort mit dem für mich neuen defmod habe ich wieder viel gelernt, was mich einen ganzen Abend beschäftigen kann ... auch nach über 2 Jahren bin ich noch ein Anfänger mit FHEM und daher recht langsam. Ich werde weiter tapfer probieren und testen und lernen und dann berichten.  ::)
FHEM 17762 auf Raspberry Pi 3 Model B Rev | nanoCUL868, CUL 868 MhZ, Rolladen- Aktoren, Heizung | Z-Wave, FIBARO FGD211 Universal Dimmer 500W, Popp Plug-in Dimmer, FIBARO Wall Plug, Everspring PIR Motion Sensor, FIBARO Door Opening Sensor | Netatmo

Offline tom44

  • Full Member
  • ***
  • Beiträge: 115
  • newbie - novice ;-)
Antw:umgekehrten watchdog
« Antwort #12 am: 19 Oktober 2018, 21:29:34 »
Warum nicht
DOIF ([smartphone:state] eq "present") (IF (ReadingsAge("Tuersensor","state","")<180) (set ....))DOELSE
attr do resetwait
attr wait 180
mit resetwait wird gleichzeitig das Toggeln des Smartphones berücksichtigt, d. h. nur wenn das Smartphone mindestens 180 Sekunden present war, wird geprüft, ob die Tür geöffnet wurde.
Danke auch an Dich Damian. Auch der DOIF funktioniert bei mir noch nicht. Zuerst habe ich die Zeit des Wartens verkürzt, da ich davon ausging, dass die Prüfung 1 (Handy angemeldet nach 180sek abgeschlossen ist und erst dann geprüft wird, ob 180sek zuvor die Tür offen war. Das war es aber leider nicht ...
define tom.zuhause.test2 DOIF ([smartphone:state] eq "present") (IF (ReadingsAge("tuersensor","state","")<180) (set ... on))
attr do resetwait
attr wait 80
ich werde weiter ausprobieren und dann berichten  :P

FHEM 17762 auf Raspberry Pi 3 Model B Rev | nanoCUL868, CUL 868 MhZ, Rolladen- Aktoren, Heizung | Z-Wave, FIBARO FGD211 Universal Dimmer 500W, Popp Plug-in Dimmer, FIBARO Wall Plug, Everspring PIR Motion Sensor, FIBARO Door Opening Sensor | Netatmo

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6123
Antw:umgekehrten watchdog
« Antwort #13 am: 19 Oktober 2018, 23:45:42 »
Ich möchte aber, dass der FHEM Befehl startet, wenn nach dem Empfang des Ereignisses <regexp1> UND innerhalb von <timespec> ein <regexp2> Ereignis empfangen wird.
[...] Oder gibt es hierfür eine andere Lösung?
https://fhem.de/commandref_DE.html#sequence waere eine weitere Möglichkeit.
Das notify von bartman123 ist ohne den für mich unverstaendlichen Tausch von notify/defmod aber auch ein Ansatz.

Gruß, Christian

Offline tom44

  • Full Member
  • ***
  • Beiträge: 115
  • newbie - novice ;-)
Antw:umgekehrten watchdog
« Antwort #14 am: 21 Oktober 2018, 14:02:31 »
https://fhem.de/commandref_DE.html#sequence waere eine weitere Möglichkeit.
Das notify von bartman123 ist ohne den für mich unverstaendlichen Tausch von notify/defmod aber auch ein Ansatz.
So einfach? Das funktioniert.  :)  :)  :) DANKE Krikran  :)  :)  :)

Also, das sieht nun so aus:
Die Tür ist offen, es wird 10 Minuten gewartet ob das Smartphone sich am WLAN anmeldet
define TuerOffen.SmartphonePresent tuersensor:open 600 smartphone:present Wenn erfüllt, wird eine Kurznachricht versendet:
define push.Sohn.zuhause TuerOffen.SmartphonePresent:trigger set Push msg 'Sohn ist zuhause'Jetzt muss ich noch eine Zeitbeschränkung hinzufügen, damit dies nur während der Schultage und nur am Nachmittag durchgeführt wird ....

Zusammengefasst:
Whatchdog
Startet einen beliebigen FHEM Befehl, wenn nach dem Empfang des Ereignisses <regexp1> NICHT innerhalb von <timespec> ein <regexp2> zweites Ereignis empfangen wird.
Sequence
Startet einen beliebigen FHEM Befehl , wenn nach dem Empfang des Ereignisses <regexp1> UND innerhalb von <timespec> ein <regexp2>zweites Ereignis empfangen wird.
Wobei bei sequence der Befehl erst durch ein weiteres triggern ausgeführt wird.

Sollte man in der FHEM Referenz bei den jeweiligen Hilfsmodulen nicht auf das jweils andere hinweisen?




FHEM 17762 auf Raspberry Pi 3 Model B Rev | nanoCUL868, CUL 868 MhZ, Rolladen- Aktoren, Heizung | Z-Wave, FIBARO FGD211 Universal Dimmer 500W, Popp Plug-in Dimmer, FIBARO Wall Plug, Everspring PIR Motion Sensor, FIBARO Door Opening Sensor | Netatmo

 

decade-submarginal