Presence und iPhone / Android

Begonnen von JoWiemann, 07 September 2017, 11:58:59

Vorheriges Thema - Nächstes Thema

MadMax-FHEM

Hm, dann ist das wohl beim iPhone so...

Bei mir war es halt ein paar mal in der Nacht, da ich dort wohl tatsächlich nichts mit dem Telefon mache ;)

Ich habe kein push aktiviert und frage Mail etc. nur alle keine Ahung was ab...

Wie gesagt: ein paar mal die Nacht. Und wenn ich dann bei offenem Fenster geschlafen habe kam eben die Nachricht "Fenster offen"... Unnötig weil ich war ja da.

Das ist seit dem weg und ein paar mal nachts einen hping3 ist ok...
...schade, dass es bei dir dann wohl nicht 2-Stufig geht/sinn macht... :-|

Musst halt mal sehen wie es sich bzgl. Akku verhält, wenn du nur den hping3-Mechanismus nimmst (so wie der Thread ja eigentlich gedacht ist/begonnen hat)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

dusti64

Na ich schau mir das mal ein paar Tage an...mal sehen, wie es sich auswirkt.

Trotzdem Danke und einen schicken Abend 🙋‍♂️

Gruß Dusti
2x Debian virtualisiert auf QNAP mit FHEM, 2x HMLAN, VCCU, Homatic Heizung+Licht-Rollläden, Alexa mit 2 Echos, Homebridge, Hue, Instar

T3mplate

Zitat von: MadMax-FHEM am 29 Oktober 2017, 20:14:35
Hm, dann ist das wohl beim iPhone so...

Bei mir war es halt ein paar mal in der Nacht, da ich dort wohl tatsächlich nichts mit dem Telefon mache ;)

Ich habe kein push aktiviert und frage Mail etc. nur alle keine Ahung was ab...

Wie gesagt: ein paar mal die Nacht. Und wenn ich dann bei offenem Fenster geschlafen habe kam eben die Nachricht "Fenster offen"... Unnötig weil ich war ja da.

Das ist seit dem weg und ein paar mal nachts einen hping3 ist ok...
...schade, dass es bei dir dann wohl nicht 2-Stufig geht/sinn macht... :-|

Musst halt mal sehen wie es sich bzgl. Akku verhält, wenn du nur den hping3-Mechanismus nimmst (so wie der Thread ja eigentlich gedacht ist/begonnen hat)...

Gruß, Joachim

Kannst du deine Lösung mal posten?

MadMax-FHEM

Zitat von: T3mplate am 29 Oktober 2017, 23:09:54
Kannst du deine Lösung mal posten?

Jep.

Also ich habe ein PRESENCE wie hier im Thread beschrieben mit hping3-Script.
Das ist auch das, nach welchem ich die Automatiken laufen lasse, bei Anwesenheit/Abwesenheit (z.B. Fenster geschlossen etc. wenn ich weg bin), da nur dieses zuverlässig abwesend anzeigt, wenn ich tatsächlich weg bin.

Hier das list:


Internals:
   DEF        function {my_CheckPhone("192.168.1.79", "xx:xx:xx:xx:xx:xx")} 3600
   MODE       function
   NAME       pIch
   NOTIFYDEV  global
   NR         351
   NTFY_ORDER 50-pIch
   STATE      absent
   TIMEOUT_NORMAL 3600
   TIMEOUT_PRESENT 3600
   TYPE       PRESENCE
   READINGS:
     2017-10-29 22:46:53   model           function
     2017-10-29 22:47:08   presence        absent
     2017-10-29 22:47:08   state           absent
   helper:
     ABSENT_COUNT 0
     call       {my_CheckPhone("192.168.1.79", "xx:xx:xx:xx:xx:xx")}
Attributes:
   alias      Ich
   devStateIcon absent:user_ext_away present:user_available maybe.absent:user_available
   event-on-change-reading .*
   icon       user_unknown
   room       Eingang


Das Intervall von 3600 Sekunden könnte auch noch (deutlich) größer sein, da es mir hier eher auf den statusRequest ankommt, den das andere PRESENCE (lan-ping) auslöst, wenn das erkennt oder zu erkennen glaubt, dass ich weg bin.

Hier das list dazu:


Internals:
   ADDRESS    192.168.1.79
   CHANGED
   DEF        lan-ping 192.168.1.79
   MODE       lan-ping
   NAME       pIch_light
   NOTIFYDEV  global
   NR         355
   NTFY_ORDER 50-pIch_light
   STATE      present
   TIMEOUT_NORMAL 30
   TIMEOUT_PRESENT 30
   TYPE       PRESENCE
   READINGS:
     2017-10-29 22:46:53   model           lan-ping
     2017-10-29 23:43:23   presence        present
     2017-10-29 23:43:23   state           present
   helper:
     CURRENT_STATE present
     PRESENT_COUNT 0
