Presence und iPhone / Android

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

Vorheriges Thema - Nächstes Thema

miche

#15
Hallo,

ich wollte das jetzt auch mal ausprobieren. Jedoch bekomme ich Fehlermeldungen.
Wenn ich den Code in die MyUtils eintrage kommt folgender Fehler:

Missing right curly or square bracket at ./FHEM/myUtilsTemplate.pm line 38, at end of line syntax error at ./FHEM/myUtilsTemplate.pm line 38, at EOF

Wenn ich in Zeile 38 noch die geschweifte Klammer schreibe kommt folgender Fehler:

Undefined subroutine &main::myUtilsTemplate_Initialize called at fhem.pl line 2450.

Nun Frage ich mich warum, in der fhem.pl wurde ja gar nix geändert!

die presence.sh hab ich auch angelegt

Meine PRESENCE Funktion bringt auch noch einen Fehler:
PRESENCE (CheckMicheiPhone) - error while processing check: unexpected function output (expected 0 or 1):

MadMax-FHEM

Alles so gemacht wie hier beschrieben:

https://wiki.fhem.de/wiki/99_myUtils_anlegen

Poste doch mal deine myUtils und bitte in code-Tags (das '#' im Menü)...

Wie hast du editiert?

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)

majorshark

Ich habe diese Lösung mal getestet. Eigentlich wollte ich gegenüber meiner jetzigen Lösung erreichen, dass die Abwesenheit schneller erkannt wird. Funktionierte leider nicht. Ich bin jetzt wieder zu der snmpCheck Variante zurückgekehrt. Diese funktioniert beim mir seit Jahren zuverlässig. Nur mit dem Manko, dass es bis zur Abwesenheit manchmal 20 Minuten dauern kann.
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

MadMax-FHEM

20min verstehe ich nicht.
Bei mir dauert es so max. 1 bis 2 min, kommt auf das eingestellte Intervall an...

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)

miche

Zitat von: MadMax-FHEM am 10 September 2017, 13:38:42
Alles so gemacht wie hier beschrieben:


Natürlich nicht, war mein Fehler.
Ich hab nicht die 99_myutils genommen sonder die myutils die vorhanden war.
Jetzt läuft !!!
Danke für den Tip

MadMax-FHEM

Hmmm, Stromverbrauch...

Gefühlt etwas mehr, leider nicht wissenschaftlich ermittelt (keine Zeit) ;)

Aktuell experimetiere ich mit einem zweistufigen Konzept:

Ein Presence mit normalem lan-ping und wenn der absent bzw. present erkennt, dann wird ein statusRequest beim hping3-Presence ausgelöst per Notify
Das hping3-Presence hat ein Intervall von (aktuell) alle Stunde ist aber das "führende" Presence

Erste Tests sind positiv (gut vielleicht etwas umständlich aber wenn es zuverlässig läuft kommt das so ins Hauptsystem) mal sehen wie es nachts wird...

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)

majorshark

Zitat von: MadMax-FHEM am 10 September 2017, 14:47:18
20min verstehe ich nicht.
Bei mir dauert es so max. 1 bis 2 min, kommt auf das eingestellte Intervall an...

Gruß, Joachim

Ich habe mal am DHCP-Server eine Einstellung geändert. Werde das jetzt mal testen und dann berichten.
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

MadMax-FHEM

Zitat von: majorshark am 11 September 2017, 15:24:10
Ich habe mal am DHCP-Server eine Einstellung geändert. Werde das jetzt mal testen und dann berichten.

Nur um sicher zu gehen:

ich verwende nicht die dhcp-Methode von Presence...

Bis vor kurzem normal lan-ping und jetzt (testweise) die aus dem Thread...

Aber keine dauert 20min...

Je nach Einstellung zwischen 1-2min...

Mich hat nur gewundert, dass die Variante aus dem Thread nicht schneller als 20min sein soll (war ja deine Hoffnung)...

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)

majorshark

Bei der snmpCheck Methode habe ich wahrscheinlich den "Fehler" gefunden. Die DHCP-Server Einstellung hat es nicht gebracht. Aber die Aktualisierungszeit der ARP-Tabelle.
Mein LANCOM Router, den ich dafür abfrage, hat ein ARP-Aging von 15 Minuten eingestellt. Da ich noch einen Watchdog von fünf Minuten dazwischen habe scheint das mit den 20 Minuten hinzukommen. Ich habe die ARP-Aging Time mal auf Fünf Minuten heruntergesetzt.

Warum aber der RasPI der Meinung ist seine eigene ARP-Tabelle auch erst nach 15 Minuten zu aktualisieren kann ich nicht sagen.
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

MadMax-FHEM

#24
Zitat von: MadMax-FHEM am 11 September 2017, 10:44:06
Hmmm, Stromverbrauch...

Gefühlt etwas mehr, leider nicht wissenschaftlich ermittelt (keine Zeit) ;)

Aktuell experimetiere ich mit einem zweistufigen Konzept:

Ein Presence mit normalem lan-ping und wenn der absent bzw. present erkennt, dann wird ein statusRequest beim hping3-Presence ausgelöst per Notify
Das hping3-Presence hat ein Intervall von (aktuell) alle Stunde ist aber das "führende" Presence

Erste Tests sind positiv (gut vielleicht etwas umständlich aber wenn es zuverlässig läuft kommt das so ins Hauptsystem) mal sehen wie es nachts wird...

Gruß, Joachim

Bislang läuft diese Kombination problemlos und der tatsächliche ("führende") Status ist wie es sein soll!

Mit dem "normalen" lan-ping habe ich immer wieder mal 'absent' bekommen (was dann einen statusRequest des hping3/Scripts auslöst), das eigentliche PRESENCE mit dem h3ping bzw. Script zeigt stabil 'present' (außer ich bin wirklich nicht da ;)  )...

Akkuverbrauch ist (gefühlt) auch wieder normal :)

Habe das jetzt vom Testsystem auf mein Hauptsystem übernommen!
(werde das Updateintervall des hping3/Scripts mal weiter vergrößern, eigentlich ist ja nur der durch das notify ausgelöste statusRequest ausschlaggebend)


Evtl. wäre es gut den Thread-Titel zu ändern, da es ja für Android (zumindest bei mir) auch funktioniert!

EDIT: achja -> vielen Dank für die Idee, das Script und das Einstellen hier!!

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)

stera

Ich habe auch sehr gute Erfahrung mit dem Fritz Box Modul und Presence Modul gemacht. Das ist ja nicht so selten, dass jemand zu Hause eine FritzBox hat. Ob das IPhone dort in der Auflistung der Geräte im Standby verschwindet kann ich leider nicht sagen, weil ich Android benutze.

Aber vll. hilft es ja den einen oder anderen  :o


Internals:
   CHANGED
   DEF        function {checkFritzMACpresent("Fritzbox","XX:XX:XX:EC:XX:1X")} 60 60
   MODE       function
   NAME       WLANHandy
   NOTIFYDEV  global
   NR         50
   NTFY_ORDER 50-WLANHandy
   STATE      present
   TIMEOUT_NORMAL 60
   TIMEOUT_PRESENT 60
   TYPE       PRESENCE
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1505554925.52647
           VALUE      present
   READINGS:
     2017-09-15 01:21:49   model           function
     2017-09-16 13:16:20   presence        present
     2017-09-16 13:16:20   state           present
   helper:
     CURRENT_STATE present
     call       {checkFritzMACpresent("Fritzbox","XX:XX:XX:EC:XX:1X")}
Attributes:
   devStateIcon present:WLAN_Status.1 absent:WLAN_Status.0
   event-on-change-reading .*
   room       Netzwerk


Gruß,
SteRa

Avatar

Ich habe noch diese Variante gefunden, ist annähernd wie schon propagiert. Es scheint dass ARP doch etwas volatile ist und es manchmal vorkommt dass bei der MAC-Adresse <incomplete> auftaucht und somit die Erkennung fehlerhaft ist.

Es wurden zwei Elemente nachgeführt, das eine wurde "sleep" eingefügt und das zweite -  bei nicht erfolgtem erkenne eine Schlaufe so oft wie gewünscht durchlaufen wird, mit der Möglichkeit dass ARP dann korrekten Inhalt hat. Schaut es an, ich bin nicht ganz überzeugt aber ich denke es ist eine Möglichkeit es etwas zuverlässiger zu machen.#!/bin/bash

# detect iphone by IP and MAC address.
# use MAC address too, to prevent false positives if IP might change
# return ON or OFF so output can be directly bound to a switch item

# number of retries, less is faster, but less accurate
MAXRETRIES=10

