Elegir un broker MQTT para estudiantes consiste sobre todo en eliminar fricciones: nadie debería perder una sesión de laboratorio instalando Mosquitto, peleándose con el firewall del campus o averiguando qué sensor de qué equipo está inundando un topic compartido. Esta guía muestra a los docentes cómo organizar laboratorios IoT con broker.connectmq.com para las demos en directo y un broker Serverless gratuito y aislado de ConnectMQ por equipo para los proyectos evaluados, con una secuencia de clases, código listo para ejecutar y normas de aula que evitan el caos habitual.
Qué necesita un aula de un broker
Enseñar MQTT tiene prioridades distintas a las de operar sistemas en producción:
- Cero configuración en los equipos del laboratorio. Los estudiantes deberían estar publicando en los primeros diez minutos.
- Accesible desde cualquier lugar. Los PC del laboratorio, los portátiles de los estudiantes en casa y las placas ESP32 en la Wi-Fi del campus necesitan el mismo endpoint.
- Tráfico visible. Ver fluir los mensajes es el momento "ajá"; un explorador de topics ayuda muchísimo.
- Aislamiento para la evaluación. Un proyecto evaluado no puede romperse porque otro equipo publique en el mismo topic.
- Sin coste. La mayoría de los cursos no tienen presupuesto para infraestructura por estudiante.
Un broker autoalojado en un servidor del laboratorio puede funcionar, pero alguien tiene que mantenerlo, abrir puertos y arreglarlo cuando se rompe a las 9 de la mañana del día de laboratorio. Un broker MQTT gestionado lo evita. Para el concepto de fondo, los estudiantes pueden empezar por qué hace un broker MQTT.
Configuración en dos niveles: público para demos, privado para proyectos
| Uso | Broker | Autenticación | Aislamiento | Por qué |
|---|---|---|---|---|
| Demos en clase, primeros laboratorios | broker.connectmq.com (área pública) | Ninguna, cualquier client ID único | Ninguno, legible por todo el mundo | Arranque inmediato, todos lo ven todo |
| Proyectos de equipo, trabajo evaluado | ConnectMQ Serverless (Free), uno por equipo | Usuario, contraseña y client ID generados | Espacio aislado | Los equipos no pueden interferir entre sí y las credenciales enseñan buenas prácticas |
El broker público para demos
El servidor MQTT público gratuito acepta conexiones anónimas en el 1883, el 8883, el 8083 y el 8084. Sus límites encajan bien con la docencia: 64 KB por mensaje, 10 mensajes por segundo por cliente, 10 suscripciones por cliente, 8 niveles de topic, QoS de 0 a 2 y sesiones de hasta 30 minutos. Esos límites también impiden que un bucle descontrolado en el código de un estudiante sature nada.
El área pública puede leerla cualquiera en internet. Conviértelo en un punto de aprendizaje y no en una nota al pie: nunca publiques allí nombres, números de estudiante, ubicaciones ni nada personal. Es un servidor para pruebas y prototipos, nunca para datos de producción.
Brokers Serverless privados para proyectos evaluados
Cada equipo se registra para obtener un broker Serverless gratuito de ConnectMQ. Recibe un usuario, una contraseña y un client ID, hasta 25 conexiones, QoS hasta 1 y mensajes de 256 KB, lo que es de sobra para un proyecto con varios sensores, un panel y un flujo de Node-RED. Los equipos pueden mostrar su trabajo en el cliente del navegador del portal, en el explorador de topics en vivo y en el panel, y configurar reglas de alerta por umbral, lo que da para una buena demostración durante la evaluación.
Una secuencia de cinco laboratorios
Laboratorio 1: publicar y suscribirse desde la línea de comandos
Cada estudiante elige un ID aleatorio corto, por ejemplo sus iniciales más cuatro caracteres aleatorios. Dos terminales:
# Terminal 1
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-ab7k2q -t 'connectmq/demo/ab7k2q/#' -v
# Terminal 2
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-ab7k2q \
-t 'connectmq/demo/ab7k2q/hello' -m 'my first MQTT message'
Después, el docente se suscribe a connectmq/demo/+/hello y la clase observa cómo llegan los mensajes. Este único comando enseña topics, comodines y desacoplamiento mejor que una diapositiva.
Laboratorio 2: QoS, retained messages y Last Will
Publica un mensaje retenido, desconéctate, vuelve a conectarte y observa cómo llega de inmediato. Mata un cliente que tenga registrado un Last Will y observa cómo aparece el will. Acompaña este laboratorio con los niveles de QoS de MQTT explicados.
Laboratorio 3: un simulador de sensor en Python
import json
import random
import time
import uuid
import paho.mqtt.client as mqtt
STUDENT_ID = "ab7k2q" # cámbialo por tu propio ID aleatorio
BASE = f"connectmq/demo/{STUDENT_ID}/room"
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"py-{STUDENT_ID}-{uuid.uuid4().hex[:4]}")
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.publish(f"{BASE}/status", "online", qos=1, retain=True)
client.subscribe(f"{BASE}/setpoint")
def on_message(client, userdata, msg):
print("New setpoint:", msg.payload.decode())
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
while True:
reading = {"temp": round(random.uniform(19.0, 24.0), 1), "ts": int(time.time())}
client.publish(f"{BASE}/temperature", json.dumps(reading), qos=1)
print("Sent", reading)
time.sleep(2)
Instálalo con pip install paho-mqtt. Después, los estudiantes publican un setpoint desde la línea de comandos y ven cómo reacciona su script.
Laboratorio 4: hardware
Pasa a las placas ESP32. El tutorial de ESP32 y MQTT consigue que una placa publique en una sola sesión; después, los equipos añaden un sensor real. La Wi-Fi del campus con portal cautivo o WPA2-Enterprise suele bloquear las placas embebidas, así que prueba la red antes del laboratorio o lleva un punto de acceso propio.
Laboratorio 5: proyecto de equipo en un broker privado
Los equipos crean su propio broker Serverless, pasan al puerto 8883 con TLS y credenciales y construyen algo de extremo a extremo: sensores, un panel en Node-RED o web y una alerta. El salto de conexiones anónimas a autenticadas es en sí mismo una lección de seguridad; remite a los equipos a buenas prácticas de seguridad en MQTT.
Normas de aula que evitan el caos
- Cada client ID debe ser único. Dos estudiantes que usen
esp32como client ID se desconectarán mutuamente sin fin; es el problema de laboratorio más común con diferencia. - Cada topic empieza con tu propio prefijo. En el broker público,
connectmq/demo/<your-random-id>/.... Prohibido publicar en el prefijo de otra persona. - Nada de datos personales en el broker público. Trátalo como un tablón de anuncios público.
- Añade una pausa a cada bucle de publicación. Un
while Truesinsleepalcanza el límite de frecuencia al instante. - Las credenciales nunca van a un repositorio Git público. Usa un archivo de configuración incluido en
.gitignoreo variables de entorno. - Mantén una profundidad de topics razonable. El broker público permite 8 niveles.
Solución de problemas en el laboratorio
| Síntoma | Causa probable | Solución |
|---|---|---|
| El cliente se conecta y se desconecta una y otra vez | Client ID duplicado | Usa un ID aleatorio único |
| No llega nada | Errata en el topic o diferencia de mayúsculas | Los topics distinguen mayúsculas y minúsculas; suscríbete a prefix/# para verlo todo |
| Conexión rechazada en el campus | Puerto bloqueado | Prueba el 8883, o WebSocket en el 8084 desde un navegador |
| Los mensajes se detienen tras una ráfaga | Límite de frecuencia del broker público | Añade una pausa entre publicaciones |
| El ESP32 nunca se une a la Wi-Fi | Red empresarial o con portal cautivo | Usa un punto de acceso del laboratorio o la zona Wi-Fi del móvil |
| Error de TLS en el broker privado | Puerto incorrecto o falta la CA | Usa el 8883 con el almacén de CA del sistema |
Gestionar las credenciales de toda una clase
Los brokers privados implican credenciales, y en un aula las credenciales se extravían. Pide a cada equipo que designe a un miembro que cree el broker y comparta las credenciales solo dentro del equipo a través de la plataforma del curso, no en un chat público. Anima a los equipos a mantener en su repositorio un pequeño archivo config.example con valores de ejemplo y a excluir el archivo real del control de versiones. Al final del curso, los equipos pueden borrar o regenerar sus credenciales, lo que sirve además como una breve lección sobre rotación de credenciales.
Ideas para la evaluación
Evaluar el trabajo con MQTT es más fácil cuando es observable. Pide a los equipos que presenten un árbol de topics en el explorador de topics y justifiquen su diseño, que demuestren cómo un Last Will deja un dispositivo offline en el panel, que muestren una regla de alerta disparándose y que expliquen sus elecciones de QoS. Una breve reflexión escrita sobre qué cambiaría en producción, como credenciales por dispositivo, TLS en todas partes o capacidad, lo completa. Nuestro tutorial de MQTT funciona bien como lectura previa, y la guía de broker MQTT en la nube ofrece a los estudiantes avanzados una visión más amplia de las opciones de hosting.
Empieza tu laboratorio IoT con ConnectMQ
Haz hoy mismo tu primera demo en broker.connectmq.com sin registrarte y después pide a cada equipo que cree un broker Serverless gratuito en app.connectmq.com sin tarjeta de crédito. ConnectMQ es un broker MQTT gestionado, así que enseñas MQTT en lugar de administración de servidores.
Preguntas frecuentes
¿Hay un broker MQTT gratuito para estudiantes?
Sí. broker.connectmq.com ofrece un área pública gratuita para demos, y cada estudiante o equipo puede crear un broker Serverless gratuito de ConnectMQ con credenciales privadas y hasta 25 conexiones.
¿Pueden los estudiantes usar el broker público para su proyecto final?
Técnicamente funciona, pero todo lo que hay allí puede leerlo cualquiera y otro estudiante podría publicar en los mismos topics. Usa un broker Serverless privado para el trabajo evaluado.
¿Los estudiantes necesitan instalar un broker en local?
No. Bastan clientes como mosquitto_pub, paho-mqtt o el cliente del navegador del portal, lo que ahorra tiempo de preparación del laboratorio.
¿Por qué los estudiantes se desconectan continuamente?
Casi siempre porque dos clientes comparten un client ID. Cada conexión necesita su propio ID único.
¿Podemos usar placas ESP32 en la Wi-Fi del campus?
A menudo solo en redes con contraseñas WPA2 sencillas. La autenticación empresarial y los portales cautivos suelen bloquear las placas, así que un punto de acceso propio para el laboratorio es la opción fiable.
