Existem Diversas Plataformas Para Desenvolvimento De Projetos De Iot

Escolhendo a plataforma certa para IoT não é sobre funcionalidades

A primeira coisa que todo mundo ignora ao começar um projeto de IoT é o lock-in. Vocês entram num ecossistema porque a interface é bonita, a documentação parece boa e o plano gratuito é generoso. Isso funciona bem até o dia em que você precisa migrar 40 mil sensores para outro provedor e descobre que seu protocolo MQTT personalizado não está em lugar nenhum. E essa é a verdade prática que nenhum vídeo do YouTube conta. O mercado tem opções demais. Tem o AWS IoT Core, o Azure IoT Hub, o Google Cloud IoT (que foi descontinuado em março de 2023, muita gente ainda não sabe disso). Tem o ThingsBoard, que é open-source e roda no seu próprio servidor. Tem o Particle, o Adafruit IO, o Blynk, o Ubidots. Cada uma com limitações completamente diferentes que só aparecem depois que o projeto já está rodando em produção. Na prática, a escolha deve começar pela conectividade, não pela interface. Se o seu dispositivo vai usar Wi-Fi, praticamente qualquer plataforma funciona. Se for LoRaWAN, aí as opções diminuem drasticamente. AWS exige que você configure um gateway Lorawan completo com o The Things Network ou uma solução similar antes de conectar qualquer dispositivo. O ThingsBoard simplesmente importa os dados do TTN via webhook e pronto. Isso economiza semanas de configuração.

O problema que eu encontrei na minha experiência foi com o Azure IoT Hub. O SDK deles para Python é decente, mas a implementação de twin desejado vs. twin atual gera uma inconsistência silenciosa que não aparece nos logs. Um dispositivo enviava telemetria corretamente mas o state reportado nunca era salvo no cloud twin. A causa? O payload vinha em bytes, e a função deserialize esperava string. O dispositivo não dava erro, o hub não dava erro. Só o twin ficava vazio. A solução foi adicionar uma camada de transformação JSON antes do publish, usando um microserviço Azure Function como bridge. Isso adicionou latência de 200ms mas resolveu o problema de forma limpa. Se você está começando agora, o ThingsBoard Community Edition é o mais honesto para testar. Roda num container Docker, não cobra nada, suporta MQTT, HTTP e CoAP nativamente. A desvantagem é que a visualização é básica e você precisa montar os dashboards do zero. O painel de administração também é lento quando você passa de mil dispositivos, porque as queries de agregação são feitas em tempo real no banco PostgreSQL por trás. Para projetos comerciais, a diferença real de custo aparece no ingest de dados. O AWS IoT Cobra por mensagem enviada, por ação de regra e por armazenamento de thing shadow. Um sensor enviando dados a cada 10 segundos gera 8 mil mensagens por dia. Com 100 dispositivos, isso é 800 mil mensagens diárias. No pricing atual, sai cerca de 12 dólares por mês só de ingest. O Azure tem modelo similar mas com custo menor por mensagem no tier gratuito. O ThingsBoard, se você hospeda no seu próprio servidor, custa apenas o VPS. Um Instância EC2 t3.medium ou equivalente rodando o ThingsBoard custa cerca de 30 dólares mensais e aguenta facilmente dez mil dispositivos enviando dados a cada 30 segundos.

Uma coisa que os tutoriais não mencionam é a gestão de certificados. No AWS IoT, cada dispositivo precisa de um certificado X.509 individual. Se você tem 500 dispositivos e um certificado expira, precisa rotacionar manualmente todos eles. O Azure permite autenticção por TLS comum com shared access keys, o que é muito mais simples para protótipos mas considerado inseguro para produção. A maioria das equipes começa com shared key e leva susto quando o security audit chega. Outro detalhe técnico: a ordenação de mensagens. MQTT garante QoS 1, que significa entrega pelo menos uma vez. Isso quer dizer que mensagens podem chegar duplicadas. Se você está armazenando leituras de temperatura por segundo em um banco de dados e duas mensagens chegam com o mesmo timestamp, seu relatório mensal terá dados duplicados sem você perceber. A solução é usar o timestamp de chegada no banco como campo de ordenação e aplicar uma regra de deduplicação baseada em hash do payload na hora da ingestão. O Blynk e o Adafruit IO são boas opções para hobby e protótipos rápidos porque abstraiem toda a complexidade de autenticação e protocolo. Você liga o dispositivo e começa a ler dados em minutos. Mas ambas têm limites rígidos: Blynk permite envio de dados a cada 10 segundos no plano gratuito e corta a conexão se você violar isso. Adafruit IO tem limite de 60 mensagens por minuto por feed. Em um projeto real com dez feeds, você fica em 600 mensagens por minuto e precisa espaçar as leituras ou comprar o planoPlus, que custa 24 dólares mensais por conta.

Se o projeto exige offline-first, onde o dispositivo precisa funcionar sem internet e sincronizar depois, praticamente só o ThingsBoard e o AWS IoT SiteWise oferecem isso de forma nativa. O AWS tem um custo de setup alto porque exige configurar o SiteWise Portal, os assets hierárquicos e os interceptores de dados. O ThingsBoard permite fila local com cache em disco e sincronização automática quando a rede volta, tudo configurável via plugin API. A desvantagem é que a fila local usa armazenamento do dispositivo, então sensores com ESP32 e 4MB de flash precisam gerenciar isso com cuidado para não estourar a partição. Resumindo sem resuminhar: não escolha a plataforma pela facilidade de começar. Escolha pela arquitetura de conexão do seu dispositivo e pelo custo que vai ter quando o projeto sair do protótipo. Teste com três dispositivos durante duas semanas antes de comprometer com qualquer provedor. Os problemas reais aparecem no segundo mês, não no primeiro deploy.