Zweck

Einige Kunden möchten Bluetooth-Beacon-Signale im Hintergrund per Mobil-App unter iOS oder Android empfangen, anstatt ein dediziertes Bluetooth-Gateway einzusetzen. In diesem Beitrag untersuchen wir, ob dieser Ansatz für die Beacon-basierte Überwachung von Lansitec technisch realisierbar ist, insbesondere für Geräte wie beispielsweise … B002 Bluetooth-Etikett Und B005 Bluetooth Beacon. Die Frage ist nicht, ob ein Smartphone überhaupt ein Beacon-Signal empfangen kann. Das kann es. Die eigentliche Frage ist, ob eine Smartphone-App dies zuverlässig im Hintergrund, über einen längeren Zeitraum und mit ausreichender Konsistenz leisten kann, um ein Gateway zu ersetzen.

Unsere Ansicht ist einfach: In manchen Fällen ist es machbar, aber nur unter den richtigen Bedingungen. Für handelsübliche Mobiltelefone und gelegentlich genutzte Apps ist dieser Ansatz in der Regel nicht zuverlässig genug, um als vollständiger Ersatz für ein dediziertes Gateway zu gelten.

Der Zielanwendungsfall

Die gewünschte Architektur ist auf dem Papier unkompliziert. B002 oder B005 Ein Beacon sendet in einem konfigurierten Intervall BLE-Daten. Ein Smartphone, auf dem die App des Kunden läuft, sucht nach diesen Daten, liest die Beacon-ID und die Signalstärke aus und lädt das Erkennungsereignis an den Server hoch.

Das passt zu den Fähigkeiten von Lansitec. Leuchtfeuer. Der B002 ist ein ultradünnes BLE-Label auf iBeacon-Basis mit konfigurierbaren Werbeintervallen von 100 ms bis 10 s und einer angegebenen Sichtlinien-Übertragungsreichweite von 150 m. B005 ist ein robusteres IP68-Leuchtfeuer mit konfigurierbaren Intervallen, optional AoA-Unterstützung, und die gleiche angegebene Sichtlinienreichweite von 150 m.

Das Problem liegt also nicht auf der Beacon-Seite, sondern auf der Telefonseite.

Warum unterscheidet sich dieses Modell vom normalen Lansitec-Modell?

In Lansitecs B-Mobile Lösung, Bluetooth-Gateways werden an festen Standorten eingesetzt. Leuchtfeuer regelmäßig werben, Gateways Die Daten werden empfangen, und der Server berechnet oder interpretiert den Standort anhand der bekannten Positionen dieser Objekte. Gateways. In denselben Dokumenten wird auch darauf hingewiesen, dass Tor Im vorgesehenen Bereitstellungsmodell ist der Empfang praktisch immer aktiv, und das RSSI kann aufgrund von Wänden, Interferenzen und Mehrwegeausbreitung variieren.

Die Platzierung der App an diesem Ort verändert das gesamte Lösungsdesign.

Ein fester Tor bietet Ihnen drei Dinge, die ein normales Handy nicht bietet:

• eine bekannte physische Position
• stabiles Leistungsverhalten
• vorhersehbare Empfangsverfügbarkeit

Dies ist der erste wichtige Hinweis, den wir jedem Kunden geben möchten. Selbst wenn die App das Beacon-Signal empfängt, ist ein sich bewegendes Smartphone nicht mit einem fest installierten Gerät vergleichbar. Tor.

iOS-Machbarkeit

Unter iOS ist Bluetooth-Nutzung im Hintergrund zwar möglich, aber eingeschränkt. Apple gibt an, dass Apps, die nur im Vordergrund ausgeführt werden, im Hintergrund oder im Ruhezustand keine werbenden Peripheriegeräte suchen und erkennen können. Apps, die den Bluetooth-zentrierten Hintergrundmodus aktivieren, können zwar weiterhin Peripheriegeräte im Hintergrund erkennen und sich mit ihnen verbinden, die Hintergrundsuche verhält sich jedoch anders: Doppelte Erkennungen werden zusammengefasst, und die Suchintervalle können sich verlängern, wodurch die Suche länger dauern kann. Apple gibt außerdem an, dass Apps, die für Bluetooth-Ereignisse aktiviert werden, schnell fertig sein sollten und dass Hintergrundprozesse etwa 10 Sekunden dauern, bevor der Ruhezustand beeinträchtigt wird. ⁽¹⁾

