But

Certains clients souhaitent utiliser une application mobile sur iOS ou Android pour recevoir en arrière-plan les émissions des balises Bluetooth, au lieu de déployer un système dédié. Passerelle Bluetooth. Dans cet article, nous évaluons la faisabilité technique de cette approche pour la surveillance par balises Lansitec, notamment pour des dispositifs tels que… Étiquette Bluetooth B002 et Balise Bluetooth B005. La question n'est pas de savoir si un téléphone peut détecter une balise. Il le peut. La vraie question est de savoir si une application mobile peut le faire de manière fiable en arrière-plan, sur la durée et avec une constance suffisante pour remplacer une passerelle.

Notre point de vue est simple : cette solution est envisageable dans certains cas, mais uniquement sous certaines conditions. Pour les téléphones grand public et les applications d’usage courant, elle n’est généralement pas suffisamment fiable pour remplacer une passerelle dédiée.

Le cas d'utilisation cible

L'architecture demandée est simple sur le papier. B002 ou B005 La balise émet des données BLE à intervalles réguliers. Un téléphone exécutant l'application du client recherche ces émissions, lit l'identifiant de la balise et la puissance du signal, puis transmet l'événement de détection au serveur.

Cela correspond aux capacités de Lansitec balises. Le B002 Il s'agit d'une étiquette BLE ultra-mince basée sur iBeacon, avec des intervalles de publicité configurables de 100 ms à 10 s et une distance de transmission en visibilité directe de 150 m. B005 est une balise IP68 plus robuste avec des intervalles configurables, en option Soutien AoA, et la même portée en visée directe de 150 m.

Le problème ne vient donc pas de la balise, mais du téléphone.

Pourquoi cela diffère-t-il du modèle Lansitec normal ?

Chez Lansitec B-Mobile solution, Passerelles Bluetooth sont déployés à des endroits fixes. Balises faire de la publicité périodiquement, passerelles Le serveur reçoit les données et calcule ou interprète la position en fonction des positions connues de ces passerelles. Ces mêmes documents indiquent également que porte La réception est effectivement toujours active dans le modèle de déploiement prévu, et ce RSSI peuvent varier en raison des murs, des interférences et des effets de trajets multiples.

Le fait d'avoir l'application à cet endroit change complètement la conception de la solution.

Un fixe porte vous offre trois choses qu'un téléphone normal n'offre pas :

• une position physique connue
• comportement de puissance stable
• disponibilité prévisible de la réception

Voici la première mise en garde que nous adressons à tout client. Même si l'application détecte le signal de la balise, un téléphone en mouvement n'est pas fonctionnellement équivalent à un téléphone fixé au sol. porte.

Faisabilité iOS

Sur iOS, le fonctionnement Bluetooth en arrière-plan est possible, mais limité. Apple précise que les applications fonctionnant exclusivement au premier plan ne peuvent pas rechercher et détecter les périphériques Bluetooth lorsqu'elles sont en arrière-plan ou suspendues. Les applications qui activent le mode Bluetooth en arrière-plan peuvent toujours détecter et se connecter aux périphériques, mais le comportement de la recherche en arrière-plan est différent : les découvertes en double sont fusionnées et les intervalles de recherche peuvent augmenter, ce qui peut allonger le temps de détection. Apple indique également que les applications activées par des événements Bluetooth doivent se terminer rapidement et précise qu'il faut compter environ 10 secondes pour le fonctionnement en arrière-plan avant que la suspension ne devienne problématique. ⁽¹⁾

Il existe une solution de contournement utile sous iOS : la surveillance des zones de détection. Le framework Core Location d’Apple peut surveiller les zones iBeacon et réactiver l’application lors d’événements d’entrée ou de sortie. Cependant, cette solution présente des inconvénients. Apple limite la surveillance à 20 zones par application et recommande explicitement d’effectuer la détection de zone uniquement lorsque l’application est au premier plan. ⁽²⁾

Concrètement, qu'est-ce que cela signifie ?

Sous iOS, une application peut gérer les comportements en arrière-plan liés aux balises, notamment les flux de travail généraux de type “ entrée/sortie de zone ”. Cependant, iOS n'est pas une plateforme adaptée à une analyse passive continue, de type passerelle, sur un déploiement à grande échelle. Si le client souhaite un téléphone toujours à l'écoute et fonctionnant discrètement comme une infrastructure, iOS est la solution la moins performante.

Faisabilité Android

Android offre plus de flexibilité, mais ce n'est pas de la magie. Les recommandations actuelles de Google pour les développeurs indiquent que la communication BLE en arrière-plan est possible, à condition que le processus de l'application reste actif. Si ce processus est arrêté, les connexions sont interrompues. Google précise également que les analyses non filtrées sont interrompues lorsque l'écran s'éteint et reprennent lorsqu'il se rallume, sauf si une analyse filtrée est utilisée.

Pour une utilisation en arrière-plan, Android propose plusieurs solutions : l’analyse via un PendingIntent, l’utilisation de CompanionDeviceService ou de WorkManager, ou l’exécution d’un service de premier plan de type connectedDevice. Google déconseille également les analyses périodiques, car elles sont inefficaces et peuvent être interrompues. À partir d’Android 14, les services de premier plan doivent déclarer explicitement leur type. ⁽³⁾

