MQTT del prototipo a producción: una ruta de migración paso a paso

Llevar un prototipo MQTT a producción consiste sobre todo en cerrar los huecos que una demo puede ignorar: quién puede conectarse, quién puede leer los datos, cómo se organizan los topics y cómo te enteras cuando algo falla. Esta guía lleva un proyecto personal típico desde el servidor MQTT público gratuito hasta un broker privado protegido con TLS, con un espacio de nombres limpio y una monitorización básica, en el orden que menos retrabajo provoca.

El punto de partida: un prototipo que funciona

La mayoría de los proyectos MQTT empiezan igual. Un sensor o un ESP32 publica JSON en un servidor público de pruebas, un portátil ejecuta mosquitto_sub o un flujo de Node-RED, y los datos aparecen. Un prototipo típico tiene este aspecto:

mosquitto_pub -h broker.connectmq.com -p 1883 -i proto-dev-x9f3 \
  -t "connectmq/demo/x9f3/temp" -m '{"c":22.1}'

Es una forma perfectamente válida de empezar. Pero no es producción, por cinco motivos:

1. Sin autenticación. Cualquiera puede conectarse; el área pública de broker.connectmq.com es legible por todo el mundo.
2. Sin cifrado. El puerto 1883 envía credenciales y payloads en texto plano.
3. Topics improvisados. El árbol de topics ha crecido de forma orgánica y no sobrevivirá a más de un puñado de dispositivos.
4. Sin presencia. No puedes distinguir un dispositivo desconectado de uno que simplemente no envía nada.
5. Sin visibilidad. Cuando los datos dejan de llegar, te enteras porque un gráfico se queda plano.

Los pasos siguientes cierran cada hueco por orden.

Paso 1: pasar a credenciales privadas

Crea una cuenta en app.connectmq.com, elige un plan, crea un broker y copia el usuario, la contraseña y el client ID generados. El plan Serverless gratuito basta para un piloto de hasta 25 conexiones; el plan Serverless de pago lo amplía a 1.000 y añade QoS 2, mensajes de 1 MB y suscripciones compartidas.

Dos reglas hacen que el resto de la migración sea indolora:

• Un juego de credenciales por dispositivo o servicio. Los client IDs están vinculados a las credenciales emitidas, así que compartir un juego entre dos dispositivos hace que se desconecten mutuamente.
• Mantén las credenciales fuera del control de versiones. Cárgalas desde variables de entorno, un archivo de secretos excluido de git o un paso de aprovisionamiento en fábrica.

# .env (no hagas nunca commit de este archivo)
MQTT_HOST=broker.connectmq.com
MQTT_PORT=8883
MQTT_USERNAME=YOUR_USERNAME
MQTT_PASSWORD=YOUR_PASSWORD
MQTT_CLIENT_ID=YOUR_CLIENT_ID

Paso 2: activar TLS en todas partes

El tráfico de producción debe usar TLS en el puerto 8883 para los dispositivos y WebSocket seguro en el puerto 8084 con la ruta /mqtt para los navegadores. ConnectMQ usa un certificado de Let's Encrypt, así que la mayoría de los sistemas operativos y entornos de ejecución ya confían en él. En los microcontroladores normalmente se incrusta el certificado ISRG Root X1; nuestra guía de ESP32 con MQTT y SSL muestra los detalles.

Aquí tienes el publicador del prototipo reescrito para producción en Python con paho-mqtt 2.x. Lee las credenciales del entorno, se conecta sobre TLS con MQTT 5, define un Last Will para que el broker pueda anunciar desconexiones inesperadas y publica un estado online retenido.

import json
import os
import time

import paho.mqtt.client as mqtt
from paho.mqtt.properties import Properties
from paho.mqtt.packettypes import PacketTypes

HOST = os.environ["MQTT_HOST"]
PORT = int(os.environ.get("MQTT_PORT", "8883"))
CLIENT_ID = os.environ["MQTT_CLIENT_ID"]
BASE = "acme/site1/greenhouse/zone2/sensor-01"   # espacio de nombres de producción

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("connect failed:", reason_code)
        return
    print("connected")
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("disconnected:", reason_code)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=CLIENT_ID, protocol=mqtt.MQTTv5)
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.tls_set()
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.on_connect = on_connect
client.on_disconnect = on_disconnect

connect_props = Properties(PacketTypes.CONNECT)
connect_props.SessionExpiryInterval = 3600   # conserva la sesión una hora sin conexión

client.connect(HOST, PORT, keepalive=60, properties=connect_props)
client.loop_start()

try:
    while True:
        reading = {"ts": int(time.time()), "temp_c": 22.1, "rh": 61}
        client.publish(f"{BASE}/telemetry", json.dumps(reading), qos=1)
        time.sleep(30)
except KeyboardInterrupt:
    client.publish(f"{BASE}/status", "offline", qos=1, retain=True).wait_for_publish()
    client.disconnect()
    client.loop_stop()

Fíjate en lo poco que ha cambiado respecto al prototipo: hostname, puerto, credenciales, TLS y unas pocas propiedades. Esa es precisamente la ventaja de usar MQTT estándar de extremo a extremo.

Paso 3: diseñar un espacio de nombres de topics para producción

Un topic de prototipo como connectmq/demo/x9f3/temp funciona para un sensor. Un espacio de nombres de producción tiene que sobrevivir a nuevas plantas, nuevos tipos de dispositivo y nuevos consumidores sin renombrar nada. Una buena estructura va de lo general a lo específico y separa los datos de los comandos y del estado.

Reglas prácticas que ahorran disgustos más adelante:

• Usa niveles en minúsculas, sin espacios y sin barra inicial.
• Pon el ID del dispositivo en el topic, no solo en el payload, para que los suscriptores puedan filtrar con comodines.
• Usa una rama cmd separada para los comandos, para que los dispositivos se suscriban de forma acotada.
• Haz que los topics de estado sean retenidos para que los suscriptores que llegan tarde vean el estado actual al instante.
• Mantén una profundidad razonable; el broker público permite 8 niveles, un presupuesto sensato en cualquier caso.

Si tu proyecto es industrial, plantéate alinearte con los niveles ISA-95 desde el principio. La vista de dispositivos de ConnectMQ agrupa los clientes por niveles ISA-95 cuando tus topics siguen ese patrón. Nuestra guía sobre la estructura de topics MQTT para el hogar inteligente cubre los proyectos residenciales.

Paso 4: seguimiento de la presencia de los dispositivos

Los mensajes de estado online y offline retenidos con un Last Will, como en el código anterior, dan a cada suscriptor una visión fiable de qué dispositivos están conectados. También puedes observar el estado en el lado del broker mediante $SYS/broker/connection/{clientId}/state, útil para un servicio backend que necesite saber cuándo se cae un cliente concreto.

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID -V mqttv5 \
  -t 'acme/site1/+/+/+/status' -v

Paso 5: añadir monitorización y alertas

Producción significa que alguien se entera de los problemas antes que los usuarios. Empieza por lo sencillo:

• Usa el dashboard del portal y el explorador de topics en vivo para confirmar que los datos fluyen después de cada despliegue.
• Crea reglas de alerta por umbral para los valores que importan, como una temperatura fuera de rango, y revisa el registro de alertas.
• Registra los reason codes de MQTT 5 en cada cliente para que los problemas de cuotas y autorización se puedan diagnosticar.
• Si necesitas almacenamiento a largo plazo o notificaciones personalizadas, ejecuta tu propio suscriptor, por ejemplo un servicio en Python, Telegraf o Node-RED, que se conecte al broker como un cliente MQTT normal y escriba en tu base de datos o herramienta de mensajería.

Para una lista más completa, lee nuestra guía de monitorización de brokers MQTT.

Checklist de preparación para producción

Antes de lanzar, confirma cada punto:

1. Cada dispositivo y servicio tiene sus propias credenciales y su propio client ID.
2. Todas las conexiones usan TLS (8883) o WebSocket seguro (8084).
3. No hay credenciales en el control de versiones del firmware.
4. El espacio de nombres de topics está documentado y empieza por un nivel de organización o inquilino.
5. Los dispositivos publican un estado retenido con un Last Will.
6. La lógica de reconexión usa backoff exponencial con jitter.
7. Los payloads quedan muy por debajo del límite de tamaño de mensaje del plan.
8. Los comandos usan al menos QoS 1 y es seguro recibirlos dos veces.
9. Tienes un plan de actualizaciones de firmware que roten las credenciales.
10. Las alertas llegan a una persona cuando cambian valores clave o la presencia de dispositivos.

Cuando hayas completado la lista, la checklist de producción MQTT y las buenas prácticas de seguridad en MQTT profundizan en el refuerzo.

Cómo elegir el plan adecuado para producción

Empieza con el plan más pequeño que cubra tu número de conexiones con margen. Pasa a Serverless de pago cuando necesites más de 25 conexiones, QoS 2, mensajes más grandes o suscripciones compartidas para consumidores backend. Elige Dedicated cuando quieras un clúster aislado, BYOC cuando el broker deba ejecutarse en tu propia cuenta cloud y Self Managed Enterprise cuando necesites ejecutarlo tú mismo. La guía del broker MQTT en la nube compara estos modelos de alojamiento con más detalle.

Lleva tu prototipo a producción con ConnectMQ

ConnectMQ te ofrece credenciales privadas, TLS, MQTT 5 y un portal con explorador de topics en vivo y reglas de alerta, sobre el mismo MQTT estándar que ya habla tu prototipo. Regístrate en app.connectmq.com, crea un broker con el plan Serverless gratuito sin tarjeta de crédito y apunta tu prototipo a él en minutos. Si prefieres no gestionar ninguna infraestructura, un broker MQTT gestionado es el camino más corto.

Preguntas frecuentes

¿Puedo seguir usando el broker público en producción?

No. El área pública de broker.connectmq.com es legible por todo el mundo y tiene límites estrictos por cliente, así que está pensada solo para pruebas. Los datos de producción deben estar en un broker privado con credenciales y TLS.

¿Tengo que cambiar el código de mis dispositivos para pasar a producción?

Normalmente solo cambian los parámetros de conexión: hostname, puerto 8883, credenciales y TLS. Los nombres de los topics cambian si adoptas un nuevo espacio de nombres, algo que vale la pena hacer antes de escalar.

¿Cómo debo gestionar las credenciales en muchos dispositivos?

Emite un juego de credenciales por dispositivo, cárgalo durante el aprovisionamiento en lugar de compilarlo en un firmware compartido y lleva un registro para poder revocar un solo dispositivo sin tocar los demás.

¿Qué plan debería usar un piloto pequeño?

Un piloto con hasta 25 conexiones simultáneas cabe en el plan Serverless gratuito. Pasa a Serverless de pago cuando necesites más conexiones, QoS 2 o mensajes más grandes.