TL;DR: Construí um controlador de temperatura profissional (ESP32, PID, auto-tune, presets, gráfico em LCD, recuperação de queda de energia, integração com cloud) em um dia. Algo que levaria um mês. O diferencial não foi a ferramenta. Foi o repertório pra saber o que pedir — e perceber quando algo estava errado sem precisar olhar o código.
O experimento
Eu tinha dois problemas de temperatura em casa. Um forno elétrico de cozinha sem controle preciso, e um aquecedor PTC que uso pra secar filamento de impressão 3D. Os dois precisam da mesma coisa: manter uma temperatura estável por um período. O que muda são os parâmetros.
Poderia ter comprado um controlador pronto. Mas aí não teria aprendido nada — e o experimento que eu queria fazer era outro.
A abordagem foi intencional: usei o Claude Code como par de programação e evitei ao máximo escrever ou até ler o código gerado. A ideia era testar o limite de “até onde a IA consegue ir sozinha, se eu só descrever o que quero?”.
O resultado ficou pronto em um dia. Mas a sensação que ficou não foi só sobre velocidade.
O que saiu disso
Antes de falar sobre o processo, deixa eu mostrar o que o bicho faz — porque o ponto aqui depende de entender que não era um projeto trivial.
Hardware
- ESP32 como cérebro
- DS18B20 como sensor de temperatura (digital, OneWire, 12-bit — 0.0625°C de resolução)
- Módulo relê controlando a resistência do forno
- LCD 20×4 I2C como display
- Rotary encoder com botão como única interface física
- Case impresso em 3D (modelado no Fusion)
Software
- 3 modos de controle: histerese (on/off), PID on/off, e PID com janela temporal
- Auto-tune: calibração automática do PID por relay feedback (Tyreus-Luyben)
- 10 presets de equipamento: salva Kp, Ki, Kd e janela por aquecedor — troco do forno pro PTC em 2 clicks
- Timer de até 24h com desligamento automático
- Gráfico de temperatura direto no LCD, com 7 escalas de tempo (de 10 minutos a 12 horas)
- Recuperação de queda de energia: se a luz cai, ao religar ele pergunta se quer continuar de onde parou
- Controle remoto via Blynk: monitoramento e ajuste pelo celular
- Sistema de segurança: detecção de sobretemperatura, falha de sensor e até relê mecanicamente travado
Tudo isso funcionando 100% offline. O WiFi é opcional e nunca bloqueia o controle local.
A interface — um encoder e 4 telas
A navegação inteira é feita com um rotary encoder: gira pra navegar, click pra selecionar, click longo pra voltar. Três níveis: tela → item → edição. Parece pouco, mas é surpreendentemente ergonômico quando bem implementado.
Home
75.3°C 01:05:30 ON
SP: 80.0 Histerese
Timer: 01:30
>[Iniciar] Forno1Gráfico
95 -▇▅▃▂▁▁▂▃▅▇▇████
>80 ▁▂▃▅▇████████▇▅▃
65 ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
0 [10m]Sim, um gráfico de barras num LCD de caractere. 16 colunas, 24 pixels de resolução vertical usando custom characters. Uma amostra a cada 30 segundos, até 12 horas de histórico.
As outras duas telas são configurações (com itens que mudam conforme o modo ativo) e auto-tune (que mostra progresso em tempo real, com ETA e parâmetros sugeridos no final).
O PID — e por que ele é diferente
Se você nunca mexeu com controle PID, a versão curta: é um algoritmo que calcula “quanto” aquecer com base em 3 fatores — o erro atual (P), o erro acumulado (I), e a velocidade de mudança do erro (D). O resultado é um valor de 0 a 100% de “potência”.
O problema é que um relê não tem “50% de potência”. Ele liga ou desliga. Ponto.
A solução clássica é a janela temporal: dentro de uma janela de 10 segundos, se o PID diz 65%, o relê fica ligado 6.5s e desligado 3.5s.
Mas a implementação ingênua tem um problema sutil: se a cada 2 segundos o PID recalcula e muda o output, o relê pode ficar “gaguejando” — ligando e desligando no meio da janela porque os números mudaram. Isso estraga o relê e não controla nada.
A solução que implementamos foi elegante: em vez de uma janela fixa com início e fim, o sistema conta quanto tempo o relê está no estado atual. Se está ligado há mais tempo do que deveria → desliga e reseta o contador. Se está desligado há mais tempo do que deveria → liga e reseta. O relê só muda de estado quando o tempo “vence”. Sem gagueira.
E aqui tá o primeiro ponto que interessa pro experimento. O código da janela “ingênua” estava correto. Fazia exatamente o que eu pedi. Mas eu sabia, por experiência, que ia dar problema. Nenhum teste unitário ia flagrar isso — porque no papel funcionava. Só deu pra perceber porque eu já tinha visto isso dar errado antes.
Auto-tune — quando o forno aprende sozinho
O auto-tune usa o método relay feedback com constantes Tyreus-Luyben. Na prática:
- Liga o relê até passar do setpoint
- Desliga e deixa a temperatura cair abaixo do setpoint
- Liga de novo
- Repete 5 vezes, medindo a amplitude e o período de cada oscilação
- Calcula os parâmetros PID ideais com base na média dos ciclos
As constantes Tyreus-Luyben (Kp = 0.33 × Ku) são mais conservadoras que o Ziegler-Nichols clássico (Kp = 0.6 × Ku). O resultado é um sistema que demora um pouquinho mais pra estabilizar, mas com muito menos overshoot. Pra forno, overshoot significa comida queimada.
A primeira tentativa usava uma biblioteca externa que funcionava na teoria, mas na prática entrava em loop. Voltei pro código custom, incorporei o que a biblioteca fazia de bom (média de ciclos, reset de min/max por semi-ciclo, constantes Tyreus-Luyben) e descartei o resto. Esse tipo de decisão — trocar biblioteca por custom, escolher Tyreus-Luyben em vez de Ziegler-Nichols — não vem do prompt. Vem de já ter quebrado a cara antes.
Segurança — porque forno não é brinquedo
Esse foi um dos pontos que mais me preocupou. O sistema tem 3 níveis de proteção:
- Sobretemperatura (>= 100°C): relê desliga imediatamente, sistema desativado, tela de erro com backlight piscando
- Falha do sensor (sem leitura por 5s): mesma coisa — desliga tudo
- Relê travado: se depois de desligar o relê a temperatura continua subindo 10°C acima do ponto de corte, o firmware conclui que o contato pode estar mecanicamente grudado. Executa 10 ciclos rápidos de on/off pra tentar desgrudar e mostra erro
Além disso: boot seguro (relê sempre inicia desligado), watchdog de 8 segundos, e WiFi que nunca bloqueia o controle local.
Recuperação de queda de energia
Se a luz cai enquanto o forno está operando, ao religar o ESP32 mostra:
Ciclo interrompido!
Continuar? 18s
[SIM] NAOSIM vem pré-selecionado. Se ninguém apertar nada em 20 segundos, ele retoma sozinho — inclusive o timer continua de onde parou, não reinicia.
O estado é salvo na memória não-volátil (NVS) a cada 30 segundos e em cada mudança de estado. Então mesmo uma queda brusca perde no máximo 30 segundos de progresso.
Agora a parte que importa: o que a IA trouxe e o que não trouxe
No começo, deu pra ser bem superficial nas instruções — e ainda assim funcionava. O esqueleto do firmware (10 arquivos, ~2500 linhas) saiu em poucas horas, com uma arquitetura de módulos que eu teria chegado sozinho, mas em muito mais tempo.
Mas conforme fui iterando, isso parou de ser suficiente. Passei a refinar mais, exigir uso de bibliotecas em vez de implementação “na unha”, descrever comportamentos com mais cuidado e, em alguns pontos críticos, usar BDD (Given/When/Then) pra guiar a lógica.
Curiosamente, esses trechos mais estruturados foram talvez 5% do que foi gerado — e consumiram uns 30% do tempo.
Teve um momento que me chamou atenção: o Claude comentou que uma classe não deveria conhecer a outra por questões de acoplamento. Foi o tipo de coisa que dá uma tranquilidade inesperada — como quando você percebe que alguém pensou em algo que normalmente passaria batido.
O que a IA fez bem
- Velocidade de prototipação absurda: horas em vez de semanas
- Modularização: sugeriu uma arquitetura limpa sem eu pedir
- Bibliotecas: quando perguntei sobre usar ESP32Encoder com PCNT hardware em vez de implementar quadratura na mão, não só concordou como explicou por quê
- Questionamento de decisões: quando pedi pra IA explicar antes de implementar, evitou mais bugs do que qualquer linter
O que precisou de repertório humano
- Sentir que o encoder estava “estranho”: nenhum log ia me dizer isso. Eu girei, senti a fricção, e sabia que tinha algo errado no debounce
- A janela do PID gaguejando: o código estava correto. Mas eu sabia que ia dar problema
- O auto-tune que não parava: a biblioteca funcionava no papel, travava na prática
- UX do encoder: qual tela aparece primeiro ao clicar, pra onde o cursor vai, o que o long press faz dependendo do contexto — tudo isso veio de testar e sentir que “isso aqui tá chato de usar”
O ponto
Saber o que pedir, perceber quando algo estava indo na direção errada mesmo sem olhar o código, sentir que uma decisão de arquitetura ia cobrar caro depois — isso não veio da ferramenta.
Veio de repertório.
A IA foi um diferencial claro. Mas sem repertório pra questionar o que ela entrega, vira só uma forma mais rápida de errar.
Um iniciante conseguiria fazer o mesmo? Acho que dificilmente. Não por capacidade, mas porque tem coisas que só fazem sentido depois que você já viu dar errado algumas vezes. Um iniciante não sentiria a fricção do encoder, não perceberia o gaguejo do relê, não saberia que Tyreus-Luyben > Ziegler-Nichols pra sistemas térmicos.
A IA hoje cozinha muito bem. Mas alguém ainda precisa saber o ponto do sal.
Números
- Tempo total: ~1 dia de trabalho focado
- Linhas de código: ~2500 (10 arquivos)
- Custo com IA: ~$30 de API
- Custo do hardware: ~R$80 (ESP32 + LCD + encoder + relê + sensor)
- RAM usada: 15.7% dos 320KB
- Flash usada: 61.8% dos 1.3MB
Quer replicar?
O código está no GitHub: esp32-pid-thermostat
O README tem pinagem completa, diagrama de ligações, modos de controle, navegação das telas e troubleshooting. É plug and play se você tiver o hardware.
E fica a pergunta que eu ainda não fechei:
Dá pra sentir fricção sem experiência prévia?
Porque foi isso que guiou as melhores decisões aqui. E é justamente isso que a IA não trouxe — ela trouxe velocidade pra agir em cima disso.
Talvez a IA não esteja substituindo experiência. Talvez esteja mudando completamente o que significa começar.
O que você acha?