O painel do mar sobre a mesa de madeira, entre um toca-discos e um amplificador, com a tela mostrando as condições de Copacabana

Minha esposa nada no mar. De vez em quando ela chega em Copacabana e descobre que o mar está agitado demais, ou começa a chover forte no meio do treino e ela precisa sair da água e voltar pra casa. Eu tinha algumas placas ESP32-C3 Super Mini sobrando de projetos de automação da casa, e há muito tempo queria projetar alguma coisa que existisse fora da tela do computador. Juntei as duas coisas e saiu isso aí da foto: um painel de mesa que mostra as condições do mar e do tempo em Copacabana. Liga na tomada e pronto.

Eu me apresento como product designer há uns treze anos. Esse título já significou exclusivamente quem projeta produtos físicos, e hoje serve pra quem projeta software também, que sempre foi o meu caso. Nunca imaginei que teria a chance de fechar esse círculo e projetar um produto com componentes eletrônicos e firmware próprio, muito menos sozinho, em casa, sem saber soldar direito. O que mudou foi ter o Claude do outro lado da conversa. Esse post é sobre como foi, incluindo o que deu errado.

O que o painel faz

Do ponto de vista de quem usa, nada. Não tem botão, não tem app, não tem configuração. Ao ligar, ele conecta no Wi-Fi e mostra:

  • O lugar, a condição do céu e a hora.
  • A altura das ondas, com a direção de onde vêm e o período em segundos.
  • Temperatura da água e do ar, vento e índice UV.
  • A curva da maré das 0h às 24h, com uma bolinha na hora atual e a próxima virada (“baixa às 18h”).
A tela do painel pixel por pixel: Copacabana, nublado, 13:15, ondas de 1,2 m de SSE com 9,6 s, água 24,4°, ar 23,7°, vento 7 km/h, UV 6, curva da maré com baixa às 18h
A tela, pixel por pixel. O aparelho desenha exatamente isso.

Os dados vêm do Open-Meteo, uma API aberta que não pede cadastro nem chave. São dados de modelo numérico, e não de uma boia na praia: o ponto consultado fica no mar, uns 7 km ao sul da areia, e a maré também é calculada. Não substitui a tábua da Marinha, mas pra decidir se vale descer até a praia, funciona muito bem.

A tela é de papel eletrônico (e-ink), de 2,9 polegadas, 296 x 128 pixels, preto e branco. Os dados são buscados a cada 30 minutos, e o relógio é redesenhado a cada minuto sem piscar. De vez em quando a tela faz uma limpeza completa, piscando por uns dois segundos pra tirar a “sombra” que os números anteriores deixam, igual acontece no Kindle.

Por que não abrir um app

Alguém pode perguntar por que minha esposa não abre o Surfguru antes de sair de casa. Lá tem muito mais informação do que nessa telinha de 2,9 polegadas, e é de graça. É verdade, e o painel mostra menos dados de propósito. A informação é só uma parte da experiência. O resto vem de umas qualidades que um app não tem:

  • Faz uma coisa só. Não tem notificação, não tem feed, não tem propaganda, não tem outro app a um toque de distância.
  • Está sempre ligado e sempre à vista. Dá pra saber se o mar está bom passando pela sala, sem pegar o celular, desbloquear e abrir alguma coisa.
  • É robusto. Liga na tomada e fica meses mostrando a mesma tela, sem atualização de app nem login que expira.
  • Faz parte da casa. É um objeto na mesa, com cara de rádio antigo, que combina com o toca-discos ao lado. Um app não decora nada.

Esse tipo de produto tem até nome, calm technology, um termo de Mark Weiser e John Seely Brown dos anos 1990 que a Amber Case transformou numa lista de princípios: tecnologia que informa sem exigir atenção. É a diferença entre um relógio de parede e o relógio do celular. Os dois dão a hora, mas só um deles você consulta sem interromper o que estava fazendo.

Começou num emulador

A primeira mensagem que mandei pro Claude foi essa:

Eu tenho uns ESP32-C3 Super Mini aqui. Queria fazer um aparelhinho que simplesmente mostra condições atuais do mar e clima na praia de Copacabana, usando dados reais e atualizados, e exibir em uma tela. Não precisa de interação nenhuma, só exibir os dados ao ligar o aparelho.

A resposta foi bem mais do que eu esperava. Além de dizer que dava pra fazer, ele sugeriu o Open-Meteo como fonte, comparou uma tela colorida com uma de papel eletrônico, e montou um emulador no navegador com as duas telas lado a lado, desenhadas com os dados daquele momento. Eu ainda não tinha comprado nada e já estava olhando pra tela final.

Isso definiu o jeito de trabalhar no projeto inteiro: simular antes de comprar. Tela, fontes e layout foram decididos no emulador, e o firmware que roda na placa reproduz os mesmos pixels. Quando o hardware chegou do AliExpress, a parte visual já estava pronta.

Foi no emulador que rolou a primeira rodada boa de ida e volta, sobre as fontes. O Claude tinha colocado uma Helvetica em bitmap, e eu pedi pixel fonts de verdade, desenhadas pra uma grade de pixels. Ele mediu a grade de cada exemplo que eu mandei, desenhou os acentos que faltavam, e eu apliquei a mesma regra que uso em interfaces: no máximo três tamanhos de fonte, com o número grande como exceção. Ficou Pixel Operator no texto e Jersey 15 nos números, e cada pixel da fonte cai exatamente num pixel da tela.

As peças

A lista de componentes é curta:

  • Uma ESP32-C3 Super Mini, a plaquinha genérica de uns 15 reais que faz Wi-Fi, busca os dados e desenha a tela.
  • Uma tela WeAct Studio de 2,9”, de papel eletrônico.
  • O cabo de 8 fios que vem com a tela, encaixado em barras de pinos soldadas na placa.
  • Uma caixa impressa em 3D, em três peças.
  • Um cabo USB-C e um carregador de celular qualquer.
Diagrama da ligação dos oito fios entre a tela e a placa ESP32-C3 Super Mini
Os oito fios entre a tela e a placa.

O firmware roda no ESPHome, que eu já usava em casa junto com o Home Assistant. A configuração é um arquivo YAML, com o desenho da tela num bloco de C++ dentro dele. O ESPHome roda num Raspberry Pi aqui de casa, que compila o firmware e manda pra placa pela rede. Depois disso o painel não depende de mais nada: tudo que ele faz, roda na placa.

Diagrama do caminho dos dados: as APIs do Open-Meteo chegam pelo roteador até a placa, que desenha na tela
O caminho dos dados.

Com os componentes na mão, pedi um guia de montagem com etapas, diagramas e o arquivo do ESPHome, que o Claude compilou no ambiente dele antes de me entregar. Guarde essa informação, porque ela vai importar daqui a pouco.

A noite da primeira gravação

Essa foi a parte com mais idas e voltas, e a que mais me ensinou sobre trabalhar com IA em hardware. Numa noite sentei pra gravar o firmware pela primeira vez, e deu errado de quatro jeitos diferentes, um atrás do outro:

  1. A porta da placa ficava piscando na lista do Chrome. Era só o modo de gravação, resolvido segurando dois botõezinhos da placa.
  2. Gravou, mas a tela não mudou. Primeiro erro do Claude: o firmware só desenhava alguma coisa quando os dados chegavam, então qualquer falha deixava a tela em branco, sem nenhuma pista. Ele passou a desenhar “buscando dados…” assim que liga, o que de quebra testa se os fios estão certos.
  3. O log mostrava o Wi-Fi caindo o tempo todo. Segundo erro: pra contornar um defeito conhecido da Super Mini, o Claude tinha reduzido a potência do rádio, e reduziu demais pra distância até o meu roteador.
  4. Conectou, e a placa reiniciava quatro segundos depois de chamar a API.