Es gibt eine nützliche iOS-Lösung: die Überwachung von Beacon-Regionen. Apples Core Location Framework kann iBeacon-Regionen überwachen und die App bei Eintritt oder Austritt aktivieren. Allerdings gibt es Einschränkungen. Apple beschränkt die Regionsüberwachung auf 20 Regionen pro App und empfiehlt ausdrücklich, die Beacon-Ortung nur dann durchzuführen, wenn die App im Vordergrund läuft. ⁽²⁾

Was bedeutet das also in der Praxis?

Für iOS kann eine App Beacon-bezogene Hintergrundfunktionen unterstützen, insbesondere grobe Workflows wie “Region betreten/verlassen”. Für kontinuierliches, Gateway-ähnliches passives Scannen in einer weitverbreiteten Umgebung ist iOS jedoch keine geeignete Plattform. Wenn der Kunde ein permanent aktives Smartphone wünscht, das unauffällig als Infrastruktur fungiert, ist iOS die unzureichende Wahl.

Android-Machbarkeit

Android bietet mehr Flexibilität, ist aber keine Zauberei. Laut Googles aktuellen Entwicklerrichtlinien ist die BLE-Kommunikation im Hintergrund möglich, solange der App-Prozess aktiv bleibt. Wird der Prozess beendet, werden die Verbindungen getrennt. Google weist außerdem darauf hin, dass ungefilterte Scans beim Ausschalten des Bildschirms gestoppt und beim Einschalten fortgesetzt werden, sofern kein gefilterter Scan verwendet wird.

Für die Hintergrundnutzung beschreibt Android verschiedene Vorgehensweisen: Scannen mit einem PendingIntent, Verwendung des CompanionDeviceService, Verwendung des WorkManager oder Ausführen eines Vordergrunddienstes mit dem Typ „connectedDevice“. Google rät generell von regelmäßigen Scans ab, da diese ineffizient sind und dennoch unterbrochen werden können. Ab Android 14 müssen Vordergrunddienste den entsprechenden Diensttyp explizit deklarieren. ⁽³⁾

Das ist der entscheidende Punkt: Android kann das besser als iOS, aber die Zuverlässigkeit hängt stark von der Disziplin bei der Bereitstellung ab.

Ein normales Android-Smartphone kann die App aufgrund von Akkuoptimierungen des Herstellers, Benutzereinstellungen, Hintergrundbeschränkungen oder Speichermangel weiterhin beenden. Um sicherzustellen, dass der Prozess im Hintergrund nicht beendet wird, ist möglicherweise ein speziell angepasstes, industrietaugliches Android-Gerät erforderlich. Ein verwaltetes Gerät mit Whitelisting, priorisierter App-Behandlung, kontrollierten Energieeinstellungen und rollenspezifischem Workflow bietet deutlich bessere Chancen.

Wenn der App-Ansatz funktionieren kann

Wir haben drei Situationen gesehen, in denen die App-basierte Idee sinnvoll ist.

Erstens, wenn die App effektiv im kontinuierlichen Betrieb ist.

Dies könnte in Fällen funktionieren, in denen der Nutzer die App während einer Schicht geöffnet lässt oder das Telefon in einem Arbeitsablauf montiert ist und verwendet wird; der Empfang von Beacons wird dadurch deutlich realistischer. Ein Beispiel wäre die Montage in einem Fahrzeug oder einer Baumaschine, ähnlich wie bei einer Uber-Fahrer-App.

Zweitens, wenn die Hardware gesteuert wird

Ein robustes oder individuell angepasstes Android-Smartphone, insbesondere eines vom Unternehmen verwalteten, ist einem beliebigen Privatgerät deutlich überlegen. Hierbei handelt es sich nicht um eine einfache Plattform für mobile Apps, sondern um ein dediziertes Endgerät. Daher ist ein höherer Grad an Anpassungsmöglichkeiten zu erwarten, und es wäre sinnvoll, die Software so zu konfigurieren, dass der Prozess praktikabel wird.

Drittens, wenn die Anforderung die Ereigniserkennung und nicht die Standortbestimmung auf Infrastrukturebene ist.

