[gelöst?] Anwesenheitserkennung via WLAN (Fritzbox und DD-WRT-Access-Point)

Begonnen von Beta-User, 06 September 2018, 12:27:16

Vorheriges Thema - Nächstes Thema

Beta-User

 Hallo zusammen,

ich habe ein Problem, das ähnlich wie das: Anwesenheit von MAC-Adresse im Netz per notify geht nicht per FRITZBOX, allerdings ist die direkte Verbindung mit der Fritzbox per WLAN nicht das eigentliche Problem (da scheint es zu funktionieren).

Folgende Konstellation:
- Fritzbox (7490 mit aktueller firmware, 6.93) mit eingerichteten FBAHAHTTP, fungiert auch als WLAN-AP;
- ein anderer Router mit DD-WRT spannt ein weiteres WLAN auf, dessen firmware habe ich jüngst auf 3.irgendwas upgedatet, nachdem ich dieses Problem hier festgestellt habe; das Teil steht auf AP-Mode, DHCP ist ausgeschaltet, die Fritte ist damit der einzige DHCP-Server im Netz.
Ein V7-Android Handy soll als anwesend erkannt werden. Auf der Fritte funktioniert das ohne weiteres wie im Wiki (https://wiki.fhem.de/wiki/FRITZBOX#Anwesenheitserkennung_per_Notify) dargestellt.

"Leider" ist der AP des DD-WRT-Routers besser, was dazu führt, dass sich das Handy oft mit diesem verbindet. Soweit so beabsichtigt.

Das eigentliche Problem:
Das Gerät verschwindet beim Ummelden auf der Fritte, ohne dass es ein anderes Reading am FBAHAHTTP-Device zu geben scheint, das man noch auswerten könnte.
Auch im Webinterface der Fritzbox ist der Androide in der Netzwerkübersicht nicht da, selbst wenn er über den anderen Router offensichtlich eine Verbindung ins Internet über die Fritzbox aufbaut. Dasselbe gilt übrigens auch für mein Linux-Notebook. Allerdings zeigt die Fritte _nicht alle_ vorhandenen Geräte, die über den DD-WRT laufen _nicht_ an: der MapleCUN wird sauber angezeigt...

Kann natürlich sein, dass irgendwas an dem DD-WRT verkonfiguriert ist, aber irgendwie werde ich den Verdacht nicht los, dass es an der Fritzbox hängt.

Hat jemand ähnliche Probleme oder eine Idee, an was ich drehen sollte? Einfach "auf Verdacht" Presence nutzen und einen LAN-Ping machen? (Ich vermute, der Androide legt sich schlafen, und meine Akkulaufzeit wollte ich eigentlich nicht absichtlich reduzieren)...

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tupol

Ich glaube nicht, dass die Fritz-Box weiß, mit wem irgendwelche systemfremde Router verbunden sind. Da gibt es vermutlich nur eine AVM interne Kommunikation.

Ping ist das einzig mögliche, das mir einfällt. Sollte aber nicht zu leeren Akkus führen. Entweder ist WLAN verbunden oder nicht.

Beta-User

Danke für die Antwort.

Vielleicht bin ich wirklich mit dem Gedanken auf dem Holzweg, dass der DD-WRT ja die MAC-Adresse an die Fritte weitergeben müßte, um DHCP-Requests auszuführen und die deswegen auch wissen müßte, wer sonst noch so alles grade 'ne IP im Netz hat. Und es erklärt nicht, warum der MapleCUN als verbundenes Gerät angezeigt wird, schön mit dem Hinweis, dass die Verbindung über die IP des an LAN2 der Fritte hängenden DD-WRT läuft.

Na jedenfalls kommt die Fritte als erstes mal testweise an einen der "normalen" LAN-Anschlüsse am DD-WRT. Die hängt bisher am WAN-Port. Vielleicht macht das ja einen Unterschied? Der WAN-Port bekommt wohl eine Sonderbehandlung, die mich bisher nicht so interessiert hatte, da es bislang nur darum ging, die LAN- und WLAN-Clients ins interne Netz zu bekommen bzw. teilweise ins Inet; das ging und geht soweit ??? .

Eigentlich nicht meine primäre Baustelle grad, aber was soll's...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

ich habe eine squeezebox boom (internetradio?) über wlan an meiner 7490. die boom stellt weiterhin ein lan anschluss bereit, an welchem ich ein smart-tv betreibe.

im fritzbox modul habe ich dadurch 2 readings mit mac adressen. ein "normales" mac_wlan reading der boom und ein 2. für den tv. hier stehen aber keine verbindungsdaten im reading, nur der name des tv.

im prinzip ja ein ähnlicher aufbau.
nur mal so als info.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
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
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Hmm, Danke für die Rückmeldung.

Im Moment beschäftige ich mich nebenbei mit dem Thema, und was ich sehe, ist noch blöder und hat eigentlich auch nichts mit der Kombination zu tun:

Im Netz hängen auch noch zwei Drucker. Die Weboberfläche von beiden ist erreichbar, sichtbar war aber in der Weboberfläche keiner. Nach dem Aufruf der Weboberfläche war einer der beiden nach einem Update da (nämlich der, der über die Fritzbox an LAN1 hängt).

Als Readings im Modul habe ich auch neben dem Drucker noch das Handy meiner Tochter gefunden; am WLAN der Fritte, sehr schön... Das war aber in der Weboberfläche gar nicht sichtbar.

Schlußfolgerung: Es ist nicht der DD-WRT, der Quer hängt; die ganze Methode scheint unbrauchbar zu sein, weil die Fritte nicht weiß, was sie tut?!?

Na ja, ist nicht so wichtig im Moment.

Aber interessant wäre schon, ob ihr alle zuverlässig alle im Netz hängenden Geräte als Readings ins Modul bekommt? Im Moment fehlen mir neben einem der Drucker 2-3 Handys, von denen eines eigentlich an der Fritte sein dürfte...

Während ich schreibe, ist wenigstens das Handy nach einem update da.?!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dtavb

Hoi,
ich habe keine fritte (süßes Wort  ;D ) sondern diverse andere Router und Konstellationen in letzten Jahren aufgebaut.
Allerdings war mir das Thema Presence dann alles zu kompliziert und "gebastelt" und habe dann kurzerhand presence genutzt (mit mehr oder weniger Problemchen...).

presence:
kannst natürlich mit Bluetooth oder lan-ping (icmp) schaffen, oder gar geofency wenn fhem aus WWW erreichbar ist.
Meine mal gelesen zu haben, dass iOS im sleep-mode keinerlei pings beantwortet, scheinbar macht das ein android oder Hersteller-Rom jetzt auch?
Eventuell kannst Du unter settings oder im dev-mode von android mal schauen ob Du einen Schalter findest: "wifi always on".
In der Tat dürfte aber mit neueren androids (8.1 und 9) die Option auf icmp so oder so verschwinden. Es ändert sich soviel ich mal gelesen habe die sleep und notifications-Abhandlung hin zu Zeitslots und zentraler Wachsteuerung durch das OS um Akku zu sparen.
ich habe dann bluetooth in presence genutzt, nachdem mein geofency-zeugs nach einiger Zeit auf dem Smartphone regelmässig aussteigt und es nicht mehr schafft Standorte und Zonen zu melden.
Bluetooth funktioniert super, vorausgesetzt Dein Telefon lässt sich entdecken. Mein neuestes Spieltelefon leider nicht...weshalb ich jetzt im Geldbeutel einen kleinen "Nut" habe.

dhcp oder ARP/snmp:
Dein DHCP-Server ist ja immer online und wach und kann gefragt werden ob Dein Gerät zumindest sich seit letzter Lease-Vergabe gemeldet hat, gibt direkt snmp MIBs dafür :)
Allerdings sind dann die dhcp-leases mit 86000 Sekunden etwas hinderlich...womit Lease-Zeiten von Minuten via DHCP im Netzwerk eigentlich keinen Sinn machen, bzw. dann evt. sleep-mode von Smartphones permanent unterbrechen, weil es non-stop damit beschäftigt ist seine IP zu erneuern. Also ist die Variante von mir nur am Anfang gut, bei etwas tieferer Betrachtung eher Mist.
Ganz allgemein die ARP-Table von einem Gerät im Netz via SNMP abfragen, vorzugsweise den Router, vielleicht auch den AP oder die Firewall...vermutlich ist das die beste Variante. ARP ist kurzlebig und jedes Netzgerät schreit im Netz rum, so dass eine "Presence" festgestellt werden kann.

