G-Tag lt. lepresenced plötzlich present, obwohl meilenweit entfernt

[FunkOdyssey]

Nachdem ich mir nochmal den Code angesehen habe, gehe ich davon aus, dass - aus welchem Grund auch immer - tatsächlich ein derartiges Beacon empfangen wird. Meine Hoffnung, dass ich die faulen Beacons irgendwie an Hand der Ausgabe von hcidump identifizieren und ausfiltern könnte, hat sich nicht bewahrheitet. Etwaige Prüfsummen (diverse Dokumente verweisen auf CRC) finde ich weder in der (aufbereiteten) Ausgabe von hcidump noch in Wireshark.

Wenn man sich die Logs von Euch so ansieht, fällt auf, dass das Alter bei den unerwünschten "presents" eher hoch ist (91 Sekunden, 117 Sekunden). Da die G-Tags im Normalbetrieb in sehr kurzen Abständen senden, spricht das dafür, dass die unerwünschten Beacons nur einzeln auftreten. Wenn sich nicht noch ein Bluetooth-Experte mit dem rettenden Tipp findet würde ich lepresenced so anpassen, dass Einzelbeacons verworfen werden.

Danke, dass du dich darum kümmerst. Kann ich bzgl. der maxAge-Parameters denn irgendwie Einfluss auf die Fehlerkennung nehmen? Im Define den Intervall erhöhen oder besser noch reduzieren auf 60 Sekunden?

Ich verstehe nicht woher das "Beacon" herkommen soll. Das kann doch nur am Dongle, im Treiber oder ähnliches liegen, oder?

Ich hätte kein Problem damit, mir einen anderen Dongle zu kaufen.

Ich könnte auch die Installation von lepresenced auf einem autarkem Raspberry B+ vornehmen. Ich kann ja in FHEM die IP entsprechend angeben.

(Auf meine Rasperry B 2 habe derzeit das aktuellste Jessie.)

[PatrickR]

Danke, dass du dich darum kümmerst. Kann ich bzgl. der maxAge-Parameters denn irgendwie Einfluss auf die Fehlerkennung nehmen? Im Define den Intervall erhöhen oder besser noch reduzieren auf 60 Sekunden?

Nee das bringt nichts solange ein Beacon ausreicht... Mit einem kürzeren Intervall hättest Du nur den Vorteil, dass das erlösende "absent" schneller kommt.

Ich verstehe nicht woher das "Beacon" herkommen soll. Das kann doch nur am Dongle, im Treiber oder ähnliches liegen, oder?

Oder es fliegt durch die Luft. Wir sind ja im ISM-Band nicht allein mit unseren brüllenden G-Tags. Dafür würde auch sprechen, dass das Problem so selten auftritt, bei mir mit 3 Tags über mehrere Monate z. B. noch garnicht.

Ich hätte kein Problem damit, mir einen anderen Dongle zu kaufen.

Ich könnte auch die Installation von lepresenced auf einem autarkem Raspberry B+ vornehmen. Ich kann ja in FHEM die IP entsprechend angeben.

(Auf meine Rasperry B 2 habe derzeit das aktuellste Jessie.)

Interessant wäre natürlich mal eine Testreihe mit mehren nebeneinanderstehenden Pis mit jeweils anderen Bluetooth-Sticks. Aber kaufen würde ich jetzt nichts.

Wie gesagt als letzte Lösung kann ich immer noch lepresenced filtern lassen. Aber spannender wäre natürlich, zu erfahren, woran es wirklich liegt.

Patrick

[Brause]

Eventuell kenne ich eine solche Störquelle persönlich.

Aus welchem Grund auch immer sendet mein LG G4 (US-Version) einen LE-Beacon mit sich in unterschiedlichen Intervallen willkürlich ändernder MAC-Adressen.
Bisher habe ich kein System hinter den Änderungen gefunden. Beobachte es auch nicht aktiv.
Hatte es mir ehrlich gesagt nur mal knapp eine Stunde angeschaut, in der Hoffnung, ich kann es als Anwesenheitskontrolle nutzen.

Laut Heise MAC-Datenbank sind die MAC-Adressen auch nicht zwingend LG zugeordnet.

[DeeSPe]

Eventuell kenne ich eine solche Störquelle persönlich.

Aus welchem Grund auch immer sendet mein LG G4 (US-Version) einen LE-Beacon mit sich in unterschiedlichen Intervallen willkürlich ändernder MAC-Adressen.
Bisher habe ich kein System hinter den Änderungen gefunden. Beobachte es auch nicht aktiv.
Hatte es mir ehrlich gesagt nur mal knapp eine Stunde angeschaut, in der Hoffnung, ich kann es als Anwesenheitskontrolle nutzen.

