Bluetooth Mesh: el aprovisionamiento funciona, ¿por qué la luz no responde?

El dispositivo aparece en el escaneo. Pulsas Añadir, el registro anuncia que el aprovisionamiento terminó correctamente y el gateway muestra una entrada nueva. Parece que todo está hecho.

Envías la orden de encendido y la luz no responde.

Antes de culpar a la cobertura, al chip o al puerto serie, conviene comprobar algo: pertenecer a la red no significa estar configurado para participar en la aplicación.

El artículo anterior trató la evolución de publicidad propia a una red multisalto. Ahora seguimos la incorporación de una lámpara a SIG Mesh: descubrimiento, Provisioning, claves, vinculación de modelos y publicación/suscripción. Es una explicación del mecanismo, no un informe de pruebas físicas ni un protocolo serie específico.

Descubrir solo indica disponibilidad

Un dispositivo no aprovisionado puede emitir un Unprovisioned Device Beacon. El teléfono o gateway lo descubre y quien asume el papel de Provisioner inicia el proceso.

Provisioner es un papel, no necesariamente un teléfono ni una función inseparable del gateway. Un programa puede reunir aprovisionamiento, configuración y control cotidiano, pero conviene distinguir esas responsabilidades.

Detectar un anuncio no demuestra que sea la lámpara que queremos añadir. Aún hacen falta identificación y el procedimiento de seguridad adecuado. Con varias lámparas iguales cerca, el instalador necesita una forma de elegir: botón, información suministrada con el producto o los medios de entrada/salida admitidos. Esa interacción debe diseñarse antes de encontrarse con una lista de nombres idénticos.

Provisioning establece la identidad de red

No consiste simplemente en escribir una contraseña. Provisioner y dispositivo intercambian capacidades, seleccionan autenticación compatible, realizan los intercambios relacionados con claves públicas y establecen de forma segura el estado necesario. Importan las capacidades de entrada/salida, el método elegido y la implementación; cifrar el canal no sustituye confirmar a quién incorporamos.

Al terminar, el dispositivo es un nodo con NetKey inicial, IV Index, direccionamiento unicast asignado y DevKey. Ambos extremos derivan DevKey por separado; no se transmite por radio como un parámetro en texto claro. Su función es distinta de la NetKey compartida.

Todavía puede faltar decidir qué clave controla la luz, qué modelo acepta la orden y a qué grupo debe escuchar. Por eso mostraría «Aprovisionado; configuración pendiente», no «Listo para usar».

Tres claves, responsabilidades distintas

Clave	Función principal	Lo que no implica
NetKey	Seguridad de red/subred y procesamiento de red	Leer el contenido de todas las aplicaciones
AppKey	Proteger mensajes de aplicación junto con la vinculación de modelos	Que todos los modelos puedan usarla por estar almacenada
DevKey	Proteger la configuración de ese nodo	Una clave compartida para el control cotidiano del grupo

Una lámpara del pasillo puede retransmitir tráfico de otros dispositivos sin necesitar acceso a todas sus aplicaciones. Separar NetKey y AppKey distingue transportar un mensaje de comprenderlo. Ser relé no prueba que se tengan permisos y modelos para ejecutar la orden.

AppKey Index es un índice, no la clave. Ver el mismo número en dos registros no demuestra que coincidan el material criptográfico y su contexto. Comprueba la correspondencia mediante registros fiables sin imprimir claves reales en logs ordinarios o capturas.

Leer la composición antes de adivinar direcciones

Configuration Client consulta y modifica el Configuration Server del nodo. Composition Data describe elementos, modelos y capacidades.

Nodo, elemento y modelo son niveles distintos. Una carcasa puede contener varios elementos y cada uno varios modelos. En un controlador multicanal, no supongas que todas las salidas están en el elemento primario ni que la dirección principal más una orden OnOff controla todo. Reserva espacio de direcciones para los elementos sin solapamientos.

En nuestro ejemplo, identifica el elemento de la lámpara y confirma Generic OnOff Server. El controlador necesita enviar los mensajes correspondientes y gestionar sus respuestas. Descubrir o aprovisionar un dispositivo no demuestra que incluya el modelo requerido. Más potencia de transmisión no corrige ese desajuste.

AppKey Add y Model App Bind no son lo mismo

Primero se añade la AppKey al nodo con su asociación NetKey. Después se vincula a los modelos de aplicación que la usarán.

Almacenar una clave no habilita automáticamente cada modelo para procesar sus mensajes. Vincularla al elemento o modelo equivocado tampoco configura la función deseada. El emisor necesita su propia configuración correcta: preparar solo la lámpara no completa la relación.

No todos los modelos usan AppKey: los modelos de Configuration usan DevKey y no deben tratarse como modelos de iluminación.