Es gäbe ja noch weitere Varianten:
- DNS (wenn Du einen eigenen kleinen DNS-Server hast, vllt. pihole) Querys werden ja von (fast) jedem Telefon oder Gerät am laufenden Band abgeballert. Setzt aber scripting-Kenntnisse voraus.


Das Presence-Modul ist eine eigene Welt/Abteilung in fhem :)
Die anderen Varianten kosten eigene Entwicklungen (vllt. gibts auch copy&past im Netz, gerade für dd-wrt ARP-Tables und SNMP)


Wenn die Fritte aber DHCP-Server ist und der AP mit dd-wrt nur die Layer1&2 Verbindung abhandelt, müsste doch auf jeden Fall auf der Fritzbox eine Spur zu finden sein?

Grüsse,
dtavb
fhem:pi3&kvm, z-wave, it-funk, milight, zigbee, wifi, bt & presence, geo-tracking, alexa, esp.
Monitoring: ELK(syslog), grafana (grafik), netdata (ermittlung)
Security: haproxy (access), ossec (überall), snort (access), opnsense (fw)
Geplant: KVM-Cluster

Otto123

Hi,

die Fritzbox ist ein Blackbox, man weiß nicht genau was sie tut. Warum nimmst Du nicht deinen besseren DD-Wrt und machst den zum DHCP Server? Bei dem weißt Du nämlich was er tut.

