Configuración MQTT Sparkplug B

Por qué Sparkplug B y no MQTT plano

MQTT por sí solo no define una estructura de datos ni maneja el estado de conexión de forma estandarizada. Sparkplug B añade sobre MQTT: tipos de dato explícitos, numeración de secuencia (para detectar mensajes perdidos) y el estado "muerte" (Death Certificate) para saber al instante si un dispositivo Edge se desconectó — algo crítico en un entorno industrial donde una lectura silenciosamente detenida es peor que un error visible.

Paso 1: Broker MQTT

iGromi OS incluye un broker MQTT propio (Sparkplug-aware) accesible en el puerto 8883 (TLS) para dispositivos externos que quieran publicar datos directamente, sin pasar por un iGromi Bridge.

Paso 2: Estructura de topics

Sparkplug B define una jerarquía fija de topics — no se pueden inventar nombres libres:

spBv1.0/{grupo}/{tipo_mensaje}/{id_edge_node}/{id_dispositivo}

• grupo: normalmente el nombre de la planta (Ej: Planta_Norte).
• tipo_mensaje: NBIRTH (nacimiento del nodo), NDATA (datos), NDEATH (muerte), y sus equivalentes D para dispositivo.
• id_edge_node: identificador único del gateway (Ej: Bridge_Envasadora_01).

Paso 3: Publicar un dato de ejemplo

1. Al conectar, el dispositivo debe publicar primero un mensaje NBIRTH declarando sus métricas (nombre, tipo de dato, alias numérico).
2. Los mensajes posteriores NDATA solo envían el alias numérico y el valor — no el nombre completo — para ahorrar ancho de banda en enlaces celulares o satelitales.
3. Configura el Last Will and Testament (LWT) del broker apuntando al topic NDEATH — así, si el dispositivo pierde conexión de forma abrupta, el broker publica la muerte automáticamente sin esperar un timeout largo.

Paso 4: Verificación en iGromi OS

En Fuentes de Datos > MQTT/Sparkplug, el nodo debe aparecer con estado ONLINE apenas llegue el NBIRTH. Si aparece STALE, revisa que el reloj del dispositivo esté sincronizado (Sparkplug es sensible a timestamps desfasados).