Attributes:
   absenceThreshold 2
   event-on-change-reading .*


D.h. das lan-ping PRESENCE läuft ganz normal.
Wenn dieses glaubt mein Handy wäre absent, dann wird per notify ein statusRequest beim hping3 PRESENCE ausgelöst.
Dieses geht eigentlich zuverlässig nur dann auf absent, wenn ich tatsächlich weg bin.
Gerade nachts hatte ich da öfter mal "Fehlalarme" (Fenster noch auf)...
...seither nicht mehr.

Hier noch das notify:


Internals:
   DEF        pIch_light:(absent|present) set pIch statusRequest
   NAME       nPresenceHandy
   NR         359
   NTFY_ORDER 50-nPresenceHandy
   REGEXP     pIch_light:(absent|present)
   STATE      active
   TYPE       notify
   READINGS:
     2017-10-29 22:46:53   state           active
Attributes:


Das Auslösen des statusRequest auch bei present-Meldung des lan-ping PRESENCE brauche ich, damit (trotz des großen Abfrageintervalls des "Haupt-PRESENCE") der Status auch im für mich eigentlich wichtigen PRESENCE gesetzt wird.

Die Erkennung auf "present" könnte etwas schneller gehen (da ist lan-ping auch etwas langsam) aber wichtiger ist mir (aktuell) die Erkennung auf absent und das zuverlässig ohne "Fehlalarme"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

T3mplate

Zitat von: MadMax-FHEM am 29 Oktober 2017, 23:50:19
Jep.

Vielen Dank.
Musstest du nicht aber auch Änderungen am bash-skript oder der Utils vornehmen?

VG
Stefan

MadMax-FHEM

#35
Zitat von: T3mplate am 30 Oktober 2017, 10:55:34
Vielen Dank.
Musstest du nicht aber auch Änderungen am bash-skript oder der Utils vornehmen?

VG
Stefan

Gerne.

Nein, warum?

Sind (bis auf den Namen meiner Funktion ;)  ) identisch zum ersten Post...

Ich habe ja nur das hping3 PRESENCE angelegt wie beschrieben, allerdings mit (sehr) großem Abfrage-Intervall (eigentlich bräuchte das gar nicht abfragen aber disable geht ja nicht ;)  )...
Bei dem rufe ich dann durch das notify den "statusRequest" auf, dadurch macht es aktiv eine Abfrage und liefert "absent/present" (und absent halt nur, wenn tatsächlich absent)...

Dann noch ein normales lan-ping PRESENCE (bzw. das was ich schon immer hatte aber halt nicht immer zuverlässig funktioniert hat) welches dann bei absent und present per notify den "statusRequest" beim hping3-PRESENCE auslöst (siehe oben ;)  ).

Und wie gesagt die 2 Stufen nur wegen dem Akkuverbrauch.
Gefühlt war der Akku nachts immer deutlich runter als ich anfangs nur den hping3-PRESENCE laufen hatte (Abfragezyklus ca. 1min).

EDIT: und wie geschrieben orientiere ich mich nur am hping3-PRESENCE bzgl. present/absent (das andere dient nur zum "Anstoßen" ;)  )

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

T3mplate

Zitat von: MadMax-FHEM am 30 Oktober 2017, 11:16:15
Gerne.

Nein, warum?

Sind (bis auf den Namen meiner Funktion ;)  ) identisch zum ersten Post...

Ich habe ja nur das hping3 PRESENCE angelegt wie beschrieben, allerdings mit (sehr) großem Abfrage-Intervall (eigentlich bräuchte das gar nicht abfragen aber disable geht ja nicht ;)  )...
Bei dem rufe ich dann durch das notify den "statusRequest" auf, dadurch macht es aktiv eine Abfrage und liefert "absent/present" (und absent halt nur, wenn tatsächlich absent)...

Dann noch ein normales lan-ping PRESENCE (bzw. das was ich schon immer hatte aber halt nicht immer zuverlässig funktioniert hat) welches dann bei absent und present per notify den "statusRequest" beim hping3-PRESENCE auslöst (siehe oben ;)  ).

Und wie gesagt die 2 Stufen nur wegen dem Akkuverbrauch.
Gefühlt war der Akku nachts immer deutlich runter als ich anfangs nur den hping3-PRESENCE laufen hatte (Abfragezyklus ca. 1min).

Gruß, Joachim

Dann wird das heute Abend gleich mal getestet.

