Dispositivos Bluetooth Mesh con batería: ¿por qué informan pronto pero no reciben control inmediatamente?

Imagina un sensor de puerta con batería: al abrirla, llega pronto una notificación al móvil; sin embargo, cambiar sus ajustes desde el teléfono tarda en surtir efecto.

¿Por qué el mismo equipo informa rápido, pero puede recibir más despacio?

No necesariamente es mala señal ni un programa bloqueado. Un dispositivo Bluetooth Mesh de bajo consumo puede seguir ritmos distintos para transmitir y recibir.

La respuesta breve: un evento local puede despertarlo para transmitir; los mensajes enviados mientras duerme pueden quedar en un Friend hasta que los solicite. Separar ambos recorridos ayuda a localizar la espera.

Veremos cómo reducir la escucha, cómo almacena mensajes un Friend y cómo comprobar si el ahorro afecta a la respuesta necesaria.

El sensor es un ejemplo hipotético, no una medición. Hablamos de Low Power y Friend en SIG Mesh. Hay que verificar SDK, placa y plataforma; no se realizaron pruebas de autonomía o latencia.

1. Mira el diagrama: transmitir no equivale a recibir siempre

Piensa en alguien que no vigila continuamente el buzón: puede salir a entregar una carta cuando hace falta; un vecino guarda las entrantes hasta que las recoge.

El vecino es Friend; el dispositivo que usa la función de bajo consumo es Low Power Node, o LPN. La analogía explica el horario de recepción, no garantiza entrega ni permite despertar remotamente un chip dormido.

Primero comprueba: dibuja por separado el informe de eventos y la configuración remota. En el lado del móvil puede haber pasarela, nube y cachés: no atribuyas toda la espera a la radio Mesh.

2. ¿Por qué un botón envía y un cambio de ajustes espera?

Silicon Labs documenta que LPN puede transmitir sin esperar al siguiente sondeo. Que un botón o contacto lo despierte con rapidez depende del hardware y la aplicación.

• Evento local: evento → despertar y procesar → enviar → procesar en destino.
• Bajada: mensaje llega a Friend → espera recogida → LPN recibe y procesa → informa del resultado si procede.

No esperar al sondeo no garantiza rapidez extremo a extremo: también influyen muestreo, reintentos y capas superiores. Una bajada lenta tampoco demuestra que todos los eventos salientes sean lentos. Un aviso rápido de apertura no justifica prometer ajustes inmediatos.

Primero comprueba: registra evento, envío, cola de Friend, recogida de LPN y aplicación real del ajuste. No restes marcas temporales de relojes sin sincronizar.

3. ¿Por qué ahorrar requiere más que enviar menos?

Un sensor que informa pocas veces aún puede gastar mucho si mantiene el receptor encendido.

Bluetooth SIG explica Low Power mediante la reducción del ciclo de recepción. Tras establecer la relación, LPN escucha menos continuamente y recoge después los mensajes aptos que almacena Friend.

Friend no es un buzón ilimitado. El número de nodos, mensajes y suscripciones depende de implementación y recursos. Acumulación, reintentos y reconstrucciones frecuentes pueden aumentar el consumo.

Primero comprueba: identifica qué representa la curva de corriente: muestreo, exploración, envío, recogida o búsqueda de Friend. La corriente mínima del chip no representa el producto entero.

4. ¿Aumentar PollTimeout ahorra más?

No necesariamente. Distingue la frecuencia de recogida del tiempo sin contacto admisible antes de perder la relación.

El intervalo real de sondeo depende del planificador de pila y aplicación. Si quedan mensajes, puede haber sondeos adicionales.

PollTimeout es un límite de mantenimiento de la relación. Friend puede terminarla si no llegan las solicitudes correspondientes a tiempo. No es el temporizador de despertar de la aplicación ni una latencia descendente medida.

ReceiveDelay describe la espera desde la solicitud de LPN hasta comenzar a escuchar; ReceiveWindow, la ventana de recepción. Tampoco son automáticamente períodos de una operación de negocio.

Recoger con menor frecuencia suele hacer esperar algunos mensajes. Colas, reintentos y ejecución también influyen: un parámetro no garantiza un plazo máximo de entrega.

Primero comprueba: contrasta política de sondeo, parámetros de mantenimiento y tiempos observados; no trates un campo timeout como único ajuste.

5. ¿Por qué apagar una luz puede aumentar el consumo del sensor?