Voici le point essentiel : Android peut le faire mieux qu’iOS, mais la fiabilité dépend fortement de la rigueur du déploiement.

Un smartphone Android grand public classique peut interrompre l'application en raison de l'optimisation de la batterie par le fabricant, des paramètres utilisateur, des restrictions d'exécution en arrière-plan ou d'une saturation de la mémoire. Un appareil Android industriel personnalisé peut être nécessaire pour garantir que le processus ne soit pas interrompu en arrière-plan. Un appareil géré avec une liste blanche, une gestion prioritaire des applications, des paramètres d'alimentation contrôlés et un flux de travail adapté aux rôles offre de bien meilleures chances de succès.

Quand l'approche par application peut fonctionner

Nous avons constaté trois situations où l'idée d'une application mobile est pertinente.

Premièrement, lorsque l'application est effectivement en utilisation opérationnelle continue

Cela pourrait fonctionner lorsque l'utilisateur garde l'application ouverte pendant son service, ou lorsque le téléphone est fixé et utilisé dans le cadre d'un processus de travail ; la réception du signal par balise devient alors beaucoup plus réaliste. Par exemple, si le téléphone est installé dans un véhicule ou un engin de chantier, comme une application pour chauffeurs Uber.

Deuxièmement, lorsque le matériel est contrôlé

Un smartphone Android robuste ou personnalisé, surtout s'il est géré par l'entreprise, est bien plus performant qu'un téléphone personnel standard. Dans ce cas, il ne s'agit pas d'une simple plateforme d'applications mobiles, mais d'un terminal semi-dédié. De ce fait, un haut degré de personnalisation est attendu et il serait judicieux que le logiciel soit adapté pour faciliter le processus.

Troisièmement, lorsque l'exigence est la détection d'événements et non la localisation à l'échelle de l'infrastructure.

Si le client a seulement besoin de savoir si une balise a été détectée, si une balise est proche du téléphone ou si un employé est entré dans une zone avec un terminal géré, alors l'application peut suffire. S'ils ont besoin d'une surveillance stable au niveau de la pièce ou du site, indépendante du comportement des utilisateurs, alors non, c'est le cas. porte territoire.

Principales limitations à énoncer clairement

L'approche par application présente les limitations fondamentales suivantes :

• L'exécution en arrière-plan est contrôlée par le système d'exploitation. iOS et Android optimisent tous deux de manière intensive l'autonomie de la batterie. 
• Un téléphone n'est pas une infrastructure fixe. Dans B-Mobile, fixé porte La position fait partie de la logique de suivi.
• RSSI est instable. Les documents de Lansitec font état d'une faible réception entre les pièces., RSSI oscillations et effets multi-trajets.
• Le comportement des utilisateurs est important. Si l'utilisateur fait glisser l'application pour la fermer, désactive les autorisations, coupe le Bluetooth ou laisse le téléphone passer en mode d'économie d'énergie agressif, les performances diminuent.
• Les différences entre les plateformes sont bien réelles. Sur Android notamment, le comportement diffère selon les fabricants, car il n'est pas rare d'observer une forte personnalisation liée à la marque, contrairement à iOS où Apple exerce un contrôle centralisé.

Recommandations pratiques

Pour un client qui insiste sur l'utilisation d'une application, nous recommandons ce qui suit.

Utiliser Android, pas iOS, Pour la preuve de concept initiale, l'application doit s'appuyer sur des analyses BLE filtrées, le comportement des services de premier plan lorsque cela est autorisé et la gestion des appareils d'entreprise. Il est recommandé d'utiliser des appareils robustes et personnalisés si possible. L'application doit être intégrée à un flux de travail opérationnel et non utilisée occasionnellement. Elle doit être considérée comme un terminal géré et non comme une application installée ponctuellement depuis une boutique d'applications.

Pour iOS, la solution doit être plus ciblée. Elle peut prendre en charge les alertes, les indications de présence ou les flux de travail contrôlés par zone de balise, mais pas le remplacement complet de la passerelle dans les déploiements exigeants.

Et pour les clients qui ont besoin d'une couverture de site constante, d'une dépendance minimale au comportement des utilisateurs et d'un point de référence stable pour le suivi, conservez la solution dédiée. Passerelle Bluetooth L'architecture. C'est encore la meilleure solution du point de vue de l'ingénierie et de la stabilité fonctionnelle.

Conclusion

Oui, une application mobile peut recevoir des signaux de balise en arrière-plan. Mais cela n'en fait pas automatiquement un bon substitut à un Passerelle Bluetooth.

Sur iOS, cette approche est limitée et ne doit être considérée que sous certaines conditions. Sur Android standard, elle est possible mais fragile. Sur les appareils Android personnalisés ou industriels, notamment dans un environnement opérationnel géré, elle devient beaucoup plus réaliste.

La conclusion finale est donc la suivante :

Une solution de surveillance en arrière-plan basée uniquement sur une application est envisageable pour certains déploiements Android avec des appareils contrôlés et une utilisation continue de l'application. Elle ne constitue pas une solution de remplacement fiable et générale pour les solutions fixes. Passerelles Bluetooth, notamment sur iOS ou sur les téléphones grand public non gérés.

Références et lectures complémentaires :

1. Apple : Guide de programmation Bluetooth de base
2. Apple : Guide de programmation de la localisation et des cartes
3. Android : communication BLE en arrière-plan