# exit immediately if no parameters supplied
if [ $# -lt 2 ]
  then
    echo "UNDEF"
  exit 1
fi

# Set variables
IP=$1
MAC=$2
COUNT=0

while [ ${COUNT} -lt ${MAXRETRIES} ];
do
  # Change dev and eth0 if needed
  #   sudo ip neigh flush dev eth0 ${IP}
  sudo hping3 -q -2 -c 10 -p 5353 -i u1 ${IP} >/dev/null 2>&1
  sleep .1
  # Only arp specific device, grep for a mac-address
  STATUS=`arp -an ${IP} | awk '{print $4}' | grep "${MAC}"`

  if [ ${#STATUS} -eq 17 ]; then
     # exit when phone is detected
     echo "1"
    exit 0
  fi
  let COUNT=COUNT+1
  sleep .1
done
# consider away if reached max retries
echo "0"


Grüsse Eric

dusti64

Zitat von: MadMax-FHEM am 11 September 2017, 10:44:06

Aktuell experimetiere ich mit einem zweistufigen Konzept:

Ein Presence mit normalem lan-ping und wenn der absent bzw. present erkennt, dann wird ein statusRequest beim hping3-Presence ausgelöst per Notify
Das hping3-Presence hat ein Intervall von (aktuell) alle Stunde ist aber das "führende" Presence

Hallo in die Runde...

ich habe mich jetzt auch mal an die Erstellung einer zuverlässigen Anwesenheit gemacht und mich eng an diesen Beitrag gehalten... jedenfalls versucht ;) vielen Dank für die Erstellung und die Tipps...

Zuerst ein lan-ping auf das iPhone, welches ja bekanntlich in den "Schlafmodus" geht (bei mir nach 3min), dann das Script erstellt, eingepflegt und eine 2. Presence auf die MAC-Adresse + Scriptausführung, sowie das notify (s.o.) erstellt und eine Structure, in der beide Presence sind. Der Status ändert sich auch zuverlässig, d.h. bin ich weg, ist die Structure absent.

Jetzt habe ich eine Verständnisfrage zu dem o.g. notify, welches ich auch eingerichtet habe:

Es ist jetzt so, wenn ich das iPhone benutze, ändern sich der Status des lan-ping auf present und die Structure Anwesenheit bleibt auf present, dadurch ruht das notify.
Geht das iPhone in den Schlafmodus und der lan-ping auf absent, wird dadurch das notify aktiv und löst ein statusRequest aus für den hping3 aus, welches ich über ein disabledForIntervals = 60 alle 60 sec ausführe.
Wo ist jetzt der Vorteil des langen Intervalls für das hping3-Presence von einer Stunde? Das greift doch nur, wenn ich das iPhone wirklich nutze und ich sitze gaaaaanz selten länger als ne Std. am Handy...oder anders rum, ich komme nach Hause und hab das Handy in der Tasche, ohne es zu benutzen (WLAN ist an, aber nicht aktiv) - dadurch, dass der lan-ping auf die IP ja noch absent ist, greift auch hier keine Änderung des notify, welches ja noch aktiviert ist/sein muss, damit ich die Änderung mit dem hping3-Script erkennen kann und die Structure ihren Status ändert...

Wo stehe ich auf dem Schlauch?

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

MadMax-FHEM

Hi,

also ich habe einen langen (noch längeren / müsste ich jetzt nachsehen ;)  ) timeout bzw. Zyklus für den hping3 da dieser auf die Akku-Laufzeit des Smartphone geht (gefühlt und manche berichteten dies).

D.h. solange der normale ping auch eine Anwesenheit erkennt brauche ich den hping3 nicht.
Geht allerdings der normale lan-ping auf absent heißt das noch lange nicht, dass ich weg bin...
...daher dann zum tatsächlichen Prüfen der hping3 etc.

Für das schnellere Erkennen, wenn ich zurück komme bin ich noch dran was zu finden.
Es gibt bei Presence ja einen Abfragezyklus "normal" und einen "anwesend".
Was ich gerne hätte bzw. ich mir mal basteln wollte ist eine höhere Frequenz für den hping3 bei Abwesenheit (da ist mir der Akku ja egal weil da der hping3 ja nicht wirkt ;)  ), dann sollte schnell die echte Anwesenheit erkannt werden wenn ich wieder zurück komme.

Aktuell geht es, könnte aber tatsächlich schneller sein...
...aber ich hab noch so viele (wichtigere) Baustellen ;)

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

Hi Joachim...und Danke:)

ich hab schon verstanden, warum die Zeit so lang gewählt ist, eben wegen dem Akku. Doch dieser Zyklus greift ja nicht, wenn das notify getriggert wird, weil der normale lan-ping auf "absent" geht. Oder anders gefragt...geht der Vorteil nicht flöten durch den statusRequest (alle 60 sec durch das disable-Intervall), wie oft wird der denn abgesetzt bei dir, wenn der normale lan-ping "absent" zeigt?
Also mein iPhone fliegt sofort raus aus dem lan-ping (mit leichter Verzögerung von 60 sec), wenn ich es sperre. Somit ist diese Art der Abfrage quasi bei über. Für Android mag es ja funktionieren...da kann ich nichts zu sagen.

Was machen denn die ganzen Hintergrundaktualisierungen (WhatsApp usw.), die sind doch auch über WLAN verbunden, wenn das iPhone WLAN hat oder? Ist der Akkuverbrauch echt soviel höher durch den hping3?

Zitat von: MadMax-FHEM am 29 Oktober 2017, 17:44:25
Was ich gerne hätte bzw. ich mir mal basteln wollte ist eine höhere Frequenz für den hping3 bei Abwesenheit (da ist mir der Akku ja egal weil da der hping3 ja nicht wirkt ;)  ), dann sollte schnell die echte Anwesenheit erkannt werden wenn ich wieder zurück komme.
Sicher, wenn du nicht da bist, ist die Häufigkeit egal, weil der Akku ja auch nicht da ist  ;D  genau das meine ich ja...wenn du nicht da bist, greift doch erst die lange Zeit für die Abfrage  :-\

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