O que você realmente precisa saber antes de montar algo
Montar um projeto de IoT parece mais simples do que é até você conectar o primeiro dispositivo e ele parar de responder. A parte teórica existe em abundance, mas o que falta são explicações sobre o que acontece quando dez sensores tentam conversar com um broker ao mesmo tempo e o TCP começa a deixar a desejar. Vou explicar como isso funciona na prática, começando pela parte que a maioria dos tutoriais ignora.
Componentes essenciais em uma arquitetura de internet das coisas
Todo projeto precisa de pelo menos quatro camadas. Dispositivos, que são os sensores e atuadores na borda. Protocolo de comunicação, que define como esses dispositivos falam entre si e com o resto do sistema. Um broker ou gateway, que recebe as mensagens e encaminha para onde precisam ir. E uma plataforma de backend ou dashboard, onde os dados são armazenados e visualizados. Em projetos pequenos, os dois últimos podem ser a mesma coisa. Você joga o dados num banco e pronto. Mas assim que você precisa de alertas em tempo real, automações conditionais ou integração com outros serviços, essa simplificação vira um pesadelo de manutenção.
Os protocolos mais comuns são MQTT, CoAP, HTTP e LoRaWAN. Cada um tem um preço. MQTT é leve, mas exige um broker rodando. HTTP é familiar, mas pesado em overhead para dispositivos com pouca memória. CoAP é bom para redes restritas, mas a maturidade das bibliotecas é inferior. LoRaWAN é para longas distâncias com baixo consumo, mas a latência é de segundos, não milissegundos. Eu escolho MQTT para a maioria dos projetos. A versatilidade dele compensa a complexidade adicional de gerenciar um broker.
Configurando o broker MQTT na prática
Você pode usar um serviço cloud como o HiveMQ Cloud ou o AWS IoT Core, mas isso gera custos recorrentes e dependência de conectividade externa. Para a maioria dos projetos, rodar um Mosquitto localmente ou num VPS barato resolve. Instale, edite o arquivo de configuração e defina pelo menos uma coisa: autenticação. A configuração básica de segurança envolve criar usuários senhas e definir ACLs. Sem isso, qualquer pessoa na sua rede pode publicar ou assinar qualquer tópico. Eu já vi um projeto inteiro comprometido porque alguém esqueceu de colocar senha no broker. Não precisa ser algo complexo. Um arquivo de senhas plano com mosquitto_passwd e uma ACL simples que restringe cada usuário aos seus próprios tópicos já resolve 90% dos problemas.
Um detalhe importante que poucos mencionam: o clean session. Quando um dispositivo se conecta com clean session igual a zero, o broker mantém as assinaturas e mensagens não entregues mesmo se o dispositivo desconectar. Isso é útil para dispositivos que entram e saem da rede frequentemente, mas pode acumular filas infinitas de mensagens se você não configurarem um TTL para as sessões. Configure retain messages com cuidado também. Uma mensagem retida errada num tópico errado pode fazer um atuador disparar na inicialização e causar danos físicos.
O problema que ninguém conta sobre QoS
O QoS do MQTT tem três níveis. Zero significa enviar e torcer. Um significa entregar pelo menos uma vez, com possíveis duplicatas. Dois significa entregar exatamente uma vez, com handshake obrigatório. A tentação é usar QoS dois para tudo. É o mais seguro. Mas QoS dois triplica a latência comparado ao QoS zero em redes com alguma congestão. Eu aprendi isso na prática quando um sistema de monitoramento de temperatura que eu projetei começou a ter delays de 4 segundos nas leituras. O gargalo não era a rede, era o handshake do QoS dois passando por cada mensagem. Trocar para QoS um nos sensores de temperatura e manter QoS dois apenas nas comandos de atuadores reduziu a latência média para 800ms. O custo foi aceitar ocasionalmente leituras duplicadas no dashboard, o que foi trivial de tratar com um filtro no backend.
A regra prática é: letelemetry, QoS zero ou um. Para comandos críticos, QoS dois. E monitore o throughput do broker. Se as filas de QoS dois estiverem acumulando, seu sistema está pedindo socorro.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Edge computing vs cloud: onde processar os dados
A tendências é tudo na nuvem. Mas processar tudo na nuvem significa enviar todos os dados brutos, o que consome banda, aumenta latência e gera custos. Em um projeto real de monitoramento industrial, eu tive dezenas de sensores vibrando a 1kHz. Enviar cada amostra para a nuvem seria absurdo. Em vez disso, implementei um pré-processamento na borda com um ESP32 que calculava RMS e valor de pico antes de enviar apenas os resumos para o broker. Isso reduziu o volume de dados em 95% e ainda permitiu detectar anomalias localmente, disparando alertas instantâneos sem depender da conectividade com a nuvem. Não adianta ignorar a borda só porque o cloud parece mais fácil. A decisão de onde processar depende de três fatores: latência exigida, largura de banda disponível e custo de infraestrutura. Se qualquer um desses três é crítico, a borda é obrigatória. Se nenhum é, mande tudo pro cloud e esqueça a complexidade.
Estruturando os tópicos MQTT
A organização dos tópicos define quão maleável seu sistema será. Estruturas planas como dispositivo_sala_1_tempo funcionam no começo. Quando você cresce para cinquenta dispositivos, essa estrutura se torna ingovernável. O padrão hierárquico com separadores é mais escalável. Uma estrutura que funciona bem é: empresa/edificio/setor/dispositivo/tipo_dado. Isso permite subscrições em nível de setor para monitoramento agregado, ou em nível de dispositivo para controle específico. Use Wildcards (+) para subscrições e (#) para capturar subárvores inteiras, mas evite aninhar wildcards profundos demais. A performance do broker degrada com subscrições muito amplas.
Outro ponto negligenciado: o payload. A maioria dos dispositivos envia JSON. JSON é legível, mas verboso. Para dispositivos com recursos limitados, formatar valores como strings numéricas ou até binário empacotado economiza banda significativa. A transformação para JSON legível pode ser feita no backend, na camada de ingestão. Separe transporte de representação. Isso economiza bateria e banda nos dispositivos e facilita a manutenção no backend.
Armazenamento e persistência
Dados de IoT são series temporais. Bancos relacionais tradicionais não foram feitos para isso. Cada INSERT em PostgreSQL ou MySQL com timestamps a cada segundo multiplica as linhas rapidamente. Um banco time-series como o InfluxDB ou até o TimescaleDB (extensão do PostgreSQL) escala muito melhor para esse padrão de escrita. Se o projeto for simples, você pode até usar o próprio Mosquitto com persistence ativada, mas isso é para prototipagem. Em produção, tenha um pipeline separado para ingestão e um banco separado para query. Misturar os dois é pedir para o broker virar gargalo quando o volume crescer, e ele vai crescer. Sempre cresce.
Testando antes de implantar
Antes de colocar qualquer coisa em produção, teste com carga real. Use ferramentas como o hivemq mqtt client ou scripts simples com paho-mqtt para simular centenas de publicações simultâneas. Meça latency, throughput e uso de memória do broker. Um Mosquitto bem configurado aguenta milhares de conexões persistentes em hardware modesto, mas isso depende de tuning de ulimit, buffer sizes e número de workers. O arquivo de configuração do Mosquitto tem parâmetros que quase ninguém ajusta. max_connections, listener, max_inflight_messages, keep_alive_interval. Valores padrão funcionam para poucos dispositivos. Para produção, aumente max_inflight_messages para 50 ou 100, ajuste keep_alive para 60 segundos e monitore o uso de memória. Sem tunar esses parâmetros, você vai ter mensagens sendo descartadas silenciosamente em momentos de pico.
A armadilha da escalabilidade
A maioria dos projetos de IoT falha na escalabilidade, não no conceito. Você faz funcionar com cinco sensores, tudo perfeito. Quando escala para cinquenta, a rede engasga, o broker cai ou os dados somem sem aviso. O problema raramente é o hardware. É a falta de planejamento para falhas. Plano básico de resiliência: Heartbeat dos dispositivos. Se um dispositivo não publicar heartbeats por um período configurado, o sistema deveá-lo como offline automaticamente. Isso evita alertas fantasmas e permite ação corretiva rápida. Retry com backoff exponencial nos dispositivos. Se um publish falhar, não tente imediatamente novamente. Aguarde, retrie, aguarde mais. Isso evita snowball de requisições quando a rede volta.
E monitoramento do broker. Grafana com Prometheus coletando métricas do Mosquitto é overkill para projetos pequenos, mas essencial para qualquer coisa que precise ficar no ar. Sem métricas, você está voando cego. O tempo médio para detectar e resolver um problema sem monitoramento é ordens de grandeza maior do que com monitoramento básico. O que funciona hoje com dez dispositivos provavelmente não funciona com cem. Planeje essa transição desde o início. A arquitetura que você escolher define o quanto de dor de cabeça terá quando crescer.
