Objetivo

Algunos clientes desean utilizar una aplicación móvil en iOS o Android para recibir transmisiones de balizas Bluetooth en segundo plano, en lugar de implementar un sistema dedicado. Puerta de enlace Bluetooth. En este artículo, evaluamos si ese enfoque es técnicamente factible para el monitoreo basado en balizas de Lansitec, especialmente para dispositivos como el Etiqueta Bluetooth B002 y Baliza Bluetooth B005. La cuestión no es si un teléfono puede detectar una baliza. Sí puede. La verdadera pregunta es si una aplicación móvil puede hacerlo de forma fiable en segundo plano, a lo largo del tiempo y con la suficiente consistencia como para sustituir a una puerta de enlace.

Nuestra opinión es simple: es factible en algunos casos, pero solo bajo las condiciones adecuadas. Para teléfonos de consumo comunes y aplicaciones de uso ocasional, este método no suele ser lo suficientemente fiable como para considerarse un sustituto completo de una puerta de enlace dedicada.

El caso de uso objetivo

La arquitectura solicitada es sencilla sobre el papel. B002 o B005 El beacon emite datos BLE a intervalos configurados. Un teléfono con la aplicación del cliente instalada busca esos anuncios, lee la identificación del beacon y la intensidad de la señal, y envía el evento de detección al servidor.

Eso se ajusta a las capacidades de Lansitec. balizas. El B002 es una etiqueta BLE ultradelgada basada en iBeacon, con intervalos de publicidad configurables de 100 ms a 10 s y una distancia de transmisión en línea de visión de 150 m. B005 es una baliza IP68 más robusta con intervalos configurables, opcional Soporte de AoA, y el mismo alcance de 150 m en línea de visión.

Por lo tanto, el problema no reside en la baliza, sino en el teléfono.

¿Por qué es diferente del modelo normal de Lansitec?

En Lansitec B-Móvil solución, Pasarelas Bluetooth se despliegan en ubicaciones fijas. Balizas publicitar periódicamente, puertas de enlace reciben los datos y el servidor calcula o interpreta la ubicación basándose en las posiciones conocidas de esos puertas de enlace. Los mismos documentos también señalan que puerta La recepción está prácticamente siempre activa en el modelo de despliegue previsto, y eso RSSI pueden variar debido a las paredes, las interferencias y los efectos de trayectos múltiples.

Tener la aplicación en este lugar cambia por completo el diseño de la solución.

Un fijo puerta Te ofrece tres cosas que un teléfono normal no tiene:

• una posición física conocida
• comportamiento de potencia estable
• disponibilidad de recepción predecible

Esta es la primera advertencia que haríamos a cualquier cliente. Aunque la aplicación detecte la baliza, un teléfono en movimiento no es funcionalmente equivalente a uno fijo. puerta.

Viabilidad de iOS

En iOS, es posible que Bluetooth funcione en segundo plano, pero con limitaciones. Apple indica que las aplicaciones que solo se ejecutan en primer plano no pueden buscar ni detectar periféricos que emitan publicidad mientras están en segundo plano o suspendidas. Las aplicaciones que declaran el modo de segundo plano Bluetooth-central aún pueden detectar y conectarse a periféricos en segundo plano, pero el escaneo en segundo plano se comporta de manera diferente: los descubrimientos duplicados se agrupan y los intervalos de escaneo pueden aumentar, lo que significa que el descubrimiento puede tardar más. Apple también señala que las aplicaciones que se activan por eventos de Bluetooth deberían finalizar rápidamente, y menciona aproximadamente 10 segundos para el trabajo en segundo plano antes de que la presión de suspensión se convierta en un problema. ⁽¹⁾

Existe una solución útil para iOS: la monitorización de regiones mediante balizas. El marco de trabajo Core Location de Apple puede monitorizar las regiones de iBeacon y activar la aplicación al entrar o salir de ellas. Sin embargo, existen algunas limitaciones. Apple limita la monitorización de regiones a 20 por aplicación y recomienda explícitamente medir la distancia de las balizas solo cuando la aplicación esté en primer plano. ⁽²⁾

¿Qué significa eso en la práctica?

En iOS, una aplicación puede admitir comportamientos en segundo plano relacionados con balizas, especialmente flujos de trabajo básicos de "entrada/salida de región". Sin embargo, no es una buena plataforma para el escaneo pasivo continuo, similar al de una puerta de enlace, en una implementación a gran escala. Si el cliente busca un teléfono que esté siempre a la escucha y que funcione silenciosamente como infraestructura, iOS es la opción menos recomendable.

Viabilidad de Android

Android es más flexible, pero no hace milagros. La guía actual para desarrolladores de Google indica que la comunicación BLE en segundo plano es posible, pero el proceso de la aplicación debe permanecer activo. Si el proceso se interrumpe, las conexiones se cierran. Google también señala que los escaneos sin filtrar se detienen cuando la pantalla se apaga y se reanudan cuando se enciende, a menos que se utilice el escaneo filtrado.

Para su uso en segundo plano, Android documenta varias opciones: escanear con un PendingIntent, usar CompanionDeviceService, usar WorkManager o ejecutar un servicio en primer plano con el tipo connectedDevice. Google también desaconseja los escaneos periódicos como solución general, ya que son ineficientes y pueden interrumpirse. A partir de Android 14, los servicios en primer plano deben declarar explícitamente el tipo de servicio correspondiente. ⁽³⁾