T3mplate

Zitat von: MadMax-FHEM am 29 Oktober 2017, 23:50:19

Internals:
   DEF        pIch_light:(absent|present) set pIch statusRequest
   NAME       nPresenceHandy
   NR         359
   NTFY_ORDER 50-nPresenceHandy
   REGEXP     pIch_light:(absent|present)
   STATE      active
   TYPE       notify
   READINGS:
     2017-10-29 22:46:53   state           active
Attributes:

So. Ich habe deine Idee jetzt übernommen.
Ich habe eine Presence Funktion über die Fritzbox (statt LAN Ping liest diese die angemeldeten Geräte auf der Fritzbox aus) laufen.
Diese funktionierte entgegen LAN Ping in der Vergangenheit nahezu Fehlerfrei bei einem Puffer von 10 Minuten.
Seit iOS11 aber habe ich mindestens 10 falsche "absent" pro Tag, was natürlich absoluter Mist ist.

Jetzt aber meine Frage zu deinem notify:
Wenn ich das richtig verstehe, dann reagierst du auf einen Wechsel von "absent" auf "present" oder andersherum.
Wenn solch ein Wechsel auf deinem LAN Ping stattfindet, dann lässt du dein führendes present Modul per statusRequest schauen.

Wie gehst du mit folgendem Fall um:
1. Dein LAN Ping macht eine Falschmeldung -> "absent"
2. Du prüfst mit hping3 ob das stimmt -> führendes Modul bleibt auf "present"
3. Direkt nach dem Falschmeldung verlässt du wirklich das Haus
4. Da LAN Ping noch auf "absent" ist, wechselt das Device nicht den Status
5. Das hping3 Modul geht erst nach 3600s (oder mehr bei höherem Intervall) auf "absent"

Ich habe deshalb folgendes bei mir umgesetzt:

defmod Stefan_Handy_Abgleich DOIF ([Stefan_Handy] ne [Stefan_Handy_Fritzbox]) (set Stefan_Handy statusRequest) (setreading Stefan_Handy_Fritzbox state [Stefan_Handy:state])
attr Stefan_Handy_Abgleich do always
attr Stefan_Handy_Abgleich group Stefan_Handy
attr Stefan_Handy_Abgleich icon it_smartphone
attr Stefan_Handy_Abgleich room Wohnzimmer-BG


Damit gleiche ich die beiden presence Module ab. Wird ein Unterschied festgestellt, dann wird hping3 ausgeführt und dieser Status in das Fritzbox Presence Device überführt. Dadurch kommt nach X Minuten (in meinen Fall 180sekunden) ein neuer Wechsel bei Fritzbox Presence und der Abgleich wird erneut durchgeführt.

Ist diese Lösung besser oder schlechter? Mich würde deine Meinung interessieren.

MadMax-FHEM

#38
Hmm,

stimmt wohl dieser Fall wäre nicht abgedeckt.

Ist aber noch nicht aufgetreten (gefühlt und laut Log)...

Tagsüber (wo ich ja doch immer wieder mal was mit dem Handy mache) hatte bislang auch das "normale" lan-ping immer funktioniert...
...Probleme/Unstimmigkeiten hatte ich nur nachts.

Bin mir bzgl. DOIF nicht sicher (verwende es [bislang] noch nicht) aber soweit mir bekannt braucht ein DOIF ebenfalls einen "Auslöser".
Da aber ja kein Statuswechsel kommt, kommt auch (dank event-on-change-reading) kein Event, also wird auch das DOIF nicht erneut ausgeführt...
...gleiches Problem.
(habe nachgesehen müsste so sein: kein Ereignis kein DOIF)

D.h. du müsstest (wie ich auch) das event-on-change-reading beim lan-ping PRESENCE/Fritzbox PRESENCE wegnehmen!

Das setreading ist vermutlich unnötig bzw. fraglich, ob das macht wie es gedacht ist:
da vermutlich das Ergebnis des statusRequest des hping3 noch nicht da ist würde das Fritzbox PRESENCE vermutlich auf present gehen (durch setreading) bis zum nächsten Prüfen...
Erst danach (nun ist ja das hping3 PRESENCE auch absent) würden beide Status auf dem selben Wert sein: absent (Fritzbox erneute eigenprüfung und hping3 durch den statusRequest).
Ohne das setreading wären beide Status nach dem hping3 statusRequest automatisch auf dem gleichen Stand: Fritzbox PRESENCE war ja absent und das hping3 PRESENCE ist es nach dem statusRequest auch.
Also gleicht sich das eigentlich automatisch ab oder es ist was unstimmig, dann eben noch mal statusRequest bis es stimmt...

