O que é o MQTT e porque é que todas as aulas de IoT na escola passaram a precisar de um broker?
O MQTT é um protocolo de mensagens leve que permite aos microcontroladores da sala de aula partilhar dados sem ligações diretas ponto a ponto. Ao encaminhar o tráfego através de um broker central, contorna as firewalls restritivas das escolas e evita que os dispositivos abaixem com a carga da rede.
Se olhou recentemente para um programa de Coding and Robotics alinhado com o CAPS, ou tentou desenhar uma prática de Internet das Coisas (IoT) para a sua sala de aula, é provável que tenha esbarrado no acrónimo MQTT e na exigência de um "broker MQTT". Para um professor de TIC ou um coordenador de tecnologia ocupado, isto pode parecer complexidade desnecessária. Porque é que um microcontrolador, como um ESP32 ou um Raspberry Pi Pico W, não pode simplesmente enviar os dados dos sensores diretamente para o portátil ou o telemóvel de um aluno através da rede Wi-Fi local?
A resposta curta é que a comunicação direta entre dispositivos é frágil, exige muitos recursos e é quase totalmente incompatível com a segurança das redes escolares. O MQTT (Message Queuing Telemetry Transport) resolve isto separando quem envia os dados de quem os recebe, encaminhando todas as mensagens através de um gestor central chamado broker. É a norma da indústria para a IoT industrial e é cada vez mais indispensável na computação física em sala de aula.
O placard da sala de aula: perceber o pub/sub
Para perceber porque é que o MQTT funciona, imagine uma turma de 40 alunos. Se cada aluno que quisesse saber a temperatura no exterior tivesse de ir até ao colega sentado à janela e perguntar "Qual é a temperatura?", esse colega passaria a aula inteira a responder a perguntas repetidas em vez de fazer o seu próprio trabalho. Se mais dez alunos quisessem saber quando era o próximo intervalo, teriam de interromper diretamente o professor.
Agora, introduza um placard no corredor. O colega da janela escreve "Temperatura: 22°C" num autocolante e afixa-o sob o título "Meteorologia". O professor afixa "Próximo intervalo: 10:30" sob "Horário". Quem quiser saber a temperatura ou a hora do intervalo vai simplesmente ao placard e lê. O colega da janela não sabe nem quer saber quem está a ler a temperatura; limita-se a publicar a atualização. Os leitores não precisam de incomodar o colega da janela.
É este o modelo publicar/subscrever (pub/sub) que o MQTT usa:
- O publicador: o microcontrolador com um sensor (o colega da janela) que envia dados para o broker.
- O subscritor: o painel, a aplicação no telemóvel ou a base de dados (os alunos que leem o placard) que quer receber esses dados.
- O broker: o servidor central (o placard) que recebe as mensagens dos publicadores e as encaminha para os subscritores certos.
O núcleo técnico: tópicos, mensagens retidas e últimas vontades
O MQTT assenta em três conceitos centrais para manter a comunicação eficiente e fiável, mesmo em ligações sem fios más.
1. Tópicos: as mensagens não são enviadas para dispositivos específicos; são publicadas em "tópicos". Os tópicos são estruturados com barras, criando uma hierarquia como school/lab1/temp ou home/garden/moisture. Um dispositivo pode subscrever um tópico muito específico ou usar caracteres universais para ouvir vários tópicos ao mesmo tempo. Por exemplo, subscrever school/+/temp permite que um único painel mostre as leituras de temperatura de todos os laboratórios do campus.
2. Mensagens retidas: normalmente, se um sensor publica uma leitura e ninguém está subscrito nesse milissegundo exato, a mensagem perde-se para sempre. Se um aluno abrir a aplicação do painel cinco minutos depois, vê um ecrã vazio até o sensor voltar a transmitir. Ao ativar a marca "retained" numa mensagem, o publicador diz ao broker: "Guarda este último valor. Da próxima vez que alguém subscrever este tópico, dá-lhe imediatamente este valor." Isto é fundamental para dados de variação lenta, como a humidade do solo ou o nível dos depósitos de água.
3. Última vontade e testamento (LWT): os microcontroladores nas salas de aula sul-africanas enfrentam desligamentos frequentes e súbitos por causa do load-shedding, de baterias descarregadas ou de alunos que puxam sem querer os cabos de alimentação. Quando um dispositivo se liga pela primeira vez ao broker, regista uma mensagem de "última vontade" (por exemplo, tópico: status/sensor1, mensagem: offline). Se o dispositivo perder subitamente a energia sem enviar um sinal de desligação limpo, o broker deteta a ligação quebrada e publica automaticamente a mensagem de "última vontade" em nome dele, avisando o resto do sistema de que o equipamento está offline.
Três coisas que correm mal numa rede escolar
Embora o MQTT seja robusto, implementá-lo num ambiente educativo obriga a navegar pelas realidades da infraestrutura de TI das escolas. Três modos de falha comuns perturbam regularmente as aulas:
Falhas comuns nas redes escolares
| Característica da rede | Porque existe | Como estraga a aula de IoT |
|---|---|---|
| Segurança WPA2-Enterprise | Protege as redes escolares exigindo nomes de utilizador e palavras-passe individuais dos alunos. | Os microcontroladores comuns (como os chips ESP8266 básicos) não conseguem negociar facilmente os protocolos de segurança Enterprise tal como vêm de origem, o que os impede de entrar na rede Wi-Fi. |
| Isolamento de pontos de acesso (AP) | Impede que os alunos ataquem ou acedam aos portáteis uns dos outros através do Wi-Fi local. | Bloqueia o tráfego local ponto a ponto. Se puser um broker MQTT a correr num Raspberry Pi na sala de aula, os dispositivos dos alunos na mesma rede Wi-Fi ficam impedidos de lhe chegar. |
| Rotatividade de IP dinâmico (DHCP) | Reutiliza endereços IP para evitar que o router da escola fique sem endereços. | Se de facto tiver um broker local num portátil, o endereço IP dele muda com regularidade. Qualquer código de microcontrolador com um endereço IP fixo no código deixa de conseguir ligar-se no dia seguinte. |
Para contornar estes obstáculos da rede local, os educadores têm geralmente de escolher entre discutir com o departamento de TI configurações à medida do router ou encaminhar o tráfego por um broker externo, alojado na nuvem e acessível através das portas web normais. Para os professores que procuram uma solução simplificada, pronta para a sala de aula, que contorne totalmente estas dores de cabeça da rede local, a plataforma Sheen IoT disponibiliza um ambiente MQTT pré-configurado e alojado na nuvem, pensado especificamente para funcionar dentro das limitações das firewalls escolares.
Ao tirar o peso das mensagens dos microcontroladores e passá-lo para um broker dedicado, o MQTT garante que, mesmo que o código de um aluno não esteja otimizado ou que o Wi-Fi da escola oscile, os dispositivos IoT da sala de aula conseguem comunicar de forma fiável e segura.