Este es el punto clave: Android puede hacerlo mejor que iOS, pero la fiabilidad depende en gran medida de la disciplina en la implementación.

Un teléfono Android de consumo normal puede detener la aplicación debido a la optimización de la batería del fabricante, la configuración del usuario, las restricciones en segundo plano o la presión de memoria. Para garantizar que el proceso no se interrumpa en segundo plano, podría ser necesario un dispositivo Android de grado industrial personalizado. Un dispositivo gestionado con listas blancas, gestión de aplicaciones de alta prioridad, configuración de energía controlada y un flujo de trabajo específico para cada rol tiene muchas más probabilidades de éxito.

Cuando el enfoque de la aplicación puede funcionar

Hemos visto tres situaciones en las que la idea de usar una aplicación es razonable.

En primer lugar, cuando la aplicación se encuentra en uso operativo continuo y efectivo.

Esto podría funcionar en casos donde el usuario mantiene la aplicación abierta durante su turno, o si el teléfono está instalado y se utiliza como parte de un proceso de trabajo; en ese caso, la recepción de la señal se vuelve mucho más realista. Un ejemplo sería si está instalado en un vehículo o maquinaria de construcción, como en la aplicación de Uber Driver.

Segundo, cuando el hardware está controlado

Un teléfono Android robusto o personalizado, especialmente uno gestionado por la empresa, es mucho mejor que un teléfono personal cualquiera. En este caso, el teléfono no es una plataforma de aplicaciones móviles común, sino un terminal semidedicado. Por lo tanto, se espera un mayor grado de personalización y sería razonable que el software se personalizara de forma que el proceso sea viable.

En tercer lugar, cuando el requisito es la detección de eventos, no la localización a nivel de infraestructura.

Si el cliente solo necesita que se detecte una baliza, que la baliza esté cerca del teléfono o que un trabajador haya entrado en una zona con un dispositivo gestionado, entonces la aplicación puede ser suficiente. Si necesitan una monitorización estable a nivel de habitación o de sitio, independientemente del comportamiento del usuario, entonces no, eso es puerta territorio.

Principales limitaciones que deben indicarse claramente

El enfoque de la aplicación tiene estas limitaciones fundamentales:

• La ejecución en segundo plano está controlada por el sistema operativo. Tanto iOS como Android optimizan agresivamente sus sistemas para maximizar la duración de la batería. 
• Un teléfono no es una infraestructura fija. En B-Móvil, fijado puerta La posición forma parte de la lógica de seguimiento.
• RSSI es inestable. Los propios documentos de Lansitec señalan una recepción débil entre habitaciones, RSSI oscilaciones y efectos de trayectorias múltiples.
• El comportamiento del usuario importa. Si el usuario cierra la aplicación, desactiva los permisos, desactiva el Bluetooth o permite que el teléfono entre en un modo de ahorro de energía agresivo, el rendimiento disminuye.
• La variabilidad entre plataformas es real. Especialmente en Android, el comportamiento difiere entre fabricantes, ya que no es raro encontrar una fuerte personalización basada en la marca, a diferencia de iOS, donde Apple tiene un control centralizado.

Recomendaciones prácticas

Para un cliente que insiste en utilizar una aplicación, recomendamos lo siguiente.

Usar Android, no iOS, Para la prueba de concepto inicial, desarrolle la aplicación en torno a escaneos BLE filtrados, comportamiento de servicio en primer plano cuando esté permitido y administración de dispositivos empresariales. Si es posible, utilice dispositivos robustos o personalizados. Mantenga la aplicación vinculada a un flujo de trabajo operativo, no a un uso ocasional. Considere la aplicación como un terminal administrado, no como una instalación casual desde una tienda de aplicaciones.

Para iOS, la solución debe ser más específica. Puede admitir alertas, indicaciones de presencia o flujos de trabajo controlados en regiones de balizas, pero no un reemplazo completo de la puerta de enlace en implementaciones exigentes.

Y para los clientes que necesitan una cobertura de sitio consistente, una dependencia mínima del comportamiento del usuario y un punto de referencia estable para el seguimiento, mantengan el dedicado Puerta de enlace Bluetooth arquitectura. Esa sigue siendo la mejor solución desde una perspectiva de ingeniería y funcionalidad estable.

Conclusión

Sí, una aplicación móvil puede recibir transmisiones de balizas en segundo plano. Pero eso no la convierte automáticamente en un buen sustituto de una Puerta de enlace Bluetooth.

En iOS, este enfoque es limitado y, en el mejor de los casos, debe considerarse condicional. En Android estándar, es posible, pero frágil. En dispositivos Android personalizados o industriales, especialmente en un entorno operativo controlado, se vuelve mucho más viable.

Por lo tanto, la conclusión final es la siguiente:

Una solución de monitoreo en segundo plano solo para aplicaciones es factible para implementaciones de Android seleccionadas con dispositivos controlados y uso continuo de la aplicación. No es un reemplazo general confiable para las soluciones fijas. Pasarelas Bluetooth, especialmente en iOS o en teléfonos de consumo no gestionados.

Referencias y lecturas adicionales:

1. Apple: Guía de programación de Bluetooth básico
2. Apple: Guía de programación de Ubicación y Mapas
3. Android: Comunicación BLE en segundo plano