A tela de papel eletrônico solta sobre a base de corte, mostrando Copacabana e a mensagem buscando dados sobreposta à mensagem de erro
A tela de espera, com a mensagem de erro por trás. Pelo menos os fios estavam certos.

No meio disso teve a minha parte da confusão. Eu estava gravando versões antigas do firmware sem perceber:

Peraí, eu não fiz nada com o yaml que vc mandou. Eu não entendo o que é o Yaml e o que é o bin que eu baixo lá do ESPHome

A partir daí mudei o combinado: em vez de me mandar caçar linhas no código, ele passou a atualizar o arquivo inteiro, pra eu só copiar e colar no ESPHome. Parece bobagem, mas foi um dos ajustes mais importantes do projeto. Quando eu tinha que editar uma linha específica de um arquivo que eu não entendia, eu errava.

O quarto problema foi o mais difícil. A resposta da API chegava vazia, e a causa era que o Claude tinha testado tudo na versão mais nova do ESPHome, enquanto a minha instalação era de meses antes, de uma versão que não lia o formato de resposta que o Open-Meteo usa. Ele foi no código-fonte das duas versões pra confirmar a diferença, eu atualizei, e tarde da noite a tela carregou dados pela primeira vez, com a sombra do texto anterior por trás dos números.

A tela na primeira vez que carregou dados: ondas de 1,3 m, água 24,5°, ar 21,7°, com a sombra da mensagem de erro por trás dos números
Funcionou, com sombra.

A caixa

Eu queria uma caixa no estilo Dieter Rams, inspirada no Braun DN40, aquele rádio-relógio com perfil de cunha. O Claude errou o perfil duas vezes, porque estava interpretando fotos em perspectiva:

Eu não sei de onde você tirou que o DN40 tem esse vale assim. O perfil dele é reto, olha a imagem.

Acertou na terceira, quando mandei uma foto exatamente de lado. A mesma coisa aconteceu com o conector da tela, que ele desenhou saindo pra fora da placa até ver uma foto de perfil. Aprendi que referência visual pra IA tem que ser foto de lado ou de frente, e não foto em perspectiva.

Tirei 26 medidas com paquímetro (da tela, da placa, do conector e do plugue) e preenchi num formulário que ele colocou no guia. Com isso ele modelou a caixa em Python e conferiu por cálculo que nada encostava em nada.

Trecho do formulário de medidas do guia, com o diagrama da ESP32-C3 Super Mini vista de cima e de lado e os campos em milímetros
O formulário do guia com as medidas que ele precisava pra modelar a caixa, e como medir cada componente.
Perfil esquemático da caixa mostrando a frente, o corpo e a gaveta da placa
O perfil da caixa, tirado do contorno real do modelo. A frente à direita, a gaveta da placa embaixo, atrás.

A caixa tem três peças, sem parafuso e sem cola. O corpo, com uma lateral fechada e a outra aberta, é impresso deitado, pra não precisar de suporte. Uma tampa fecha a lateral aberta com quatro abas que estalam em canais internos. A frente (preta no modelo final, como no DN40; a minha, da primeira impressão, saiu toda branca) segura a tela por quatro pinos e desliza em trilhos no corpo. A placa entra deslizando numa gaveta, com o USB-C apontando pra trás.

O interior da caixa visto pela lateral aberta, com os oito fios coloridos descendo até a placa encaixada na gaveta
A placa entra deslizando e fica presa sem cola.

A primeira impressão teve problemas: a frente entrou tão justa que abriu a borda do corpo, a tampa ficou frouxa e a placa ficou no fundo, fora do alcance da mão. Colei tudo e fui usar. Mas como eu quero imprimir mais unidades sem precisar lixar nem colar nada, entrou a parte de calibrar:

Lembra que estou usando um bico 0.8 na impressora, então tem que considerar que a forma final do objeto acaba ficando mais distorcida do que o modelo 3D. Podemos fazer umas impressões de teste

