Executando verificação de segurança...

1 min de leitura ·

Dificuldades de integrar IoT e web no Brasil: como resolver?

Gostaria de saber a opinião de vocês sobre o seguinte: estou trabalhando em um projeto para criarmos, no Brasil, um site semelhante ao The Things Network, só que brasileiro. Tenho muitos anos de experiência em prototipagem de IoT, inclusive atuando em incubadoras de universidades, e percebo que a maior dificuldade, principalmente para iniciantes e estudantes universitários, é ter a expertise para unir várias tecnologias. Por exemplo: muitos conseguem fazer um protótipo, mas têm dificuldade para colocar uma interface web, exibir dados de forma fácil, realizar testes web, utilizar servidores online, ou seja, integrar o seu projeto com outras tecnologias como portais, ou até mesmo apenas exibir os dados coletados para um cliente, o que poderia impulsionar o projeto.

Minha ideia é disponibilizar um site gratuito (até um certo limite) para isso: permitir integrar IoT à web de diversas formas, bem como fazer a web disparar comandos para dispositivos IoT, concentrar dados (hubs), distribuir, etc. Ou seja, oferecer essa parte de infraestrutura na web.

Já tenho esse projeto quase pronto, mas acabei paralisando por causa de outros trabalhos. Agora, estou querendo saber qual seria o interesse de vocês nisso antes de me aventurar mais a fundo e colocar no ar.

O que vocês acham?

Muito interessante essa ideia!
Nem sabia do The Things Network, e pesquisando rapidamente parece que aqui no RJ a ideia está aparentemente parada por algum motivo (falta de público interessado?)

Outra coisa recente que descobri e estou prestes a testar é a Meshtastic. A comunidade BR parece ter avançado mais: https://platform.meshbrasil.com/?lat=-22.888827380892344&lng=315.81710815429693&zoom=9

Se puder ajudar (atualmente fora do horário de trabalho CLT), pode contar comigo!

Meus 2 cents,

O problema que vejo na rede da The Things Network (TTN) eh o preco dos equipamentos (o que acaba impactando na capilaridade da rede).

Na pratica, quem quer trabalhar LoRaWAN pode usar a rede da ATC (agora Netmore) via parceiros (como Kore, Algar) cujo custo para DEV eh bem vantajoso (producao eh outra historia).

E se for para uso local, um gateway privado (como robocore, KHOMP, raspberry PI + shield) ou mesmo via Lora P2P (esp32, LILYGO) acaba sendo mais interessante.

E por fim, para uso coorporativo, em muitos casos tem empresas optando por NB-IoT/LTE-M (que no final das contas usa a infra das operadoras).

Saude e Sucesso !

Autor

Mandou muito bem nesse complemento, @Oletros. Esse mapa de opções que você fez resume bem a realidade:
– TTN encarece pelo custo dos equipamentos/gateways,
– pra LoRaWAN sério dá pra usar ATC/Netmore via Kore/Algar,
– pra uso local faz sentido gateway privado ou LoRa P2P,
– e em corporativo NB-IoT/LTE-M acaba se apoiando na infra das operadoras.

Justamente por existir esse mosaico de possibilidades de conectividade é que eu estou pensando a minha solução como camada de integração web por cima da rede, e não como concorrente de nenhuma delas.

A ideia é:
– você escolhe o que faz mais sentido no campo (mesh, LoRaWAN privado/público, NB-IoT, LTE-M, Wi-Fi, o que der),
– em algum ponto isso chega a um ponto de acesso que consiga fazer uma requisição HTTP (ou outro protocolo suportado),
– e aí a plataforma entra com endpoints simples (tipo /sendData, /upload_error_log/<device_id>), armazenamento, visualização em painel, e depois integração com outros sistemas.

Mesmo quando não existe biblioteca pro microcontrolador específico, a ideia é que a doc traga exemplos “pé no chão”, mostrando como montar o request na unha (C/Arduino/MicroPython), pra que qualquer MCU que fale TCP/IP consiga usar a mesma API.

