Masterarbeit über gesprächige BLE-Geräte

Jetzt stehst’e da: Scheinfrei im Studium, aber ein Thema für die Masterarbeit fehlt. Angebotene Themen klingen einfach nicht spannend, aber eigene Ideen haste auch nicht.

Atmina x Kilian

Was hatte meine Frau neulich gesagt, bei welcher Firma ich mich nach dem Studium bewerben soll? (Sie folgt da so einer auf Instagram…). Nochmal nachgefragt, Firma gefunden. Mal anrufen, vielleicht haben die ein Thema? …und zack, war ich dabei! (Ja gut, noch ein bisschen Orga-Kram, aber darüber hat Christoph hier ja schon berichtet😉

Und auch nach der Honeymoon-Phase bin ich noch ganz begeistert.

Irgendwas mit Sensorik

Vor und im Informatikstudium habe ich gerne mit Mikrocontrollern gearbeitet. Die machen einfach, was sie sollen (insofern man es ihnen richtig sagt 😅. Angefangen – wie sich das gehört – mit ’nem Arduino.
Später bin ich dann über den ESP8266 gestolpert: Mann, der kann WLAN! Und noch ein bisschen später kam ich auf den ESP32, der on-top noch Bluetooth spricht.

Schon im ersten Telefonat mit Simon erzählte er von einem möglichen Projekt, “irgendwas mit Sensorik und draußen an der frischen Luft”.

TBH: In dieser Sekunde hatte er mich. Ja, da waren auch andere spannende Dinge, aber …

Weiter ging es dann in Richtung Besucherstromanalyse. Starkes Wort, erst einmal googeln: Wer geht wann von wo nach wo und wie lange dauert das.

Das ganze soll ein zukünftiges Produkt von ATMINA erweitern. Die potentiellen Kunden haben bisher nix in der Richtung (außer manuelle Erhebungen mit dem Klemmbrett). Und welchen Mehrwert wollen wir damit liefern?

• Annahmen der Kunden über ihre Besucher bestätigen
• oder auch einen Fluchtwegplan ableiten
• und allg. Kennzahlen, um Besuchererlebnis und Besucherströme zu optimieren.

Mein Hirn rattert… Könnte man da nicht ESP’s für einsetzen? BLE-Geräte sind doch sehr gesprächig. Jedes Smartphone, jede Smartwatch, jede Boombox, jeder Earbud, viele Autos, viele Mietroller/-räder, etc. sagen mehrmals pro Sekunde: “Hallo, hier bin ich!” Lass mal untersuchen, ob man durch Mitschreiben dieser Infos auf so etwas wie Besucherströme schließen kann.

Bluetooth Logger

Kurzer Hand besorge ich mir fünf ESP’s für knapp 10€ pro Stück mit Kabel und Gehäuse. Hardware fertig.

Die Firmware besteht grob aus 5 Teilen:

• BLE Scanner: Scanne alle 10 Sekunden nach BLE Geräten.
• WiFi Client: Sende gefundene Geräte an den Server.
• MQTT Client: Nachrichtenprotokoll zwischen Server (Broker) und Client (ESP).
• OTA Handler: Zukünftige Firmware-Updates können über WLAN erfolgen.
• Watchdog: ESP-Neustart falls irgendetwas zu lange dauern sollte.

Und schon ist die Hardware einsatzbereit. Ich nenne sie “Bluetooth Logger” (das klingt freundlicher als “Sniffer” 🤓.

Drei davon platziere ich zunächst bei Atmina, um zu schauen, was für Daten da überhaupt reinkommen.

Daten

So sieht aktuell eine Messung aus (je nach Gerät sind mehr oder weniger Felder gefüllt):

{
  "address-type": "1",
  "address": "38:2f:a6:5f:c1:ea",
  "name": "",
  "manufacturer-data": "0600010920029e1[...]b8",
  "serviceUUID": "",
  "appearance": "",
  "rssi": "-91",
  "tx-power": "0",
  "timestamp": "1651042693"
}

Was kann ich aus diesen Daten lesen?

• Die 1 in address-type sagt mir, dass es sich um eine randomisierte MAC-Adresse handelt.
  Steht hier ein 0 ist es eine statische aka. public Adresse, die sich nie ändert.
• address ist die MAC-Adresse. Ist sie randomisiert, ist dieser Wert für mich Müll.
  Falls sie statisch ist, kann ich mit dem Präfix den Chip-Hersteller zuordnen (OUI Lookup List von Wireshark).
• Der “freundliche Name” name ist niemals bei randomisierten und nur manchmal bei statischen Adressen gesetzt. Dieser kann bspw. “Galaxy Watch Active2” oder “heart rate sensor” sein (echte Messungen).
  In einer Woche habe ich über 500 unterschiedliche Gerätenamen aufgezeichnet.
• Bei der manufacturer-data wird es komplizierter. Ganz einfach kann ich im o.g. Beispiel den Prefix 0600 mit den Bluetooth Company Identifiers vergleichen und finde heraus, dass es sich um ein Gerät von Microsoft handelt.
• Für einige Dienste wird eine feste ServiceUUID verwendet, so bspw. für die Corona-Warn-App der Präfix 0xFD6F.
• Appearance wird selten gesetzt, soll aber über die Art bzw. die generischen Fähigkeiten des Gerätes informieren (Telefon, PC, Uhr, etc.).
• Der RSSI (Received Signal Strength Indicator) kann mit etwas rechnen als ungefähre Entfernung zum Logger ausgewertet werden (Je kleiner der Absolutwert desto näher).
• Die Sendestärke (tx-power) kann zur genaueren Entfernungsbestimmung genutzt werden.
  Mit dem RSSI zusammen, lassen sich Entfernung unter einem Meter sehr genau bestimmen.
  (Das ist für mich eher uninteressant, aber erst mal haben.)

Reichweite

So in etwa 10m Umkreis sollten die BLE Logger aufnehmen können. Sicher lässt sich dieser Bereich mit besserer Hardware noch vergrößern.

Hier im dritten Stock bekomme ich sogar E-Roller eines großen Anbieters rein, die unten auf dem Bürgersteig stehen. Das sind sogar 12m und ne Wand ist auch noch dazwischen! Bspw. diese beiden:

name,              address
****-931303XXXXXX, 50:51:a9:xx:xx:xx
****-931303XXXXXX, 4c:24:98:xx:xx:xx

Diese haben eine statische MAC-Adresse (address-type: 0) und broadcasten im Namen auch ihre ID.

Also zwei Daten, die sich niemals ändern (Ich könnte sie wiedererkennen, wenn sie das nächste Mal vor der Tür parken). Den Präfix der statischen MAC-Adresse kann ich mit der OUI Lookup List von Wireshark vergleichen und weiß nun, dass die einen Chip von Texas Instruments verbauen.

Corona-Warn-App aka. Exposure Notification

Von allen aufgenommenen Messungen bisher gingen ca. 10% von der Corona-Warn-App (CWA) aus. Das erkenne ich an dem Präfix der Service-UUID 0xFD6F, die Apple und Google zusammen in Exposure Notification Bluetooth Specification definieren.

Hier kann ich zwar die MAC-Adresse nicht auswerten, weil die randomisiert ist, aber ich kann schauen, wie lange ich sie aufgenommen habe. Erste und letzte Messung einer CWA-ID:

address,           serviceUUID,    timestamp,  daytime
15:17:a7:fb:c1:1c, 0000fd6f-00..., 1651736979, 2022-05-05 09:49:39
15:17:a7:fb:c1:1c, 0000fd6f-00..., 1651738032, 2022-05-05 10:07:12

Hier schlägt nach 18 Minuten die OS-seitige MAC-Randomisierung zu. Somit ändert sich auch die CWA-ID (>10 && <20 minutes).

Bewegt sich aber ein Gerät innerhalb dieses Zeitfensters von einem Logger zu einem anderen, ließe sich hiermit ein “Flow” zwischen den Logger-Positionen erkennen.

Tracking Potential

Schnell fand ich einige gesprächige Geräte im Büro. Das waren – neben anderen – Maxis Kopfhörer von einem Stockwerk über den Loggern. Sie senden (wie fast alle Kopfhörer) eine statische MAC und lassen sich somit suuuper einfach tracken.

Erste Versuche mit Messungen vom 6. bis 10. Mai in einem pandas-DataFrame und ein bisschen Python:

>>> maxi=sensors_data.loc[sensors_data['address']=="<public-mac-address>",
                         ['day', 'time']]
>>> presence=maxi.groupby('day').agg({'time':['min','max']})
>>> presence
                time
                 min       max
day
2022-04-06  07:09:28  14:47:28
2022-04-07  07:09:59  13:48:15

Bemerke: Die Zeiten sind in GMT (also +2h).

So so, Maxi kommt pünktlich um 10 nach 9, raus ist er ähnlich minutiös; ich behaupte, er fährt Bahn!

Am 7. um 15:44 Uhr schreibt er noch intern, dass er jetzt Feierabend macht. Vier Minuten später verlässt er den Aufzeichnungsbereich meiner Logger. Am 8. war er im Homeoffice, dann war Wochenende.

Hey, das ist ein Proof-of-Concept!

Wie geht’s weiter?

Mein Ziel ist es, viele dieser Logger im Testgebiet zu verteilen, um Übergänge zu beobachten. Bspw. “Wieviel Prozent gehen von Attraktion A zu Attraktion B?”

Wie viele Logger brauch ich? Für die gesamte Fläche von ca. 22ha wohl knapp 600. Na gut, in den Gehegen vielleicht nicht. Nur auf dem Rundweg mit vollständiger Abdeckung bräuchte ich wohl ca. 200 Stück. Aber da spielt das WLAN des Testgebiets schon gar nicht mit, über das ich die Messdaten an meinen Server schicke. Ich muss mir also ein paar strategisch gute Orte überlegen und dort ein paar zig verteilen…

Todo:

• Daten anonymisieren: Daten dienen ausschließlich dem statistischen Zweck der personenunabhängigen Besucherstromanalyse bzw. Fluchtwegplanung. Infos wie Klarname oder public-MAC werden nur hashed abgelegt, um Rückschlüsse auf eine bestimmte Person vorzubeugen.
• Datenaufbereitung: Filtere stationäre Geräte, Mitarbeitende, Autos, etc. und entferne Duplikate.
• Übergangserkennung: Reduziere Messdaten auf Tupel aus Logger, Gerät-ID und Status (IN, OUT) und kombiniere OUT einer Station mit IN einer anderen mit derselben ID.
• Visualisierung: Eine Art Heatmap zeigt in welchen Logger-Bereichen wieviele ungleiche Geräte zu einem bestimmten Zeitfenster gemessen wurden. Ein Übergangsgraph zeigt die prozentualen Anteile der Bewegungen zwischen den Logger-Bereichen.
• Integration: Baue diese Visualisierung in das aktuelle Backend des Rahmenprojekts ein.
• …
• Masterarbeit schreiben… Profit!

Und wenn das alles läuft und gute Daten liefert, könnte das vielleicht auch andere Freizeitangebote und Außengelände interessieren… 🤔