NOTAS DO PROFESSOR 📖 O que define a Internet das Coisas A IoT consiste em dar a objetos físicos a capacidade de sentir, atuar e comunicar pela internet. O essencial é perceber a combinação de quatro elementos: sensores, atuadores, processamento e rede. Ancorar o conceito em exemplos que os formandos já conhecem, como uma lâmpada inteligente ou um termostato, torna a ideia imediata. 🗣️ Pontos a desenvolver oralmente • Pedir exemplos de dispositivos IoT que os formandos já usam em casa • Distinguir sensor de atuador com casos concretos • Referir a escala do mercado e os setores onde a IoT cresce
NOTAS DO PROFESSOR 📖 A cadeia do sensor à nuvem Um sistema IoT típico segue um percurso claro: o sensor lê, o microcontrolador processa, a rede transmite e a nuvem armazena, visualiza e alerta. Visualizar este fluxo ajuda os formandos a situarem cada tecnologia da UC dentro do todo. Esta cadeia é o mapa mental que devem reter para todos os exercícios seguintes. 🗣️ Pontos a desenvolver oralmente • Percorrer o diagrama da esquerda para a direita com a turma • Indicar em que etapa entra cada tema da UC (ESP32, MQTT, dashboards) • Explicar porque o foco é device para cloud e não o sentido inverso
NOTAS DO PROFESSOR 📖 Escolher o microcontrolador certo O ESP32 destaca-se por juntar WiFi e Bluetooth, dois núcleos e bom preço, o que o tornou o cavalo de batalha da IoT amadora e profissional. Convém contrastá-lo com o ESP8266, mais barato mas mais limitado, para os formandos perceberem o critério de escolha. Ter a placa física em mão durante a aula ajuda a fixar pinos e dimensões. 🗣️ Pontos a desenvolver oralmente • Comparar ESP8266 e ESP32 em preço e capacidades • Mostrar a placa física e localizar os pinos principais • Justificar a escolha do ESP32 DevKit para os exercícios da UC
NOTAS DO PROFESSOR 📖 Preparar o ambiente de desenvolvimento Antes de programar é preciso configurar o Arduino IDE para reconhecer o ESP32, adicionando o URL das placas e instalando o respetivo pacote. Este passo costuma ser onde os iniciantes encalham, sobretudo na seleção da porta e nos drivers USB. Vale a pena percorrer a configuração ao vivo e antecipar os erros mais comuns. 🗣️ Pontos a desenvolver oralmente • Explicar a diferença entre o pacote de placas e a porta série • Antecipar o problema da placa não aparecer e como diagnosticar • Indicar como identificar se é necessário o driver CP210x ou CH340
NOTAS DO PROFESSOR 📖 O primeiro programa: ligar ao WiFi Este exemplo é a base de quase todos os projetos IoT: ligar o ESP32 a uma rede e obter um endereço IP. Note-se o padrão de esperar pela ligação dentro de um ciclo while, imprimindo pontos no monitor série como feedback. Convém destacar o uso do Serial.begin a 115200 e o monitor série como a primeira ferramenta de depuração. 🗣️ Pontos a desenvolver oralmente • Explicar o ciclo de espera até WL_CONNECTED • Mostrar o monitor série a imprimir o IP obtido • Alertar para não deixar credenciais WiFi em código partilhado
NOTAS DO PROFESSOR 📖 Consumir uma API com HTTP GET O ESP32 pode atuar como cliente HTTP e consumir APIs REST, tal como um browser. Este exemplo mostra o padrão essencial: verificar a ligação, iniciar o pedido, ler o código de resposta e o corpo, e fechar a ligação. O delay de 60 segundos é uma primeira forma, ainda que rudimentar, de espaçar os pedidos para não sobrecarregar o serviço. 🗣️ Pontos a desenvolver oralmente • Explicar o significado do código de resposta HTTP devolvido • Sublinhar a importância de fechar a ligação com http.end() • Discutir porque convém respeitar limites de pedidos das APIs
NOTAS DO PROFESSOR 📖 Enviar leituras com HTTP POST Enquanto o GET serve para obter dados, o POST permite ao dispositivo enviar leituras para um servidor próprio. Note-se a construção manual do corpo em JSON e a definição do cabeçalho Content-Type, que indica ao servidor o formato dos dados. Este padrão é a base de qualquer estação que reporta sensores a um backend. 🗣️ Pontos a desenvolver oralmente • Explicar o papel do cabeçalho Content-Type no pedido • Mostrar como se monta o JSON com os valores dos sensores • Antecipar o tema MQTT como alternativa mais eficiente ao HTTP
NOTAS DO PROFESSOR 📖 MQTT: o protocolo da IoT O MQTT foi pensado para dispositivos com pouca potência e redes instáveis, sendo muito mais leve que o HTTP para comunicação contínua. A diferença-chave é o modelo publicar/subscrever, em que um broker central encaminha mensagens organizadas por tópicos, em vez do clássico pedido/resposta. Perceber esta arquitetura é essencial para projetos IoT que escalam para muitos dispositivos. 🗣️ Pontos a desenvolver oralmente • Contrastar publicar/subscrever com o modelo pedido/resposta do HTTP • Explicar o papel do broker como ponto central de encaminhamento • Dar exemplos de hierarquias de tópicos bem estruturadas
NOTAS DO PROFESSOR 📖 O fluxo de mensagens no MQTT Este diagrama torna concreto o modelo publicar/subscrever: o sensor publica num tópico e o broker reencaminha a mensagem a todos os subscritores interessados. O ponto importante é que o publicador não conhece os recetores, o que desacopla os componentes e facilita acrescentar novos consumidores. Vários sistemas podem reagir à mesma leitura sem qualquer alteração no dispositivo. 🗣️ Pontos a desenvolver oralmente • Sublinhar o desacoplamento entre quem publica e quem subscreve • Mostrar como acrescentar um novo subscritor sem mexer no sensor • Relacionar o diagrama com um caso real de casa inteligente
NOTAS DO PROFESSOR 📖 Publicar leituras com PubSubClient A biblioteca PubSubClient é a forma mais comum de fazer MQTT no ESP32. O exemplo mostra três passos essenciais: garantir a ligação ao broker, chamar mqtt.loop() para manter a comunicação viva, e publicar periodicamente sem bloquear o programa usando millis(). Esta técnica de temporização sem delay é uma boa prática que vale destacar. 🗣️ Pontos a desenvolver oralmente • Explicar porque mqtt.loop() tem de ser chamado em cada iteração • Comparar a temporização com millis() face ao uso de delay() • Mostrar o tópico publicado a aparecer num cliente MQTT de teste
NOTAS DO PROFESSOR 📖 Receber comandos com subscribe Subscrever um tópico permite ao dispositivo reagir a mensagens vindas do exterior, fechando o ciclo de controlo bidirecional. A função de callback é invocada sempre que chega uma mensagem ao tópico subscrito, transformando o payload em ação, como acender um LED. É aqui que a IoT deixa de ser só monitorização e passa a permitir atuação remota. 🗣️ Pontos a desenvolver oralmente • Explicar como o payload em bytes é convertido para texto • Mostrar um comando enviado de uma app a acender o LED • Distinguir o papel de publicar (enviar) e subscrever (receber)
NOTAS DO PROFESSOR 📖 ThingSpeak: visualizar dados sem programar o servidor O ThingSpeak permite recolher e visualizar dados de sensores na nuvem sem construir backend próprio, com gráficos automáticos e alertas. O fluxo é simples: criar um canal, obter a chave de escrita e enviar leituras por um pedido HTTP. É uma excelente porta de entrada para os formandos verem dados reais a aparecer num painel. 🗣️ Pontos a desenvolver oralmente • Mostrar a criação de um canal e onde fica a Write API Key • Explicar o conceito de campos (fields) dentro de um canal • Discutir os limites do plano gratuito e quando são atingidos
NOTAS DO PROFESSOR 📖 Adafruit IO: dashboards via MQTT A Adafruit IO é uma plataforma cloud particularmente amigável para MQTT, com painéis visuais que se montam por arrastar e largar. É uma boa escolha quando se quer combinar a eficiência do MQTT com visualização sem esforço de programação. Convém destacar o conceito de feeds, equivalente aos tópicos, e os limites do plano gratuito. 🗣️ Pontos a desenvolver oralmente • Relacionar os feeds da Adafruit IO com os tópicos MQTT • Mostrar a construção de um dashboard por arrastar e largar • Comparar Adafruit IO com ThingSpeak quanto a facilidade e MQTT
NOTAS DO PROFESSOR 📖 Blynk: controlar a partir do telemóvel A Blynk distingue-se por permitir construir uma interface móvel para o projeto sem programar a app, ligando botões e gráficos a variáveis do dispositivo. É ideal quando o objetivo é controlar o sistema a partir do smartphone, por exemplo ligar um relé ou ver uma leitura à distância. Convém referir que o plano gratuito é limitado, o que condiciona projetos maiores. 🗣️ Pontos a desenvolver oralmente • Mostrar a montagem de uma UI por arrastar e largar na Blynk • Dar um exemplo de controlo remoto de um atuador pelo telemóvel • Comparar a abordagem app-first da Blynk com os dashboards web
NOTAS DO PROFESSOR 📖 Home Assistant: a nuvem em casa O Home Assistant inverte a lógica anterior: em vez de depender de serviços cloud externos, corre na própria casa, tipicamente num Raspberry Pi, dando controlo e privacidade totais. Suporta MQTT, Zigbee, Z-Wave e milhares de integrações, sendo o padrão de facto entre entusiastas. É a opção certa para quem não quer que os seus dados saiam de casa. 🗣️ Pontos a desenvolver oralmente • Discutir as vantagens de privacidade do self-hosting face à cloud • Explicar o papel das automações no Home Assistant • Referir a necessidade de hardware dedicado, como um Raspberry Pi
NOTAS DO PROFESSOR 📖 Deep sleep: autonomia de meses ou anos Para dispositivos alimentados a bateria, o consumo é decisivo: em uso normal o ESP32 esgota uma bateria em horas, mas em deep sleep dura anos. O padrão é acordar, ler o sensor, enviar o dado e voltar a dormir, em vez de manter o ciclo loop sempre ativo. É importante perceber que ao acordar o ESP32 reinicia o setup, mantendo apenas a memória RTC. 🗣️ Pontos a desenvolver oralmente • Comparar a duração da bateria em uso normal e em deep sleep • Explicar porque o programa reinicia do setup após acordar • Discutir o compromisso entre frequência de leituras e autonomia
NOTAS DO PROFESSOR 📖 Porque a segurança IoT é crítica Os dispositivos IoT são alvos fáceis: passwords por omissão, comunicação sem encriptação e firmware desatualizado abrem a porta a ataques. O caso da botnet Mirai, que recrutou milhões de aparelhos IoT, mostra que um dispositivo inseguro não é só um risco para o dono, mas para toda a internet. Esta consciência deve acompanhar qualquer projeto, mesmo de aprendizagem. 🗣️ Pontos a desenvolver oralmente • Explicar como uma password por omissão é explorada num ataque • Contar o caso Mirai e o seu impacto à escala global • Sublinhar a responsabilidade de quem coloca dispositivos na rede
NOTAS DO PROFESSOR 📖 Boas práticas de segurança IoT Proteger um sistema IoT passa por medidas concretas e cumulativas: usar TLS para encriptar a comunicação, credenciais únicas por dispositivo, atualizações remotas e isolar a rede IoT numa VLAN dedicada. O exemplo mostra como passar de MQTT em texto simples para MQTTS com certificado, mudando também a porta. A ideia-chave é que segurança se constrói por camadas, não com uma única medida. 🗣️ Pontos a desenvolver oralmente • Explicar o que muda ao passar da porta 1883 para a 8883 com TLS • Justificar credenciais únicas por dispositivo em vez de partilhadas • Discutir o valor de isolar os dispositivos IoT numa VLAN própria
NOTAS DO PROFESSOR 📖 Atualizar firmware sem fios (OTA) Depois do primeiro carregamento por USB, o ESP32 pode receber novas versões de firmware pela rede WiFi, surgindo no IDE como uma porta de rede. Isto é essencial em produção, porque na vida real os dispositivos ficam instalados em locais de difícil acesso. Sem OTA, corrigir um bug obrigaria a recolher fisicamente cada aparelho. 🗣️ Pontos a desenvolver oralmente • Explicar como o dispositivo passa a aparecer como porta de rede • Sublinhar a importância de proteger o OTA com password • Dar um exemplo real em que aceder fisicamente seria impraticável
NOTAS DO PROFESSOR 📖 Síntese do percurso IoT Este resumo recapitula a cadeia completa: do dispositivo ESP32 às formas de comunicação HTTP e MQTT, dos dashboards cloud ao Home Assistant, passando pela autonomia e pela segurança. A mensagem central é que um projeto IoT competente combina hardware barato, um protocolo adequado e uma plataforma de visualização. Convém reforçar que segurança e gestão de energia não são extras, mas requisitos. 🗣️ Pontos a desenvolver oralmente • Pedir aos formandos para desenharem a arquitetura de um projeto próprio • Rever a escolha entre HTTP e MQTT conforme o caso de uso • Relembrar que segurança e consumo devem ser pensados desde o início