Ich habe das so gemacht, Ich habe zwei Fritzboxen die sind nur DSL Modem und Telefonanlage, dahinter ein OpenWrt Router der mir das Netzwerk "macht" und das macht der wirklich prima. Der weiß innerhalb von Sekunden welcher Wlan Client verbunden und wieder abgemeldet ist.
Ja, damit ist das Fritzbox Modul raus aus der Nummer, und ein OpenWrt (DD-Wrt) Modul gibt es nicht. Aber das ist lösbar.

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

Beta-User

Moin,

Danke für die Rückmeldungen.

Vorab: eigentlich ging es "nur mal schnell" darum, meine "Bewohner" im Rahmen der Tests für das neue AutoShuttersControl-Modul etwas "intelligenter" zu machen. Deswegen die ganze Infrastruktur umzubauen, ist mir doch im Moment etwas too much, zumal das derzeitige setup ja - abgesehen von der Tauglichkeit für die Anwesenheitserkennung - soweit funktioniert...

Die Fritzkotz (gibt es eigentlich noch mehr gängige Bezeichnungen für diese Dinger?) wäre halt samt Modul vorhanden gewesen, das machte diese Variante - unabhängig von allem anderen - als schnelle Lösung attraktiv. Aber wenn das Teil halt nicht tut, was man von ihm erwartet (und es nicht an irgendwelchen Einstelloptionen liegt, die ich übersehen habe), ist das halt so :( .

Dann werde ich das Thema erst mal zurückstellen bzw. mit den stochastischen Ergebnissen leben; ich habe hier auch noch NFC-Kartenleser für MySensors rumliegen usw., und Bluetooth wäre sicher auch eine Lösung, auch wenn ich nicht weiß, ob das für unsere Hardware  und Nutzungsgewohnheiten jeweils eine gute Lösung wäre.

Schönes WE zusammen,
Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Nachtrag: Habe eben ein Update der FB-firmware auf 7.01 durchgeführt.

Zumindest kurzfristig erscheinen die über den DD-WRT angeschlossenen Geräte _alle_ (auch die über WLAN) in der Netzwerkübersicht (als am LAN des DD-WRT angeschlossen)... Damit werden auch Events erzeugt.

Bin mal gespannt, ob das so bleibt bzw. ob ich jetzt "zu viele" Events bekomme ??? .

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files