Se você estivesse hoje tirando um projeto novo do papel aqui no BR, por onde começaria na prática em termos de conectividade: LoRaWAN privado, NB-IoT/LTE-M, mesh…? Curioso pra saber qual caminho você considera mais realista em 2025.

Autor

Valeu demais, @faelpinho! 🙌

Também tive essa sensação de que a TTN aqui em vários lugares acabou esfriando, muito mais por falta de massa crítica mesmo do que por falta de potencial.
E Meshtastic/MeshBrasil é um excelente exemplo de como a comunidade BR consegue empurrar coisas de comunicação alternativa pra frente quando o modelo faz sentido pra galera.

O que estou construindo caminha em outra camada: em vez de ser uma rede em si, a ideia é ser um “hub web” pra qualquer nó de IoT, independente de ser LoRa, mesh, Wi-Fi, NB-IoT ou o que for.
E a visão é que qualquer microcontrolador (ESP, STM, AVR, o que for) que consiga fazer um POST HTTP simples consiga mandar dados pra lá — mesmo que não exista biblioteca pronta. A doc da plataforma vai ensinar a montar o request “na unha”, com exemplos em C/Arduino/MicroPython bem simples.

Por isso inclusive essas malhas tipo Meshtastic encaixam bem: elas podem cuidar da comunicação “no mato”, e em algum ponto um nó de borda pode empurrar os dados pra API web e aparecer no painel.

Curti demais você se colocar à disposição pra ajudar fora do horário CLT. Se você topar, quando eu tiver um MVP redondinho, queria muito montar um teste real contigo:
– pegar um nó Meshtastic (ou algo parecido),
– fazer ele empurrar algum dado simples (ex: temperatura, mensagem, estado) pra API,
– e ver isso aparecendo num painel web.

Que tipo de caso você acharia mais legal de testar primeiro: monitoramento ambiente, localização, mensagens entre nós…? Se você disser o que te anima mais, eu já penso com esse uso em mente.

Meus 2 cents,

Minha sensacao eh: sim, existe mercado (se voce olhar o interesse no post recente sobre ESP32 acho que confirma isso).

https://www.tabnews.com.br/lucasrguerra/espdocs-criei-a-documentacao-para-esp32-que-eu-sempre-quis-ter-e-talvez-voce-tambem

Porem...

Tenho contato com IoT a quase vinte anos - basicamente desde quando era chamado apenas de 'sistemas embarcados' (usando GPRS/2G/3G/WifiNB-IoT/LoRaWAN/RS485/etc).

Pensando no TTN e LoRaWAN - tive muito contato com a ATC, Kore, Algar, KHOMP (entre outras empresas) - inclusive criando uma plataforma para tratamento de telemetria/dashboard/billing (recebendo dados REST ou MQTT) neste tipo de segmento (testamos varios tipos de gateway e NS, privados e publicos).

Tinha um projeto onde a telemetria recebida podia ser inserida em um blockchain (ou tangle) e/ou assinada via carimbo do tempo para nao-repudio e posterior auditabilidade (p.ex. tracking de medicamentos, controle de custodia e temperatura).

Acabei 'congelando' os projetos IoT por enquanto simplesmente porque o retorno nao acontecia - geralmente por conta dos custos.

Muito se fala em cidades inteligentes - mas a adocao esta mais lenta que o previsto.

Hoje o meu foco eh IA - que tem sido bem mais promissor.

Talvez (um talvez bem grande) hoje em dia seja mais facil/barato fazer um projeto com foco coorporativo para IoT - nao sei.

Outro talvez seria explorar os dados de telemetria do IoT (big data) com as flexibilidades da IA (via ML) - outro grande 'nao sei'.

Vai contando como esta sendo tua jornada - tem muita gente (inclusive eu) que gostaria de continuar acompanhando.