Statt setreading state sollte set auch genügen...
...aber ich denke es ist unnötig (siehe oben).

Aber danke für den Hinweis auf die Lücke.
Ich werde es allerdings so lösen (bleibe bei notify ;)  ):

event-on-change-reading wegnehmen beim lan-ping PRESENCE
dadurch wird ja jeder Status (auch bei nicht Wechsel) gemeldet
notify löst aus
allerdings will ich ja nicht jedesmal einen statusRequest (daher ja das event-on-change-reading und die 2 stufigkeit), daher werde ich auch auf unterschiedlichen Status prüfen und nur dann einen hping3 statusRequest auslösen, wenn sich die beiden unterscheiden (also so wie du mit DOIF ;)  ).

Gruß und danke, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

dindihi

Nur so als Info, hatte auch lange das Problem dass die Android bzw Ipad's im Standby nach ner Weile keine ping's mehr beantworten.
Da ich als Router Mikrotik nutze mit capsman, hatte ich dann die Idee dies über die caps registration table zu realisieren.

Hab dies dann so gelöst:

sub CheckPhone($$)
{
my ($ip,$mac)= @_;
my $ret = "";
my $cmd = "ssh -l USERNAME -i /opt/mikrotik/rb3011_id_dsa 192.168.88.1 \"/caps-man registration-table print count-only  where mac-address=$mac\" |tr -d \'\\r\\n\' |tr -s \' \'";
$ret = qx($cmd);
$ret =~ s,[\r\n]*,,g;
Log3 "CheckPhone", 2, "CheckPhone: $ret";
if ($ret == 1) {return 1;} else {return 0;}
}

(im script wird die Variable IP nicht genutzt.)
Das dsa certificate muss zuerst erstellt werden (google).


BooosesThaSnipper

Hi zusammen,

bin neu hier und habe gerade diesen Thread gefunden. Eigentlich komme ich aus der LightManager Ecke und habe dort eine ähnliche Anforderung gehabt und hab ebenso hping3 genutzt um meine Anforderung zu lösen. (https://www.jbmedia.de/forum/viewtopic.php?f=24&t=952)

Hab das Script dazu auch bereits seit längerem auf GitHub stehen:
https://github.com/BooosesThaSnipper/SmartHome/blob/master/PresenceCheck2Marker/presencecheck2marker.sh

Vielleicht hilft diese Variante auch hier dem ein oder anderem weiter. Aktuell ist dieses Script zu 100% auf den LightManager ausgelegt. Da ich noch neu bei FHEM bin, und aktuell noch beim einlesen bin, weiß ich nicht was FHEM für Rückgabewerte erwartet. Aus den bereits genannten Scripten reicht wohl ein ReturnCode von 0 oder 1 (abwesend / anwesend) aus. Ist das korrekt?

Falls Interesse besteht würde ich das Script für FHEM umschreiben, so dass am Ende eine 0 oder 1 raus kommt. Würde hierfür Interesse bestehen?

Viele Grüße
Markus



Neuhier

@dindihi
Das Problem ist wohl eher, daß das Handy nach einer Weile kein WLAN aktiv hat.
Müßtest mal schauen, ob Du diesen Ruhemodus (?) deaktivieren kannst.

Ich mache hier Presence über G-Tags, also BT.

bstohs

danke für die tollen Code-Fragmente

ich habe lange probiert, bis ich eine stabile Funktionsweise hatte.

Auf meinem Raspi funktioniert hping3 mit dem im Code angegebenen Interface nicht.
Also habe ich den Parameter weggelassen und es wird das Standard-Interface verwendet.
Hier meine presence.sh Datei:

declare -a DEVICES
sudo hping3 -2 -c 10 -p 5353 $1 -q >/dev/null 2>&1
sleep 2
DEVICES=`arp -an | awk '{print $4}'`
CHECK="$2"
if [[ ${DEVICES[*]} =~ $CHECK ]]
then
echo "1"
else
echo "0"
fi

Master_Nick

Mahlzeit,

ich kann die hping3 Geschichte bisher nicht als wakeup nachstellen bei einem S5 und einem S7.
Scheint es dann doch nur bei Iphone zu gehen?
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

MadMax-FHEM

Zitat von: Master_Nick am 29 Dezember 2017, 01:01:26
Scheint es dann doch nur bei Iphone zu gehen?

Nein, habe ein SONY Xperia X compact und damit funktioniert es auch.

Daher wurde es von anfänglich iPhone auf iPhone und Android umbenannt ;)

Was geht denn nicht?
Wird alles asuber ausgeführt aber das Telefon geht trotzdem auf absent, obwohl present?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)