Wenn der Kunde lediglich die Meldung “Beacon gesehen”, “Beacon in der Nähe des Telefons” oder “Mitarbeiter hat eine Zone mit einem verwalteten Mobiltelefon betreten” benötigt, dann ist die App möglicherweise ausreichend. Wenn sie eine stabile Überwachung auf Raum- oder Standortebene unabhängig vom Nutzerverhalten benötigen, dann nein, das heißt Tor Gebiet.

Wichtigste Einschränkungen, die klar benannt werden sollten

Der App-Ansatz weist folgende grundlegende Einschränkungen auf:

• Die Hintergrundausführung wird vom Betriebssystem gesteuert. Sowohl iOS als auch Android optimieren aggressiv auf maximale Akkulaufzeit. 
• Ein Telefon ist keine feste Infrastruktur. In B-Mobile, fest Tor Die Position ist Teil der Tracking-Logik.
• RSSI ist instabil. In den eigenen Dokumenten von Lansitec wird auf eine schwache Raumüberbrückung hingewiesen., RSSI Schwingungen und Mehrwegeausbreitung.
• Das Nutzerverhalten ist wichtig. Wenn der Benutzer die App wegwischt, Berechtigungen deaktiviert, Bluetooth ausschaltet oder das Telefon in einen aggressiven Energiesparmodus versetzt, sinkt die Leistung.
• Plattformunterschiede sind real. Insbesondere bei Android unterscheidet sich das Verhalten je nach Hersteller, da starke markenspezifische Anpassungen nicht unüblich sind, im Gegensatz zu iOS, wo Apple die Kontrolle zentralisiert hat.

Praktische Empfehlungen

Für einen Kunden, der auf der App-Lösung besteht, empfehlen wir Folgendes.

Verwenden Android, nicht iOS, Für den primären Machbarkeitsnachweis. Aufbauend auf gefilterten BLE-Scans, Vordergrunddienstverhalten (sofern zulässig) und Enterprise-Geräteverwaltung. Nach Möglichkeit robuste/kundenspezifische Geräte verwenden. Die App sollte in einen operativen Workflow eingebunden und nicht nur gelegentlich genutzt werden. Sie sollte als verwaltetes Terminal und nicht als zufällige Installation aus einem App Store behandelt werden.

Für iOS sollte die Lösung enger gefasst werden. Sie kann Benachrichtigungen, Anwesenheitshinweise oder kontrollierte Workflows in Beacon-Regionen unterstützen, jedoch keinen vollständigen Gateway-Ersatz in anspruchsvollen Umgebungen.

Für Kunden, die eine durchgängige Standortabdeckung, minimale Abhängigkeit vom Nutzerverhalten und einen stabilen Referenzpunkt für die Standortverfolgung benötigen, empfiehlt sich weiterhin die dedizierte Bluetooth-Gateway-Architektur. Dies ist nach wie vor die beste Lösung hinsichtlich technischer Machbarkeit und stabiler Funktionalität.

Abschluss

Ja, eine mobile App kann Beacon-Signale im Hintergrund empfangen. Das macht sie aber nicht automatisch zu einem guten Ersatz für ein Bluetooth-Gateway.

Unter iOS ist dieser Ansatz eingeschränkt und sollte bestenfalls als bedingt betrachtet werden. Auf Standard-Android ist er zwar möglich, aber fehleranfällig. Auf kundenspezifisch angepassten oder industriellen Android-Geräten, insbesondere in einer verwalteten Betriebsumgebung, wird er deutlich realistischer.

Die abschließende Schlussfolgerung lautet also:

Eine App-basierte Hintergrundüberwachungslösung ist für ausgewählte Android-Installationen mit kontrollierten Geräten und kontinuierlicher App-Nutzung praktikabel. Sie ist jedoch kein zuverlässiger allgemeiner Ersatz für eine feste Überwachung. Bluetooth-Gateways, insbesondere auf iOS-Geräten oder auf nicht verwalteten Mobiltelefonen von Endverbrauchern.

Referenzen und weiterführende Literatur:

1. Apple: Leitfaden zur Bluetooth-Programmierung (Kernbereich)
2. Apple: Programmierleitfaden für Standortdienste und Karten
3. Android: BLE-Kommunikation im Hintergrund