La API de configuración de Silicon Labs separa añadir la clave y vincular el modelo, con eventos de resultado. Que la interfaz local acepte una petición, que el nodo remoto confirme la configuración y que la función opere son tres hechos distintos.

Espera los resultados según el SDK y comprueba nodo, elemento, modelo y código de estado. Un timeout deja incertidumbre; no demuestra que el nodo no haya ejecutado nada.

Primero una lámpara; después el grupo

Empieza enviando una orden unicast al elemento confirmado y observando el estado correspondiente.

El control unicast no exige añadir previamente una suscripción de grupo. Tampoco toda API con destino explícito requiere configurar antes una dirección de publicación del modelo.

Una vez validado unicast, añade el grupo. Para un interruptor que controla varias luces del pasillo:

• Su modelo cliente publica en la dirección del grupo.
• Los modelos servidor correspondientes de las lámparas se suscriben a ella.
• Ambos lados tienen claves y configuración compatibles.

Una lámpara nueva puede incorporarse tras aprovisionamiento, configuración y suscripción, sin reescribir una lista de lámparas en el interruptor.

El nombre «Luces del pasillo» solo es una etiqueta. Las suscripciones se configuran para modelos concretos; arrastrar un dispositivo a una habitación en una app no prueba que esa configuración inalámbrica se haya aplicado.

Publicación y retorno de estado

La lámpara puede responder a una petición que exige respuesta. Si cambia mediante un botón local, puede necesitar enviar un informe espontáneo. Son caminos diferentes.

La configuración de publicación puede incluir destino, AppKey y parámetros admitidos. Fijar el destino no garantiza informes periódicos en todos los modelos ni el tratamiento correcto de cada cambio local.

«El gateway enciende» y «conoce el estado reportado actual» son pruebas distintas. En un puente Matter, un cambio local que no llega deja a la app mostrando la última orden en lugar del estado reciente. Incluso un informe tiene límites: salida activada no demuestra iluminación física sin sensores o realimentación apropiados.

La configuración necesita recuperación

Puede cortarse la energía, perderse una respuesta o reiniciarse el host. Una secuencia que solo añade clave, vincula modelo y configura suscripción/publicación no basta para saber dónde continuar.

Registra la configuración deseada y los resultados confirmados. Al recuperar, consulta el estado necesario y corrige diferencias. Tras un timeout de AppKey Add, comprueba el estado remoto con las capacidades del protocolo/SDK antes de decidir repetir. El comportamiento al repetir depende del comando; no todos son inocuos.

Persiste asignaciones de direcciones, identidades y registros necesarios de claves y configuración, con control de acceso y copias. De lo contrario, los dispositivos pueden seguir en una red que su administrador ha olvidado gestionar.

Restablecer de fábrica no es la primera respuesta universal: cambia estado y puede romper vínculos. Distingue no aprovisionado, aprovisionado sin configurar y configurado con registros de gestión perdidos.

Relacionar síntomas y capas

Síntoma	Revisar primero
Se descubre, pero no se aprovisiona	Modo de incorporación, bearer, autenticación y errores
Se aprovisiona, pero configurar agota el tiempo	Direcciones, DevKey/contexto de red, cobertura, respuestas y temporización LPN
Configuración correcta, unicast falla	Elemento/modelo, AppKey añadida y vinculada, emisor
Unicast funciona, grupo no	Destino real, suscripciones, claves y envío
Control funciona, estado visible no cambia	Respuestas, publicación espontánea, recepción y mapeo
Falla tras reiniciar	Persistencia, direcciones, recuperación y contexto de claves

Es un orden de investigación, no un diagnóstico automático. Usa consultas de estado, registros y capturas cuando sean necesarias para localizar la etapa fallida.

Verifica unicast y estado, luego grupos e informes tras cambios locales, y finalmente interrupciones y reinicios. Un criterio explícito por etapa vale más que anotar solamente «la lámpara encendió».

Añadir un dispositivo es un proceso

Puede haber un único botón, pero debajo existen varios estados: descubierto, aprovisionado, composición identificada, aplicación configurada y control/estado verificados.

Separarlos permite explicar qué terminó, qué falta y desde dónde reanudar sin enseñar todo el protocolo al usuario. SIG Mesh aporta mecanismos comunes; no promete compatibilidad automática de toda marca, modelo o ecosistema tras Provisioning. El trabajo del gateway cubre la distancia entre entrar en la red y poder gestionar fiablemente el dispositivo.

La próxima entrega vuelve a Xiaomi Mesh: ¿qué definiciones de producto, identidad y requisitos de plataforma añade Xiaomi Home a la red y los modelos estándar?

Referencias

• Bluetooth SIG: Mesh Networking Primer: direcciones, publicación/suscripción, claves, aprovisionamiento y configuración.
• Silicon Labs: Configuration Client API: composición, claves, vinculación, suscripción y publicación. Consulta la versión de tu SDK.