Saude e Sucesso !

Autor

Cara, valeu demais por compartilhar essa experiência toda, dá pra ver que você já rodou MUITO nesse mundo de IoT/embarcados.

Eu enxergo a coisa bem parecido com você: aqui no Brasil, hoje, o maior gargalo é justamente tirar o protótipo de IoT do laboratório e levar pro mundo real sem morrer nos custos – principalmente quando entra homologação, Anatel, rede, gateway, etc.

A proposta do que estou construindo não é ser “mais uma rede” tipo TTN, e nem ficar preso a ESP32/LoRa. A ideia é ser uma camada web genérica, em cima de qualquer solução de campo:
– no backend eu já tenho hoje cadastro/login de usuários, confirmação de e-mail,
– cadastro de dispositivos, geração de arquivo de configuração, ele gera o arquivo pra voce gravar nos esp com micropython por exemplo.
– endpoint HTTP pra receber dados em JSON (/sendData),
– endpoints pra receber error_log.txt e “skeleton” do dispositivo (upload de logs),
– e um painel web pra visualizar e organizar isso.

A visão é: qualquer microcontrolador que consiga abrir uma conexão e fazer um POST HTTP simples consegue falar com a plataforma – mesmo sem biblioteca específica. A doc vai mostrar exemplos de código em C/Arduino/MicroPython, justamente pra quem está com um PIC, STM32, ESP, RPi Pico, etc. conseguir integrar só copiando o padrão de requisição.

Ou seja, eu quero atacar essa fase de prototipagem/MVP antes da dor pesada de homologação: ajudar o cara a validar o conceito, integrar com web, mostrar dado pro cliente/investidor, sem precisar ser especialista em backend/nuvem. Se vingar, ele parte pra rede definitiva (LoRaWAN, NB-IoT, LTE-M, o que for) e pro investimento maior.

Também estou bem atento a esse ponto que você comentou de telemetria + IA. Como a plataforma já recebe e organiza dados e logs, faz todo sentido, num segundo momento, pensar em features de análise/anomalia/insights pro usuário em cima desse histórico.

Com a tua bagagem, queria muito ouvir tua visão: se você fosse desenhar hoje um “modelo de negócio minimamente viável” pra esse tipo de plataforma aqui no BR, você focaria mais em universidade/makers e PoC ou já iria direto pro corporativo, com coisas mais maduras tipo billing, auditoria, etc.?

Meus 2 cents extendidos,

