Anwesenheitskontrolle per Wlan Ping und Android 6

Begonnen von Steffmaster, 09 Februar 2016, 09:01:08

Vorheriges Thema - Nächstes Thema

Marlen

Hallo,

naja, also Bluetooth is somit bei mir auch raus! Dafür muss ich zu viel Fläche abdecken!

Dann bleibt noch Geofancy!

Kann man mit der Gefancy App Telegram-Nachrichten verschicken? Das Gehrt doch irgendwie mit einer URL!?

LG Marlen

Snuggle

#46
Hallo Leute,

Anwesenheitserkennung in einem 1 Personenhaushalt mal anders.
Ich habe an der Eingangstüre einen Tür/Fensterkontakt und in den meisten Zimmern einen Bew.-Melder.
Einen Dummy speichert den Anwesenheitsstatus.
Komme ich nun nach Hause werde ich nicht im Flur übernachten, sondern betrete ein Zimmer mit Bew.-Melder und schon bin ich anwesend.
Verlasse ich die Wohnung meldet der Türkontakt "Achtung" weiter passiert noch nichts.
Damit die Bude nicht direkt runterfährt.
Sollte nun innerhalb von 5 Min. (Watchdog) keine Bewegung an den Bew.Meldern stattfinden geht der Status auf abwesend. Fertig. Evtl. ausbaufähig auf mehrere Personen.

Prof. Dr. Peter Henning

Leider unbrauchbar.

Wenn man sich nämlich in der Tür entscheidet, doch nicht ins Zimmer zu gehen (z.B. weil man etwas vergessen hat), ist das System ausgetrickst.

Um das zu vermeiden, müsste man also sein Verhalten reproduzierbar an die Maschine anpassen.

In den "SmartHome Hacks" habe ich verschiedene Projekte beschieben, mit denen man z.B. die Anwesenheitserkennung für Katzen machen könnte. Auch da scheitert die "einfache" Kontrolle an dem genannten Problem.

Nach dem aktuellen Stand derForschung müssen für eine sichere Anwesenheitserkennung unterschiedliche Techniken kombiniert werden.

LG

pah

Snuggle

#48
Es funktioniert doch, egal wie du dich entscheidest. Erst wenn die Eingangstüre geschlossen wird, wird nach 5 Minuten (watchdog) auf Abwesend gestellt. Ansonsten wird jeder Bew-Melder sofort die Anwesenheit schalten, oder den watchdog abbrechen mit entsprechendem Befehl.
Simpel und von mir schon seit langem so in Betrieb
PS: Die Bew.-Melder sind in den Räumen, nicht im Flur

marvin78

Zitat von: Otto123 am 04 Dezember 2016, 11:06:34
also wie schon 100 fach erwähnt: das WLAN Verhalten der modernen Systeme (egal ob Android oder IOS) ist kein Bug sondern ein Feature.

Nicht ganz. Wenn unter Android nicht eine Einstellung vorhanden wäre, mit der ein User das Verhalten steuern können soll, würde ich dir zustimmen. In der in Android 6 vorhandenen Form ist es klar ein Bug, auch wenn er sich nach Stand der Technik nicht verhindern lässt.

Otto123

Zitat von: marvin78 am 05 Dezember 2016, 15:52:40
Nicht ganz. Wenn unter Android nicht eine Einstellung vorhanden wäre, mit der ein User das Verhalten steuern können soll, würde ich dir zustimmen. In der in Android 6 vorhandenen Form ist es klar ein Bug, auch wenn er sich nach Stand der Technik nicht verhindern lässt.
Naja und wir können uns alle auf den Kopf stellen und zwischen jeder Zehe ein anderes Smartphone hochhalten - wir werden daran nichts ändern. Sowohl bei Android als auch bei IOS ist das Verhalten nicht vorhersehbar.
Das nicht vorhersehbare Verhalten sehe ich klar als Feature!  :-X Es ist einfach so!

Wobei in meinem Umfeld alle Android und IOS Smartphones ein absolut klares Verhalten an den Tag legen. Auch mit allen Energiesparfeatures (die auch nachweislich mit längerer Akkulaufzeit wirken) sind alle stabil im Wlan registriert. Aber ich weiß eben auch, dass es völlig anders sein kann!

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Prof. Dr. Peter Henning

Kannst Du ein Foto machen lassen, wenn Du auf dem Kopf stehend zwischen jeder Zehe ein Smartphone hast ? Oder wenigstens ein Selfie ?

LG

pah

pula

#52
Stehe auch grad vor diesem Problem...
Zwei Android-Geräte (6.x), die nach etwa einer Stunde per ping nicht mehr ansprechbar sind...
Schlecht. Werde mal versuchen, mit Tasker stündlich ein Ping auf den Router abzusetzen. Hat das schon jemand versucht?
Hab grad was eigenartiges festgestellt: per nmap werden die Android-Geräte als up erkannt - obwohl sie nicht pingbar sind. Allerdings nur, wenn das nmap als root (unter debian) ausgeführt wird. Werde das mal weiter verfolgen....


Cheers,

Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

madjack84

Hallo zusammen,

