Zitat von: Wuehler am 16 Oktober 2020, 20:09:24
Ich schlage vor, daraus einen eigenen Thread zu machen. Bitte postet dort folgende Infos um zu schauen, wo es eine Gemeinsamkeit gibt:
- fehlerhaftes Endgerät (iPhone SE, ...)
- Versionen UnifiModul, UnifiController (UC)
- wo läuft der UC? RasPi, CloudKey, UDM, ...
- Schilderung des fehlerhaften Verhaltens
- was euch sonst noch auffällt/einfällt
Moinsen,
hier nun der eigene Thread. Ich nutze das Unifi Modul mittlerweile schon mehrere Jahre. Bisher gab es noch nie Probleme damit!
Endgeräte
- iPhone XR (rr_Mann)
- iPhone XS (rr_Frau)
Derzeitig: iOS 13.7 --> Werde gleich mal das Update auf iOS 14.1 machen.
Versionen UnifiModul, UnifiController (UC)74_Unifi.pm 19989 2019-08-12 18:25:21Z wuehler
74_UnifiClient.pm 19989 2019-08-12 18:25:21Z wuehler
74_UnifiSwitch.pm 21942 2020-05-14 19:28:57Z wuehlerIch werde im Anschluss gleich mal mein FHEM aktualisieren. Habe gerade gesehen, dass es Änderungen am Unifi Modul gab.
Mittlerweile bin ich auf Controller Version 6.0.23, habe aber sehr lange die LTS Version genutzt.
Wo läuft der UC? RasPi, CloudKey, UDM, ...Der Controller läuft auf einem Debian Stretch in einem Docker Container:
:~# uname -a
Linux omv4 4.19.0-0.bpo.9-amd64 #1 SMP Debian 4.19.118-2+deb10u1~bpo9+1 (2020-06-09) x86_64 GNU/LinuxEs ist alles-up-to-date, wenn man mal davon absieht, dass es sich um Stretch handelt und nicht um Buster.
Schilderung des fehlerhaften VerhaltensIch weiß nicht genau seit wann es so ist, aber wenn ich in meine Logfiles schaue, sehe ich ständige Statusänderungen an meinen Residents. Die beiden Residents sind mit unseren Smartphones verknüpft.
2020.10.14 14:17:55 2: ROOMMATE set rr_Frau absent
2020.10.14 14:18:26 2: ROOMMATE set rr_Frau home
2020.10.14 14:19:58 2: ROOMMATE set rr_Frau absent
2020.10.14 14:20:59 2: ROOMMATE set rr_Frau home
2020.10.14 14:26:36 2: ROOMMATE set rr_Frau absent
2020.10.14 14:30:42 2: ROOMMATE set rr_Frau home
2020.10.14 14:35:17 2: ROOMMATE set rr_Mann absent
2020.10.14 14:36:19 2: ROOMMATE set rr_Frau absent
2020.10.14 14:37:51 2: ROOMMATE set rr_Mann home
2020.10.14 17:15:07 2: ROOMMATE set rr_Mann absent
2020.10.14 17:15:38 2: ROOMMATE set rr_Mann home
2020.10.14 17:17:10 2: ROOMMATE set rr_Mann absent
2020.10.14 17:18:41 2: ROOMMATE set rr_Mann home
2020.10.14 17:20:13 2: ROOMMATE set rr_Mann absent
2020.10.14 17:20:44 2: ROOMMATE set rr_Mann home
2020.10.14 17:26:21 2: ROOMMATE set rr_Mann absent
2020.10.14 17:27:22 2: ROOMMATE set rr_Mann home
2020.10.14 17:31:27 2: ROOMMATE set rr_Mann absent
2020.10.14 17:31:58 2: ROOMMATE set rr_Mann home
2020.10.14 18:29:40 2: ROOMMATE set rr_Mann absent
2020.10.14 18:30:10 2: ROOMMATE set rr_Mann home
2020.10.14 18:37:19 2: ROOMMATE set rr_Mann absent
2020.10.14 18:37:50 2: ROOMMATE set rr_Mann home
2020.10.14 18:38:21 2: ROOMMATE set rr_Mann absent
2020.10.14 18:38:51 2: ROOMMATE set rr_Mann home
2020.10.14 18:40:54 2: ROOMMATE set rr_Mann absent
2020.10.14 18:41:25 2: ROOMMATE set rr_Mann home
2020.10.14 18:48:34 2: ROOMMATE set rr_Mann absent
2020.10.14 18:49:36 2: ROOMMATE set rr_Mann home
2020.10.14 18:51:38 2: ROOMMATE set rr_Mann absent
2020.10.14 18:52:40 2: ROOMMATE set rr_Mann home
2020.10.14 18:53:10 2: ROOMMATE set rr_Mann absent
2020.10.14 18:53:41 2: ROOMMATE set rr_Mann home
2020.10.14 19:00:19 2: ROOMMATE set rr_Mann absent
2020.10.14 19:00:50 2: ROOMMATE set rr_Frau home
2020.10.14 19:01:21 2: ROOMMATE set rr_Mann home
2020.10.14 19:01:51 2: ROOMMATE set rr_Mann absent
2020.10.14 19:02:22 2: ROOMMATE set rr_Mann home
2020.10.14 19:04:55 2: ROOMMATE set rr_Mann absent
2020.10.14 19:05:26 2: ROOMMATE set rr_Mann home
2020.10.14 19:25:22 2: ROOMMATE set rr_Mann absent
2020.10.14 19:25:53 2: ROOMMATE set rr_Mann home
2020.10.14 20:07:48 2: ROOMMATE set rr_Frau absent
2020.10.14 20:08:19 2: ROOMMATE set rr_Frau home
2020.10.14 20:12:24 2: ROOMMATE set rr_Mann absent
2020.10.14 20:13:56 2: ROOMMATE set rr_Mann home
2020.10.14 20:43:35 2: ROOMMATE set rr_Mann absent
2020.10.14 20:44:06 2: ROOMMATE set rr_Mann home
2020.10.14 20:59:56 2: ROOMMATE set rr_Mann absent
2020.10.14 21:00:27 2: ROOMMATE set rr_Mann home
2020.10.14 21:06:35 2: ROOMMATE set rr_Mann absent
2020.10.14 21:07:06 2: ROOMMATE set rr_Mann home
2020.10.14 21:16:18 2: ROOMMATE set rr_Mann absent
2020.10.14 21:16:48 2: ROOMMATE set rr_Mann home
2020.10.14 22:01:16 2: ROOMMATE set rr_Mann absent
2020.10.14 22:01:47 2: ROOMMATE set rr_Mann home
2020.10.14 22:09:57 2: ROOMMATE set rr_Mann absent
2020.10.14 22:10:28 2: ROOMMATE set rr_Mann home
2020.10.14 22:15:04 2: ROOMMATE set rr_Frau absent
2020.10.14 22:15:35 2: ROOMMATE set rr_Frau home
2020.10.14 22:17:07 2: ROOMMATE set rr_Frau absent
2020.10.14 22:17:37 2: ROOMMATE set rr_Frau home
2020.10.14 22:25:17 2: ROOMMATE set rr_Mann absent
2020.10.14 22:25:48 2: ROOMMATE set rr_Mann home
2020.10.14 22:27:20 2: ROOMMATE set rr_Frau absent
2020.10.14 22:37:02 2: ROOMMATE set rr_Frau home
2020.10.14 22:43:41 2: ROOMMATE set rr_Frau absent
2020.10.14 22:46:45 2: ROOMMATE set rr_Mann absent
2020.10.14 22:47:15 2: ROOMMATE set rr_Mann home
2020.10.14 22:53:54 2: ROOMMATE set rr_Mann absent
2020.10.14 22:54:25 2: ROOMMATE set rr_Mann homeWoran kann das liegen?
Ich habe die Vermutung, dass jeder Wechsel zw. 2.4GHz und 5GHz zu einem kurzzeitigen "absent" führt.
Die Definition meines Controllers sieht wie folgt aus:
define UnifiController Unifi localhost 8443 username password 30 defaultDie Definition für eins meiner Smartphones sieht wie folgt aus:
define Mann_iPhone_XR_WLAN PRESENCE event UnifiController:Mann-iPhone-XR:.disconnected UnifiController:Mann-iPhone-XR:.connectedDie Definition eines Residents sieht wie folgt aus:
define rr_Mann ROOMMATE Bewohner
attr rr_Mann rr_presenceDevices Mann_iPhone_XR_WLANFrüher wurden Geräte erst 5 Minuten nachdem Sie das WLAN verlassen haben auf disconnected bzw. Residents auf absent gesetzt.
Kann ich irgendwo angeben, nach wieviel Sekunden/Minuten eine Statusänderung übernommen werden soll? Hat hier noch jemand das Problem? Wie kann man das lösen?
Danke und Gruß Hoppel
Folgenden Post habe ich im Hauptthread für das Unifi Modul gefunden:
Zitat von: Wuehler am 15 September 2020, 14:18:59
Hallo H-man,
ich kann mich dunkel daran erinnern, dass irgendjemand schon mal so ein Problem hatte. Lösung war glaube ich, dass es die Mac oder client im Unifi-Controller zwei mal gab. Musst du mal unter Insights suchen und den falschen löschen.
Ggf. zusätzlich mal ein clear all im Modul.
VG,
Dirk
Habe unter Insights aufgeräumt. Es gibt nun keine veralteten Einträge mehr. "clear all" habe ich auch ausgeführt. Beides bringt nichts.
Weitere Ideen?
Gruß Hoppel
So, habe FHEM gerade aktualisiert und nutze nun folgende Unifi Modul Version:
74_Unifi.pm 22962 2020-10-13 05:56:28Z wuehler
74_UnifiClient.pm 19989 2019-08-12 18:25:21Z wuehler
74_UnifiSwitch.pm 22962 2020-10-13 05:56:28Z wuehler
Vielleicht bringt das ja schon was. Das iOS Update läuft ebenfalls gerade. Ich melde mich später wieder.
Gruß Hoppel
Wenn Du auf IOS14.x updatest, dann hast Du noch ein weiteres Problem. Da wird default mäßig die MAC Adresse verändert um ein Tracking zu verhindern. Das kann man aber gezielt abschalten in den settings zu jeder SSID in den Einstellungen. Hatte nach dem Update Stress mit meiner Anwesenheitserkennung.
Wird bei Unify nicht anders sein....
Hast Du es mal mit einem UnifiClient versucht anstelle des Presence?
Einfach en UnifiClient anlegen, falls Du ein "presence" reading benötigst geht das easy über ein Userreading.
Hier eine Beispiel Definition meines Handys:
defmod Presence_Frank_UniFi UnifiClient Handy-Frank_Doogee-S88
attr Presence_Frank_UniFi event-on-change-reading .*
attr Presence_Frank_UniFi stateFormat {ReadingsVal($name,"presence","absent") eq "absent" ? "absent since ".ReadingsVal($name,"_f_last_seen","") : "present since ".ReadingsVal($name,"_f_uptime","")}
attr Presence_Frank_UniFi userReadings presence:fhem_state.* {(ReadingsVal($name,'fhem_state','disconnected') eq 'disconnected' ? 'absent' : 'present') }
Zitat von: mbrak am 21 Oktober 2020, 12:27:28
Wenn Du auf IOS14.x updatest, dann hast Du noch ein weiteres Problem. Da wird default mäßig die MAC Adresse verändert um ein Tracking zu verhindern. Das kann man aber gezielt abschalten in den settings zu jeder SSID in den Einstellungen. Hatte nach dem Update Stress mit meiner Anwesenheitserkennung.
Wird bei Unify nicht anders sein....
Danke für den Hinweis. Tatsächlich kann man nun bei jeder SSID eine "Private WLAN-Adresse" konfigurieren bzw. die Funktion ein- und abschalten.
Für meine Haupt-SSID ist die MAC gleich geblieben. Das kann also grundsätzlich erstmal keine Probleme bereiten. Ich werde die "Private WLAN-Adresse" für meine 4 SSIDs hier zu Hause aber deaktivieren, um Probleme damit zu vermeiden.
Zitat von: Frank_Huber am 21 Oktober 2020, 12:57:41
Hast Du es mal mit einem UnifiClient versucht anstelle des Presence?
Einfach en UnifiClient anlegen, falls Du ein "presence" reading benötigst geht das easy über ein Userreading.
Hier eine Beispiel Definition meines Handys:
...
Das probiere ich auf jeden Fall aus, wenn wir das mit Presence nicht gelöst bekommen.
Ich habe das gerade nochmal ein wenig analysiert. Es hängt mit dem "Roaming" zusammen. Ich bin gerade mal von meinem Wohnzimmer "AP-Name: wap-living" in die Küche "AP-Name: wap-kittchen" gegangen und zurück.
In meinem FHEM logfile sehe ich folgendes:
2020.10.21 17:07:34 2: ROOMMATE set rr_Mann absent
2020.10.21 17:08:05 2: ROOMMATE set rr_Mann homeGleichzeitig sehe ich am Unifi Controller folgendes in den Ereignissen:
Mann-iPhone-XR hat die Verbindung mit SSID "Gallien" getrennt (war 11m verbunden, hat 23.3 MB übertragen, letzter AP wap-living) 5:06 pm 10/21/2020
Mann-iPhone-XR hat sich über AP wap-kittchen mit der SSID "Gallien" auf Kanal 6 verbunden. 5:06 pm 10/21/2020
Mann-iPhone-XR hat sich mit Gallien verbunden. 5:06 pm 10/21/2020
Mann-iPhone-XR wechselt von Kanal 6 auf Kanal 44 auf AP wap-kittchen 5:07 pm 10/21/2020
Mann-iPhone-XR hat die Verbindung mit SSID "Gallien" getrennt (war 0m verbunden, hat 47.9 KB übertragen, letzter AP wap-kittchen) 5:07 pm 10/21/2020
Mann-iPhone-XR hat sich über AP wap-living mit der SSID "Gallien" auf Kanal 44 verbunden. 5:07 pm 10/21/2020Die Fast Roaming Option ist in meiner Unifi WLAN Konfiguration deaktiviert.
Anscheinend wird jeder Access Point Wechsel vom Unifi Modul (und somit Presence Modul) gesehen und geloggt. Grundsätzlich ist das ja erstmal nicht falsch bzw. schlecht.
Aber kann man da so etwas wie ein DOIF wait einbauen, so dass bspw. erst nach einer Minute Abwesenheit eine Statusänderung geloggt wird?
Das müsste ja eigentlich reichen, da der AP-Wechsel üblicherweise nur ein paar Sekunden dauert.
Um 17:07 Uhr gab es auch noch einen Wechsel von Kanal 6 zu Kanal 44 auf AP wap-kittchen. Evtl. hängt es auch damit zusammen.
Was meint ihr?
Viele Grüße Hoppel
Genau genommen wertest du mit dem presence Events aus.
Beim Roaming verlässt und betrittst du das WLAN.
Zwar nur kurz, aber es reicht wohl aus.
Habe das über Events und unifi nie selbst versucht.
das problem sollte doch einfach mit attr absenseThreshold glöst werden können, oder?
Eigenich ja, die ganze Logik wird dadurch dann nur "langsamer"
Zwischen present und absent kommt dann das "maybe abyent"
Wäre aber auch nen Versuch wert.
Zitat von: Frank_Huber am 21 Oktober 2020, 19:57:17
Genau genommen wertest du mit dem presence Events aus.
Beim Roaming verlässt und betrittst du das WLAN.
Zwar nur kurz, aber es reicht wohl aus.
Habe das über Events und unifi nie selbst versucht.
Jo, sehe ich genauso. Laut "FHEM Wiki Presence" ist die Event Methode die bevorzugte: https://wiki.fhem.de/wiki/PRESENCE#.C3.9Cberwachen_mittels_Events
Zitat von: frank am 21 Oktober 2020, 20:10:55
das problem sollte doch einfach mit attr absenseThreshold glöst werden können, oder?
Wenn ich an meinen Geräten "absenseThreshold - 60" setzen möchte, erhalte ich folgende Meldung:
ZitatabsenceThreshold is not applicable for mode 'event'
Dort gibt es aber auch noch einen absenceTimeout. Diesen habe ich nun auf 60 Sekunden gesetzt.
Damit funktioniert es nun wieder wie früher. Super, danke euch!
Bin aber gerade am Überlegen, ob die von mir verwendete Variante wirklich die beste ist. Momentan dauert es ca. 7 Minuten bis das Presence-Device auf "absent" geht. Das Smartphone wird beim Verlassen noch an das Security Gateway übergeben, bevor es endgültig aus der Controller-Oberfläche verschwindet und somit auch das Presence-Device in den Status "absent" wechselt.
@Frank_Huber Wie lange dauert das bei der von dir aufgeführten UnifiClient Methode?
Bis hierhin auf jeden Fall schonmal ein dickes Danke. Ich hatte fest damit gerechnet, dass @Wuehler ran muss. :D
Viele Grüße Hoppel
Zitat von: hoppel118 am 21 Oktober 2020, 21:24:15@Frank_Huber Wie lange dauert das bei der von dir aufgeführten UnifiClient Methode?
Eben extra paarmal WLAN an und aus gemacht.
Jeweils geschätzt maximal 1min für den Statuswechsel.
Der Unifi Contoller ist mit 15sec angelegt.
Ok, danke für's Testen. Dann werde ich das morgen auch mal ausprobieren. Jetzt ist der PC schon aus.
Ich melde mich nochmal.
Schönen Abend noch
Konnte die Finger nun doch nicht mehr davon lassen... ;)
Zitat von: Frank_Huber am 21 Oktober 2020, 12:57:41
Hier eine Beispiel Definition meines Handys:
defmod Presence_Frank_UniFi UnifiClient Handy-Frank_Doogee-S88
attr Presence_Frank_UniFi event-on-change-reading .*
attr Presence_Frank_UniFi stateFormat {ReadingsVal($name,"presence","absent") eq "absent" ? "absent since ".ReadingsVal($name,"_f_last_seen","") : "present since ".ReadingsVal($name,"_f_uptime","")}
attr Presence_Frank_UniFi userReadings presence:fhem_state.* {(ReadingsVal($name,'fhem_state','disconnected') eq 'disconnected' ? 'absent' : 'present') }
WOW!!! Dieser UnifiClient scheint der Hammer zu sein. Beim "Roamen" zwischen den APs bleibt mein Roommate im Status "home". Wenn ich WLAN am iPhone abschalte, wird kurz danach auch der Status "absent" am Roommate gesetzt. Coole Sache! :D
Eine Frage bleibt noch. Im Wiki wird ein anderes userReadings aufgeführt:
https://wiki.fhem.de/wiki/UnifiClient#Anwesenheitserkennung
attr <UnifiClientName> userReadings presence {((ReadingsVal("$name","is_wired","?") eq "true") ? "absent" : ((ReadingsVal("$name","fhem_state","?") eq "connected") ? "present":"absent"));;}Deins sieht wie folgt aus:
attr <UnifiClientName> userReadings presence:fhem_state.* {(ReadingsVal($name,'fhem_state','disconnected') eq 'disconnected' ? 'absent' : 'present') }Siehst du bei dem userReadings im Wiki irgendeinen Vorteil deinem userReadings gegenüber?
Ich habe jetzt erstmal deins in Betrieb.
Vielen Dank und Gruß Hoppel
Ich habe in einem anderen Thread bzgl. Unifi/UnifiClient mitbekommen, dass es (wohl mal) vorkommt/vorkommen kann, dass WLAN Clients beim "weggehen" auch mal fälschlicherweise als "wired" angezeigt werden...
Mit diesem userreadings fängst du auch diesen "Umstand" ab...
Ob das noch so ist: keine Ahnung.
ABER (generell): es ist ein (deutlicher) Unterschied, ob am Client WLAN abgeschaltet wird oder er einfach "weg" ist...
Gruß, Joachim
EDIT: ich habe es mittlerweile aufgegeben mittels WLAN die Anwesenheit zu "regeln"... Ich habe auch so einiges versucht, u.a. auch den UnifiClient, hping3, ... Aber ich hatte u.a. im Sommer "Falschmeldungen" bzgl. offene Fenster, weil das Handy mal als "nicht da" erkannt wurde... Bin jetzt auf BT Gigaset G-Tags umgstiegen und seit dem: :)
Zitat von: hoppel118 am 21 Oktober 2020, 23:51:26
Eine Frage bleibt noch. Im Wiki wird ein anderes userReadings aufgeführt:
https://wiki.fhem.de/wiki/UnifiClient#Anwesenheitserkennung
attr <UnifiClientName> userReadings presence {((ReadingsVal("$name","is_wired","?") eq "true") ? "absent" : ((ReadingsVal("$name","fhem_state","?") eq "connected") ? "present":"absent"));;}
Deins sieht wie folgt aus:
attr <UnifiClientName> userReadings presence:fhem_state.* {(ReadingsVal($name,'fhem_state','disconnected') eq 'disconnected' ? 'absent' : 'present') }
Siehst du bei dem userReadings im Wiki irgendeinen Vorteil deinem userReadings gegenüber?
Ganz ehrlich, ich kannte das aus dem WIKI nicht. hab mir das gebastelt um das presence Reading zu bekommen. :-)
schaut aber aus als ob es das gleiche macht PLUS das "wired" abzufangen.
mir ist das wired Problem allerdings noch nicht untergekommen seit ich Unifi habe.
Und klar, Verlust vom Empfang und WLAN abschalten ist nicht das selbe, man kann aber dennoch die Reaktionszeit ganz gut damit abschätzen.
WLAN Anwesenheitserkennung lief bei mir knapp 4 Jahre über die Fritzbox, jetzt seit nem halben Jahr über Unifi.
Ich habe mit keinem davon Probleme gehabt.
Hallo in die Runde,
habe heute beide Varianten (Presence-Device und UnifiClient) nochmal ausführlich getestet. Leider funktionieren beide nicht.
Der Wechsel zw. zwei APs reicht meistens (nicht immer) aus, damit mein Resident kurz in den status "absent" wechselt und dann wieder in den Status "present".
Testfall -> Mein iPhone wechselt vom AP wap-living zum AP wap-kittchen und zurück, verwendet wird ein UnifiClient
Logfile Fhem:
2020.10.22 22:28:56 2: ROOMMATE set rr_Mann absent
2020.10.22 22:29:27 2: ROOMMATE set rr_Mann home
Ereignisse UnifiController:
Manns-iPhone-XR hat die Verbindung mit SSID "Gallien" getrennt (war 5m verbunden, hat 278 KB übertragen, letzter AP wap-living) 10:28 pm 10/22/2020
Manns-iPhone-XR hat sich über AP wap-kittchen mit der SSID "Gallien" auf Kanal 44 verbunden. 10:28 pm 10/22/2020
Manns-iPhone-XR hat die Verbindung mit SSID "Gallien" getrennt (war 1m verbunden, hat 56.4 KB übertragen, letzter AP wap-kittchen) 10:29 pm 10/22/2020
Manns-iPhone-XR hat sich über AP wap-living mit der SSID "Gallien" auf Kanal 44 verbunden. 10:29 pm 10/22/2020
Auch hier beim UnifiClient sehe ich nun das 31 Sekunden Problem. Das Reading "_f_uptime" wird beim Wechsel zw. 2 APs auf "0min 0sec" zurückgesetzt. Gestern Abend habe ich nur WLAN am iPhone ein- und ausgeschaltet. Dabei wird mein Resident nicht auf "absent" gesetzt.
@Frank_Huber Hast du einen oder mehrere APs? Du hattest ja gestern auch nur WLAN an- und abgeschaltet. Verwendest du das Residents Modul?
Das gleiche passiert auch, wenn ich ein Presence-Device (event) verwende. absenceTimeout funktioniert leider entgegen meiner Aussage gestern doch nicht. Wie eingangs erwähnt funktioniert das Presence-Device anscheinend nur manchmal.
@MadMax-FHEM Es hat nun mehrere Jahre ohne Probleme funktioniert. Ich schätze, dass das mit einem Update des UnifiControllers zusammenhängt.
Gibt es hier noch weitere Ideen?
@Wuehler Welche Logfiles brauchst du in welchem Loglevel, damit du dir das mal anschauen kannst?
Danke euch und viele Grüße Hoppel
Zitat von: hoppel118 am 22 Oktober 2020, 22:56:06
@Frank_Huber Hast du einen oder mehrere APs? Du hattest ja gestern auch nur WLAN an- und abgeschaltet. Verwendest du das Residents Modul?
Es werkeln hier drei NanoHD AccessPoints.
Das Residents Modul verwende ich nicht.
Weiter sind hier nur Androide im Einsatz, kein iOS.
Hi,
das Unifi-Modul loggt im Debug-Modus leider so viel, dass man das Problem nur durch langes draufsehen findet.
Bitte ändert mal in folgenden sechs Zeilen die ", 5," in eine ", 1,". Danach ein reload des Moduls und dann den Fehler nachstellen und das Log posten.
Das ist erstmal nur, um ein Gefühl dafür zu bekommen, was wann passiert. Danach können wir versuchen, den Fehler weiter einzugrenzen.
Zeile 838, 988, 1043, 1100 und 1486: Log3 $name, 5, "$name ($self) - executed.";
..
Zeile 1582: Log3 $name, 5, "$name ($self) - Client '$clientName' previously connected is now disconnected.";
Alternative: Aus der 5 eine 4 machen und verbose auf 4 stellen.
VG,
Dirk
Hi,
ich gehöre auch zu den Problemkindern.
Und folgendes ist das Ergebnis der Loglevelumstellung:
egrep 'executed.|Christian|dc_52_85_00_cc_20' fhem-2020-11-10.log
2020.11.10 08:20:23.047 1: UnifiController (Unifi_DoUpdate) - executed.
2020.11.10 08:20:23.128 1: UnifiController (Unifi_GetClientInsights_Receive) - executed.
2020.11.10 08:20:23.185 1: UnifiController (Unifi_GetClients_Receive) - executed.
2020.11.10 08:20:23.298 1: UnifiController (Unifi_SetClientReadings) - executed.
2020.11.10 08:20:53.800 1: UnifiController (Unifi_DoUpdate) - executed.
2020.11.10 08:20:53.909 1: UnifiController (Unifi_GetClients_Receive) - executed.
2020.11.10 08:20:53.972 1: UnifiController (Unifi_GetClientInsights_Receive) - executed.
2020.11.10 08:20:54.032 1: UnifiController (Unifi_SetClientReadings) - executed.
2020.11.10 08:20:54.064 1: UnifiController (Unifi_SetClientReadings) - Client 'dc_52_85_00_cc_20' previously connected is now disconnected.
2020.11.10 08:20:54.072 2: ROOMMATE set rr_Christian absent
2020.11.10 08:21:24.917 1: UnifiController (Unifi_DoUpdate) - executed.
2020.11.10 08:21:25.041 1: UnifiController (Unifi_GetClients_Receive) - executed.
2020.11.10 08:21:25.161 1: UnifiController (Unifi_GetClientInsights_Receive) - executed.
2020.11.10 08:21:25.188 1: UnifiController (Unifi_SetClientReadings) - executed.
2020.11.10 08:21:25.230 1: UnifiController (Unifi_SetClientReadings) - Client 'dc_52_85_00_cc_20' previously connected is now disconnected.
2020.11.10 08:21:55.692 1: UnifiController (Unifi_DoUpdate) - executed.
2020.11.10 08:21:55.833 1: UnifiController (Unifi_GetClients_Receive) - executed.
2020.11.10 08:21:55.883 1: UnifiController (Unifi_GetClientInsights_Receive) - executed.
2020.11.10 08:21:55.947 1: UnifiController (Unifi_SetClientReadings) - executed.
2020.11.10 08:21:55.979 1: UnifiController (Unifi_SetClientReadings) - Client 'dc_52_85_00_cc_20' previously connected is now disconnected.
2020.11.10 08:22:26.550 1: UnifiController (Unifi_DoUpdate) - executed.
2020.11.10 08:22:26.703 1: UnifiController (Unifi_GetClients_Receive) - executed.
2020.11.10 08:22:26.759 1: UnifiController (Unifi_GetClientInsights_Receive) - executed.
2020.11.10 08:22:26.818 1: UnifiController (Unifi_SetClientReadings) - executed.
2020.11.10 08:22:26.878 2: ROOMMATE set rr_Christian home
2020.11.10 08:22:57.359 1: UnifiController (Unifi_DoUpdate) - executed.
2020.11.10 08:22:57.393 1: UnifiController (Unifi_GetClients_Receive) - executed.
2020.11.10 08:22:57.522 1: UnifiController (Unifi_GetClientInsights_Receive) - executed.
2020.11.10 08:22:57.597 1: UnifiController (Unifi_SetClientReadings) - executed.
Das passiert beim wechseln der Etagen und damit auch den UAPs.
Hardware ist ein iPhone 12 Pro und diverse AP-AC-PROs.
Wollen Sie mehr wissen? :)
LG
Christian
Hi,
ich hab' mir das ganze jetzt nochmal weiter angeschaut.
Folgendes ist mir aufgefallen:
* Wenn das iPhone auf disconnected wechselt, ist es tatsächlich nicht im reply ($data) von Unifi_GetClients_Receive() enthalten, die Liste ist ansonsten aber lang
* Mein Unifi Controller zeigt in der "History" für mein iPhone sowohl Einträge mit langer als auch mit kurzer Verbindungsdauer, aber insbesondere jetzt beim letzten 'disconnected' in fhem zeigt er eine durchgehende Verbindung über 34 Minuten an: '12.11.2020 15:42 34m 7s 680 KB 820 KB'
* Das 'disconnected' wurde zeitgleich auf meinem produktiven fhem und meinem dev-fhem angezeigt, es scheint also kein 'verschlucker' zu sein.
LG
Christian
Hi Zusammen,
ich grabe den Thread mal wieder aus, da ich heute festgestellt habe, dass mein iPhone XR (meine Vermutung nach dem letzten iOS Update auf 14.3) ebenfalls ständig in ROOMMATE von home auf absent springt. Das iPhone SE meiner Frau macht keine Probleme. Da ist das Update auch noch nicht installiert:
2021.01.14 17:08:48 2: ROOMMATE set rr_sTaN home
2021.01.14 15:37:50 2: ROOMMATE set rr_sTaN absent
2021.01.14 15:31:37 2: ROOMMATE set rr_sTaN home
2021.01.14 15:30:34 2: ROOMMATE set rr_sTaN absent
2021.01.14 15:29:31 2: ROOMMATE set rr_sTaN home
2021.01.14 15:27:26 2: ROOMMATE set rr_sTaN absent
2021.01.14 15:25:21 2: ROOMMATE set rr_sTaN home
2021.01.14 15:24:18 2: ROOMMATE set rr_sTaN absent
2021.01.14 15:18:02 2: ROOMMATE set rr_sTaN home
2021.01.14 15:15:57 2: ROOMMATE set rr_sTaN absent
2021.01.14 15:14:55 2: ROOMMATE set rr_sTaN home
2021.01.14 15:10:45 2: ROOMMATE set rr_sTaN absent
2021.01.14 15:09:43 2: ROOMMATE set rr_sTaN home
2021.01.14 15:08:40 2: ROOMMATE set rr_sTaN absent
Ich selbst nutze lediglich das Modul Unify und den Unify Controller auf einen RPi. Alles up to date. Auch nur einen AP-AC-PRO, der alle versorgt.
Das UnifiController Device aktualisiere ich alle 60 Sekunden und habe folgende Attribute gesetzt:
Attributes:
event-on-change-reading .*
group Systeme
icon radio_checked
room Wohnzimmer
Mein Presence Device sieht wie folgt aus:
Internals:
DEF event UnifiController:sTaNs-iPhone-XR:.disconnected UnifiController:sTaNs-iPhone-XR:.connected
EVENT_ABSENT UnifiController:sTaNs-iPhone-XR:.disconnected
EVENT_PRESENT UnifiController:sTaNs-iPhone-XR:.connected
FUUID 5XXXXXXXXXXXXXXXXXXXXXX
MODE event
NAME iPhone.sTaN
NOTIFYDEV UnifiController,global
NR 697
NTFY_ORDER 50-iPhone.sTaN
STATE present
TYPE PRESENCE
READINGS:
2021-01-12 21:53:34 model event
2021-01-14 17:35:48 presence present
2021-01-14 17:35:48 state present
helper:
CURRENT_STATE present
Attributes:
group Systeme
icon it_smartphone
room Residents,Wohnzimmer,Zentral
Bringt denn das Modul UnifiClient eine sinnvolle Verbesserung? Ich meine ich sehe zwar den Vorteil darin, lediglich über UnifiClient nur die benötigten Geräte anzulegen und in ROOMMATE zu verlinken, sowie das Update Intervall des Controllers sehr hoch zu setzen und nur die benötigten Geräte zu aktualisieren, weil es ja doch sehr gesprächig ist, aber gibt es hierzu weitere Erfahrungen oder ein Update zur Problematik?
Braucht es weitere Infos?
EDIT: Achso die Private WLAN Adresse im iPhone der SSID war zuvor immer aktiv! Habe ich jetzt mal deaktiviert.
Gruß
sTaN
Hallo sTaN,
ich kämpfe mit dem Thema nun auch schon seit 3 Monaten.
Leider hat bei mir weder das Abschalten des Private-WLAN-Schalter noch der Umweg über den Unifi-Client etwas gebracht.
Grundsätzlich ist das Problem auch nicht permanent nur temporär. Spannend ist aber das Phönomen gewesen, dass dieses oszillierende Verhalten letzte Woche passiert ist, wie das betroffene Presence Device mehr als 100 km vom WLAN entfernt war. Seitdem glüht mein Hirn, um mit dieser Info die Ursache einzugrenzen.
Es hätte ja dann definitiv nichts mit Wechsel des AP oder der Frequenzbänder zu tun. Ist damit also eher ein SW Bug durch einen Cache, oder oder...?
VG
Obelix
Ok....jetzt habe ich das ganze auf die Spitze getrieben....
Habe den Unifi-Controller HW-technisch heruntergefahren.
Der läuft bei mir auf einem separaten Raspi.
...und Ergebnis:
2021.01.23 09:36:43.337 2: ROOMMATE set rr_Valentina home
2021.01.23 09:36:43.792 2: ROOMMATE set rr_Valentina absent
2021.01.23 09:37:43.967 2: ROOMMATE set rr_Valentina home
2021.01.23 09:37:44.464 2: ROOMMATE set rr_Valentina absent
2021.01.23 09:38:40.805 2: ROOMMATE set rr_Valentina home
2021.01.23 09:38:41.331 2: ROOMMATE set rr_Valentina absent
2021.01.23 09:39:37.797 2: ROOMMATE set rr_Valentina home
2021.01.23 09:39:38.270 2: ROOMMATE set rr_Valentina absent
2021.01.23 09:40:34.671 2: ROOMMATE set rr_Valentina home
2021.01.23 09:40:35.171 2: ROOMMATE set rr_Valentina absent
Das heißt dieses Phänomen ist meinem Verständnis nach damit völlig unabhängig vom iPhone und vom Controller.
Hypothese:
- FHEM hat 2 Zustände zu ein und demselben Presence-Device gespeichert?
- oder der Primary-Key für Presence ist nicht eindeutig?
- oder...?
Kann jemand das Verhalten ggf. jemand verifizieren?
Spannend ist auch, dass in FHEM der Status zum beim Unifi-Controller nach 20 Min immer noch auf "connected" steht.
Die einzelnen Clients verabschieden sich sukzessive in den Status "disconnected", aber das oszillierende Verhalten des Presence-Devices geht weiter...
Habt Ihr Ideen, wie ich das Problem weiter eingrenzen kann?
VG
Obelix
Ok....
ich sehe mindestens 2 MAC-Adressen zu dem Presence-Device im Event log.
(der controller ist immer noch aus)
2021-01-23 10:08:03.421 UnifiClient Smartphone_Valentina mac: 4c:**:**:**.**.**
...
...
2021-01-23 10:08:03.937 UnifiClient Smartphone_Valentina mac: 92:**.**.**.**.**
Wie kann ich diese Referenz in der FHEM-DB reinitialisieren?
Moin,
versuch mal folgendes:
1. Im Unifi-Controller bitte mal unter insights nachsehen, ob da noch das Smartphone_Valentina mit der falschen Mac vorhanden ist und dort löschen. Wenn du da nichts findest, dann ...
2. Im Unifi-Modul gibt es ein set clear all. Damit vergisst das Modul alles. Anschließend update aufrufen. Falls du UnifiClient-Devices angelegt hast, diese, falls das clear all nichts bringt, ggf. auch erneuern.
VG,
Dirk
Servus Dirk,
habe jetzt mal sowohl im Controller, als auch im Unifi device nach Deiner Anleitung "durchgeputzt".
Ja, da waren noch doppelte Clients in der Insight-View.
Ich vermute, dass der Wurm dadurch reingekommen ist, da sich meine Töchter anscheinend auch ins Guest-WLAN eingeloggt haben und hier im iPhone der "private WLAN-Schalter" noch nicht deaktiviert war.
Habe jetzt den "private WLAN-Schalter" für ALLE WLANs auf meiner Unifi-Landschaft in den iPhones deaktiviert.
...und gleichzeitig die Devices meiner Töchter für das Guest-WLAN geblockt.
Nachdem das ja kein permanentes Verhalten ist, werde ich das jetzt mal beobachten.
Ich melde mich, sobald ich neue Erkenntnisse habe.
Vielen Dank
Obelix
OK...hat leider nichts gebracht. :(
Die oszillierenden Ereignisse kommen leider wieder.
Habe auch den Unifi Client gelöscht und wieder angelegt..
VG
Obelix
Hast du weiterhin zwei mac-Adressen für denselben Client im Log?
Hallo Dirk,
nein, doppelte MACs hatte ich erstmal nicht mehr gefunden.
Habe jetzt aber nochmal den "Clear All" im Unifi Device gemacht und die "Unifi Client Devices" nochmal neu angelegt.
Dann einmal das FHEM durchgebootet.
Jetzt scheint erstmal Ruhe zu sein. Ich beobachte weiter....
Danke & VG
Obelix
Moinsen,
doppelte Macs über das Unifi Controller WebInterface entfernen, Clear all im Unifi Modul und Unifi Clients neu anlegen, hatte ich damals auch alles gemacht.
Das Problem besteht weiterhin. Habe aber momentan keine Zeit mich damit auseinander zu setzen. Mittlerweile gab es auch schon einige Controller Updates (6.0.41 ist gerade installiert). Meine FHEM Installation wurde schon länger nicht mehr geupdated.
Viele Grüße Hoppel
Zitat von: hoppel118 am 24 Januar 2021, 09:09:41
Moinsen,
doppelte Macs über das Unifi Controller WebInterface entfernen, Clear all im Unifi Modul und Unifi Clients neu anlegen, hatte ich damals auch alles gemacht.
Das Problem besteht weiterhin. Habe aber momentan keine Zeit mich damit auseinander zu setzen.
Dem kann ich mich anschließen. Hatte diese Schritte auch bereits auf Basis diverser Beiträge durchgeführt und habe mittlerweile Controller Version 6.0.43 drauf und immer noch keine Besserung. Mir fehlt auch leider die Zeit dran zu bleiben, aber würde es natürlich auch gern lösen, da ich einige Ideen bzgl. Anwesenheitserkennung umsetzen würde.
Aktuell meldet er mir lediglich per Pushover Fenster offen Meldungen, die aber auch gerne mal ausbleiben, wenn man genau in dem Moment kurz disconnected ist.
Notfalls muss ich dann doch auf Geofency und Bluetooth umsteigen. Schade.
Gruß sTaN
So....auch bei mir wechselt der Status - ja nach Tagesform - hochzyklisch zwischen absent und present her.
Werde nun meine verstaubten Shell-Kenntnisse auspacken und versuchen ein Script zu schreiben, dass dann erst nach dem 2. gleichen Event in Folge den Status setzt. Damit müsste ich die Reaktion auf den oszillierenden Statuswechsel ausschalten können.
VG
Obelix
es reicht völlig absenceThreshold im PRESENCE modul zu verwenden.
Ich hab mir Unifi Client Geräte angelegt und da drin ein presence Userreading.
Klappt 1a ohne "flattern"
defmod Presence_Frank_UniFi UnifiClient Frank-Handy-S88
attr Presence_Frank_UniFi event-on-change-reading .*
attr Presence_Frank_UniFi stateFormat {ReadingsVal($name,"presence","absent") eq "absent" ? "absent since ".ReadingsVal($name,"_f_last_seen","") : "present since ".ReadingsVal($name,"_f_uptime","")}
attr Presence_Frank_UniFi userReadings presence:fhem_state.* {(ReadingsVal($name,'fhem_state','disconnected') eq 'disconnected' ? 'absent' : 'present') }
Hallo Justme,
an den Thresholds habe ich mich auch schon versucht.
Ich habe verstanden, dass es für ein eventbasierendes Presencemodul den Timeout-Threshold gibt.
Den Absence- und Presence-Timout habe ich jeweils auf 60 (sek) gestellt.
Internals:
DEF event Smartphone_Matthias:fhem_state:.disconnected Smartphone_Matthias:fhem_state:.connected
EVENT_ABSENT Smartphone_Matthias:fhem_state:.disconnected
EVENT_PRESENT Smartphone_Matthias:fhem_state:.connected
FUUID 5e103a95-f33f-f80f-6862-0b53e51cfe9e54fc
MODE event
NAME Matthias_iPhone_priv
NOTIFYDEV Smartphone_Matthias,global
NR 519
NTFY_ORDER 50-Matthias_iPhone_priv
STATE present
TYPE PRESENCE
READINGS:
2021-04-04 08:34:32 model event
2021-04-04 08:40:50 presence present
2021-04-04 08:40:50 state present
helper:
CURRENT_STATE present
Attributes:
absenceTimeout 60
presenceTimeout 60
room Abwesenheit
Ich hätte dann eigentlich erwartet, dass es diese Phänomen nicht gibt:
2021.04.04 08:22:10.501 2: ROOMMATE set rr_Matthias home
2021.04.04 08:22:11.185 2: ROOMMATE set rr_Matthias absent
2021.04.04 08:22:46.513 2: ROOMMATE set rr_Matthias home
2021.04.04 08:22:47.199 2: ROOMMATE set rr_Matthias absent
2021.04.04 08:23:22.253 2: ROOMMATE set rr_Matthias home
2021.04.04 08:23:22.939 2: ROOMMATE set rr_Matthias absent
Hätte eigentlich erwartet, dass der Status nicht umgeschaltet wird, wenn das Antagonist-Event innerhalb der Timeout-Spanne kommt.
Um den absenceThreshold im PresenceModul zu verwenden, werde ich dann wohl auf eine function-/script-basierte PRESENCE-Lösung wechseln.
Danke für den Hinweis, durch den Threshold sollte ich mir dann das Persistieren des Vorgänger-Events sparen können.
Hallo Frank,
Die Unify Clients habe ich auch angelegt. Auch das hat leider nicht geholfen.
Auffällig ist, dass dieses Flattern wohl hauptsächlich bei iOS Geräten in Verbindung mit dem Unifis entsteht.
VG
obelix
Ok, wir haben kein iOS im Haus.
absenceThreshold und presenceThreshold ist etwas anderes als absenceTimeout und presenceTimeout.
ansonsten bei iOS: es ist wichtig auf dem device in den wlan einstellungen die private wlan adresse auszuschalten.
Hallo
Ich nutze fast ausschließlich Apple Geräte und habe natürlich auch das Problem das die Geräte immer mal wieder flattern, vor allem wenn sich die Geräte im Haus bewegen und die Clients den AP wechseln.
Ich habe das auf eine recht simple Weise gelöst.
Zunächst nutze ich das Presence Modul mit dem Attribut absenceTimeout 00:02:00 das verhindert das der Status ständig auf "absent" springt sondern zunächst auf "maybe absent".
defmod Handy_Daniel PRESENCE event unifi_controller:Apparat:.disconnected unifi_controller:Apparat:.connected
attr Handy_Daniel DbLogExclude .*
attr Handy_Daniel absenceTimeout 00:02:00
Der Status des Moduls wird von einem DOIF überwacht was dann in einen dummy schreibt.
defmod di.Handy_Daniel_present DOIF ([Handy_Daniel] eq "absent") (\
set Anwesend_Daniel:FILTER=STATE!=off off)\
DOELSE (set Anwesend_Daniel:FILTER=STATE!=on on)
attr di.Handy_Daniel_present DbLogExclude .*
defmod Anwesend_Daniel dummy
attr Anwesend_Daniel event-on-change-reading state
attr Anwesend_Daniel setList on off
attr Anwesend_Daniel webCmd on:off
Den Wert des dummies nutze ich dann für meine Abfragen oder die Statusanzeige auf meinen TabletUI.
Vielleicht hilft es jemanden.
Gruß
Daniel
Hallo WhyTea,
danke für Deine Lösung.
Ich habe mich jetzt aber für die folgende Lösung entschieden, in der ich dann auch mit dem von justme erwähnten absenceThreshold arbeite:
ein Presence Device mit folgenden Parametern angelegt:
Internals:
CFGFN
DEF shellscript /opt/fhem/helper/smartphone_status.pl Smartphone_Matthias 120
FUUID 606acb00-f33f-f80f-e4c9-0848122e526a14ae
INTERVAL_NORMAL 120
INTERVAL_PRESENT 120
MODE shellscript
NAME Matthias_iPhone_priv
NOTIFYDEV global
NR 4111
NTFY_ORDER 50-Matthias_iPhone_priv
STATE present
TYPE PRESENCE
READINGS:
2021-04-10 07:05:14 model shellscript
2021-04-10 07:56:57 presence present
2021-04-10 07:56:57 state present
helper:
CURRENT_STATE present
DISABLED 0
call /opt/fhem/helper/smartphone_status.pl Smartphone_Matthias
Attributes:
absenceThreshold 2
room Abwesenheit
und das zugehörige Perl-Script:
#!/usr/bin/perl
$| = 1;
my ($id) = @ARGV;
my $RC=0;
$connection=`/opt/fhem/fhem.pl 7072 "XXXXXXX" "{InternalVal('$id','STATE','')}"`;
if ($connection =~ m/^connected/){
$RC=1;
};
if ($connection =~ m/^disconnected/){
$RC=0;
};
print "$RC";
Damit sollte das Thema jetzt hoffentlich behoben sein.
VG
obelix
der umweg über ein externes shellscript das doch wieder fhem abfragt ist unnötig. einfach die function variante verwenden und den externen umweg sparen. ein reading auszuwerten ist in der regel auch besser als ein internal zu verwenden.
also etwa so: define <name> PRESENCE function {ReadingsVal('unifi','iPhone-andre','') eq "connected" ? 1 : 0} 60 60
Na klar, viel besser!!!
Danke, justme. :D
Ja das sieht wirklich interessant aus! :D
Inder Commandref steht das so:
define <name> PRESENCE function {...} [ <check-interval> [ <present-check-interval> ] ]Mir ist der Unterschied zwischen <check-interval> und <present-check-interval> gerade nicht ganz klar.
Würdest Du mir kurz das Verhalten beschreiben wenn man 60 60 setzt?
das ist doch in der commandref beschrieben:
Zitat
check-interval - The interval in seconds between each presence check. Default value: 30 seconds
present-check-interval - The interval in seconds between each presence check in case the device is present. Otherwise the normal check-interval will be used.
Sorry, dass habe ich tatsächlich überlesen.
Darüber hinaus habe ich aber dennoch eine Frage. Nur um sicher zu gehen. ;-)
So wie ich das Verhalten jetzt beobachtet habe geht das Device, ohne zusätzliche Attribute, auf den Status "maybe absent" wenn beim check einmal das zu prüfende Gerät nicht "connected" ist. Und beim zweiten mal in folge auf "absent".
Habe ich das so richtig beobachtet oder habe ich wieder was übersehen?
nein. die maybe zustände gibt es nur wenn absenceThreshold und/oder presenceThreshold gesetzt sind.