Compatible con SIG Mesh, pero no con Mi Home: identidad del producto y límites de Xiaomi Mesh

Una lámpara ya puede incorporarse a una red SIG Mesh y una placa de desarrollo controla su encendido y brillo. Para añadirla a Mi Home, ¿basta con cambiar el nombre anunciado y conectar una pasarela Xiaomi?

También surge la pregunta inversa: si una lámpara Bluetooth Mesh de Mi Home utiliza un estándar, ¿puede una pasarela propia gestionarla y conectarla a Matter?

La etiqueta «compatible con SIG Mesh» no responde ninguna de las dos preguntas.

El artículo anterior explicó Provisioning, claves de aplicación y vinculación de modelos. Ahora subimos una capa: cómo se convierte un dispositivo en un producto reconocido por Mi Home, cómo sus funciones se traducen en mensajes y qué garantiza realmente la pasarela.

El texto se basa en la documentación BLE Mesh de Xiaomi consultable el 5 de noviembre de 2026. Hay que comprobar por separado generaciones de productos, SDK y firmware de las pasarelas. No es una lista universal de capacidades de todo lo comercializado como Xiaomi Mesh. Los ejemplos y diagnósticos son propuestas de diseño, no resultados de pruebas físicas de interoperabilidad.

Una lámpara debe responder tres tipos de preguntas

En Mesh estándar importan direcciones, claves, elementos y modelos. Mi Home también necesita saber qué producto es, qué funciones tiene y cómo lo utiliza la persona.

Capa	Qué debemos resolver	Qué no basta
Red y aplicación Mesh	Incorporación, modelos que reciben mensajes y configuración de claves	Detectar un anuncio Bluetooth
Definición e identidad del producto	Identificar producto y unidad; completar la vinculación de la plataforma	Implementar un modelo de iluminación
Uso y mantenimiento en la plataforma	Compatibilidad de app, voz y pasarela con funciones, estados y actualizaciones	Completar una primera vinculación

Estas capas se relacionan, pero no se sustituyen. El tercer artículo avanzaba desde la incorporación hasta las condiciones para comunicarse. La integración con Mi Home debe introducir esas capacidades en un flujo de producto admitido por la plataforma.

Cuando el proveedor dice «soporta SIG Mesh», conviene preguntar: ¿qué solución de integración, qué versión del SDK y qué categorías de producto admite?

MIoT Spec y Mesh Model describen interfaces diferentes

La guía histórica de Xiaomi distingue MIoT Spec de Mesh Spec. La primera describe servicios, propiedades y operaciones del producto; la segunda, modelos, mensajes y estados SIG Mesh. La documentación actual de conceptos básicos BLE Mesh mantiene la conversión entre Spec y mensajes Mesh en la pasarela.

Encender una lámpara puede expresarse en la plataforma como cambiar una propiedad a «encendido». En la radio debe convertirse en un mensaje que el dispositivo pueda procesar. Los estados notificados recorren el camino inverso.

No es un simple cambio de nombres: plataforma y firmware deben coincidir en identificadores, tipos, rangos y forma de notificación. Un control deslizante visible en la app no demuestra que sus valores se traduzcan correctamente al modelo de iluminación.

El esquema resume la ruta por la nube descrita por Xiaomi y omite detalles como los retransmisores. No implica que todo control deba pasar por la nube; la conexión directa del teléfono y la automatización local dependen de cada implementación.

Los modelos estándar pueden coexistir con extensiones del fabricante. El ejemplo histórico de lámpara con temperatura de color incluye ambos. Sirve para explicar la arquitectura, no para garantizar que productos actuales conserven los mismos elementos e identificadores.

Añadir una función personalizada en la plataforma tampoco hace que pasarela, firmware y voz la entiendan automáticamente. Hay que comprobar cada parte de la solución actual.

Modelo de producto, identidad y claves Mesh no son lo mismo

El nombre model de la plataforma identifica un tipo de producto. Un Mesh Model define comportamientos de comunicación de la aplicación. Que el nombre contenga «light» no implementa el modelo correspondiente.

El PID, Product ID, tampoco es la dirección unicast Mesh de una unidad: identificar productos y direccionar nodos son tareas diferentes.

Las preguntas frecuentes BLE Mesh indican que, en la solución de módulos documentada, la cadena de certificados, Product ID y MAC quedan asociados tras la primera vinculación. Cambiarlos puede impedir incorporaciones posteriores. Borrar toda la memoria del chip puede eliminar la cadena de certificados.

Por eso no debe tratarse el módulo como una placa vacía que siempre puede borrarse para asignarle otro PID. Antes de programarlo, confirme las zonas de identidad y los procedimientos de actualización, restablecimiento y recuperación admitidos por el proveedor.

Son condiciones de esa solución Xiaomi, no requisitos universales de SIG Mesh. No permiten deducir una distribución de memoria común a todos los chips ni un procedimiento único de recuperación.

NetKey, AppKey y DevKey protegen respectivamente las comunicaciones de red, aplicación y configuración Mesh. No sustituyen los requisitos de identidad del producto; un certificado tampoco es una clave de aplicación Mesh.

Una demostración Mesh estándar demuestra que esa ruta técnica funciona. Convertirla en un producto propio para Mi Home requiere además configurar la plataforma y la identidad.

Una diferencia real entre documentos: cuidado con las plantillas antiguas

El hallazgo más útil fue una diferencia de versiones, no un fragmento de código.

La página de conceptos básicos, fechada el 4 de agosto de 2026, anuncia cambios desde el 6 de agosto para productos BLE Mesh nuevos; excluye los productos de prueba ya creados. Las plantillas de brillo y de brillo/temperatura de color permanecen iguales. Las de interruptores de una, dos y tres teclas y ventiladores pasan a MI_MESH_TEMPLATE_CLOUD.

Advierte que una discrepancia entre la plantilla de plataforma y firmware puede romper control o notificaciones. Tras cambiar a MI_MESH_TEMPLATE_CLOUD, hay que añadir manualmente las propiedades de publicación periódica.

Sin embargo, la FAQ fechada el 6 de noviembre de 2024 conserva MI_MESH_TEMPLATE_THREE_KEY_SWITCH en el ejemplo de tres teclas.

Esto no significa actualizar obligatoriamente todos los firmwares antiguos. Primero determine cuándo se creó el producto, su categoría, las opciones actuales de plataforma y la versión/configuración del SDK.

Para productos afectados, contraste con el aviso más reciente. Para los existentes, no cambie de plantilla solo porque apareció una macro nueva.

Que un tutorial compile no demuestra que coincida con la plataforma actual. Registre conjuntamente definición de producto, firmware y versión de pasarela, no solo el chip.

«Recibido» por la pasarela no equivale a «ejecutado» por la lámpara

Después de añadir el dispositivo, suele aparecer otro problema: la interfaz responde, pero la lámpara no cambia.

Xiaomi describe la comunicación servidor–pasarela–dispositivo como asíncrona: la pasarela responde inmediatamente al comando del servidor.

Esa respuesta no acredita por sí sola la ejecución. Distinga procesamiento de solicitud, entrega inalámbrica y estado notificado; interprete los códigos según la definición concreta de la interfaz.

Consultar una propiedad tampoco significa necesariamente consultar en ese instante al dispositivo por radio. Al finalizar la vinculación, si la pasarela aún no tiene propiedades en caché, la app puede recibir -4004. El envío proactivo de propiedades tras vincularse es una de las soluciones sugeridas.

Además, la pasarela almacena propiedades y filtra su envío a la nube según condiciones de intervalo o cambio. Los eventos siguen otra ruta y, según el documento, se remiten inmediatamente. Esa palabra describe el procesamiento de la pasarela, no garantiza latencia ni entrega de extremo a extremo.

Así, la lámpara puede cambiar antes que la interfaz de nube, o continuar comunicándose sin volver a notificar una propiedad. Revise control, informes, caché y filtros antes de atribuir todo a pérdidas de radio.

En una pasarela propia guardaría estado deseado, último estado informado y su fecha, en vez de marcar todo como encendido al enviar la orden. Es una recomendación de ingeniería, no una interfaz impuesta por Xiaomi.

Un altavoz Bluetooth no siempre es una pasarela Mesh adecuada

La FAQ pide comprobar si el altavoz admite BLE Mesh, si la función está habilitada y si su firmware es apropiado.

Por tanto, «tenemos un altavoz XiaoAI» no define compatibilidad. Hay que identificar modelo, firmware y funciones del producto. Reproducir audio Bluetooth no implica gestionar BLE Mesh.

Retransmitir tampoco equivale a ser pasarela. La documentación básica indica retransmisión predeterminada para dispositivos que no son de bajo consumo y tienen ventana de escaneo FULL; también señala que, en esa solución, los dispositivos no se controlan mutuamente.

No es una contradicción: retransmitir ayuda a entregar mensajes; controlar requiere roles y configuración de aplicación. La introducción de Bluetooth SIG describe control local entre interruptores, sensores y luces. Que una solución Xiaomi lo implemente y exponga es otra cuestión.

No convierta una limitación de la solución en una limitación universal del estándar, ni una posibilidad del estándar en una promesa de un producto concreto.

Verifique el funcionamiento sin conexión por cada ruta de control

Xiaomi indica que el control remoto requiere pasarela y que puede desarrollarse control Bluetooth directo sin ella. Eso no significa que todos los productos vendidos ofrezcan la misma conexión directa ni que toda automatización sea local.

Antes de desarrollar o comprar, pruebe las mismas funciones bajo condiciones diferentes:

Condición	Qué observar
Internet desconectado; router, pasarela y equipos encendidos	Qué controles y automatizaciones siguen funcionando
Pasarela apagada; equipos encendidos	Botones físicos, conexión directa expresamente admitida e interacciones entre equipos
Estado modificado físicamente en el dispositivo	Actualización en pasarela/app y estados antiguos tras reconectar
Reinicio separado de pasarela y equipos	Persistencia de vinculación/configuración y recuperación del estado

Es un plan pendiente de ejecutar, no resultados de este artículo. Registre modelos, firmware, versión de app y entrada de control para asociar los resultados con una combinación concreta.

Que el botón físico siga encendiendo una lámpara con la pasarela apagada no demuestra independencia de toda la automatización. Limite cada conclusión a la ruta probada.

Para una pasarela propia o Matter, primero elija dónde integrarse

Para gestionar una lámpara Mi Home existente, confirme los métodos admitidos y permitidos: incorporación a una red propia, configuración de modelos e implementación disponible de identidad y aprovisionamiento. Un restablecimiento de fábrica no garantiza apertura a cualquier Provisioner.

Si se usa una API oficial de plataforma, se integran sus funciones, permisos y ruta de control. Eso no constituye automáticamente gestión directa de la red Mesh. El control que pasa por la nube no se convierte por ello en local.

Controlar el firmware permite coordinar modelos, informes y mantenimiento. Mantener una versión propia y otra Mi Home sigue exigiendo evaluar identidades, configuraciones y capacidades; no prometa migración sin pérdidas con un simple interruptor.

El puente Matter añade otra capa: representar funciones que ya pueden gestionarse de forma fiable como dispositivos y estados Matter. No resuelve falta de permisos, funciones incompatibles o estados inaccesibles en Bluetooth. Véase una pasarela Matter en Rust.

Acuerde una compatibilidad concreta antes de iniciar el proyecto

Para un producto Mesh de Mi Home, confirmaría con el proveedor:

• Soluciones admitidas para la categoría y versiones de SDK disponibles y mantenibles.
• Suministro de identificadores e identidades, datos que deben conservarse al programar y recuperación admitida.
• Modelos o conversiones para encendido, brillo, temperatura de color y funciones propias, incluidos sus estados.
• Combinaciones exactas de pasarela/firmware para aceptación y capacidades separadas de app, voz y uso sin conexión.
• Responsabilidad sobre actualizaciones, productos existentes y cambios en la plataforma.

La lista no sustituye admisión y lanzamiento. Una demostración técnica no concede autorización comercial, certificación ni derechos de marca. Consulte las condiciones actuales con plataforma y proveedor, sin asumir tarifas o promesas de tutoriales antiguos.

Una afirmación útil dice: este producto, con estas versiones y ajustes, realiza estas operaciones por esta ruta y permite verificar su estado. Así se distingue reutilización del estándar, adaptación de plataforma y pruebas pendientes.

El próximo artículo comparará Mesh propio, SIG Mesh estándar e integración Mi Home según control, funcionamiento sin conexión y mantenimiento, con un diseño de evaluación justo y repetible.

Referencias

• Xiaomi IoT: conceptos básicos BLE Mesh, fecha indicada 2026-08-04; plantillas, mensajes y notificaciones.
• Xiaomi IoT: FAQ BLE Mesh, 2024-11-06; identidad, programación y diagnóstico. Contrastar las plantillas con avisos posteriores.
• MiEcosystem: integración Bluetooth Mesh, referencia histórica de arquitectura, no guía vigente de chips o lanzamiento.
• Bluetooth SIG: The Bluetooth Mesh Networking Primer, capacidades estándar frente a implementaciones de ecosistema.