Cómo validar una pasarela Matter: de UART a la sincronización con Apple Home

Conectas las placas, pulsas un botón en el móvil y la luz se enciende. En un proyecto de domótica, es fácil pensar que lo más difícil ya está resuelto.

Después desenchufas la lámpara y el móvil quizá siga mostrándola encendida. Reinicias la pasarela y el dispositivo podría necesitar otro emparejamiento. Apagas la luz con su botón físico y el icono de Apple Home no cambia.

Son problemas de ejecución, sincronización del estado y recuperación. Una demostración aislada apenas permite detectarlos.

La lista de placas y herramientas anterior trataba del hardware necesario. Ahora toca definir qué pruebas debe dejar la primera integración y qué condiciones permiten avanzar.

El prototipo Matter en el ordenador ya se conecta a Apple Home y la imagen Linux está compilada. La interoperabilidad real entre el NCP de Silicon Labs y los dispositivos Telink, el retorno de estado de las lámparas y la recuperación completa siguen pendientes. Este artículo es el plan de aceptación inicial, no un informe de ensayos realizados.

Una lámpara y unas versiones fijas

Apple Home se comunica con la pasarela Linux por la red local. Esta utiliza UART/BGAPI para llamar al NCP Bluetooth Mesh de Silicon Labs, que controla el dispositivo Telink. El estado debe regresar por esas mismas capas.

En la primera ronda conectaré un solo dispositivo y comprobaré el encendido y apagado. La regulación, la temperatura de color, las escenas y los interruptores de varios canales pueden esperar. Añadir tipos de dispositivos multiplica las posibles causas de cada fallo.

Antes de empezar, hay que registrar el commit del programa anfitrión, las versiones del firmware NCP y del SDK, el firmware del dispositivo y los parámetros del puerto serie. Conviene fotografiar el cableado, especialmente niveles eléctricos, masa y RTS/CTS. Cambiar a la vez el programa y el firmware impide saber qué resolvió un problema.

Primero usaré un ejemplo anfitrión suministrado con el SDK elegido. Después lo sustituiré por nuestro programa Rust manteniendo hardware y firmware. Si el ejemplo oficial tampoco funciona, revisaré capacidades y configuración de modelos. Si solo falla nuestro programa, el foco estará en el análisis de tramas y la secuencia de llamadas.

Cuatro significados distintos de «éxito»

Capa	Qué demuestra	Qué no demuestra
Escritura en UART	Los bytes se entregaron a la interfaz	El NCP los interpretó correctamente
Respuesta BGAPI	El NCP devolvió el resultado de esa llamada	La lámpara ejecutó la orden
Estado del dispositivo	El modelo remoto informó de un estado actual u objetivo	Matter y el móvil ya están sincronizados
Coincidencia en Apple Home	La pantalla coincide con lo observado	El sistema seguirá correcto tras una interrupción

El significado de cada respuesta BGAPI depende del comando. Un código de éxito no equivale siempre a «luz encendida». Además, los eventos asíncronos pueden intercalarse con las respuestas; el analizador no puede suponer que a cada escritura le sigue únicamente la respuesta esperada.

Asignaré un identificador interno a cada operación para relacionar destino, estado solicitado, envío, respuesta, evento de estado y resultado. Es un identificador de nuestra aplicación: no implica que BGAPI o todos los mensajes Mesh lo devuelvan.

Al principio permitiré una única operación pendiente por dispositivo. Para asociar un estado comprobaré dirección de origen, elemento, modelo y ventana temporal. El informe de otro dispositivo o un estado anterior no deben confirmar una orden nueva.

Aprovisionar no basta

Un dispositivo puede estar dentro de la red y todavía no ser controlable. Hay que leer Composition Data, identificar el elemento y el modelo de la función, añadir las AppKeys, vincularlas a los modelos y configurar las publicaciones o suscripciones necesarias.

Dos productos Bluetooth Mesh pueden coincidir solo en algunos modelos estándar. Las funciones privadas del fabricante necesitan adaptación adicional.

La primera prueba debe usar unicast a una dirección concreta y un modelo de encendido conocido, preferentemente con operaciones confirmadas y una consulta de estado para contrastar. Así se revisan dirección, claves, modelos y recepción sin introducir grupos ni respuestas de varios nodos.

También hay que distinguir la respuesta a una orden de la publicación espontánea de estado. Si el firmware informa de cambios provocados por el botón físico, se verifica su publicación y recepción. Si no lo hace, habrá que evaluar consultas periódicas y su retraso, sin prometer sincronización instantánea.

Tres recorridos que se prueban por separado

Primero, controlar la lámpara desde el anfitrión sin Matter. Se observa la luz y después el estado recibido. Si hay transiciones, se separan valor actual, objetivo y tiempo restante: el destino de una transición no demuestra que ya haya terminado.

Segundo, cambiar la lámpara con su botón u otro control conocido, sin enviar una orden desde el anfitrión. La prueba comprueba el retorno independiente. Una consulta que obtiene el valor correcto no sustituye la verificación de una publicación espontánea. Si el diseño utiliza consultas periódicas, se mide su demora por separado.

Tercero, controlar la luz real desde Apple Home: orden del móvil, ejecución, estado recibido y actualización e informe de atributos Matter. Después se cambia la luz localmente y se comprueba que el móvil la siga.