Supón que una lámpara compatible con Friend sirve al nodo, pero un interruptor mecánico corta su alimentación. La relación anterior ya no puede funcionar normalmente.

Silicon Labs señala que reiniciar Friend o LPN requiere restablecerla. La señal marginal con pérdidas repetidas también aumenta el gasto. Buscar continuamente en un bucle no ahorra: hay que diseñar espera progresiva y recuperación según la implementación.

La ubicación importa: el artículo de Bluetooth SIG explica que Friend Request no se retransmite. Que el tráfico normal admita varios saltos no significa que LPN encuentre Friend a cualquier número de saltos.

Friend, Relay y pasarela de aplicación son funciones diferentes. Retransmitir no implica almacenar para LPN; llamarse pasarela no garantiza exponer Friend. Tampoco debe suponerse que un nodo con batería retransmita continuamente para otros.

Primero comprueba: funciones, alcance directo y hábitos de alimentación del candidato; después ensaya cortes. No supongas migración de colas ni cambio transparente de Friend.

6. Mide la corriente media del producto antes de predecir autonomía

Entre un modo de bajo consumo y una promesa de autonomía está el producto completo: sensores, reguladores, LED, depurador y registros. La carga incluye muestreo, uso, informes, recogidas, reintentos y búsqueda.

Corriente media ≈ suma de corriente × duración de cada estado ÷ tiempo total observado.

Con una base coherente en el lado de batería: capacidad utilizable (mAh) ÷ corriente media (mA) ≈ horas de uso. Si hay conversión de tensión, incorpora eficiencia o trabaja con energía consistente; no mezcles ambos lados del convertidor.

No es una garantía: temperatura, envejecimiento, autodescarga, capacidad de pulsos y tensión de corte alteran la capacidad utilizable.

Primero comprueba: separa funcionamiento estable y recuperación de fallos. Un intervalo breve en reposo y con buena señal no representa el ciclo completo. Con poca carga, observa caídas de tensión y fallos de comunicación.

7. Guarda esta lista para las pruebas del prototipo

Son comprobaciones de ingeniería, no certificación. Usa un entorno aislado y acuerda frecuencia de uso, espera admisible y criterios de éxito antes de medir.

Síntoma	Qué revisar primero	No concluir apresuradamente
Informa, pero los ajustes esperan	Ambas rutas, sondeo, cola y aplicación	La señal debe ser mala
Reposo bajo, pero gasto total alto	Muestreo, escucha, envío, reintentos y periféricos	Cambiar pila o chip basta
Anomalías al perder alimentación Friend	Pérdida de relación, espera, reconstrucción y recuperación	Las colas migran y el cambio es transparente
Muchos ajustes producen resultados inesperados	Límites de cola, procesamiento y estado final	Cada orden histórica se conserva siempre
Faltan mensajes de grupo	Suscripciones del modelo y Friend, tráfico	Multicast garantiza éxito de todos
Fallos con poca carga	Tensión al transmitir, alimentación y recuperación	Toda la capacidad nominal es aprovechable

Registra placa, SDK, parámetros, ubicación y ventana. Desensibiliza identidades; no publiques NetKey, AppKey, DevKey ni claves privadas.

Para elegir, empieza por estas preguntas:

• ¿Predominan eventos salientes ocasionales? Evalúa LPN y Friend, midiendo la carga real.
• ¿Necesitas órdenes entrantes puntuales? Acuerda la espera y valida recepción frente al presupuesto energético.
• ¿Exiges larga espera, recepción inmediata y retransmisión continua? Comprueba compatibilidad antes de prometer autonomía.

La cuestión útil no es solo si Bluetooth Mesh admite baterías: ¿cuándo despierta, qué hace y qué ocurre cuando no puede recibir temporalmente? Responde antes de estimar duración.

Lectura adicional: selección y aceptación de Bluetooth Mesh.

Fuentes y alcance

• Bluetooth SIG: Bluetooth Mesh Networking: Friendship, 2017-08-24. Introducción histórica a mecanismos, no sustituto de la versión normativa del proyecto.
• Silicon Labs: Bluetooth Mesh Node Power Consumption, 11.0.1. Envío, ventanas, recuperación y consumo; aplica el SDK real.

Fuentes comprobadas el 2026-11-06. Es análisis documental y orientación de ingeniería, no una experiencia de laboratorio ni garantía verificada de autonomía, latencia o capacidad.