Control de grupos Bluetooth Mesh: una luz no se enciende, ¿hay que reenviar a todas?

Imagina que pulsas «encender todas» en una sala. Casi todas las luces se encienden, salvo una en la esquina. Sin embargo, el móvil muestra «envío correcto».

Pulsas de nuevo y ahora funcionan todas. Pero ¿habrá que mirar al techo después de cada orden de grupo?

La solución evidente es que cada luz responda «recibido» y repetir cuando falte una respuesta. Eso aporta información, pero muchas respuestas simultáneas y consultas repetidas también pueden sobrecargar la red.

Respuesta breve: no reenvíes automáticamente al grupo entero por falta de información. Distingue si se envió la orden, qué estado notificó el dispositivo y si la luz se encendió físicamente. Son pruebas distintas.

La sala es un ejemplo hipotético, no una prueba de campo. Hablamos de multidifusión y mensajes de modelo en SIG Mesh, no de la implementación de productos como Mijia. No se midieron tasas de éxito, latencia ni capacidad de nodos. La gestión de estados y compensación propuesta es orientación de ingeniería, no una solución completa que el protocolo aporte automáticamente.

1. ¿Hasta dónde llega un «envío correcto»?

Puede significar que la aplicación entregó la solicitud a la pasarela o que el módulo aceptó una tarea de transmisión. Comprueba la interfaz y los registros, no lo deduzcas del texto.

Separa tres niveles de evidencia:

El emisor aceptó la tarea. La solicitud llegó a una etapa de envío; eso no demuestra recepción en la luz.

El modelo de destino notificó su estado. Generic OnOff Status informa del estado Generic OnOff del elemento correspondiente. Identifica el origen y distingue valor presente, objetivo y tiempo de transición restante cuando proceda.

La iluminación física cumple lo exigido. También depende del controlador de potencia, la alimentación, la fuente luminosa y el entorno. Que el modelo diga «encendido» no equivale a una medición óptica independiente ni descarta una avería del LED o su controlador.

No hacen falta tres confirmaciones para cada operación. Lo importante es que la evidencia respalde exactamente lo que afirma la interfaz.

Comprueba primero: el código o contrato de interfaz que produce el aviso. ¿Es puesta en cola, resultado del módulo o estado del destino? Sin esa definición, incluso la estadística de éxito puede partir de una base errónea.

2. Una orden de grupo no es un recibo firmado por todos

SIG Mesh suele controlar grupos mediante publicación y suscripción: un interruptor envía a una dirección de grupo y los modelos pertinentes de las luces se suscriben a ella. Es hablar una vez a «la sala», no llamar individualmente a cada luz.

Esto evita enviar por separado la misma intención. Pero la dirección de grupo no genera una lista completa de miembros que ejecutaron la orden.

La gestión debe conocer los miembros esperados. ¿Se configuró la suscripción del modelo de la nueva luz? ¿Sigue el dispositivo sustituido en el inventario antiguo? Unas cuantas notificaciones no reconstruyen esa lista de forma fiable.

Tampoco basta contar paquetes: hay que cotejar elementos y modelos esperados. Los duplicados de un origen no son más dispositivos que hayan terminado.

Comprueba primero: inventario de instalación, modelos, vinculación de AppKey y suscripciones. Si una luz falla siempre, confirma que pertenece al grupo antes de aumentar todos los parámetros de relé y retransmisión.

3. ¿No sería más fiable que respondieran todas?

Con Generic OnOff:

• Generic OnOff Set requiere respuesta: Generic OnOff Status.
• Generic OnOff Set Unacknowledged no exige una respuesta del modelo a esa solicitud.

Hablamos de respuesta de la capa de modelo, no de un «ACK» que mezcle confirmaciones de transporte, respuestas de la API de la pasarela y ejecución física.

Esperar una respuesta concreta puede ser útil en operaciones individuales. Pero si muchos nodos responden a una sola orden de grupo, el consumo de radio deja de ser únicamente el de esa orden.

Bluetooth SIG explica que respuestas de multidifusión, nuevas consultas y reintentos pueden crear un flujo denso de mensajes. Por eso destaca el uso de mensajes sin confirmación para control multidifusión, en vez de exigir siempre pasar lista.

No significa entrega garantizada sin confirmación, ni prohíbe órdenes de grupo con respuesta. Significa presupuestar control y confirmación según la aplicación. Más respuestas no equivalen automáticamente a más fiabilidad.

No exigir una respuesta a esta solicitud tampoco impide que el dispositivo publique estados. La publicación y las respuestas a solicitudes son comportamientos y configuraciones diferentes.

Comprueba primero: el mensaje enviado, la respuesta esperada y las publicaciones configuradas. Decide después qué reintentos tienen sentido.

4. Sin estado recibido, empieza por «desconocido», no «fallo»

Puede que no llegara la orden, que se ejecutara pero fallara el retorno del estado, que continúe una transición o que se confundiera un informe antiguo con un resultado nuevo. Un simple indicador de respuesta no los distingue.

Una interfaz más honesta puede mostrar:

• Solicitado: intención enviada, todavía sin evidencia suficiente del destino.
• Estado confirmado: se recibió un estado que satisface los criterios de la operación, con origen y hora registrados.
• Pendiente de comprobar: faltan pruebas suficientes dentro de la ventana acordada.

Son sugerencias de aplicación, no nuevos estados estándar de Mesh.

La confirmación tampoco dura para siempre. Un interruptor, sensor o automatización puede cambiar el dispositivo. Muestra la hora de la última confirmación; no presentes el «encendido» de ayer como estado en directo.

Además, Generic OnOff Status no contiene el TID del mensaje Set. No supongas una correlación uno a uno basada en un identificador de transacción dentro de la respuesta. Con órdenes rápidas, publicaciones y varios controladores, evalúa origen, valor, hora de recepción y contexto. Un «encendido» recién recibido no basta para dar por completada esta orden.

5. ¿Por qué no repetir indefinidamente al grupo entero?

Repetir puede recuperar una orden perdida, pero consume recursos. La mayoría puede haber terminado ya. Tampoco arregla suscripciones ausentes, falta de alimentación ni controladores averiados.

Una dirección más controlable es: enviar al grupo, observar, comprobar con ritmo limitado algunos miembros inciertos cuando sea necesario y compensar de forma acotada solo donde esté justificado.

No lo conviertas en consultar inmediatamente a todos después de cada operación. Solo trasladaría el mismo tráfico. Prueba alcance, ritmo, plazo y máximo de intentos según tamaño y tiempos exigidos.

Respeta las reglas de transacción del modelo. El TID de Generic OnOff Set diferencia una transacción nueva de la retransmisión de la misma. No lo incrementes arbitrariamente en cada repetición ni reutilices indefinidamente el antiguo para órdenes independientes. Consulta ventanas y condiciones completas en la especificación y SDK aplicables; aquí no se propone un intervalo universal.

Antes de compensar, comprueba si existe una intención más reciente. Si el usuario pidió apagar y aún se compensa el encendido anterior, una tarea vieja está interfiriendo con la nueva.

6. Lleva esta tabla a la integración

Es orientación de diagnóstico, no certificación ni una política predeterminada validada.

Observación	Comprobar primero	No dar por hecho
La interfaz dice éxito, una luz no enciende	Significado del aviso, suscripciones, alimentación	La ejecución de todos está garantizada
Luz encendida, interfaz indica fallo	Retorno del estado, recepción, ventana de observación	Sin respuesta no hubo ejecución
Control individual correcto, grupo irregular	Configuración, respuestas y publicaciones, carga simultánea	Más repeticiones siempre ayudan
Estado «encendido», luz apagada	Semántica, transición, controlador y fuente luminosa	Estado de software equivale a verificación óptica
Estado oscila tras órdenes rápidas	Antigüedad, otros controladores, compensaciones viejas	El último mensaje recibido es el más reciente
Un dispositivo nunca informa	Inventario, modelo, claves, suscripción, alimentación, cobertura	Reenviar al grupo lo solucionará

Registra por separado resultado del emisor, estado del modelo y observación física. Usa las mismas muestras, ventanas y miembros esperados; no mezcles tres criterios en una única «tasa de éxito».

Anota versión del SDK, tipo de mensaje, origen, destino, hora y configuración pertinente. Anonimiza identidades y no publiques NetKey, AppKey, DevKey ni datos de clientes.

En un entorno aislado prueba también cortes de alimentación individuales, órdenes consecutivas y tráfico normal simultáneo. Observa cómo se muestra la incertidumbre, cuándo cesan los reintentos y si la recuperación ejecuta tareas obsoletas. No introduzcas fallos en iluminación pública o sistemas con funciones de seguridad.

7. Fiabilidad no es solo «al final se encendieron todas»

Un botón oculta tres problemas: enviar eficientemente, conocer las pruebas disponibles y resolver la incertidumbre sin empeorarla.

No siempre hace falta pasar lista, pero tampoco vender la falta de información como éxito total.

Antes de decidir cuántas repeticiones son mejores, define miembros esperados, evidencia de finalización, límites de espera y retirada de tareas antiguas ante una nueva orden. Así la luz de la esquina será un problema diagnosticable, no solo una invitación a pulsar otra vez.

Lecturas: configuración y vinculación de modelos, lista de selección y aceptación y recepción en nodos de batería.

Fuentes y alcance

• Bluetooth SIG: Mesh Model v1.1, sección 3.2.1: mensajes, TID y campos de transición. Verifica la versión y el SDK del producto.
• Bluetooth SIG: Mesh in large-scale networks, 2018-06-26: radio compartida y carga de respuestas. Sus ejemplos históricos no son prestaciones actuales de un producto.
• Silicon Labs: Lighting Demonstration, 11.0.1: publicación, suscripción y control de grupos, no conducta universal de fabricantes.

Fuentes comprobadas el 2026-11-06. Análisis de mecanismos y recomendaciones de ingeniería, sin pruebas de rendimiento físicas o de campo.

La portada es una ilustración generada con IA del control de iluminación de una sala de reuniones, no una fotografía de una prueba real.