Autor Thema: umgekehrten watchdog  (Gelesen 382 mal)

Offline tom44

  • Full Member
  • ***
  • Beiträge: 100
  • 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

Offline bartman121

  • Full Member
  • ***
  • Beiträge: 184
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: 100
  • 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

Offline roedert

  • Sr. Member
  • ****
  • Beiträge: 632
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: 1270
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.8 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: 100
  • 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?






Offline frank

  • Hero Member
  • *****
  • Beiträge: 6830
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: 100
  • 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.

Offline frank

  • Hero Member
  • *****
  • Beiträge: 6830
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: 184
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: 5582
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

 

decade-submarginal