hab die letzten Tage nmap mal ausprobiert. Leider finde ich keine Parameter mit denen ich zuverlässig die Anwensenheit eines Android Phones erkennen kann.
Es sind wohl Port 2000 - 2002 offen aber egal mit welchem Parameter -Pn -sA -sT , etc. (https://wiki.ubuntuusers.de/nmap/) nichts ist zuverlässig. Ich pinge alle 10s in etwa aber immer wieder ist der Host mal nicht erreichbar. In der Fritzbox ist das Gerät aber IMMER vorhanden. Wie prüft AVM das?
Keine Ahnung was Android hier im Hintergrund verbricht....

Hat jmd eine funktionierende Option gefunden?

CoolTux

Ping hat nichts mit Portscan zu tun. Dein Handy meldet sich sicherlich an der Fritzbox per WLAN an. Daher weiß AVM das dein Handy da ist. Bedeutet aber noch nicht das es auch pingbar ist. Bekommt das Handy eine IP?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Otto123

Zitat von: madjack84 am 20 Dezember 2016, 12:35:19
Hallo zusammen,

hab die letzten Tage nmap mal ausprobiert. Leider finde ich keine Parameter mit denen ich zuverlässig die Anwensenheit eines Android Phones erkennen kann.
Es sind wohl Port 2000 - 2002 offen aber egal mit welchem Parameter -Pn -sA -sT , etc. (https://wiki.ubuntuusers.de/nmap/) nichts ist zuverlässig. Ich pinge alle 10s in etwa aber immer wieder ist der Host mal nicht erreichbar. In der Fritzbox ist das Gerät aber IMMER vorhanden. Wie prüft AVM das?
Keine Ahnung was Android hier im Hintergrund verbricht....

Hat jmd eine funktionierende Option gefunden?
Wenn Dein Handy mit der Fritzbox immer verbunden ist, dann nimm das FRITZBOX Modul und frage dort ab.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

pula

#56
Ich habs jetzt für mich (testweise) mal so gelöst:

Vorab: Ich weiß, daß es das nmap-Modul für fhem gibt, aber ich habe mein fhem nicht als root laufen und für die hier nötigen nmap-Funktionen muß nmap als root laufen....

Ein bash-script wird einmal in der Minute aufgerufen und liest per nmap den status von zwei Android-Handys aus (mittels nmap -sP 192.168.x.x). Das funktioniert zwar nicht zu hundert Prozent, weil immer wieder fehlerhaft gemeldet wird, daß ein host down ist, aber gut genug (weil ich per at einen 10 Minuten Puffer eingebaut habe, sh unten). Das bash-script erzeugt zwei Files in /tmp/, auf deren Vorhandensein dann fhem prüft (direkter Aufruf von fhem.pl mit Parametern funktioniert bei mir derzeit nicht, keine Ahnung wieso).

Es werden zwei Dummies in fhem befüllt und mittels Doif wird ein weiteres Dummy gesetzt, je nachdem, ob mindestens ein Gerät im Netz ist oder nicht.

Ein notify springt auf dieses generierte Dummy an und erzeugt ein um 10 Minuten zeitverzögertes at mit den eigentlich auszuführenden Befehlen, die ausgeführt werden sollen, wenn niemand mehr zu Hause ist. Vom gleichen notify wird das at wieder gelöscht, wenn sich der Status des Dummy innerhalb dieser 10 Minuten wieder auf anwesend ändert.

Ist ein wenig kompliziert, funktioniert aber anscheinend recht zuverlässig. Da ich derzeit noch in der Testphase bin, lasse ich mir von dem erzeugten at jeweils nur eine Telegram-Nachricht schicken. Bis jetzt hatte ich noch keine einzige "Fehlzündung" - und bin damit auch von Herstellern (Fritz) unabhängig....

Sollte sich ergeben, daß diese Mechanik Fehlzündungen liefert, werde ich hier berichten....

Cheers,

Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

madjack84

So einen Puffer hatte ich auch eingebaut und die Abfragezeiten je nach Zustand variiert. Auch das hat aber nicht zuverlässig funktioniert. Auch bei einem Threshold von 5 Abfragen kam der Counter Mehrfach auf 7 Versuche...

Ich nutze Android 7.1.1

Gestern habe ich dann python fritzconnection eingebaut (TR064).
Mein Log über Nacht sagt aber, dass nicht mal die Fritzbox zuverlässig die Anwesenheit bestimmen kann  :o Auch in absolut unregelmäßigen Zuständen bekomme ich Abrisse.... allerdings nur immer für einen Poll. Daher werde ich auch hier nun einen Puffer einbauen... nicht schön.

Mein Abfragezyklus ist 30s.

Jetzt gehen mir sonst leider etwas die Ideen aus...

JoeALLb

Hier habe ich noch eine gut funktionierende Methode beschrieben, geht abe rnur mit Routern die auch SNMP können.

Dadurch, dass selbst das ruhende Handy eine DHCP-Adresse zieht und den lease aktuell hält,
ist dies ziemlich zuverlässig.
https://forum.fhem.de/index.php/topic,57273.msg544306.html#msg544306
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

pula

@madjack: eigenartig. hat sich hier mit android 7 schon wieder was geändert? :-(
wäre toll, wenn du deine erkenntnisse hier teilen würdest...
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram