¿Qué es MQTT y por qué toda clase de IoT escolar necesita de repente un broker?
MQTT es un protocolo de mensajería ligero que permite a los microcontroladores del aula compartir datos sin conexiones directas entre pares. Al encaminar el tráfico a través de un broker central, esquiva los restrictivos cortafuegos escolares y evita que los dispositivos se caigan por la carga de red.
Si has echado un vistazo recientemente a un temario de Programación y Robótica alineado con el currículo CAPS, o has intentado diseñar una práctica de Internet de las cosas (IoT) para tu clase, seguramente te has topado con las siglas MQTT y con el requisito de un «broker MQTT». Para un profesor de informática o un coordinador de tecnología con mil cosas encima, esto puede parecer una complicación innecesaria. ¿Por qué no puede un microcontrolador, como un ESP32 o una Raspberry Pi Pico W, enviar sin más sus datos de sensor al portátil o al móvil de un alumno por la red wifi local?
La respuesta corta es que la comunicación directa entre dispositivos es frágil, consume muchos recursos y resulta casi por completo incompatible con la seguridad de una red escolar. MQTT (Message Queuing Telemetry Transport) lo resuelve separando a quien envía los datos de quien los recibe, y encaminando todos los mensajes a través de un gestor central llamado broker. Es el estándar del sector para el IoT industrial y cada vez resulta más imprescindible en la computación física del aula.
El tablón de anuncios del aula: entender el modelo pub/sub
Para entender por qué MQTT funciona, imagina una clase de 40 alumnos. Si cada alumno que quisiera saber la temperatura exterior tuviera que acercarse al único alumno sentado junto a la ventana y preguntarle: «¿A cuánto estamos?», ese compañero de la ventana se pasaría toda la clase respondiendo preguntas repetidas en lugar de hacer su propio trabajo. Y si diez alumnos más quisieran saber cuándo es el próximo recreo, tendrían que interrumpir directamente al profesor.
Ahora pon un tablón de anuncios en el pasillo. El de la ventana escribe «Temperatura: 22 °C» en una nota adhesiva y la clava bajo el encabezado «Meteorología». El profesor clava «Próximo recreo: 10:30» bajo «Horario». Quien quiera saber la temperatura o la hora del recreo se acerca al tablón y lo lee. Al de la ventana ni le consta ni le importa quién lee la temperatura; se limita a publicar la actualización. Y los lectores no necesitan molestarle.
Este es el modelo de publicación/suscripción (pub/sub) que usa MQTT:
- El publicador: el microcontrolador con un sensor (el alumno de la ventana) que envía datos al broker.
- El suscriptor: el panel, la aplicación del móvil o la base de datos (los alumnos que leen el tablón) que quiere recibir esos datos.
- El broker: el servidor central (el tablón de anuncios) que recibe los mensajes de los publicadores y los encamina hacia los suscriptores correspondientes.
El núcleo técnico: topics, mensajes retenidos y últimas voluntades
MQTT se apoya en tres conceptos básicos para que la comunicación sea eficiente y fiable incluso con conexiones inalámbricas malas.
1. Topics: los mensajes no se envían a dispositivos concretos, sino que se publican en «topics» (temas). Los topics se estructuran con barras, lo que crea una jerarquía del tipo school/lab1/temp o home/garden/moisture. Un dispositivo puede suscribirse a un topic muy concreto o usar comodines para escuchar varios a la vez. Por ejemplo, suscribirse a school/+/temp permite que un único panel muestre las lecturas de temperatura de todos los laboratorios del centro.
2. Mensajes retenidos: normalmente, si un sensor publica una lectura y en ese milisegundo exacto no hay nadie suscrito, el mensaje se pierde para siempre. Si un alumno abre su panel cinco minutos después, verá una pantalla en blanco hasta que el sensor vuelva a transmitir. Al activar el indicador «retained» en un mensaje, el publicador le dice al broker: «Guarda este último valor. La próxima vez que alguien se suscriba a este topic, dáselo de inmediato». Esto es fundamental para datos que cambian despacio, como la humedad del suelo o el nivel de un depósito de agua.
3. Última voluntad y testamento (LWT): los microcontroladores de las aulas sudafricanas sufren desconexiones frecuentes y repentinas por los cortes programados de luz, las pilas agotadas o los alumnos que desenchufan un cable de alimentación sin querer. Cuando un dispositivo se conecta por primera vez al broker, registra un mensaje de «última voluntad» (por ejemplo, topic: status/sensor1, mensaje: offline). Si el dispositivo se queda de golpe sin corriente sin enviar una señal de desconexión limpia, el broker detecta la conexión rota y publica automáticamente el mensaje de «última voluntad» en su nombre, avisando al resto del sistema de que ese hardware está fuera de línea.
Tres cosas que salen mal en una red escolar
Aunque MQTT es robusto, implantarlo en un entorno educativo obliga a lidiar con la realidad de la infraestructura informática de un colegio. Hay tres modos de fallo habituales que trastocan las clases con regularidad:
Fallos habituales de la red escolar
| Función de red | Por qué existe | Cómo revienta la clase de IoT |
|---|---|---|
| Seguridad WPA2-Enterprise | Protege las redes del colegio exigiendo un usuario y una contraseña individuales a cada alumno. | Los microcontroladores corrientes (como los chips ESP8266 básicos) no pueden negociar con facilidad los protocolos de seguridad Enterprise de fábrica, lo que les impide entrar en la wifi. |
| Aislamiento del punto de acceso (AP) | Impide que los alumnos accedan a los portátiles de sus compañeros por la wifi local o los hackeen. | Bloquea el tráfico local entre pares. Si ejecutas un broker MQTT en una Raspberry Pi del aula, los dispositivos de los alumnos conectados a esa misma wifi no podrán llegar hasta él. |
| Rotación dinámica de IP (DHCP) | Reutiliza direcciones IP para que el router del colegio no se quede sin ellas. | Si llegas a montar un broker local en un portátil, su dirección IP cambiará con regularidad. Cualquier código de microcontrolador con una IP fija escrita a mano no logrará conectarse al día siguiente. |
Para sortear estos obstáculos de la red local, los docentes suelen tener que elegir entre pelearse con su departamento de informática para conseguir configuraciones a medida del router o encaminar su tráfico a través de un broker externo alojado en la nube al que se llegue por puertos web estándar. Para el profesorado que busca una solución ágil y lista para el aula que esquive por completo estos quebraderos de cabeza de la red local, la plataforma Sheen IoT ofrece un entorno MQTT preconfigurado y alojado en la nube, diseñado específicamente para funcionar dentro de las restricciones de los cortafuegos escolares.
Al trasladar la carga de la mensajería desde los microcontroladores a un broker dedicado, MQTT hace que, incluso si el código de un alumno no está optimizado o la wifi del colegio flaquea, los dispositivos IoT del aula puedan comunicarse de forma fiable y segura.
