Home / Integrar una app BLE TPMS en tu propio producto

Cuando un OEM evalúa un sensor BLE TPMS, la conversación empieza por la exactitud de presión y termina en la especificación de radio. Lo que falla de verdad está en medio: la interfaz entre el sensor y lo que el usuario final mira.

No compras un sensor, compras una ruta de datos

• En un sistema con pantalla esa interfaz es un cable y una pantalla que el proveedor vende contigo. En BLE es un protocolo de radio y una aplicación.
• Ambas cosas son negociables, y ambas deberían cerrarse antes de fabricar utillaje, no después.

Tres rutas de integración

• Ruta uno: la app del proveedor. El sensor llega con una app que ya funciona. Pones tu marca en el embalaje y el cliente descarga una aplicación de uso general. Es lo más rápido al mercado y lo más débil en propiedad de marca: la relación del cliente con el software es de otro.
• Ruta dos: una versión con tu marca de la app del proveedor. Funcionalmente es la app del proveedor, pero con tu nombre, tus colores y tus umbrales. Es el compromiso habitual para un distribuidor con catálogo y sin equipo de software.
• Ruta tres: tu app, con el sensor como componente. El sensor pasa a ser un periférico de tu producto; tu app habla con él por el servicio BLE y todo lo que ve el usuario es tuyo. Es la ruta correcta para un OEM con app propia, o para quien vende la app y no el hardware.
• La ruta elegida determina qué hay que acordar: la tres exige documentación de protocolo, código de ejemplo y una política de versiones de firmware.

Qué se puede personalizar

• Para programas OEM podemos adaptar el servicio BLE y el formato de datos. En la práctica eso cubre:
• Servicio y características — definiciones, qué valores se leen y cuáles se notifican, según la arquitectura de tu app.
• Formato de datos — orden de bytes, escalado, unidades, flags, marcas de tiempo, según tu parser y tu esquema de nube.
• Advertising e identidad — qué anuncia el sensor, cómo se nombran y filtran los equipos; importante con varios sensores por vehículo y en flotas.
• Comportamiento de alarma — umbrales, histéresis, qué condiciones disparan, según mercado y clase de vehículo. Marca de la app — nombre, icono, colores, diseño, idiomas. Marcado del sensor — láser, incluidos tus números de pieza y la posición de rueda.
• Lo que no es negociable es la medición física: el elemento sensor, la cadena de medida y la calibración de presión son el producto. La personalización ocurre por encima de esa línea.

El estado de la app, dicho claro

• Android está disponible. El APK se descarga hoy, así que una integración Android se puede evaluar de inmediato sobre hardware real.
• iOS no está publicado. En el momento de escribir esto no hay una versión iOS que entregar. Si tu plan de producto asume una app para iPhone a corto plazo, esa premisa hay que comprobarla con nosotros y no tomarla de un folleto.
• Preferimos escribirlo a que un programa lo descubra tres meses después. Si iOS está en tu ruta crítica, plantéalo en la primera conversación, incluida la ruta tres: tu equipo construye el cliente iOS contra el protocolo del sensor en lugar de esperar al nuestro. Ese es el argumento general de la ruta tres: si el protocolo está documentado y es estable, la app que va encima es tu calendario, no el de otro.

Qué implica integrar de verdad

• Descubrimiento e identificación. Un vehículo puede tener dos, tres o cuatro sensores en alcance. Tu app debe encontrar los correctos, distinguirlos de los del vehículo de al lado y asignarlos a posiciones de rueda.
• Gestión de conexiones. Las conexiones BLE no son gratis. Mantener cuatro sensores abiertos todo el tiempo agota el teléfono; consultar demasiado despacio pierde una fuga rápida. El patrón correcto depende de si el producto es un panel en vivo o un monitor en segundo plano.
• Datos ausentes. La radio pierde paquetes. Tu app necesita un comportamiento definido ante una notificación perdida: mostrar el último valor con su antigüedad, o no mostrar nada. Ambas son defendibles; presentar en silencio un valor viejo como actual, no.
• Lógica de alarma. Umbrales, compensación de temperatura, la diferencia entre una fuga lenta y una mañana fría, y qué hace la alarma con el teléfono dormido. Dónde vive esa lógica —sensor o app— se decide una vez y se escribe.

Qué acordar antes de empezar

• ¿Recibiremos la documentación del servicio BLE y del formato de datos? Sin ella la ruta tres es imposible y la dos depende del calendario de otro.
• ¿Se puede cambiar el formato de datos para nosotros o hay que aceptar el estándar? Los cambios de orden de bytes parecen pequeños y no lo son, porque afectan a todos los consumidores del dato.
• ¿Cuál es la política de versiones de firmware? Qué pasa cuando cambia el firmware y si sigue siendo compatible con tu app.
• ¿Cuál es la situación de iOS, por escrito? Una fecha o la frase clara de que no hay fecha. Las dos sirven; una respuesta vaga no.
• ¿Recibimos unidades de evaluación antes de comprometernos? Los problemas de integración aparecen en el hardware, no en los documentos.
• ¿De quién son la app y los datos del cliente? Si la relación con el cliente es tu activo, esta es la pregunta que más importa.

Dónde estamos

• Fabricamos el sensor nosotros: medición, lógica de alarma, servicio BLE y formato de datos son nuestros. Eso es lo que permite adaptar en lugar de pedir a un cliente que trabaje alrededor de una pieza fija de catálogo.
• Volumen hoy: más de 10.000 juegos al mes al mercado secundario chino de dos ruedas, con capacidad de 30.000 sensores al mes. Cada sensor se calibra en presión con nuestro propio software antes de salir; inmersión en agua, alcance de RF y verificación de protocolo se hacen en casa. La certificación se trata por mercado y por proyecto.
• Si estás integrando un sensor BLE en un producto existente y quieres saber qué habría que cambiar en cada lado, envía la forma del proyecto: vehículo, número de ruedas, plataforma de app y mercado.

← Todos los artículos

Productos · Aplicación · Contacto