72_FRITZBOX.pm und checkFritzMACpresent - kein "inactive" mehr?

Begonnen von Pfriemler, 06 Dezember 2018, 20:09:49

Vorheriges Thema - Nächstes Thema

Pfriemler

Ich hänge mich mal lieber hier rein:

Auch ich habe seit dem letzten Update Probleme mit der Anwesenheitserkennung. Ich nutze aber noch gezwungenermaßen 6.83 (wegen der Updatepolitik von vodafone/KD - wie lange ist die 7 jetzt raus? ein Jahr) ...

Daher hier: kein Mesh etc, nur Abfrage der Hauptbox.

In meiner FRITZBOX-Definition halten sich diverse readings im Stil
mac_F4_09_D8_xx_xx_xx        RobertsS5 (WLAN, 0 / 0 Mbit/s, 0)
die das Modul FRITZBOX eigentlich "inactive" kennzeichnen und sogar rauswerfen sollte, was aber offenbar öfter nicht passiert, warum auch immer.

Dadurch aber wiederum erkennt die SUB checkFritzMACpresent (aus dem Wiki), die ich in meiner PRESENCE verwende, diese "Karteileichen" als anwesende Geräte. Manchmal sind sie dann doch weg, manchmal erscheinen sie spontan über den Tag wieder, auch wenn man weit auswärts war.

In der Fritzbox selbst sind die Geräte stets als nicht aktiv gelistet.
Insgesamt ist der Zustand damit derzeit unbefriedigend.

Any hints, folks?

edit: ich hatte bisher auch nur eine FRITZBOX-Instanz, mein Repeater ist nicht definiert. Mesh-Sideeffekts wie in    
Merkwürdiges Problem mit Fritzbox Anwesenheitserkennung
treffen daher nicht zu ...

2. edit: Ich habe jetzt den Repeater nachdefiniert und bei der Gelegenheit gleich mal auf 7.01 geupdatet.
Hier funktioniert die "inactive"-Methode einwandfrei. Muss also wohl mit der OS-Version zusammenhängen.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

LudgerR

zur Info

habe 72_FRITZBOX.pm und checkFritzMACpresent  in der letzten woche unter OS 6.88 mit einem UM Kabelmodem (FB_6490) getestet und habe heute nacht unerwartet meinen Update auf OS 7.01 von Unitymedia erhalten. Vor und nach dem update wurde die An- und Abmeldung der mac-adressen unmittelbar erkannt. Meine Befürchtung, dass sich etwas ändern könnte traten somit nicht ein.
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

Pfriemler

#2
Auf dem Repeater wird inactive nach wie vor einwandfrei gesetzt.
Ich beobachte, dass alle Geräte, die von der Box auf den Repeater wechseln, auf jeden Fall so lange mit der besagten "(WLAN, 0 / 0 Mbit/s, 0)" in der Fritzbox stehenbleiben, solange sie sich am Repeater befinden. Gehen sie vom Repeater ins Off, werden sie dort "inactive", bleiben aber [edit] in der Fritzbox dennoch weiter als "(WLAN, 0 / 0 Mbit/s, 0)" stehen.
Seltsamerweise habe ich das gerade mit meinem Handy getestet - und wie zum Fluch wird es jetzt auch in der Fritzbox "inactive". Na toll ...

Trotzdem: vorgestern war ich angeblich den ganzen Tag zu Hause, und vor drei Tagen meinte wohl auch die Fritzbox, dass ein anderer Bewohner bereits 20 Minuten vor seinem tatsächlichen Erscheinen mal zu Hause war. Diese Pseudoanwesenheiten dauern auch manchmal nur kurz.
Ich hätte noch VPN in Verdacht, weil ich das manchmal nutze, aber wo ich es gerade bewusst nutze (bei deaktivem WLAN natürlich), bleibt mein Handy "abwesend". Und der andere Bewohner nutzt VPN gar nicht.

Mittlerweile bin ich auf checkAllFritzMACpresent gewechselt und habe dort eine Suche nach " 0)" - dem Ende der o.g. Meldung - eingebaut.
Findet die Sub jetzt also eine solche Zeile, wird sie ebenso wie "inactive" oder der default "weg", wenn das mac_-Reading gar nicht mehr existert, ignoriert.
Mal schauen, ob es jetzt zuverlässiger wird...

sub checkAllFritzMACpresent($) {
# Benötigt: nur die zu suchende MAC ($MAC),
# Es werden alle Instanzen vom Type FRITZBOX abgefragt
#
# Rückgabe: 1 = Gerät gefunden
# 0 = Gerät nicht gefunden
my ($MAC) = @_;
# Wird in keiner Instanz die MAC Adresse gefunden bleibt der Status 0
my $Status = 0;
$MAC =~ tr/:/_/;
$MAC = "mac_".uc($MAC);
my @FBS = devspec2array("TYPE=FRITZBOX");
foreach( @FBS ) {
my $StatusFritz = ReadingsVal($_, $MAC, "weg");
if ($StatusFritz eq "weg") { # Reading existeriert nicht mehr
} elsif ($StatusFritz eq "inactive") { # durch das Modul 72_FRITZBOX.pm inaktiv gekennzeichnet
} elsif (index($StatusFritz, " 0)") != -1) { # als (WLAN, 0 / 0 Mbit/s, 0) geführt
} else { # Reading existiert, Rückgabewert ist nicht "inactive" bzw. (WLAN ... 0), also ist das Gerät am Netzwerk angemeldet.
$Status = 1;
}
}
return $Status
}


"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

LudgerR

Den Status

(WLAN, 0 / 0 Mbit/s, 0)

sollte man nicht mit "inactive"  gleichsetzen.

Ich habe zwei FBs im Haus, eine FB7390 im OG und eine FB6490 im EG.   Mit dem Modul FRITZBOX monitore ich den Kabelrouter FB6490.  Gehe ich ins OG, verbindet sich mein Smartphone mit dem WLAN im OG und unmitelbar darauf wechselt der Status auf

(WLAN, 0 / 0 Mbit/s, 0)

auf der FB6490.

Somit verwende ich 3 verschiedene Stati:

1) keine Mac  --> Bin außer Haus (bzw. WLAN am Smartphone ausgeschaltet)
2) (WLAN, 0 / 0 Mbit/s, 0)   --> Bin im OG
3) WLAN ohne "0" Werte      --> Bin im EG bzw. Keller

"inactive" taucht nur sehr kurzzeitig auf und deshalb werte ich es bisher nicht aus.
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

Pfriemler

#4
Die Frage ist,  warum Deine 6490 bei der 0-Meldung bleibt solange Du im OG angemeldet bist. Bei meinem Repeater ist das klar, die reden ja miteiinander. Bei ner zweiten Fritte als AP aber?

Fakt ist: meine 6490 behält die 0-Meldung noch Stunden nachdem das Gerät weg ist, auch vom Repeater.

Und die Geschosstrennung klappte bei mir noch nie. Ein Tablet im Wohnzimmer bleibt hartnäckig beim Repeater durch eine Geschossdecke, statt die nähere Fritzbox im gleichen Raum zu nehmen.

edit: Bis jetzt liefert meine Notlösung einen Bilderbuchverlauf in der Anwesenheit, keine Zacken mehr. Allerdings ist das Timeoff auch großzügig bei reichlich 5 Minuten. Das stört mich nicht.
Effektiv benutze ich eine Oder-Kombi aus WLAN-ping und Fritzbox: Der WLAN-ping erkennt ein zurückkehrendes Gerät meist schneller als die Fritzbox, die wiederum erkennt die Handys auch, wenn sie im Standby nicht mehr auf reguläre pings antworten.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

LudgerR

Die Geschossdecke  zwischen EG und OG  war bisher ein Fluch (alle 60cm ein Stahltrager in denen vorgefertigte Poroton/Bimsstein oder ähnliche Elemente eingelegt wurden).  Wegen diesem fahradäischen Käfig gibt es kaum befriedigende  Funkverbidungen  zwischen beiden Geschossen. Daher verwende ich die FB7390 im OG als DECT Repeater und als weiteren WLAN AP.  FB7390 und FB6490 sind per LAN verbunden. Bereits ohne Mesh (7390 unterstützt es leider nicht) wechseln meine Smartphones automatisch den AP, weil die Qualität des Funksignales so  :)stark differiert.

Diesmal beabsichtige ich diesen Fluch zu einem Feature zu machen.  :)
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

Pfriemler

#6
OT: 60 cm sind keine Hürde für WLAN und DECT. Es müsste ein Netz mit deutlich engeren Maschen sein (16 bzw. 12 cm), um das abzuschirmen. Eventuell ist in den Elementen was.
Hier tut eine Spannbetondecke Dienst, dort gibt es alle 20 cm einen ca 1 cm dicken Spannstab - der macht keinerlei Probleme.
In der Tat könnte auch ich hier mit etwas Aufwand so eine Kontrolle über den benutzten AP machen - in Deinem Fall würde ich es auch so tun.


"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

LudgerR

ZitatDie Frage ist,  warum Deine 6490 bei der 0-Meldung bleibt solange Du im OG angemeldet bist. Bei meinem Repeater ist das klar, die reden ja miteiinander. Bei ner zweiten Fritte als AP aber?

Die FB7390 im OG  ist per LAN-Kabel mit der 6490 im EG verbunden und reden somit auch intensivst miteinander. Alle WLAN Verbindungen  die über der 7390 werden auf der 6490 mit " WLAN 0 / 0 Mbits 0"  angezeigt und zwar nur so lange wie sie aktiv sind.  Ich habe die events gemonitort und tatsächlich innerhalb von 3 Minuten wird der Wechsel von OG auf EG und vice versa und die Deaktivierung des Wlan-Netzwerkes auf dem Smartphone (auch im OG) zuverlässig (bisher) gemeldet. Das Interval bei dem FRITZBOX modul habe ich dabei auf 60 sec gesetzt.
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

willib

Ich habe das Problem nun auch bei mir Festgestellt.
Die Mac Readings der Fritzbox entsprechen nicht oder nur unzuverlässig  den Angaben in der FritzBox Benutzeroberfläche. Somit ist meine Anwesenheitserkennung Murks.
Interessanterweise kann ich die Anzeige der korrekten mac Adressen provozieren wenn ich mich auf der Box einlogge um die verbundenen Geräte zu prüfen.
Ich verwende eine 7590 mit Fritz OS 7.01 als Router und Modem und nochmal das Gleiche als Repeater.
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

Jamo

Seit der gestrigen AVM Labor Version FRITZ!OS 7.08-66527/66525, funktioniert die WLAN An-/Abwesenheitserkennung schnell und zuverlässig.
Wo früher evtl 15 Minuten vergingen, bis ein Wlan Gerät als abgemeldet erkannt wurde, ändern sich entsprechende Readings in der Fritzbox jetzt mit der Labor von gestern, innerhalb 2 - 6 Minuten.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

willib

Das ist ja interessant.
Steht dazu was im changelog?
Ich würde lieber warten bis der patch? in der offizellen firmware landet. Trau mich ans labor nicht recht ran.
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD