Einen Belegungssensor mit einem 5-Dollar-ESP32 und einer serverlosen DB bauen

 (matthew.science)
2 Punkte von GN⁺ 2023-11-14 | 1 Kommentare | Auf WhatsApp teilen
  • Nachdem der Vertrag mit Bluefox, das Daten zur Auslastung der Mensa bereitgestellt hatte, weggefallen war, wurde ein Gerät gebaut, das Belegungstrends auf dem Campus direkt über die Anzahl der in BLE-Advertising-Paketen sichtbaren Geräte misst
  • In Laptop-Tests bewegte sich die Zahl der BLE-Geräte in kleinen Räumen schnell zusammen mit der tatsächlichen Auslastung, und auch in großen Mensen passte sie gut zu den Trendänderungen während der Wechselzeiten vor und nach Vorlesungen
  • Ein Raspberry Pi Zero W erwies sich wegen Linux-Bluetooth, DBus, Cross-Compilation und Headless-Wi-Fi-Setup als schwer für ein Deployment-Gerät nutzbar, daher fiel die Wahl auf den einfacheren ESP32
  • Günstige ESP32-WROOM-Boards wurden wegen Speicherproblemen in der Nähe von etwa 250–400 Geräten instabil, aber Seeed Studio XIAO ESP32C3/S3 liefen langfristig stabil und hielten bis zu etwa 1000 Geräte Erkennung aus
  • Die finale Architektur scannt mit dem ESP32 die Anzahl der BLE-Geräte, sendet sie an Cloudflare Functions und D1 und visualisiert bzw. prognostiziert sie mit Grafana und NeuralProphet; Kalibrierung der Genauigkeit und Datenschutzprüfung stehen noch aus

Verschwundene Daten zur Mensa-Auslastung

  • Im ersten Studienjahr war Sodexo der Mensabetreiber, und Sodexo nutzte über einen Vertrag mit Bluefox Belegungssensoren, die die Zahl der Menschen in der Mensa anzeigten
  • Laut per FOIA-Anfrage erhaltenen Unterlagen arbeitete das Bluefox-Gerät, indem es MAC-Adressen von Smartphones in Bluetooth-Advertising-Paketen zählte
  • Wenn man API-Aufrufe an Grafana anschloss, konnte man die Mensa-Auslastung als Echtzeitdiagramm sehen und Stoßzeiten vermeiden
  • Später wechselte der Mensabetreiber zu Aramark, und Aramark schloss keinen Vertrag zur Erfassung von Belegungszahlen wie mit Bluefox ab, sodass die bisherigen Daten verschwanden

BLE-Beacons als Proxy für die Personenzahl nutzen

  • Der Kern des Projekts war zu prüfen, wie gut sich die Zahl der Bluetooth-Beacons als Ersatz für die tatsächliche Personenzahl und Aufenthaltsdauer eignet
    • Manche Menschen tragen mehrere Geräte bei sich, etwa Kopfhörer oder Smartwatches
    • Manche tragen gar keine Geräte bei sich oder haben Bluetooth am Handy deaktiviert
  • Für die Schätzung der Aufenthaltsdauer war offen, ob sich der Wechsel (Churn) eindeutiger MAC-Adressen nutzen lässt und wie sich die Randomisierung von MAC-Adressen bei verschiedenen Herstellern wie Android und Apple auswirkt
  • Für das Senden der Daten an einen zentralen Server war Wi-Fi die naheliegendste Wahl, aber nicht an jedem Standort war es leicht verfügbar
  • Auch LoRa kam je nach Beacon-Verteilung infrage, allerdings hängt die reale Reichweite stark von Antennengewinn und Montageort ab
  • Für die Datenspeicherung spielte zudem eine Rolle, ob eine Zeitreihendatenbank verwendet werden sollte und ob sich bei langfristigen Trendprognosen Sondereffekte wie Homecoming-Wochenende oder Prüfungswochen ausklammern lassen

Erste Validierung mit einem Laptop

  • Das erste Experiment war einfacher Code, der mit dem Bluetooth-Adapter eines Laptops x Sekunden lang scannte, dies alle y Sekunden wiederholte und die Daten in einer SQLite-Datenbank speicherte
  • Die Daten wurden gesammelt, indem mit dem Laptop an mehreren Orten wie Mensa, Chick-Fil-A und Starbucks gewartet wurde
  • In Starbucks, einem kleinen einzelnen Raum, war die Gerätezahl ziemlich genau und spiegelte zumindest den Belegungstrend schnell wider
    • Wenn Menschen hereinkamen, stieg das Diagramm schnell an
  • In großen Räumen wie einer Mensa ließ sich die Gesamtzahl der Menschen nicht direkt zählen, und auch die Reichweite des Bluetooth-Adapters war unklar, aber der Anstieg nach Vorlesungsende auf dem Weg zum Essen passte gut zur Zunahme der erkannten Beacons

Warum der Ansatz mit dem Raspberry Pi Zero W scheiterte

  • Das erste naheliegende Gerät für ein langfristiges Deployment war der kleine, günstige Raspberry Pi Zero W mit Wi-Fi und Bluetooth
  • Der Code wurde in Rust neu geschrieben, um Reboots, fehlendes Netzwerk und den Verlust des Adapters abzufangen
  • Der Umgang mit Linux-Bluetooth in einer Headless-Umgebung war deutlich komplizierter als erwartet
    • Die DBus-Bindings erforderten Konfiguration für Cross-Compilation
    • Auch mit Cross ließ sich das Problem nicht lösen
    • Nach diversen Compiler-Flags, verlorener Arbeit am Makefile und QEMU-Bridge-Setup lief das Binary schließlich auf dem Pi
  • Wi-Fi-Verbindung, Installation der beim Start benötigten Bibliotheken, Registrierung des Executables als Dienst und automatische Updates wurden zwar umgesetzt, funktionierten nach dem realen Boot aber nicht zuverlässig
  • Dieser Ansatz zog den gesamten Linux-Kernel und viele bewegliche Teile mit sich, obwohl eigentlich nur zuverlässiges Wi-Fi und Bluetooth gebraucht wurden

Wechsel zum ESP32

  • Laut Dokumentation brachte der ESP32 alles mit: Wi-Fi, Bluetooth, geringen Stromverbrauch, niedrigen Preis und kleine Bauform
  • Bei Amazon wurde ein beliebiges ESP32-WROOM-32 mit OLED-Display gekauft
    • Das Ziel war, Live-Daten direkt auf dem Display anzuzeigen
  • Da das Rust-Ökosystem für ESP32 noch nicht ausgereift genug erschien, wurde der Datenerfassungscode in C++ neu geschrieben
  • Das OLED wurde mit SSD1306Wire display(0x3c, 5, 4); in Betrieb genommen
  • Beim Campus-IT-Team wurde Whitelisting der MAC-Adresse angefragt, und Cloudflare Functions sowie die D1-Datenbank wurden als Backend für die Datenerfassung gebaut

Speicherprobleme beim ersten Deployment

  • Ein Datenerfassungsgerät wurde in der Campus-Bibliothek installiert, und auf dem Laptop ließ sich eingehender Datenverkehr bestätigen
  • Danach traten seltsame Ergebnisse auf, als hätten alle Menschen die Bibliothek verlassen; die Ursache war die schwache Ausstattung des zufällig gekauften ESP32-Boards
  • Das Gerät stürzte in der Nähe von etwa 250 Geräten ab
    • Zuerst lag der Verdacht nahe, dass die Ergebniszahl in einem 1-Byte-Wert gespeichert wurde und deshalb bei etwa 255 hängen blieb
    • Serial.print zeigte jedoch zufällige Abstürze in ähnlichen Bereichen wie 249 oder 265, also keinen simplen Integer-Overflow
  • Während des Scans wurden sämtliche Ergebnisse bis zum Ende in Datenstrukturen gehalten, darunter Signalstärke, Advertising-Services und Hersteller-IDs, wodurch sich auf dem kleinen RAM zu viele Daten ansammelten
  • Tatsächlich wurde nur die Zahl eindeutiger Geräte benötigt, sodass eine Struktur zum Behalten kompletter Scan-Ergebnisse überdimensioniert war

Selbstgebautes Hash-Set und seine Grenzen

  • Als Lösung wurde eine kleine Hash-Set-Datenstruktur direkt in C++ implementiert
  • In jedem Callback wurde die MAC-Adresse in das Hash-Set eingefügt und anschließend die eingebaute Ergebnisstruktur geleert, um Speicher freizugeben
  • Das hatte den Nachteil, dass die eingebaute Ergebnisstruktur ihre Daten zur Duplikaterkennung verlor und dadurch bei jedem BLE-Advertising-Paket ein Callback ausgelöst wurde
    • In addToSet wurde die Duplikatprüfung im Hash-Set zwar durchgeführt
    • Dennoch traten Hunderte doppelte Callbacks auf, und durch ständiges Allozieren und Freigeben der Ergebnisstruktur entstand Heap-Churn
  • Trotzdem erschien es besser, häufig eine Hash-Map mit höchstens unter 1000 Einträgen zu prüfen, als schon bei rund 250 Personen an Kapazitätsgrenzen zu stoßen

Wahl eines stabileren ESP32-Boards

  • In den Herbstferien wurde ein 5-Tage-Langzeittest versucht, aber in der Nähe von etwa 400 Geräten trat erneut ein Absturz auf
  • Das Problem zeigte sich nach etwa drei Stunden Nutzung, und selbst mit periodischen Reboots lieferte das System irgendwann bei jedem Scan sofort nur noch 0 Geräte zurück
  • Es wurden mehrere Boards getestet
    • Seeed Studio XIAO ESP32S3/C3
    • WaveShare ESP32S3 Zero
    • No-Name ESP32-WROOM mit OLED
    • Orange Pi Zero W
    • Raspberry Pi Zero W
  • Die einzigen Boards, die langfristig stabil liefen, waren XIAO ESP32C3/S3, und beide arbeiteten auf akzeptablem Niveau
  • Die endgültige Wahl fiel auf den XIAO ESP32C3
    • Die RISC-V-Basis gefiel
    • Er war günstiger
  • Mit dem Wechsel auf ein besseres Hersteller-Board stieg auch der SRAM, und Abstürze wurden seltener, selbst wenn statt der Eigenbau-Hash-Map wieder die Standard-Ergebnisstruktur verwendet wurde
  • Bis zu etwa 1000 erkannte Geräte zeigten sich keine Anzeichen von Verlangsamung, und vermutlich gingen auch Heap- und Callback-Churn zurück

Bewegungsmuster vom Wohnheimfenster aus

  • Nachdem ein stabiles Gerät gefunden war, wurde es zur einfacheren Wiederholung von Deployments ans Fenster des Wohnheimzimmers verlegt
  • In den Tagesdaten zeigten sich Peaks zu den Zeiten des Vorlesungswechsels
  • Obwohl das Gerät im Wohnheim stand, maß es nicht hauptsächlich nur Wohnheimbewohner
    • Wären nur Wohnheimbewohner erfasst worden, wäre der Höchstwert früh morgens zu erwarten gewesen und hätte tagsüber abgenommen
    • Durch die Ausrichtung aus dem Fenster wurden vor allem Studierende erfasst, die sich zu zwei nahegelegenen Lehrgebäuden bewegten
  • Der Peak gegen 7:50 passte zu den 8-Uhr-Veranstaltungen in Ewell Hall und Washington Hall
  • Die Peaks um 8:50, 9:50 und 10:50 passten jeweils zu den Wegen zu den 9-, 10- und 11-Uhr-Veranstaltungen
  • Das Gerät schien gut für die Verfolgung von Bewegungstrends im Umfeld geeignet, und die Antennenreichweite reichte offenbar bis zur Washington Hall auf etwa 160 ft und bis zur Ewell Hall auf etwa 100 ft
  • Auch die Höhe im dritten Stock dürfte zur Erfassungsreichweite beigetragen haben

Prognosen und offene Validierungsfragen

  • Die gesammelten Daten zeigten viele stündliche, tägliche und wöchentliche Trends und eigneten sich daher gut für Zeitreihenprognosen mit Werkzeugen wie NeuralProphet
  • Nach Hinzufügen der Prognosefunktion ließ sich der Tagestrend inzwischen gut vorhersagen
  • Längerfristige Trends über Wochen, Monate und Saisons dürften sich mit ausreichend Daten angleichen
  • Viele Fragen sind noch offen
    • Wie gut die Zahl der BLE-Beacons tatsächlich als Proxy für die reale Personenzahl taugt
    • Ob sich wegen Menschen mit mehreren Geräten ein Korrekturfaktor wie ungefähr 0.7x Personen für x Beacons ableiten lässt
    • Ob in Informatikgebäuden wegen vieler Geräte pro Person das Verhältnis von Beacons zu Menschen höher ist oder wegen oft deaktiviertem Bluetooth niedriger
    • Ob es in Mitarbeitergebäuden niedriger ist, weil dort weniger Geräte als bei Studierenden mitgeführt werden
    • Ob es in Mensen niedriger ist als in Hörsälen, weil dort seltener Laptops oder iPads parallel genutzt werden
  • Auch bei der Genauigkeitsverbesserung bleibt Arbeit
    • Setzen eines RSSI-Mindestwerts, um schwache Signale auszuschließen
    • Filterung nur auf Apple- und allgemeine Android-Hersteller-IDs
    • Das Problem, dass Apple Watch, AirPods und MacBook weiterhin mitgezählt werden
    • Ob beim aktuellen Ansatz, der nur reine Beacon-Zahlen und keine tatsächlichen MAC-Adressen verfolgt, zusätzliches Rauschen nötig ist
    • Ob es realistisch ist, aus der reinen Gerätezahl einzelne Nutzer zu identifizieren
    • Wahl einer Scan-Dauer, die nicht zu kurz ist, um Hunderte Geräte nicht zu verpassen, und nicht zu lang, um bereits verschwundene Geräte weiter zu zählen
    • Eine dynamische Scan-Länge, die den Scan beendet, wenn sich über eine gewisse Zeit nichts mehr ändert

Mögliche Deployment-Formen

  • Es ist geplant, die Daten an Orten zu validieren, an denen sich die tatsächliche Personenzahl leicht erfassen lässt
    • Fitnessstudio mit Zutrittsprotokollen
    • Mensa oder Starbucks mit begrenzten Eingängen
  • Mit Professoren wird über Einsatzmöglichkeiten in Universitätsgremien oder für wissenschaftliche Forschung gesprochen
  • Auch ein Vertrieb an stationäre Geschäfte zur Messung von Belegungstrends wird erwogen
  • Die Konfiguration pro Deployment-Einheit ist relativ gut paketierbar
    • Wi-Fi in den Einstellungen konfigurieren
    • Bei Portalnetzwerken setzt das Netzwerk die MAC-Adresse auf die Whitelist
    • Offene oder passwortgeschützte Wi-Fi-Netze werden beim Boot verbunden
    • In den Einstellungen machine ID und site ID ändern
    • Das Gerät an eine Steckdose an zentraler oder praktischer Stelle anschließen
    • Im Backend ein Grafana-Dashboard einrichten, das jedes Gerät ausliest
    • Ein separates Grafana-Dashboard einrichten, das die prognostizierten Trends als eigenes Diagramm anzeigt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-14
Hacker-News-Kommentare

  • Ich habe mit dieser Technik ein echtes Unternehmen (occuspace.io) aufgebaut und die meisten der aufgeworfenen Fragen schon behandelt.
    Die Anzahl der BLE-Beacons korreliert sehr stark mit der Zahl der anwesenden Personen, aber die Korrelationskoeffizienten unterscheiden sich je nach Mensa, Hörsaal oder Bibliotheksetage deutlich; deshalb ist es besser, zusätzlich komplexere Merkmale zu verwenden.
    Die Aufenthaltsdauer anhand der Sichtbarkeitszeit eines BLE-Beacons zu schätzen, halte ich nicht für genau, weil Bluetooth-MACs je nach Hersteller alle 8 bis 20 Minuten randomisiert werden.
    Schwaches RSSI auszublenden und nur nahe Geräte zu zählen, ist eine gute Idee, aber der Schwellwert hängt von der Art des Raums und der Sensorposition ab.

    • Mich würde interessieren, wie oft man wirklich eine exakte Zahl braucht.
      Wenn die ursprüngliche Anforderung „überfüllte Mensen vermeiden“ war, kann es ausreichen, grob zu wissen, ob viel oder wenig los ist.
      Im Business-Kontext frage ich mich, ob Kunden hohe Genauigkeit erwarten, und ob das alle tun oder nur ein Teil.
      Auch wenn MAC-Adressen randomisiert werden, könnte es vielleicht eine Möglichkeit geben, den Gerätetyp zu erkennen, nur Smartphones zu zählen und Kopfhörer usw. auszuschließen.
    • Mich würde interessieren, ob so ein Anwesenheits-Tracking auch im Freien genau funktioniert.
      Ich vermute, dass es schwieriger ist, weil sich Signale weiter ausbreiten, und ich arbeite an einem Startup, das die Belegung von Tennisplätzen tracken muss.
      Man könnte vielleicht Bluetooth-Geräte an den Ecken eines Außenbereichs installieren und deren Signalstärke als Schwellwert verwenden.
    • Auch Meraki stellt solche Informationen als Teil seines Cloud-Managements für Netzwerke bereit.
      Wenn man Wi-Fi, Wi-Fi-MACs und Videodaten trackt und miteinander verknüpft, ließe sich vielleicht noch mehr machen.
      Gut, das als einen potenziellen Wettbewerber auf dem Schirm zu haben.
    • Dass sich die Korrelationskoeffizienten je nach Raum unterscheiden, wirkt wie ein Punkt, der eine Produktisierung erschwert.
      In einem STEM-Universitätsgebäude kann es mehr als drei Bluetooth-Geräte pro Person geben, an anderen Orten vielleicht weniger als eins.
    • Wäre damit auch Sturzerkennung für ältere Menschen möglich?

  • Großartiger Artikel.
    Es hieß, dass nach Tests mit Seeed Studio XIAO ESP32S3/C3, WaveShare ESP32S3 Zero, Unbranded ESP32-WROOM with OLED, Orange Pi Zero W und Raspberry Pi Zero W über längere Zeit — aktuell etwa einen Monat — nur der XIAO ESP32C3/S3 stabil lief; ich vermute, dass es ein Stromversorgungsproblem sein könnte.
    Die ESP32-Familie kann beim Senden empfindlich auf Spannungsschwankungen reagieren, daher empfehle ich dringend, einen großen Kondensator an die Versorgungsschiene zu hängen.
    Sowohl RPi als auch ESP können je nach Netzteil, Kabel und Kabellänge heikel sein, und die SD-Karte des RPi geht bei plötzlichen Stromausfällen leicht kaputt.
    Trotzdem sollten alle länger als einen Monat durchhalten können, und meine Pis und ESPs liefen jeweils monatelang.
    Mich würde interessieren, was passiert, wenn man an andere ESP32 oder Pis einen größeren Kondensator hängt.

    • Es war wahrscheinlich kein Stabilitätsproblem der ESP32-Plattform selbst, sondern eher ein Problem meiner Nutzungsweise.
      ESP32 ist extrem verbreitet, daher dürfte die Ursache gewesen sein, dass der erste No-Name-ESP32, den ich gekauft hatte, nicht lange durchgehalten hat.
      Nach dem Wechsel auf ein Produkt eines ordentlichen Herstellers war das Problem gelöst, und der ESP32 funktioniert gut.
      Der Raspberry Pi hat tatsächlich kaum funktioniert, weil er eine Aufgabe, für die eigentlich nur Bluetooth-Scanning und HTTP-Aufrufe nötig sind, unnötig kompliziert gemacht und zu viel verwaltet hat.
      Da ich direkt aus der Steckdose per USB-C 5V 1A geliefert habe, glaube ich nicht, dass es ein Stromproblem war; allerdings hatte auch der Xiao ESP32-S3 gelegentliche Probleme, und soweit ich mich erinnere verbraucht der XTensa-Core mehr Strom als der RISC-V-basierte ESP32-C3, also sollte man das prüfen.
    • In meiner Home Automation übernehmen mehrere ESP32 Kernaufgaben der Infrastruktur und laufen seit etwa einem Jahr problemlos.
      Gelegentlich aktualisiere ich sie mit ESPHome, aber es gab keine besonderen Probleme.
      Manche erledigen mehrere Aufgaben gleichzeitig; einer ist zum Beispiel Bluetooth-Proxy im Homeoffice und steuert zugleich einen Light Strip entlang einer Skadis-Lochplatte.
      Ich verwende beliebige Markenprodukte von einem Unternehmen namens „AZDelivery“ auf Amazon und habe nichts Besonderes damit gemacht.
      Sie stecken in 3D-gedruckten Gehäusen und sind meist mit kurzen Kabeln unter 30 cm an mindestens 5V/1A-Netzteile angeschlossen.
    • Auf dem RPi nutze ich sehr gern Alpine, um Schreibzugriffe auf die SD-Karte zu reduzieren.
      Nur wenn man lbu commit -d ausführt, wird auf die Disk geschrieben; standardmäßig bootet es in eine Art tempfs.

  • Da es ein Projekt eines Studierenden an einer Universität ist und in gewissem Maße Personen-Tracking beinhaltet, wäre das eine gute Gelegenheit, einen Professor zu fragen, welche Verfahren für Forschung mit menschlichen Probanden nötig wären, falls es Forschung ist.
    Einen Professor zu fragen, kann einfacher sein als das IRB der Universität.
    Das IRB könnte das Gespräch verweigern, weil es nicht zuständig sei, oder misstrauisch werden, weil man nicht früher mit ihnen gesprochen hat.
    Auch Datenschutz- und Sicherheitsrichtlinien der Campus-IT könnten gelten.
    Normale Websites, Apps und IoT-Geräte greifen zwar viel stärker in die Privatsphäre von Menschen ein, aber Universitäten haben manchmal das Ziel, besser zu sein als die Außenwelt.

    • Genau darüber spreche ich gerade mit einem Professor.
      Ich habe es nicht in den Text aufgenommen, weil es vielleicht nicht klappt.
    • Mich würde interessieren, welche Regeln für Dinge wie Tracking-Beacons gelten.
      Beacons werden ausgesendet, und sie werden vermutlich fast überall, wo wir hingehen, ohne Zustimmung gesammelt.
      Mein Haus steht an einer Kreuzung, daher sammeln sich in der Nähe häufig viele Bluetooth-Geräte; ich hatte einmal vor, nur aus Spaß einen BLE-Tracker zu installieren, um zu sehen, was man erfassen und was man aus den Daten herausfinden kann.
      Zum Beispiel bin ich überzeugt, dass es eine Korrelation zwischen schlechter werdender Luftqualität im Haus und dem Eintreffen von Bluetooth-Geräten in der Gegend gibt.
    • Leider lügen Leute gegenüber IRBs häufig.

  • Der Satz „Bei so einem Nerd-Snipe ist es entscheidend wichtig, nicht den Schwung zu verlieren“ hat mich zum Lachen gebracht.
    Mein Nerd-Gehirn hat mich schon mehrfach genau mit dieser Logik überzeugt, Geld auszugeben.

    • Lustig, aber auch wahr.
      Es gibt eindeutig Zeiten, in denen ich stärker Lust habe, Projekte zu machen; besonders im Winter mache ich mehr Elektronikprojekte und spiele auch mehr.
      Meine Gaming-„Saison“ hat letzte Woche ebenfalls wieder angefangen.
      Der dramatische Wechsel von „Was will ich heute machen?“ zu „Worauf habe ich in dieser Saison Lust und wofür habe ich Zeit?“ hat viel mit dem Älterwerden und Kindern zu tun, aber die Abstände, in denen ich überhaupt Willen und Zeit für solche Projekte habe, sind so groß, dass ich, wenn ich den Schwung verliere, vielleicht erst ein Jahr später zurückkomme — oder gar nicht mehr.
      Ich habe ein Elektronikprojekt, das ich vor mindestens 10 Jahren begonnen habe; ich habe ziemlich viel Geld dafür ausgegeben und bestehe immer noch darauf, es irgendwann fertigzustellen, weshalb es in meiner Familie berüchtigt geworden ist.

  • Mein Wecker besteht aus einem ESP32, einem ziemlich großen LED-Array, einem Buzzer und einem PIR-Sensor.
    Er zeigt nicht die Uhrzeit an, sondern alarmiert mit Buzzer und Blinken, hellt den Raum langsam auf oder dimmt ihn nachts nach einer gewissen Zeit langsam herunter, nachdem alle Lichter ausgeschaltet wurden.
    Ein zusätzlicher Vorteil, den ich später entdeckt habe: Selbst wenn der AP nicht zwischen mir und dem ESP steht, reflektiere ich genug RF, sodass ich allein anhand der RSSI-Logs nicht nur erkennen kann, wann ich im Bett bin, sondern sogar, wann ich nachts die Position wechsle.
    https://imgur.com/a/VixOlu5
    Entgegen der Warnung gibt es keine anstößigen Inhalte.
    Das Grüne in der Mitte ist RSSI, das Gelbe unten ist der PIR-Sensor, und oben ist eine Mischung aus Mi-Band-3-Daten und Anmerkungen dazu, wann ich im Bett war.
    Stimmt auch, dass ich vor dem Einschlafen und vor dem Aufstehen lange Nachrichten gelesen habe.

    • Mich würde interessieren, wie dein Stack für Datenerfassung und Visualisierung aussah.
    • Ich würde auch gern ein Foto des oben erwähnten Wecker-Aufbaus sehen.

  • Mich würde interessieren, wie man ESP32-Projekte wie ein Produkt aufräumt.
    Ich meine damit nicht Massenproduktion, sondern dass ich statt eines Boards mit lauter herausstehenden Kabeln ein eigenständiges Gerät bauen möchte.
    Viele Seiten zeigen nur nackte Boards, aber in der Realität muss man das Ganze verpacken.
    Als jemand, der eher aus der Software-Ecke kommt, würde ich wahrscheinlich lieber etwas mehr bezahlen und dafür eine sauber aufgeräumte Form bekommen, statt selbst an allem herumzubasteln.

    • Wenn du gut in Holzarbeiten bist, nimm Holz.
      Wenn du einen 3D-Drucker hast, mach einen 3D-Druck.
      Wenn du mit Acryl arbeitest, schneidest du mit dem Lasercutter die Form aus und bohrst ein paar Löcher, dann hast du eine Box.
      Wenn du gar nichts hast und nur eine minimale Box willst, kannst du Altoids-Dosen nehmen, etwa 25 Dollar für 12 Stück; da sind nutzlose Minzbonbons drin, die wirfst du weg und packst dein Projekt hinein.
      Wenn du etwas Besseres als eine Altoids-Dose willst, kauf ein Hammond Enclosure.
      (https://www.hammfg.com/electronics/small-case)
      Ich würde es vermutlich mit Isolierband umwickeln, darüber so etwas wie Duct Tape wickeln und es dann mit einem Permanentmarker anmalen.
    • Es gibt viele Firmen, die Gehäuse für Elektronik herstellen, auch wasserdichte.
      Meist gibt es ein paar vorgebohrte Flansche, an denen man das Board festschrauben kann, und die externen Öffnungen für Ein- und Ausgänge bohrt man nach Bedarf selbst.
      Einige Hersteller sind unten aufgeführt; wenn du ohnehin ein Dev-Board oder andere Teile kaufst, findest du so etwas meist auch bei Adafruit oder Digi-Key, um Versandkosten zu sparen.
      https://www.hammfg.com/
      https://www.budind.com/
      http://takachi-enclosure.com/
      https://www.adafruit.com/product/903
    • Es gibt viele Optionen.
      Die meisten Projekte, die man sieht, werden nicht produktisiert.
      Es sind einmalige Hacker-Projekte; schön, wenn andere sie nützlich finden, aber das ist nicht das Ziel, daher braucht es keine Verpackung, und manchmal wird es einfach in eine Kiste gestopft.
      Wenn du etwas Hübscheres willst, musst du jemanden mit dem Design eines Gehäuses beauftragen.
      Dieser Jemand kannst auch du selbst sein.
      Der ESP32 ist so ausgelegt, dass man ihn leicht in eigene Produkte integrieren kann; der übliche Ablauf ist also, Leiterplatte und Gehäuse passend zueinander zu entwerfen und ESP32-Chips in Stückzahlen zu kaufen und auf die Platine zu bestücken.
      Die Boards, die man fürs Prototyping kauft, sind offiziell nur Referenzboards und nicht wirklich für die Endauslieferung gedacht, auch wenn es in der Praxis häufig vorkommt, dass genau diese Boards ausgeliefert werden.
      Denn sie sind klein, günstig, und jemand anderes hat das schwierige Board-Design bereits erledigt.
    • Lass einen „Produktdesigner“ das Gehäuse entwerfen.
      Wenn das Produkt standardisiert genug ist, kann man diesen Schritt eventuell überspringen.
      Danach kontaktiert man lokale Hersteller und Hersteller in größeren Märkten, lässt sich Muster schicken und prüft, ob alles richtig funktioniert.
      Wenn es passt, bestellt man zunächst eine kleine Stückzahl.
      Es ist sinnvoll, ein Qualitätssicherungsverfahren zu entwerfen oder jemanden zu finden, der dabei hilft, damit der Hersteller nicht 20 % Ausschuss liefert.
      Dann bringt man es in Offline-Läden oder erstellt eine Website und verkauft es über Portale wie Amazon.
      Man spricht mit Kunden, hört auf Feedback und verbessert jeden Schritt nach und nach.
      Das klingt überwältigend, aber als ich bei einem kleinen Smart-Home-Startup gearbeitet habe, habe ich gelernt, dass es in Shenzhen eine ganze Industrie gibt, die darauf vorbereitet ist, Gründern dabei zu helfen, ihre Wunschprodukte Wirklichkeit werden zu lassen, und dass man für jeden Schritt Leute beauftragen kann.
      Unserer Erfahrung nach waren die chinesischen Services viel besser, günstiger und schneller als europäische Angebote.
    • Ich befestige das Board mit Nylon-Abstandshaltern am Deckel eines Take-away-Behälters.
      Der Rest des Take-away-Behälters wird zum Gehäuse.
      Für die Kabel, die hinein- und hinausgehen, bohre ich Löcher in den Behälter.
      Wenn es etwas schicker sein soll, nehme ich einen Tupperware-Behälter.

  • Das Problem, Daten im Speicher zu halten, habe ich nicht ganz nachvollzogen, und inzwischen scheint es gelöst zu sein, aber zur Schätzung der Anzahl eindeutiger Beacon-IDs ließe sich wohl ein Kardinalitätsschätzalgorithmus verwenden, sodass nur konstanter Speicher nötig ist.
    https://en.wikipedia.org/wiki/Count-distinct_problem

    • Guter Punkt.
      Ich hatte vor, das Gerät zu einem der letzten Fußballspiele mitzunehmen, um es mit der größten schnell erreichbaren Menschenmenge einem Stresstest zu unterziehen.
      Wenn es problemlos Tausende scannen kann, würde ich es für ziemlich robust halten.
      Trotzdem wäre es wirklich interessant, Schätz-Datenstrukturen fester Größe zu untersuchen, und ich werde mir das auf jeden Fall ansehen.
      Einer der Teile, die ich an diesem Projekt am meisten mag, ist, dass ich ohne den Druck, die einfachste Lösung wählen zu müssen, tiefer in interessante Informatikkonzepte eintauchen kann.
      Ich entwickle hier keine Lösung, die ASAP ausgeliefert werden muss, sondern kratze an einer eigenen juckenden Stelle.

  • Der Abschnitt „Linux-Bluetooth headless zu verwenden, ist extrem schmerzhaft. Die DBus-Bindings erforderten Cross-Compile-Magie, und auch Cross konnte das nicht lösen“ entsprach auch meiner Erfahrung.
    Weil ich eigentlich an etwas anderem arbeitete, entschied ich mich am Ende dafür, beide Geräte ins gleiche Wi-Fi-Netz zu hängen und pi.local zu scannen.
    Mich würde allerdings interessieren, wie andere Crates damit umgehen, dass sie ohne Bibliothek den Build nicht verweigern, sondern erst zur Laufzeit crashen.

  • Es hätte klar gesagt werden müssen, dass das für BLE ist.
    Anfangs dachte ich, es basiere auf Herzfrequenz, Wärme, Zugang/Eintritt oder etwas noch Physischerem.
    Außerdem ist die Empfangsempfindlichkeit des ESP32 mit etwa -94 dBm ziemlich schlecht; die meisten Geräte kommen auf -100, -102 oder sogar -104 dBm.
    Dieser Unterschied ist ziemlich groß.

  • ESPresence ist ein interessantes Projekt und läuft auch auf dem ESP32-C3.
    Es ist eher darauf ausgelegt, zu erkennen, in welchem Raum man sich befindet.

    1. https://espresense.com/