Laut Heise MAC-Datenbank sind die MAC-Adressen auch nicht zwingend LG zugeordnet.

Ich glaube das ist nicht nur LG spezifisch.
Gab es da nicht mal was dass einige Geräte random BT Beacons senden damit die nicht von z.B. Reklametafeln getrackt werden können!? 
Das iPhone macht das meines Wissens auch. Wenn man aber die echte Adresse kennt, ist das kein Problem bei der Erkennung.
Bei einer Anwesenheitserkennung kann es aber tatsächlich zum Problem werden.

Gruß
Dan

[KernSani]

Beobachte seit gestern das selbe Verhalten... einer meiner 4 Gtags ist immer mal wieder present, obwohl eigentlich weg. Bei den anderen Dreien (die schon älter sind) ist alles normal...

[PatrickR]

Mahlzeit!

Hier mal Version 0.81 zum Testen.

lepresenced merkt sich jetzt nicht nur den Timestamp des letzten Beacons sondern auch den des vorletzten. Für Present müssen beide innerhalb des eingestellten Intervalls liegen.

Patrick

[Jojo11]

Danke! Werde ich die kommenden Tage mal testen.

Schöne Grüße
Jo

[FunkOdyssey]

Ich habe die Änderungen erst Montag Abend aktiviert und konnte erst zwei/drei längerfristige Abwesenheiten testen.
Bisher aber erfolgreich. Ich konnte noch keine Fehlerkennung feststellen. Ich behalte das weiter im Auge.

Mahlzeit!

Hier mal Version 0.81 zum Testen.

lepresenced merkt sich jetzt nicht nur den Timestamp des letzten Beacons sondern auch den des vorletzten. Für Present müssen beide innerhalb des eingestellten Intervalls liegen.

Patrick

Wenn nun also zwei Erkennung innerhalb des Intervalls liegen müssen (also eine Art presenceThreshold?), wie oft findet dann die Abfrage statt?

Mein Intervall liegt nun bei 60 Sekunden. Also muss in dieser Zeit zweimal das G-Tag gefunden werden. Wie oft wird denn geprüft? Das habe ich noch irgendwie nicht verstanden.

Danke für dein Fix.

[PatrickR]

Hi!

Wenn nun also zwei Erkennung innerhalb des Intervalls liegen müssen (also eine Art presenceThreshold?), wie oft findet dann die Abfrage statt?
Mein Intervall liegt nun bei 60 Sekunden. Also muss in dieser Zeit zweimal das G-Tag gefunden werden. Wie oft wird denn geprüft? Das habe ich noch irgendwie nicht verstanden.

lepresenced prüft nicht aktiv sondern lauscht dauerhaft mit. Meine G-Tags senden etwa 1x pro Sekunde, d. h. mein Fix könnte allenfalls problematisch werden, wenn Du sehr kurz scannst, z. B. 2 Sekunden

Wenn Du den Log level auf LOG_DEBUG hochschraubst kannst Du sehen, wie alt das letzte und vorletzte Beacon ist, bei mir i. d. R. 0-2 Sekunden.

Patrick

[FunkOdyssey]

Danke für die Erläuterung. Das wir neu. Wobei das eigentlich sogar logisch sein sollte.

[Jamo]

Hi Patrick,
ich habe die letzte Version mit dem Fix auch installiert, und bei mir läufts bisher auch problemlos seit 3 Tagen. Danke!

[Jojo11]

Hallo,

auch ich habe den Fix jetzt auf den 3 PIs installiert und habe seitdem keine Fehlauslösungen mehr. Vielen Dank schon mal dafür!
Ich werde auch weiter beobachten 

schöne Grüße
Jo

[PatrickR]

Freut mich zu hören! Wobei mich doch interessieren würde, wo die Geisterbeacons herkommen.


Von unterwegs gesendet.

[Jojo11]

Eine Sache ist mir noch aufgefallen. Passt evtl nicht 100% hier hin. Wenn der Status auf absent springt, bleibt im reading rooms noch ein Raum (ich denke der letzte, in dem der tag gesehen wurde) stehen. Könnte man das reading bei absent nicht löschen? Würde bei der Visualisierung erheblich helfen 

Schöne Grüße
Jo

[peterk_de]

@JoJo ich wäre auch dafür, das Reading room in dem Fall dann auf "none" o.ä. zu setzen, denn aktuell ist es nicht konsistent, da das Reading nicht den aktuellen Raum anzeigt, sondern den, in dem der Beacon zuletzt emofangen wurde (müsste aktuell also eher "lastRoom" oder so heißen) Aber ich bin nicht dafür, das gabze Reading zu löschen das gibt wieder ganz  andere Probleme