Em vez de imprimir a caixa inteira de novo, o Claude desenhou peças de teste de poucos gramas pra cada encaixe. Eu sugeri testar fatias maiores direto no corpo que eu já tinha, o que economizou plástico e tempo. E o resultado mudou depois que as peças esfriaram: a que encaixava melhor quente não era a melhor fria. No fim ficou uma folga que desliza, com uns ressaltos minúsculos em três pontos dos trilhos pra segurar.

Peças de teste impressas em PLA branco espalhadas sobre um notebook: fatias do corpo, tampas pequenas, uma frente de teste com a tela encaixada e o corpo novo da caixa
Peças de teste de poucos gramas pra acertar os encaixes com bico de 0,8 mm, e o corpo novo ao fundo.

Quem fez o quê

“Fiz com IA” pode significar muita coisa, então vou ser específico.

Eu comprei os componentes, soldei, liguei os fios, gravei o firmware, colei os logs, tirei as medidas, imprimi e montei tudo, avaliei cada versão da tela e da caixa e defini as regras de design. Também corrigi o Claude toda vez que ele errou forma ou interpretação, e dei alguns palpites de engenharia, como testar fatias no corpo existente.

O Claude propôs a arquitetura e a fonte de dados, escreveu todo o código (emulador, firmwares, geradores das fontes e da caixa), diagnosticou os bugs pelos logs, escreveu o guia, modelou a caixa e desenhou as peças de teste.

E ele errou um bocado: potência do Wi-Fi, tela em branco sem dados, firmware testado numa versão diferente da minha, perfil do DN40, conector da tela, placa fora de alcance na primeira caixa, folgas que não consideravam o bico grosso da impressora. A diferença é que nenhum desses erros ficou escondido. Quando eu apontava, ele corrigia e dizia o que tinha errado.

A versão pra presente

O painel original está na minha mesa. O próximo lote é pras amigas que nadam com a minha esposa, e aí a conversa mudou de assunto: como entregar isso pra alguém que não vai abrir um terminal na vida?

A versão pra presente tem um firmware separado. Na primeira vez que liga, a placa cria a própria rede Wi-Fi e a tela mostra um QR code que conecta o celular nela. Uma página abre sozinha pra escolher a rede da casa, e outro QR code leva a uma página onde a pessoa escreve o bairro ou a cidade. Se não tiver mar por perto, a tela vira um painel de tempo. Se o roteador mudar, a tela volta sozinha pro modo de configuração. E nada disso depende do Home Assistant, porque quem recebe não tem um.

Tela de configuração de Wi-Fi da versão pra presente, com um QR code
A tela de configuração da versão pra presente. Aponta o celular e conecta.

O que eu aprendi

Algumas coisas que eu levaria pro próximo projeto de hardware com IA:

  • Simule antes de comprar. O emulador com dados reais resolveu tela, fontes e layout antes de eu gastar um real.
  • Mande os logs. Todos os bugs de firmware foram resolvidos a partir de logs que eu colava na conversa. Sem eles, as hipóteses do Claude estavam erradas.
  • O ambiente de teste da IA não é o seu. Hoje a primeira coisa que eu informo é a versão de tudo que tenho instalado.
  • Impressão 3D precisa de teste físico. A folga que estava certa no modelo saiu errada na impressora com bico de 0,8 mm.
  • Diga como você quer receber as coisas. A conversa andou muito melhor depois que eu pedi arquivos inteiros em vez de instruções pra editar linhas. A IA não sabe o quanto você sabe até você dizer.

Passei treze anos projetando software. Esse é o primeiro produto que eu posso segurar na mão, e a parte mais legal não foi o Claude escrever o código. Foi poder discutir perfil de caixa, folga de encaixe e potência de rádio com alguém que respondia na hora, errava, assumia o erro e tentava de novo, até o objeto ficar do jeito que eu queria.

P.S.: Se você quiser montar o seu, a lista de componentes está aí em cima e o ESPHome tem documentação muito boa pra essa tela. Me conta se fizer 😉