Eh bom lembrar que nem todo device vai ter acesso a HTTP/REST - depende da conectividade e do integrador (broker).
Alem do REST eu incluiria uma opcao para MQTT ou algum tipo de messageria: tem brokers que so funcionam assim. E messageria geralmente permite comunicacao bidirecional que via REST voce nao tem.
Onde: Coorporativo, monta a plataforma MVP e bate na porta do iot-labs. Entre em contato tambem com a netmore (https://netmoregroup.com/contact-us/).
ALGAR: https://loja.algar.com.br/empresas/lorawan/#lorawan_form
Kore: https://www.korewireless.com/br/contact-us/
Mas nao investe 'muito' na plataforma: eh cadastrar devices, receber telemetria e mostrar dados. Coisas mais profundas podem ser desenvolvidas em uma PoC (paga) pelo interessado ou negociada com os brokers (algar, kore, etc)
Em suma: tem de ter alguem bancando teu projeto - universidade/makers podem fazer parte do ecosistema, mas antes precisa garantir fluxo financeiro (ate para saber o que vai dar resultado).

Se voce tiver interesse, podemos marcar uma call para bater papo sobre o assunto (via teams, zoom ou g.metting). Se sim, basta mandar um email para [email protected]

Saude e Sucesso !

Mano, ver o seu post até animou meu dia, atuo como desenvolvedor web, mas me formei em engenharia elétrica, e meu TCC foi envolvendo IoT, e sou fascinado pelo tema.

Uma das maiores dificuldades que tive dentro da universidade era encontrar material e infraestrutura relacionada a isso, ainda mais em português.

Hoje em dia não estou muito por dentro de como tá essa questão, mas lembro que na época foi uma dor muito grande minha, então acredito que o seu projeto tenha bastante potencial, principalmente se conseguir explorar o nicho universitário que sofre um pouco de não saber por onde começar um projeto de IoT.

Enfim, boa sorte aí mano, desejo sucesso! ❤

Autor

Mano, sério, obrigado demais pelo comentário – ler isso aqui também me deu um gás, o projeto é grande e você vai desanimando um pouco no percurso quando a coisa ainda não está rodando no ar. 😄

Você é exatamente o tipo de pessoa que eu tinha em mente quando comecei a desenhar esse projeto: alguém que curte IoT, tem formação em engenharia, mas hoje está mais no mundo web e sentiu na pele a falta de referência e infraestrutura em português na época da faculdade/TCC.

Eu concordo contigo: pra quem está na universidade, a maior dor não é “soldar o sensor”, é juntar os mundos – pegar um microcontrolador qualquer, colocar pra falar com a web, expor API, montar dashboard, fazer automação… isso normalmente exigiria 4–5 perfis profissionais diferentes.

O que estou construindo é justamente uma plataforma que evita que o aluno precise virar especialista em tudo:
– ele cadastra o dispositivo,
– recebe um endpoint de API e instruções,
– e, se o microcontrolador conseguir fazer uma requisição HTTP simples, ele já consegue mandar dados, salvar logs e visualizar isso num painel web.

A ideia é que seja agnóstico de hardware: ESP32, STM32, Arduino, Raspberry Pico… não importa. Mesmo quando não existe biblioteca, a doc ensina a montar o request “na unha”, com exemplos de código em C/Arduino/MicroPython. Assim o foco do TCC volta a ser o problema em si (energia, automação, monitoramento, etc.) e não “como levantar um backend do zero”.

Quero muito explorar esse nicho universitário que você comentou. Se você topasse opinar, que tipo de coisa teria te ajudado mais no seu TCC na época?
– mais exemplos de integrações prontas (coisa tipo “pega esse código e já sobe os dados”),
– uma infra gratuita até X dispositivos/alunos,
– ou material didático explicando o passo-a-passo de “do sensor ao dashboard”?

Se puder compartilhar essa visão de ex-universitário que sofreu com isso, ajuda demais a encaixar a plataforma na realidade de quem está chegando agora.

Lendo vocês aqui senti que meu conhecimento em iot é quase infantil, só brincando com mqtt e nodeRed.

É uma área muito grande mano, é normal ter pouco conhecimento sobre, envolve tanto eletrônica quanto computação, que são áreas correlatas mas beeem extensas e complexas.

Eu também me sinto assim kkkkk.

Demorei um pouco, mas vim aqui responder.

Na época minhas maiores dificuldades foram:

Como conectar meu dispositivo a minha aplicação (quis usar o padrão pub/sub com mqtt, mas lembro que foi bem complicado de implementar um broker adequado na época);
Encontrar exemplos, aulas e documentações em português, que explorassem todo este fluxo de comunicação;
Entender como escalar o sistema (Conectar múltiplos dispositivos a um mesmo sistema web).

Na época, acabei explorando vários caminhos, mas lembro de sofrer com o uso e implementação de brokers mqtt, acabei utilizando serviços externos, mas nenhum deles parecia muito confiável. No final, fiz a comunicação através do Firebase Realtime Database (não foi a melhor abordagem, mas foi a mais prática de se implementar).

Hoje em dia, sei que existem ferramentas melhores no mercado, estou um pouco afastado do universo de IoT, mas ainda tenho muita vontade de desenvolver novos projetos como hobby.

guilhermegalanti

Eu trabalho com IoT e temos uma enorme dificuldade em integrar os dados e apresentar em dashboards.

Quando o sistema tem coisa demais, ele não serve porque muitas vezes queremos mostrar uma métrica ou outra... mas quando tem de menos, o sistema impede consultas avançadas e acabamos tendo que recorrer aos métodos antigos, deixando os sistema de lado.

Cheguei a fazer alguns protótipos de plataforma para cuidar de diversos sensores em campo ao mesmo tempo.

Dica: temos problemas relacionados à versão de hardware e firmware em campo. Tenho certeza que empresas grandes pagariam para solucionar problemas de compatibilidade!

Meus 2 cents,

Essa questao de versao de hardware/firmware eh um problema bem real: na plataforma que desenvolvi temos campos especificos para identificar estes itens (inclusive configuracoes personalizadas) onde o comportamento do sistema pode mudar conforme a versao (o mesmo a estrutura do JSON).

Outro problema comum eh o payload - que dependendo do broker (intermediario) as vezes vinha com detalhes diferentes (para o mesmo equipamento).

Ou ainda, que dependendo do tipo de conectividade (p.ex. LoraWan) o payload tinha tamanho maximo e tinha de fazer um certo malabarismo para comprimir os dados da telemetria dos sensores para caber (nada de JSON verbosos).

Ou ainda ter de lidar com a classe do dispositivo para saber se a comunicacao poderia ser bi-direcional, criar um fluxo de controle para saber se um comando/configuracao enviado tinha sido recebido e acatado pelo dispositivo e por ai vai.

Enfim - trabalhar com embarcados eh lindo na teoria (p.ex. arduino, esp32) mas quando chega na pratica de equipamentos com pouca memoria, pouco processamento, pouco armazenamento e conectividade limitada vira um contorcionismo e eh o famoso: "como faz para colocar um elefente num fusca ?" - e o cliente quer resposta (te vira).

Saude e Sucesso !

Autor

Eu desenvolvi um firmware para ESP32 que permite atualizar o código em campo via rede LoRa. A ideia é possibilitar a atualização remota da aplicação sem correr o risco de travar o controlador.

Ele é todo baseado em MicroPython e, depois que o firmware é gravado, o que passa a ser atualizado não é o firmware em si, mas apenas o código da aplicação. Além disso, há um watchdog específico para falhas de atualização: se ocorrer algum erro durante o processo, o dispositivo se conecta ao servidor, faz automaticamente um downgrade para a versão anterior e fica pronto para receber uma nova tentativa de atualização.

Também estou unindo isso a um conceito de trabalho modular. Minha ideia é desenvolver um produto/módulo ESP que você possa integrar facilmente a outros, criando um controlador maior e com mais portas. Esses módulos se comunicam via I²C, tudo sobre uma rede LoRa, usando um protocolo de mensageria semelhante ao MQTT, mas que estou escrevendo do zero.

Em breve vou postar mais coisas sobre esse projeto — quero ter algo mais robusto para mostrar.

Sobre a questão dos Dashboards e integração de dados é justamente o que estou trabalhando para ser bem universal com uma biblioteca ou até mesmos poucas linhas de código dentro do código principal, no site depois pretendo colocar a integração via código nas linguagens mais usadas, ele vai permitir versionamento, upload de logs sem armazenamento local no controlador e backup de código se o controlador suportar claro por que essa função já exige um pouco mais de memória, por isso eu pretendo lançar umas três possibilidades de integração cada uma terá mais funções e consome mais memória.

Já tive um projeto semelhante, criado em 2019, chamado ComedataIoT. Era um sistema web para visualização de dados de IoT, onde os dispositivos embarcados enviavam informações via API da aplicação, e o sistema exibia gráficos configuráveis pelo usuário. Atualmente, estou iniciando um processo de reescrita desse projeto, mas estou com pouco tempo disponível.

Se quiser bater um papo sobre, chama!