Si el anfitrión ya conoce el estado pero Apple Home no cambia, hay que revisar mapeo, atributos y notificaciones de suscripción. Volver a aprovisionar suele borrar pistas.

Guardaré por separado el estado deseado y el último estado real confirmado. Una petición puede quedar pendiente hasta recibir información adecuada. Si la interfaz muestra un resultado optimista, debe existir un plazo y un mecanismo de corrección. Escribir con éxito en UART no puede dejar una lámpara desenchufada registrada indefinidamente como encendida.

Un criterio inicial medible

Mi plan es realizar 20 ciclos de encendido y apagado a corta distancia, con una sola lámpara, esperando el final de cada operación. Registraré por separado el tiempo del cambio físico, la recepción del estado y la actualización del móvil. El límite provisional de extremo a extremo será de cinco segundos; superarlo contará como fallo y conservará sus registros.

Los 20 ciclos y los cinco segundos son criterios provisionales del proyecto, no requisitos de Matter o Bluetooth Mesh ni resultados medidos. Sirven para comparar las primeras pruebas y podrán endurecerse después.

La ronda pasa si no quedan estados erróneos sin explicación, operaciones olvidadas tras un timeout o bloqueos que obliguen a reiniciar. Un segundo intento correcto no elimina el fallo inicial.

También importa el desorden de respuestas. Una consulta antigua puede contestar después de una operación nueva; no se debe sobrescribir el estado solo por el orden de llegada. La prueba secuencial reduce el riesgo, pero las pulsaciones rápidas exigirán ensayos propios de colas, respuestas caducadas y convergencia.

Introducir un fallo cada vez

Después de verificar el control normal, probaré estos casos, regresando a un estado estable entre ellos:

Fallo	Qué observar	Qué debe ocurrir al recuperarse
Lámpara sin alimentación	Timeouts y declaración de inaccesibilidad	Vuelve el control y se obtiene el estado real
Reinicio del NCP	Detección del reinicio y operaciones pendientes	Se recuperan sesión e inicialización y funcionan los dispositivos existentes
Reinicio del proceso anfitrión	Persistencia de identidad Matter, dispositivos y mapeos	No aparecen duplicados ni se vuelve a añadir la pasarela
Pérdida de LAN	Conexión Matter y funcionamiento Mesh por separado	Se actualiza el estado en vez de conservar indefinidamente la caché

Una consulta sin respuesta no siempre basta para declarar un dispositivo desconectado. Hay que definir ventana de observación y número de fallos, registrar el motivo y adaptar la política a alimentación, publicaciones y comportamiento de la red. Una única regla de heartbeat no sirve para todos los nodos.

Los identificadores también deben ser estables. Cada redescubrimiento de una luz no puede generar otro endpoint Matter. Las relaciones entre dispositivo, elemento y endpoint puenteado deben persistir y restaurarse según la pila.

Las claves Mesh, las direcciones, los números de secuencia y el estado de protección contra repetición necesitan los mecanismos de persistencia adecuados. Hay que saber qué guarda el NCP y qué guarda el anfitrión. Añadir manualmente un desplazamiento al número de secuencia no resuelve de forma general la recuperación eléctrica.

Estos ensayos reinician el hardware original. Sustituir el NCP plantea además la migración de su estado persistente; aprobar un reinicio no demuestra que esa sustitución sea viable.

Guardar pruebas antes de restablecer de fábrica

Eliminar y volver a añadir una lámpara puede ocultar una vinculación incorrecta, una caché antigua o claves incoherentes con los registros. Antes de hacerlo hay que guardar versiones, pasos, identificación y logs. Al compartirlos, se eliminan claves, credenciales de incorporación y otros datos sensibles.

Campo	Registro
Identificador del caso y versiones	Por completar
Estado físico y del anfitrión antes de actuar	Por completar
Pasos y resultado esperado	Por completar
Tiempos de respuesta UART, estado y actualización del móvil	Por completar
Aprobado/fallido y ubicación del log	Por completar
Acción de recuperación y posibilidad de reproducirlo	Por completar

También conviene precisar qué se elimina. Quitar la pasarela de una plataforma Matter no equivale a eliminar y resetear las lámparas Mesh. Limpiar un emparejamiento del móvil no debería borrar toda la red subordinada.

Cuándo añadir más dispositivos

Al terminar quiero un proceso repetible, con versiones identificadas, que configure una lámpara, la controle, reciba sus cambios independientes y mantenga coherencia con el móvil. Los reinicios separados de lámpara, NCP y anfitrión deben permitir continuar.

Entonces añadiré una segunda lámpara para comprobar que direcciones y endpoints no se mezclan, seguida de regulación, temperatura de color y grupos. Redes grandes, pruebas prolongadas, OTA, sustitución del módulo y certificación quedan para ensayos específicos.

La primera capacidad que merece la pena construir es localizar fallos: saber dónde se detuvo una orden y cuál fue el último estado fiable. Sobre esa base se pueden añadir funciones con mucha más confianza.

Lecturas relacionadas

• Placas y validación de una pasarela Matter
• Rust y rs-matter para conectar dispositivos a Apple Home
• Referencia Bluetooth Mesh de Silicon Labs: consultar la versión del SDK usada para las semánticas precisas.

Si trabajas en un puente Bluetooth Mesh–Matter, podemos intercambiar experiencias sobre sincronización y recuperación: contacto.